On Tue, 2014-03-04 at 22:39 -0800, Yan Zhu wrote: > We've gotten this suggestion a couple times before. Seth Schoen tells me > that the HTTPS Finder rules are often buggy or incomplete, so it's > better if humans look at them first and submit them to us (rather than > have HTTPS Finder automatically submit everything that it finds).
Yeah, that is why I suggest only submitting domains rather than rules. When you get new domains submitted by users you can pro-actively check the ruleset, test the domains from multiple network points and update the ruleset. > As discussed previously, it would be great for us to decouple ruleset > updates from extension updates so that we can ship ruleset updates more > frequently (extension updates happen about once every two months). I'm > open to the idea of shipping ruleset updates over HTTPS with certificate > pinning (i.e., bundling the public key with the HTTPS Everywhere > package) as soon as they get checked into git, but this would mean that > ruleset updates are less secure than extension updates (since we sign > extension updates with an offline private key in addition to serving > them over HTTPS). How about signing ruleset updates with the same key? It would mean bringing that key online more often though I guess. Alternatively you could have a separate online signing key stored in a hardware token. > (There's a good argument that ruleset security should be equivalent to > extension security, since an attacker can submit a ruleset update that > rewrites the extension update URL to a malicious one!) I think the code could have a hardcoded URL for ruleset updates that isn't subject to ruleset rewriting? -- bye, pabs http://bonedaddy.net/pabs3/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
