Opened 6 years ago

Closed 3 years ago

#9769 closed project (fixed)

Move HTTPS Everywhere back to addons.mozilla.org

Reported by: micahlee Owned by: micahlee
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords:
Cc: schoen, ecleuffa, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We currently have millions of Firefox users. Here's a list of the most popular Firefox addons: https://addons.mozilla.org/en-US/firefox/extensions/?sort=users

It's hard to tell exactly how many because we keep such minimal logs, but my guess is around 3 million. If this is true, we'll probably hit #3. I think moving HTTPS Everywhere back to AMO will increase our visibility and potentially get us a lot more users.

Additionally, I heard feedback that some users in Syria have been trained to never install Firefox addons from anywhere but https://addons.mozilla.org/, so they were weary of installing HTTPS Everywhere from https://www.eff.org/.

The reasons that HTTPS Everywhere isn't currently hosted on AMO are:

  • We had issues with Mozilla's data retention policy. I have heard that Mozilla has since updated their policies. Here is the current policy that governs AMO: https://www.mozilla.org/en-US/privacy/policies/websites/ -- I should read it and go over it with an EFF lawyer to make sure we're ok with it now.
  • Mozilla has an approval process for posting updates to extensions that sometimes takes a long time. Since most of our major bugs that require time-sensitive fixes are for rulesets, I think we should not ship rulesets with our extension and instead implement a ruleset-updating feature, kind of like Adblock Plus lists. (I should open a ticket for this)
  • We currently sign our releases using a key stored on an airgapped signing machine. If we switch to AMO, I believe Mozilla will be responsible for signing our releases (though I should do more research into this). In any case, if we start releasing rulesets separately from extension updates we should continue to use the airgapped signing machine to sign our ruleset updates.

Child Tickets

TicketStatusOwnerSummaryComponent
#9868closedpdeStop bundling rulesets with extension, download separately instead (like ABP)HTTPS Everywhere/EFF-HTTPS Everywhere

Change History (26)

comment:1 in reply to:  description Changed 6 years ago by arma

Replying to micahlee:

so they were weary of installing HTTPS Everywhere from https://www.eff.org/.

Pet peeve: wary. Unless they were weary too.

comment:2 in reply to:  description Changed 6 years ago by arma

Replying to micahlee:

  • We had issues with Mozilla's data retention policy. I have heard that Mozilla has since updated their policies. Here is the current policy that governs AMO: https://www.mozilla.org/en-US/privacy/policies/websites/ -- I should read it and go over it with an EFF lawyer to make sure we're ok with it now.

This is (was) the big issue from Tor's side. We looked at their detailed graphs of where all the users are, and where all the users are asking for updates from, and realized that they basically track the locations, versions, other add-ons installed, etc of all their users all the time -- and anybody who breaks into or otherwise gets their data set can too. I guess how long they retain the data is a fine question too, but collecting such detailed and fine-grained per-user info at all makes me very sad.

comment:3 Changed 6 years ago by micahlee

arma, you're talking about these graphs? https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/statistics/?last=30

We certainly don't need to move HTTPS Everywhere to AMO, and I think if Tor folks still have strong concerns that's a good reason to re-evaluate the decision. I do think that the benefits will be large. And while I wish the usage statistics didn't contain as much detail, I will like knowing how many users we have without have to grep our server logs.

comment:4 Changed 6 years ago by mikeperry

With respect to the third point from the description: Mozilla does not sign updates. It also turns out that cert pinning is still not implemented for addons.mozilla.org, so anyone with any compromised CA cert will be able to feed addon updates that trojan/subvert/replace HTTPS-Everywhere. According to Camilo, A.M.O. pinning won't land until at least Q1 2014.

I am not sure if it is possible to use a custom addon update key with A.M.O. Probably not by default, since it would require that your addon have its own update.rdf URL still on EFF's servers (and signed with your key). This is forbidden by the A.M.O. upload process, but maybe you can get them to craft an exemption for you.

comment:5 Changed 6 years ago by micahlee

Thanks mikeperry. I just emailed some Mozilla folks asking if it would be possible for them to make an exception for us so we can still sign our releases and get them verified when people update. And I also asked for an update on A.M.O. cert pinning, but if we can just get signature verification that would be best.

comment:6 Changed 6 years ago by micahlee

Cc: schoen added

comment:7 in reply to:  3 Changed 6 years ago by arma

Replying to micahlee:

arma, you're talking about these graphs? https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/statistics/?last=30

I think the graphs I was talking about looked different. They let you investigate number of users at any given hour by country, number of downloads like that, etc. Basically they made it clear that Mozilla had the whole data set, not aggregated or anonymized, on their backend and they were experimenting with how to help the rest of the world see it too.

There was a phone call long ago between me, Cindy, and somebody Cindy knew at Mozilla, where I accidentally yelled at the Mozilla person for having such poor and dangerous privacy practices, and then quite reasonably they decided that talking to me further was no fun so they stopped. :/ We all have too many fights to fight these days.

We certainly don't need to move HTTPS Everywhere to AMO, and I think if Tor folks still have strong concerns that's a good reason to re-evaluate the decision. I do think that the benefits will be large. And while I wish the usage statistics didn't contain as much detail, I will like knowing how many users we have without have to grep our server logs.

Well, so long as the Tor Browser Bundle prevents Tor users from contributing so much to this enormous data store that Mozilla maintains, you probably aren't screwing the non-TBB users much more than they're already screwed. I think ditching a.m.o for a single extension is mostly a symbolic act at this point, since most of their users are entangled so deeply in it. So, if you think it's a worthwhile tradeoff, don't let me slow down progress. :)

comment:8 Changed 6 years ago by zyan

