<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div>What is strange however is that even though the changelog says this is enabled now, it actually isnt, at least for me.</div><div><br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">So you should probably wait before enabling the disabling of mixed content rulesets on Firefox.</div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif;
background-color: transparent; font-style: normal;"><br></div> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> Peter Eckersley <pde@eff.org><br> <b><span style="font-weight: bold;">To:</span></b> Fruitless Creek <fruitlesscreek@rocketmail.com> <br><b><span style="font-weight: bold;">Cc:</span></b> "mezzanine@Safe-mail.net" <mezzanine@Safe-mail.net>; "https-everywhere@eff.org" <https-everywhere@eff.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Saturday, October 20, 2012 9:58 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [HTTPS-Everywhere] Clarifying the process for testing rulesets<br> </font> </div> <br>I think this just increases the urgency of working on
this:<br><br><a href="https://trac.torproject.org/projects/tor/ticket/6975" target="_blank">https://trac.torproject.org/projects/tor/ticket/6975</a><br><br>I will write a patch so that the Firefox version knows to disable mixed<br>content rules on version 18+.<br><br>On Sat, Oct 20, 2012 at 05:32:08AM -0700, Fruitless Creek wrote:<br>> Related?<br>> <br>> "Disable insecure content loading on HTTPS pages"<br>> <br>> <a href="https://www.mozilla.org/en-US/firefox/18.0a2/auroranotes/" target="_blank">https://www.mozilla.org/en-US/firefox/18.0a2/auroranotes/</a><br>> <br>> <br>> <br>> <br>> ________________________________<br>> From: Peter Eckersley <<a ymailto="mailto:pde@eff.org" href="mailto:pde@eff.org">pde@eff.org</a>><br>> To: <a ymailto="mailto:mezzanine@Safe-mail.net" href="mailto:mezzanine@Safe-mail.net">mezzanine@Safe-mail.net</a> <br>> Cc: <a ymailto="mailto:https-everywhere@eff.org"
href="mailto:https-everywhere@eff.org">https-everywhere@eff.org</a> <br>> Sent: Wednesday, October 17, 2012 11:53 PM<br>> Subject: Re: [HTTPS-Everywhere] Clarifying the process for testing rulesets<br>> <br>> On Thu, Oct 11, 2012 at 03:42:34AM -0400, <a ymailto="mailto:mezzanine@Safe-mail.net" href="mailto:mezzanine@Safe-mail.net">mezzanine@Safe-mail.net</a> wrote:<br>> > The page at <a href="https://www.eff.org/https-everywhere/rulesets" target="_blank">https://www.eff.org/https-everywhere/rulesets</a> talks about<br>> > how to create rulesets and also touches upon the step of testing a<br>> > ruleset. Even so, some aspects of how to test a ruleset are unclear.<br>> > For example, it may be the case where a specific domain or subdomain<br>> > appears to support HTTPS on more than one page, but with the question<br>> > as to whether each and every page under the domain supports HTTPS.<br>> >
Should the tester try to visit and examine almost every page under the<br>> > site before submitting the ruleset? <br>> <br>> This is clearly not possible in many cases. Having said that, the more<br>> complicated a site becomes, the more you would ideally want to have tested it<br>> extensively. A good heuristic might be that if a site supports accounts, the<br>> ruleset author should make and use one, and try a bunch of the site's features<br>> to ensure that things aren't exploding.<br>> <br>> > For that matter, how much testing and evaluation is performed on a ruleset<br>> > after it is submitted? Among other things, is it the case that a new ruleset<br>> > may be added to a development release of HTTPS Everywhere before being added<br>> > to a release version? <br>> <br>> This is almost always the case, yes, although occasionally things slip through<br>> in git. With the
3.0 release, it seems as though we caught and fixed a lot of<br>> bugs in the new rulesets with the 3.0development releases, but another big<br>> wave of reports (more per unit time, fewer total, thus far) came in after the<br>> 3.0 release went stable.<br>> <br>> The other testing that occurs at present is the syntax sanity checks that are<br>> used if you build the extension. There are some cert-validity test scripts in<br>> existence, but I'm not sure if any of them know about transvalidity (missing<br>> intermediate CA certificates which browsers will cache, causing a cert to<br>> switch from invalid to valid) yet, and none are run automatically.<br>> <br>> We have plans to try and implement/deploy an automated ruleset testing framework,<br>> possibly based on <a href="https://github.com/hiviah/https-everywhere-checker" target="_blank">https://github.com/hiviah/https-everywhere-checker</a>,<br>> possibly
using Selenium or Marionette, but none of that is close to ready.<br>> <br>> > It is one's presumption that it is sufficient to test<br>> > a ruleset prior to submission by using it with the HTTPS Everywhere<br>> > extension and the Firefox browser, and that it is not necessary to use<br>> > the Google Chrome browser, even though the HTTPS Everywhere extension<br>> > is available in alpha form for the Chrome browser. <br>> <br>> Interesting point. Currenly, we have one major difference between the Chrome<br>> and Firefox platforms, which is that rulesets creating mixed content are okay<br>> on Firefox, but sometimes quite problematic on Chrome:<br>> <br>> <a href="https://trac.torproject.org/projects/tor/ticket/6975" target="_blank">https://trac.torproject.org/projects/tor/ticket/6975</a><br>> <br>> There are some rumours that Firefox is going to copy Chrome's mixed-content<br>> blocking
strategy at some point, in which case we may have a large and sudden set<br>> of changes to make to the ruleset library. It's therefore a good idea to<br>> start watching for and labelling rulesets as "mixedcontent" where possible.<br>> <br>> > Although it seems sensible to subject a submitted ruleset to a certain<br>> > amount of post- submission testing (among other things, screening for<br>> > potential security issues), it would also seem advantageous for<br>> > pre-submission and post-submission testing of a ruleset to complement each<br>> > other, and to avoid (if possible) the situation where the two overlap<br>> > excessively.<br>> <br>> Yup :). <br>> > <br>> > Ticket #2160 (<a href="https://trac.torproject.org/projects/tor/ticket/2160" target="_blank">https://trac.torproject.org/projects/tor/ticket/2160</a>) on<br>> > the Tor Bug Tracker & Wiki talks about
documenting the ruleset review<br>> > process for HTTPS Everywhere. The documentation that this ticket would<br>> > involve would be meant both for ruleset submitters and also<br>> > administrators/reviewers, according to the ticket description. The<br>> > rulesets for HTTPS Everywhere include coverage of sites that would<br>> > seem to be very large, such as sites for certain universities. Has<br>> > anyone had any experience or any comments regarding testing rulesets<br>> > prior to submitting them, particularly rulesets for large sites?<br>> <br>> It feels as though the ruleset review process is still fluid enough that<br>> documenting it might be premature :)<br>> <br>> -- <br>> Peter Eckersley <a ymailto="mailto:pde@eff.org" href="mailto:pde@eff.org">pde@eff.org</a><br>> Technology Projects
Director Tel +1 415 436 9333 x131<br>> Electronic Frontier Foundation Fax +1 415 436 9993<br>> <br>> _______________________________________________<br>> HTTPS-everywhere mailing list<br>> <a ymailto="mailto:HTTPS-everywhere@mail1.eff.org" href="mailto:HTTPS-everywhere@mail1.eff.org">HTTPS-everywhere@mail1.eff.org</a><br>> <a href="https://mail1.eff.org/mailman/listinfo/https-everywhere" target="_blank">https://mail1.eff.org/mailman/listinfo/https-everywhere</a><br><br>-- <br>Peter Eckersley <a ymailto="mailto:pde@eff.org" href="mailto:pde@eff.org">pde@eff.org</a><br>Technology Projects Director Tel +1 415 436 9333 x131<br>Electronic Frontier Foundation Fax +1 415 436 9993<br><br><br> </div> </div> </div></body></html>