On 04/21/2014 11:14 AM, Yan Zhu wrote: > Hi all, > > The good news is that HTTPS Everywhere is going in AMO eventually. The > question is when. > > The main reason I haven't put it in AMO *yet* is because AMO offers > *less* security to users than EFF self-hosting it, ironically. AMO > doesn't do any code signing for extensions, so they're only protected by > HTTPS. As we saw with Heartbleed, SSL private keys can be compromised. > > Why wasn't HTTPS Everywhere affected by Heartbleed? Because we sign > updates with an offline signing key that EFF keeps on a dedicated > airgapped machine. So even if SSL is totally broken, the integrity of > updates is guaranteed. Yay! > > Luckily the AMO update servers weren't using a vulnerable version of > OpenSSL, even though the servers that hosted static files (favicons, > etc.) were. Had the update servers been affected by Heartbleed, someone > could push a malicious update to almost any addon that you had installed > from AMO. This is pretty terrifying, given that a malicious Firefox > addon can completely and invisibly pwn your browser. > > So there's two situations that would make me comfortable with putting > HTTPS Everywhere in AMO: > > 1. AMO allows us to sign updates with our offline signing key, which is > what Chrome Web Store already does. This is *by far* the easiest route > from my perspective. I have opened a bug with Mozilla; please star it! > https://bugzilla.mozilla.org/show_bug.cgi?id=999014
Wow, that sure got marked as invalid and closed quickly. It seems that at least one Mozilla dev. is strongly against considering this option. Probably going to go with #2. > > 2. Once public key pinning lands in Firefox (supposedly scheduled to > happen this summer), we can sign HTTPS Everywhere with a CA-signed > certificate via this arcane process: > https://developer.mozilla.org/en-US/docs/Signing_a_XPI. It would take > some wrangling to make it work with an offline private key but probably > not impossible. > > More info inline, but the above was the gist of it. > > On 04/20/2014 01:58 PM, Dave Warren wrote: >> On 2014-04-20 12:53, Andrew Sillers wrote: >>> >>> Without further comment, I'll call out: >>> >>> * the FAQ entry on this topic: >>> https://www.eff.org/https-everywhere/faq#amo >>> >> >> This one doesn't seem to make sense to me. The Mozilla privacy policy >> would only apply to Mozilla possibly keeping track of who downloads the >> add-on, but wouldn't automatically make the add-on start intruding on >> privacy somehow, would it? > > This answer is outdated; as mentioned above, the privacy policy isn't > the blocker anymore. Will update the FAQ. > >> More importantly, if a user is happy with a less restrictive privacy >> policy, what's the problem? > > Nothing in particular, except that we realize that users rarely read > privacy policies. So there is an argument for developers to provide them > with the maximum amount of privacy by default (which is supposedly what > we do by not making AMO an option). > > This is kind of a moot point because I think the popularity benefit of > being in AMO outweighs the minor-and-possibly-hypothetical privacy loss. > >>> * the extant discussion on this topic in the bug tracker: >>> https://trac.torproject.org/projects/tor/ticket/9769 >>> >> >> While the approval process is a factor, having some code in the rulesets >> that says "Do not apply this rule to versions below 'x'" should negate >> the issue of time-sensitive rules, save for the fact that an >> incompatible rule simply won't run until the extension is updated. A >> small price to pay for making this easy and safe for users. > > It seems that you're talking about a tangential issue here, which is > whether/how ruleset updates should be hosted if/when we get to a point > where ruleset updates are independent from extension updates (which will > happen if Zack's GSoC project works out). AFAIK, there is no way in AMO > to let us update rulesets without updating the entire extension, so we > will need to self-host ruleset updates if we want them to be separate > from extension updates. > >> >> As far as signing, the ruleset update signing has already been discussed >> and can still be done separate from rule updates using EFF's key. > > Confused here. What's the difference between "ruleset update" and "rule > update"? > >> >> It ultimately may not be as simple as just uploading to Mozilla and >> being done with it, but it's pretty close to that and it's not as though >> EFF is releasing frequent enough updates for Mozilla's slight delay to >> be a significant factor, at least IMO. >> > > -- Yan Zhu <[email protected]>, <[email protected]> Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134
signature.asc
Description: OpenPGP digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
