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.
Oh definitely -- I was thinking @jsha's proposal was on the
development / codebase side, not client extension side. Though
maybe things change so rarely it makes sense to manually validate
all disabled rules.
Exactly, this would be a measure that would be applied during
development.
Definitely we would want a mechanism to distinguish transient
failures from permanent ones, and we might want to manually review
removals depending on how much volume we get. Certainly we would
want to review all the disabled rules before doing a release, and
notify the maintainer. But if an attacker is willing to block HTTPS
to a site from the perspective of our test machine *and* from the
perspective of a maintainer, I don't think we can reasonably
distinguish that from the site actually being broken for HTTPS.
_______________________________________________
HTTPS-Everywhere mailing list
[email protected]
https://lists.eff.org/mailman/listinfo/https-everywhere
