<offtopic> 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... </offtopic>
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. 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. Best regards, Maxim Nazarenko On 18 August 2014 22:24, Dave Warren <[email protected]> wrote: > On 2014-08-18 09:13, Nick Semenkovich wrote: > >> I love the ideas! >> >> Automatically disabling broken rules could really improve the user >> experience -- and adding some TravisCI hooks to pull-requests would be >> great. >> >> Two thoughts >> - How would we go about automatically disabling rules? >> 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.) >> >> > 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. > > 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. > > 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. > > 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? > > 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. > > -- > Dave Warren > http://www.hireahit.com/ > http://ca.linkedin.com/in/davejwarren > > > > _______________________________________________ > HTTPS-Everywhere mailing list > [email protected] > https://lists.eff.org/mailman/listinfo/https-everywhere >
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
