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 addons.mozilla.org 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.
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.