We got a few requests recently to put HTTPS Everywhere in AMO. I'm leaning towards doing so but leaving the download up on eff.org with a note about why we might discourage users from downloading from AMO.

The graphs that Micah linked to for AdBlock Plus can be kept private - it's up to the developer. In our case, we definitely should keep them private (and also double-check with Mozilla about their data retention practices).

It's worth mentioning that we already offer HTTPS Everywhere through the Opera/Chrome addon stores, presumably because we decided that there was no easy alternative for people who use these browsers to get the extension. Not sure offhand if either of those does signature verification on updates.

comment:9 Changed 6 years ago by zyan

Update: We sign the Chrome extension with the offline signing key, and the webstore checks for a signature from this key before it allows us to update the crx.

comment:10 Changed 6 years ago by arthuredelstein

Assuming that Mozilla continues to retain individual records on all AMO downloads, and sends this data automatically to all interested third parties, it's still a small privacy leak compared to the immense leakage by likely thousands of users who aren't using HTTPS Everywhere, because they aren't aware of it, or because they searched for HTTPS Everywhere on AMO and didn't find it.

So I would advocate putting HTTPS Everywhere on AMO unconditionally, and in parallel, continuing to push Mozilla to improve their privacy practices.

comment:11 in reply to:  3 Changed 5 years ago by cypherpunks

Replying to micahlee:

... And while I wish the usage statistics didn't contain as much detail, I will like knowing how many users we have without have to grep our server logs.

Besides saving some internal grep effort, another benefit of putting HTTPS Everywhere in AMO would be an easy to find public url that tracks the number of users and is constantly updated. This sort of thing can really come in handy when trying to convince a webmaster to improve his/her site's compatibility with HTTPS Everywhere. i.e. "This is the 3rd most popular FF Extension, so you should pay attention to this issue".

comment:12 Changed 5 years ago by zyan

Update: Ignoring the (hypothetical?) privacy issues, my main concern is that AMO doesn't allow us to sign extension updates with our airgapped signing key (whereas the Chrome web store does).

However, I have heard that Mozilla will roll out cert pinning for addons.mozilla.org in the next couple months or so. Perhaps that will be Good Enough.

comment:13 Changed 5 years ago by zyan

It appears that AMO does *no* code signing for addons, so they're just protected by HTTPS after the approval process. Kind of scary in light of Heartbleed!

I have decided that the best-case scenario is for AMO to let us sign updates with our own key, which Chrome Web Store does. Please star and discuss here: https://bugzilla.mozilla.org/show_bug.cgi?id=999014

If that fails, we can wrangle the release scripts to use a new CA-signed cert as soon as PKP lands in Firefox.

comment:14 Changed 5 years ago by jsha

zyan's bugzilla bug to allow offline signatures for AMO extensions was rejected.

Public key pinning has landed in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=744204 and https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#How_to_use_pinning. However, that's for HTTPS requests, but the documentation to use CA-signing for XPIs appears to be about code signing. I'm willing to bet that the PKP implementation does not extend to code signing.

Also, kmag on the bugzilla thread (https://bugzilla.mozilla.org/show_bug.cgi?id=999014) has a very good point. If there's a universal hotfix addon that is not offline-signed and can deliver updates to any addon, there's no additional security for Firefox users in our current method. TBB users, of course, don't get their HTTPS Everywhere from AMO, and so are not affected.

I think we should proceed with adding HTTPS Everywhere to AMO. zyan, any objections?

comment:15 Changed 5 years ago by zyan

jsha: no objections, thanks for taking the lead on this. Seth has the credentials for our AMO account.

comment:16 Changed 5 years ago by jhall

Any updates on this?

Hosting on AMO seems like such a big win.

Personally I really want https-anywhere, but its not that I dont trust you, I just really want the external pair of eyes looking it over =)

Trust but verify!

comment:17 Changed 5 years ago by jsha

I submitted the 4.0 release for preliminary review by AMO. It took a while, but they finally came back with a few minor issues. Those are fixed in master, and when we do another 4.0.* release in the next few weeks we'll upload that to AMO also.

comment:18 Changed 5 years ago by jhall

Great news!

comment:19 Changed 5 years ago by jsha

TODO on this: Need to update the release process to generate two XPI's: One with an install.rdf that includes updateURL and updateKey, and one without those suitable for uploading to AMO (AMO will reject any extension with those elements present in install.rdf).

comment:20 Changed 4 years ago by ecleuffa

Cc: ecleuffa added

comment:21 Changed 4 years ago by cypherpunks

Starting in FireFox 42 unsigned extensions will not be allowed. Might be worth thinking about this issue.

https://wiki.mozilla.org/Addons/Extension_Signing

comment:22 Changed 4 years ago by jsha

I'm working on the addon signing issue. Details are here: https://github.com/EFForg/https-everywhere/issues/2051

comment:23 Changed 4 years ago by mcs

Cc: mcs added

comment:24 Changed 4 years ago by cypherpunks

Resolution: fixed
Severity: Normal
Status: newclosed

comment:25 Changed 3 years ago by isis

Resolution: fixed
Status: closedreopened

Dear cypherpunks, if you're going to anonymously alter ticket statuses, and particularly if you're going to close tickets, please clearly state your reasons for doing so.

comment:26 Changed 3 years ago by legind

Resolution: fixed
Status: reopenedclosed

Currently HTTPS Everywhere is both self-hosted at https://www.eff.org/ as well as published to AMO.

Note: Tor Browser uses the self-hosted version, which means this was not a vector for the recent extension update vulnerability,  though Tor Browser was vulnerable otherwise.

Note: See TracTickets for help on using tickets.