Introducing Extension Signing: A Safer Add-on Experience

Jorge Villalobos
FEB 10 2015
This year will bring big changes for add-on development, changes that we believe are essential to safety and performance, but will require most add-ons to be updated to support them. I’ll start with extension signing, which will ship earlier, and cover other changes in an upcoming post.

The Mozilla add-ons platform has traditionally been very open to developers. Not only are extensions capable of changing Firefox in radical and innovative ways, but developers are entirely free to distribute them on their own sites, not necessarily through AMO, Mozilla’s add-ons site. This gives developers great power and flexibility, but it also gives bad actors too much freedom to take advantage of our users.

Extensions that change the homepage and search settings without user consent have become very common, just like extensions that inject advertisements into Web pages or even inject malicious scripts into social media sites. To combat this, we created a set of add-on guidelines all add-on makers must follow, and we have been enforcing them via blocklisting (remote disabling of misbehaving extensions). However, extensions that violate these guidelines are distributed almost exclusively outside of AMO and tracking them all down has become increasingly impractical. Furthermore, malicious developers have devised ways to make their extensions harder to discover and harder to blocklist, making our jobs more difficult.

We’re responsible for our add-ons ecosystem and we can’t sit idle as our users suffer due to bad add-ons. An easy solution would be to force all developers to distribute their extensions through AMO, like what Google does for Chrome extensions. However, we believe that forcing all installs through our distribution channel is an unnecessary constraint. To keep this balance, we have come up with extension signing, which will give us better oversight on the add-ons ecosystem while not forcing AMO to be the only add-on distribution channel.

Here’s how it will work:

Extensions that are submitted for hosting on AMO and pass review will be automatically signed. We will also automatically sign the latest reviewed version of all currently listed extensions.
Extension files that aren’t hosted on AMO will have to be submitted to AMO for signing. Developers will need to create accounts and a listing for their extension, which will not be public. These files will go through an automated review process and sent back signed if all checks pass. If an add-on doesn’t pass the automated tests, the developer will have the option to request the add-on to be manually checked by our review team. A full review option will also be available for non-AMO add-ons, explained further ahead.
For extensions that will never be publicly distributed and will never leave an internal network, there will be a third option. We’ll have more details available on this in the near future.
There will be a transition period of two release cycles (12 weeks total) during which unsigned extensions will only generate a warning in Firefox.
After the transition period, it will not be possible to install unsigned extensions in Release or Beta versions of Firefox. There won’t be any preferences or command line options to disable this.
Installation of unsigned extensions will still be possible on Nightly and Developer Edition, as well as special, unbranded builds of Release and Beta that will be available mainly for developers testing their extensions.
All Firefox extensions are affected by this change, including extensions built with the Add-ons SDK. Other add-on types like themes and dictionaries will not require signing and continue to install and work normally. Signature verification will be limited to Firefox, and there are no plans to implement this in Thunderbird or SeaMonkey at the moment.

What this means for developers
For developers hosting their add-ons on AMO, this means that they will have to either test on Developer Edition, Nightly, or one of the unbranded builds. The rest of the submission and review process will remain unchanged, except that extensions will be automatically signed once they pass review.

For other developers, this is a larger change. For testing development versions, they’ll have the same options available as AMO add-on developers. For release versions, however, we’re introducing the required step of uploading the extension file to AMO for signing. For most cases, this step will be automatic, but in cases where the extension doesn’t pass these tests, there will be the option to request a manual code review.

In the case of developers who want their extensions to be side loaded (installed via an application installer rather than using the usual Web install method) the review bar will be higher, equal to fully reviewed add-ons on AMO (with the exception of AMO content restrictions). This is a convenient installation avenue for software that comes bundled with an extension, for example an antivirus application that includes a Firefox extension that interacts with it.

One important improvement that signing brings about is that the extension install experience will be renewed and improved. Extensions that meet the full review standard will have a smoother and friendlier install experience, regardless of where they’re hosted. Here’s an early mockup of how this will work:

Installation flowThe plan is to have this system working, at least in the transition stage, in Q2 this year. So, we will probably introduce extension signing warnings on Firefox 39.

Discussion
We welcome comments on this post, but if you want to debate the merits of this plan, please do so in the add-ons user experience list. That’s where the people driving the project will read and respond to your concerns.

Source : https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/comment-page-1

Dans les commentaires c'est un carnage. Les utilisateurs sont furax, à raison.

Je pense que c'est quand même une énorme connerie.

Je pense que c'est quand même une énorme connerie.

Surtout que la plupart des malwares ont un moteur de hook.
Un petit patch pour firefox.exe et goodbye check crypto ...

Le store android est bourré de malwares, je vois pas ce que ça change ?

Je ne pense pas que corrector parle spécifiquement de store, mais plutôt du mécanisme d'installation en lui-même: on installe un package qui est lu par un outil du système d'exploitation (apk sous android, rpm ou deb sous linux...), et l'on n'utilise pas un installeur exécutable. Ce n'est pas nécessairement lié à un store.

Dans l'idée, ça laisse moins de latitude aux malwares.
En pratique, je ne suis pas certain que ça change beaucoup de choses: dans les rpm comme dans les deb, les scripts de "post-installation" peuvent comprendre à peu près n'importe quoi. Je connais moins bien les apk.

Ah et un msi c'est pas lu par un ouitil du système d'exploitation ?

Si, il me semble même que ça appel "microsoft installer"