Categories: developers

The Case for Extension Signing

Mozilla’s  recent announcement that mandatory extension signing is coming to Firefox this summer generated a lot of feedback from our developer community. Most of them were concerned with the burden this puts on developers who don’t host their add-ons on AMO as well as the centralization of add-on oversight. I would like to add more insight into why we are making this change. In our last post we mentioned the difficulties of tracking down add-ons and blocking them, but there’s much more behind the decisions that were made to come up with this plan. This post should give you a better idea of why we think extension signing is necessary and how we are still honoring our principles of openness and user control.

The power of add-ons

We love add-ons and wouldn’t want to browse the Web without the enhanced experience they offer. I myself have 22 active add-ons at the moment, with another seven disabled but on hand just in case. Firefox add-ons aren’t restricted to a limited API for manipulating Web content and parts of the browser. Add-ons can use, manipulate, or even replace just about any aspect of Firefox internals. Add-ons are one manifestation of a freedom so important to us that we have enshrined it in our Mozilla principles: Individuals must have the ability to shape the Internet and their own experiences on the Internet.

The adware scourge

The Web experienced by tech-savvy developers, however, is not the Web experienced by most people. While only fourteen add-ons hosted on our site have more than a million users, and only two of those have more than 3 million, many tens of millions of users have non-hosted add-ons that were installed without their informed consent. Users run the risk of picking up unwanted extra add-ons and other software every time they download software over the Internet. Even updates of software that many users find indispensable or software from download sites run by trusted news organizations come bundled with these unwanted extras. Their Internet experience is being shaped by these third party add-ons in ways they did not choose and that benefit third parties and not the user. Most of these unwanted add-ons are advertising related in some way, tracking user actions and altering content. These add-ons are not created with user security in mind and can break fundamental browser security. These violate another of Mozilla’s basic principles: Individuals’ security and privacy on the Internet are fundamental and must not be treated as optional.

Signing Add-ons

The solution we are pursuing, as described in our last post, is for the builds used by the majority of Firefox users to require that add-ons be signed by Mozilla. It is heartbreaking that there are so many malicious developers in the world intent on taking advantage of others, but we’ve reached the same conclusion as other similar ecosystems that there needs to be a referee looking our for the user’s interests. Firefox users will still be able to shape their online experience through installing add-ons created by others: for the vast majority of them nothing will have changed in that regard. This does, unfortunately, place an additional burden on add-on developers: they will have to develop against an unbranded but otherwise identical version of Firefox that we will provide.

Many developers have asked why we can’t make this a runtime option or preference. There is nowhere we could store that choice on the user’s machine that these greyware apps couldn’t change and plausibly claim they were acting on behalf of the user’s “choice” not to opt-out of the light grey checkbox on page 43 of their EULA. This is not a concern about hypotheticals, we have many documented cases of add-ons disabling the mechanisms through which we inform users and give them control over their add-ons. By baking the signing requirement into the executable these programs will either have to submit to our review process or take the blatant malware step of replacing or altering Firefox. We are sure some will take that step, but it won’t be an attractive option for a Fortune 500 plugin vendor, popular download sites, or the laptop vendor involved in distributing Superfish. For the ones who do, we hope that modifying another program’s executable code is blatant enough that security software vendors will take action and stop letting these programs hide behind terms buried in their user-hostile EULAs.

The other common question is why developers can’t have their own certificates and sign their own add-ons. This would require Mozilla to function as a Certificate Authority which is currently not in our expertise. It also means we would not be able to run security scans on the add-on code. The only thing preventing a malicious add-on in that case would be the strength of our contracts requiring non-malicious code and our ability to bring legal action should those contracts be breached. This approach would favor established companies in jurisdictions where we have offices and would be extremely unfair to individual developers, especially those outside those regions. We feel the community would be better off if we put our resources into the review and scanning process that can treat everyone equally rather than setting up a certificate issuing infrastructure.

More Info and Discussions

The previous blog post on this issue generated a lot of feedback and discussion – we anticipate you will want to discuss this again. The most effective place for these discussions to take place is on the Add-ons User Experience newsgroup.

