[HTTPS-Everywhere] Https Everywhere for Internet Explorer possible

[Peter Eckersley]

match_rule is deprecated; I don't think it needs to be implemented anymore,
and the implementations can be removed from the Chrome and FF ports.

Before the <target host=""> mechanism existed, match_rule was a way to improve
performance when every <rule> was tested against every outgoing URL (there
were many fewer rulesets back then!).  The match_rule would be tested first,
and only if it matched would the <rule>s in that <ruleset> be applied.

On Tue, Apr 24, 2012 at 04:34:32PM -0700, Julien Sobrier wrote:
> Hello,
> the document does not define the attribute "match_rule". This attribute
> seem to be used differently in the Chrome version and ion the Firefox
> version.
> 
> For example, in Chrome, "match_rule" is NOT used for GoogleSearch.xml or
> GoogleAPIs.xml. But is used with Firefox in the GoogleSearch ruleset.
> 
> If the Chrome logic is applied for Firefox,
> target="translate.google.com" would never be used because GoogleSearch
> has a match_rule="http:.*google\.". This is unless the order in which
> rules are loaded, and processed matters. But this is not specified in
> your document.
> 
> So, I have 2 questions:
> * do the name of the .xml file matters, meaning rules have to be loaded
> and processed in alphabetical order?
> * why do you need the "match_rule" as a final match, and not use only
> the "target" tag?
> * why the difference between Firefox and Chrome regarding the match_rule
> in the "Google APIs" attribute?
> 
> 
> Thank you
> Julien Sobrier
> 
> 
> On 4/3/2012 6:01 PM, Peter Eckersley wrote:
> > These are great questions.  
> > 
> > What you probably want to start with is the documentation for rulesets, which
> > is here:
> > 
> > https://www.eff.org/https-everywhere/rulesets
> > 
> > You can also look at the two existing implementations.  The chromium
> > implementation is simpler and probably the better one to start with.  The
> > firefox implementation is more canonical and featureful, but is written
> > against a much messier API.  They both live in the
> > git://gitweb.torproject.org/https-everywhere.git repository; start with the
> > README file.
> > 
> > We don't have a test suite for HTTPS Everywhere
> > at the moment, though building one is one of our proposed GSOC projects
> > (https://mail1.eff.org/pipermail/https-everywhere/2012-April/001340.html)
> > 
> > A backup "acceptance testing" method would be to take a range of sites that are rewritten
> > (Wikipedia, twitter, google, etc) and use Wireshark to observe the requests
> > that IE + your code is making over the network when you use those sites.
> > If any of the requests are HTTP and contradict a ruleset, that's a problem :)
> > 
> > 
> > On Sat, Mar 31, 2012 at 08:24:09PM -0700, Julien Sobrier wrote:
> >> Sure, I'll do that. Do you have any additional document I could use,
> >> like testing procedure, test cases, unit tests, etc.
> >>
> >> Julien
> >>
> >> On 3/31/2012 6:38 PM, Peter Eckersley wrote:
> >>> On Fri, Mar 30, 2012 at 03:01:39PM -0700, Julien Sobrier wrote:
> >>>>
> >>>> I am very interesting in providing Https Everywhere for Internet
> >>>> Explorer, without the secure cookie n the first versions. Is it possible
> >>>> for me to collaborate with the EFF on this release? I can support IE6 on
> >>>> Windows XP SP3 to IE 9 on Windows 7.
> >>>
> >>> Hi Julien, 
> >>>
> >>> HTTPS Everywhere is free/open source software, and we're always happy to
> >>> collaborate with people who want to make improvements or ports.  If you make
> >>> progress on an IE port, please send us git pull requests and we'll merge them
> >>> into the main source tree.
> > 
> 
> 

-- 
Peter Eckersley                            pde at eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993