[HTTPS-Everywhere] Https Everywhere for Internet Explorer possible

[Julien Sobrier]

Thank you for the details.

Julien

On 4/24/2012 5:42 PM, Peter Eckersley wrote:
> 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.
>>>
>>
>>
>