<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Related?</span></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;">"Disable insecure content loading on HTTPS pages"</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><span></span></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;"><span>https://www.mozilla.org/en-US/firefox/18.0a2/auroranotes/<br></span></div><div><span></span></div><div><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> mezzanine@Safe-mail.net <br><b><span style="font-weight: bold;">Cc:</span></b> https-everywhere@eff.org <br> <b><span style="font-weight: bold;">Sent:</span></b> Wednesday, October 17, 2012 11:53 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [HTTPS-Everywhere] Clarifying the process for testing rulesets<br> </font> </div> <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> </div> </div> </div></body></html>