[HTTPS-Everywhere] HTTPS-Everywhere needs to be on firefox addons

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 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 <yan at eff.org>, <yan at torproject.org> Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140421/62d2c620/attachment.sig>