<div dir="ltr"><div><div><div><div><div><div><offtopic><br></div>I'd argue that HTTPS Everywhere main purpose is BOTH redirect from http to https for sited not doing that server-side and prevent downgrade attack. Ultimately, the extension is a crutch, site operators can and should deploy redirection and HSTS with preloaded lists, but...<br>


</div></offtopic><br><br></div>More on topic, I don't think automatically disabling rules is a good idea. When a break is detected during CI tests, the rule maintainer is notified, and then it is up to him to take measures. When something breaks for an end-user, one can always disable the rule. I don't think we should make  security vs usability tradeoffs instead of end users.<br>


<br></div>My suggestion was more like "Press here to report a broken rule" button, i.e. a way for end users to notify the rule maintainer. Optionally, we may ask for additional details such as URL being accessed etc, that must be opt-in naturally. Using Tor for reports is a good idea, and we employ captcha if spam becomes a problem.<br>


<br></div>Best regards,<br></div>Maxim Nazarenko <br><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 August 2014 22:24, Dave Warren <span dir="ltr"><<a href="mailto:davew@hireahit.com" target="_blank">davew@hireahit.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 2014-08-18 09:13, Nick Semenkovich wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I love the ideas!<br>
<br>
Automatically disabling broken rules could really improve the user experience -- and adding some TravisCI hooks to pull-requests would be great.<br>
<br>
Two thoughts<br>
- How would we go about automatically disabling rules?<br>
Should we have some protected class of "super stable" rules (e.g. Twitter's SSL shouldn't be disabled if there's a transient curl test failure.)<br>
<br>
</blockquote>
<br></div>
The downside is that this potentially enables an attack vector that opens up sites to the very downgrade attacks that HTTPS Everywhere exists to prevent.<br>
<br>
Without HTTPS Everywhere, nothing stops sites from applying redirections from HTTP to HTTPS themselves, so HTTPS Everywhere's primary purpose is to prevent downgrade attacks, and to apply a client-side enforcement of HTTPS on sites that don't redirect it themselves.<br>



<br>
With automatic validation and deactivation of rules in the event that a destination page fails, all an attacker needs to do is to keep a site's HTTPS busy or offline for some period of time for HTTPS Everywhere to disengage, returning the site to a less secure state.<br>



<br>
Like with so many things in security, there is an obvious security vs usability tradeoff here, is it better to return an insecure version of a page, or an error message and an unusable site?<br>
<br>
Obviously if this is a permanent situation, the rule should be disabled and removed, but in the case of a temporary error on the HTTPS side, I'd be very nervous about automatically removing a layer of security.<span><font color="#888888"><br>



<br>
-- <br>
Dave Warren<br>
<a href="http://www.hireahit.com/" target="_blank">http://www.hireahit.com/</a><br>
<a href="http://ca.linkedin.com/in/davejwarren" target="_blank">http://ca.linkedin.com/in/<u></u>davejwarren</a></font></span><div><div><br>
<br>
<br>
______________________________<u></u>_________________<br>
HTTPS-Everywhere mailing list<br>
<a href="mailto:HTTPS-Everywhere@lists.eff.org" target="_blank">HTTPS-Everywhere@lists.eff.org</a><br>
<a href="https://lists.eff.org/mailman/listinfo/https-everywhere" target="_blank">https://lists.eff.org/mailman/<u></u>listinfo/https-everywhere</a><br>
</div></div></blockquote></div><br></div></div>