WebExtensions timeline/checklist

[Hainish]

1. Wait until a few weeks after Tor Browser 7.0 stable has been released, so that users have had the chance to upgrade to a Tor Browser based on Firefox 52 ESR.
2. Change https://github.com/EFForg/https-everywhere-docker-base/blob/master/Dockerfile to use ESR 52.
3. Merge the webextensions branch into master.
4. Make a new release, which will follow the WebExtensions date-based versioning. In AMO, ensure the versioning is correct, so that users are upgraded only if they are on Firefox >= 52 or Fennec >= 53.
5. Generate a signature for https://www.eff.org/files/https-everywhere-eff-update-2048.rdf which ensures upgrading to the WebExtension version if users are on Firefox >= 52 or Fennec >= 53.
6. Create https://www.eff.org/files/https-everywhere-updates.json and ensure it is signed, so that the WebExtensions version can update itself.
7. Create the 2017.X.X tag, and push it to both tor and github remotes

[Hainish]

cc @J0WI @jeremyn @gloomy-ghost @jsha

[jeremyn]

It would be really nice if you could release another version of HTTPS Everywhere, call it "HTTPS Everywhere (WebExtensions Beta)" and make that available alongside the live version for one or two Firefox release cycles. You could even just release it on the EFF site, with a hidden link, and not AMO. I feel like we'll have a much lower chance of catastrophic failure if even a few of us could run with it for a month or two before it goes out to a million people.

[Hainish]

@jeremyn I think that's a fine idea. I'm currently waiting on Mozilla to document how in WebExtensions you can provide a signature and embed the extension public key. This is supported in XPCOM, but maybe not WebExtensions (yet?) This provides a mechanism above and beyond TLS keys to ensure that extension upgrades are securely deployed.

Regardless, providing a temporary WebExtensions beta to interested users wouldn't necessitate that level of secure signing, and can probably be done pretty easily.

[jeremyn]

Is that process different than the lower level review that Mozilla does for add-ons that aren't distributed through AMO?

[jeremyn]

I mean the "unlisted" process described here.

[Hainish]

Yes, it's a separate thing that allows app developers to embed their own public key into an extension, and then Firefox will only upgrade when the upgrade manifest is signed with this public key. This is only available for self-hosted, not for AMO.

[jeremyn]

Oh okay. Can you point to some discussion on that somewhere? I'd like to know more about it.

[jeremyn]

I guess you mean something like https://addons-server.readthedocs.io/en/latest/topics/api/signing.html .

[Hainish]

@jeremyn you can see this by downloading the self-hosted XPI, then checking the install.rdf file in it (it's also in src/ in the source tree), which lists the public key. The extension then checks for new files and attempts to verify the signature in https://www.eff.org/files/https-everywhere-eff-update-2048.rdf and if it verifies, an upgrade can take place.

The documentation for updateKey is here.

There is more comprehensive documentation of the entire process here

[jeremyn]

Thanks!

[Hainish]

I've created a new tag to note issues with the WebExtensions version for Firefox, just called webextensions-firefox. I've already noted one issue: #9965

@jeremyn: here's a link to the testing versions of HTTPS Everywhere: https://www.eff.org/files/https-everywhere-test/index.html

I have several files listed there. The first few (older) files are to test the upgrade path. Feel free to install and test it yourself, and if you encounter any issues just tag it with the above-mentioned label.