[Bug-gnuzilla] Introducing Extension Signing: A Safer Add-on Experience

[David Englund/Hedlund]

Read all 19 pages in https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/ :

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.