You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 6, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 6, 2023. It is now read-only.
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.
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.
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.
Reacted by Hugo Gruson, Michael Keck, Scott Stensland, Aminda Suomalainen ⚧, Dylan Myers, Freya Gentz and Wolfgang Marcos
@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.
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 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.
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
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.
Reacted by J0WI, Hugo Gruson, Paul and Antoine Pultier
Firefox Stable will make the transition to 57 on November 14th. Transitioning to full WebExtensions in late October should give us enough padding to fix any issues if they arise as well as allow time for AMO review.
@strigona-worksight That is working fine, thank you. 2 more questions, will I now stay on the developer version or will that be upgraded to release version once finished? I had 2 versions listed in parallel, the old non-WebExtension one (which I removed manually) and the new developer version, why?
I'm not sure if it's been noted, but if you upload the WebExtension to AMO and set the minimum version to 57, users that don't have 57 won't be upgraded until their browser updates to 57.
@pwd-github we plan to do this regardless, but doing so would shorten the time that the embedded WebExtension has the opportunity to migrate users settings.
I'm not sure if it's been noted, but if you upload the WebExtension to AMO and set the minimum version to 57, users that don't have 57 won't be upgraded until their browser updates to 57.
@pwd-github we plan to do this regardless, but doing so would shorten the time that the embedded WebExtension has the opportunity to migrate users settings.
@Hainish How so? Users of Firefox <57 should get an update to the latest supported version, shouldn't they? Only Firefox 57+ users (currently beta & nightly) would get the update to a WebExtension version and those are versions where the embedded WebExtension wouldn't work anyway.
Full WebExtensions release has been made. Thank you for all your hard work in fleshing out the bugs missing features. There's still some work to be done to replace some of the features that we lost when moving from XPCOM. This can be tracked here: https://github.com/EFForg/https-everywhere/projects/1
Reacted by Franklin Yu, AJ Jordan, Ed Flanagan, David, girst, CHAN, Chak Shing and Jon Dufresne
Activity
Hainish commentedon May 19, 2017
cc @J0WI @jeremyn @gloomy-ghost @jsha
jeremyn commentedon May 19, 2017
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 commentedon May 19, 2017
@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 commentedon May 19, 2017
Is that process different than the lower level review that Mozilla does for add-ons that aren't distributed through AMO?
jeremyn commentedon May 19, 2017
I mean the "unlisted" process described here.
Hainish commentedon May 19, 2017
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 commentedon May 19, 2017
Oh okay. Can you point to some discussion on that somewhere? I'd like to know more about it.
jeremyn commentedon May 19, 2017
I guess you mean something like https://addons-server.readthedocs.io/en/latest/topics/api/signing.html .
Hainish commentedon May 19, 2017
@jeremyn you can see this by downloading the self-hosted XPI, then checking the
install.rdffile in it (it's also insrc/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
updateKeyis here.There is more comprehensive documentation of the entire process here
jeremyn commentedon May 19, 2017
Thanks!
Hainish commentedon May 20, 2017
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.
63 remaining items
Hainish commentedon Sep 22, 2017
For reference, the Firefox release schedule is available here: https://wiki.mozilla.org/RapidRelease/Calendar.
Firefox Stable will make the transition to 57 on November 14th. Transitioning to full WebExtensions in late October should give us enough padding to fix any issues if they arise as well as allow time for AMO review.
J0WI commentedon Sep 23, 2017
What about the open ToDos for Webextensions?
jeremyn commentedon Sep 23, 2017
Seconding @J0WI 's question about the remaining open issues. For reference, they are https://github.com/EFForg/https-everywhere/issues?q=is%3Aopen+is%3Aissue+label%3Awebextensions-firefox and many of them are serious.
Diapolo commentedon Sep 27, 2017
Firefox Quantum 57.0b3 (64-Bit) is now on my machine, sadly HTTPSEverywhere is not yet ready :-/.
strigona-worksight commentedon Sep 27, 2017
@Diapolo You can install the developer version which is WebExtension here: https://www.eff.org/https-everywhere
Diapolo commentedon Sep 28, 2017
@strigona-worksight That is working fine, thank you. 2 more questions, will I now stay on the developer version or will that be upgraded to release version once finished? I had 2 versions listed in parallel, the old non-WebExtension one (which I removed manually) and the new developer version, why?
uniquePWD commentedon Oct 16, 2017
I'm not sure if it's been noted, but if you upload the WebExtension to AMO and set the minimum version to 57, users that don't have 57 won't be upgraded until their browser updates to 57.
Hainish commentedon Oct 21, 2017
@pwd-github we plan to do this regardless, but doing so would shorten the time that the embedded WebExtension has the opportunity to migrate users settings.
FranklinYu commentedon Oct 25, 2017
Not sure whether it helps, but AMO provides beta channel.
mgol commentedon Oct 30, 2017
@Hainish How so? Users of Firefox <57 should get an update to the latest supported version, shouldn't they? Only Firefox 57+ users (currently beta & nightly) would get the update to a WebExtension version and those are versions where the embedded WebExtension wouldn't work anyway.
J0WI commentedon Oct 30, 2017
The first full WebExtensions release is just around the corner: #13420.
Hainish commentedon Oct 30, 2017
Full WebExtensions release has been made. Thank you for all your hard work in fleshing out the bugs missing features. There's still some work to be done to replace some of the features that we lost when moving from XPCOM. This can be tracked here: https://github.com/EFForg/https-everywhere/projects/1