We created a wiki page about Extension Signing where we will post all of the information we have about it. It includes an FAQ that offers answers to many of the questions the community has posed, as well as some questions that are still pending a definitive answer. We will also continue posting updates on this blog.

12 comments on “The Case for Extension Signing”

  1. Mindaugas J. wrote on

    > Will there be an upload and signing API so I don’t have to manually upload each new version of the add-on?

    > This isn’t currently part of the plan for the first version of this project. However, we have received enough requests for this feature that we’re looking into ways to make this happen.

    Yet I could not find any bug related to this. It is definitely not among tracked/dependencies of does not sound like it

  2. Alexander J. Salas B. wrote on

    For reference also:
    Introducing Extension Signing: A Safer Add-on Experience

    Signing an extension on MDN:

    Self-signing for test on MDN:

    My question is: How I can check if my cert provider is a valid root CA for Code Signing Request (CSR) in Mozilla products?

    1. Alexander J. Salas B. wrote on

      I can see, only be signed by the system of AMO and only accepted this signature.

  3. Robert Zenz wrote on

    Am I seeing this correct that there is no option to turn it off, is first and foremost about slowing down possible malicious software? Like an “installer/setup” that tries to inject an addon into the current profile?

    1. Michael Buckley wrote on

      That is what they have been arguing in everything they have said in the last month. Basically the only option that malicious installers will have that want to get their adware/spyware filled extension into Firefox is get it signed (and Mozilla will say no) or patch the Firefox binary.

  4. Robert Zenz wrote on

    The wiki states that the developer/unbranded edition will only be available in en-US locale. What is the reason for that?

  5. DAOWAce wrote on

    Driver signing is now live and causing massive issues.

    Older versions of Firefox (tested v28, pre-australis) and forks of Firefox (such as Pale Moon) now crash when initializing an update to signed addons.

    People now need to manually disable updating of every single addon obtained from the AMO.

    Big, big mistake from Mozilla.

  6. Toady wrote on

    I see no information on how the automated submission system for developers to submit there addons for signing, i.e a command line tool for this would be a great idea to automatically submit it and return the signed addon via a download link or if the addon requires extra attention open a page with a ticket like system.

    How can we painlessly automate this process

  7. Terrell Kelley wrote on

    Something I would like to see before you go live with this is telemetry data on the commonest non-AMO extensions. From there, we could probably pretty easily figure out which ones users intentionally install. From there, we can determine if there are any that are abandoned and won’t be signed. And, from there, we determine which ones don’t have a replacement on AMO or one that works as well. We can then file bugs on those to see if we can get them updated enough to be signed, even if they are only preliminarily hosted.

    I have been personally experimenting with one such extension I assume must be fairly popular, since it is still recommended on MozillaZine, and there isn’t a fully featured replacement on AMO. It’s Keyconfig by Dorando, and is the only keybinding program that covers all keybindings. I know I’ve had some trouble getting it signed, and I at least have done some minor XPI work in the past. Granted, this is a fairly old addon, designed for Gecko 1.9, but it does still work on current Firefox and even works with Electrolysis on NIghtly. Still, being old, it uses some bad practices that I’ve had to fix.

    (If you wonder why I picked this particular addon: I use it to disable F11 and Ctrl zoom on my parents computers–they use it with a wireless keyboard, which sometimes falls or their lap dogs will jump on them. There was only one other addon that offered any keybindings, and it didn’t have these.)

    1. Terrell Kelley wrote on

      Quick edit to the above: I mean file bugs in Bugzilla, for others to take and fix up, like is happening with Electrolysis compatibility.

      As the above indicates, we can’t depend on Electrolysis breaking them.

  8. Giota wrote on


    I am a new firefox extension developer and followed these steps to sign the xpi with a TEST certificate, unfortunately with no success (keep getting Author not verified).

    Today I found this blog post As I understand I don’t need to bother with manually signing my xpi and obtaining a valid software developer code-signing certificate (for example Unizeto Centrum), since signature verification will be done by AMO right?

    Could you please confirm above and give more details regarding submission process? When will this take place?

  9. Synonymous wrote on

    “[…] but we’ve reached the same conclusion as other similar ecosystems that there needs to be a referee looking our for the user’s interests.”
    Which of those prevent users from disabling that mechanism?