Mozilla's Add-on File Registration System has serious consequences for some developers
If you are a developer you have two options currently to distribute your add-on to the Firefox community. You can either go the official route, create an account over at Mozilla AMO, upload your add-on to the official site and distribute it through it, or avoid this altogether and distribute the add-on via third party sites or software installations exclusively.
Most add-ons as far as I can tell are offered on the official website. Some popular ones are not, like HTTPS Anywhere for example which is only distributed via the EFF site directly.
The main problem with these third party hosted add-ons is that they have not been tested for malware or other code that may impact the user in a negative way.
For Mozilla, the situation is even more complicated. It is sometimes difficult to get hold of these add-ons, if they are mentioned in bug reports for example, as there is sometimes no direct way of downloading and installing them.
This is for instance the case when add-ons are distributed solely in installers, for instance in wrappers that many download portals use these days to generate extra revenue.
Add-on File Registration System
The Add-on File Registration System is part of the larger AMO Squeaky project which aims to improve the user experience surrounding add-ons.
Note: AMO refers to the official Mozilla Add-on repository.
The main idea behind the project is to make it mandatory for add-on developers to submit their add-ons to the registration system before they can be installed in the browser.
There is no change involved for developers who distribute their add-ons via the official add-on repository on the Mozilla website, as it will be just added to the process.
Developers who do not use the official site to distribute their add-ons on the other hand will have to submit it to the index by uploading it to the Registration System. If they do not, Firefox won't install their add-ons. The add-ons that they upload won't be published on AMO or anywhere else.
Doing so ensures two things:
- Mozilla has access to all Firefox add-ons regardless of how they are distributed.
- All add-ons are checked for malicious code.
Files that are uploaded this way are scanned for malicious code and then hashed twice (once packed, once unpacked) if found clean. It is likely that Firefox will use the hash to determine whether add-ons can be installed in the browser or not.
On the user side of things
When users try to install unregistered files, they will receive a message informing them that the add-on cannot be installed. Mozilla plans to use a transition period for that. In the first phase of it, errors are only displayed in the Browser Console but the add-ons will be installed as before. The notification message is displayed in the second phase, with an option to override it so that the add-on can be installed regardless of it.
Once the transition period is over, only the message will be displayed but without options to override it. If extensions are side-loaded, a message about the integration will be displayed in a tab in the browser informing users of the same consequence.
Add-ons will be installed if connection errors are encountered during validity checks. Mozilla plans to run periodic registration checks for all add-ons so that extensions that should not have been installed are discovered this way.
Add-on developers do not have to register their test versions. Mozilla is currently considering two options:
- A startup switch that overrides the registration check
- A whitelisting approach to whitelist specific add-ons based on ID.
Closing Words
The proposal tries to create a registration system for all add-ons created for the Firefox web browser to improve the user experience by scanning all add-ons available for the browser and making them available to Mozilla for further investigation and reference.
This should in theory reduce the chance that malicious extensions are installed in the browser. A positive side-effect of this can be that some companies who like to distribute add-ons via third party software installations may not do so anymore because of the new requirement.
It is however also likely that some add-ons that are currently offered via third party sites won't be uploaded to the new system, for instance if they have been abandoned by their developers or if the developer does not want to go through that process every time the add-on is updated.
Advertisement
Firefox has been my preferred browser for many years, but I really cannot abide the ongoing introduction of these non-togglable, non-overridable “nanny state” features. Mozilla’s PR still claims a goal of empowering users, supporting user choice — obviously that claim is now specious, if not outright hypocritical.
For me, the “health reporting” feature or, more importantly, the switcheroo (default setting now has the user OPTED-IN) was a wake-up call. Yesterday (relatively speaking) the user agent wouldn’t “divulge” its particulars unless I opted-in. Today, I’m expected to read the fine-print (which is presented once, ever) and preserve my privacy by opting out. Yes, I understand that I may later wade through the preferences dialogs/tabs/panes and opt out. Yes, I understand that the transmitted “health report” contains zero personally-identifying data… today, but what about tomorrow, or whenever the remote decides to push an update containing yet another switcheroo? With that in mind, I object to the presence of this feature, period. Choice? No. Mozilla provides no choice to download a user agent containing only selected, ala carte, xpcom components.
An earlier commentor mentioned “dumbing down”. Please, let’s get past “rational ignorance” — time spent tweeting and blogging to gripe about unwanted features would be better spent on building a new browser forked from the firefox code. No, palemoon is not a happy alternative; that’s just someone’s “no, you can’t see the details of my build environment” ego tripping project. Compiling and maintaining a codebase stripped of the “social”, “health report”, mibbit, 30boxes, etc non-browser shite, along with any privacy-unfriendly or choice-limited functionality, really seems like a noble, and overdue, course of action.
This means that I’ll end up with browser where this freaking control policy won’t be implemented, will it be some special FF version, or some other browser.
Who is Mozilla kidding, they don’t have the infrastructure mainly people to review the addon in any sense of a timely manner. Xmarks released a critical update 6 months ago, but the people at AMO don’t seem to care so people who install xmarks at the AMO site languish with an already fixed incompatibility.
Then there addons like My Wot who seems to have some of inside cronyism priority, their updates get reviewed and released on the same they release it their general site even though every other addon takes weeks or months for AMO people to grace it presence.
I might conjecture that at a high level this is Mozilla’s response to pressures similar to those faced by MS with the Windows Store, Mac with the Mac App Store, Linux official repositories, etc. The parent concern wants a diverse app/add-on/application ecosystem, and at the same time does NOT want malware and shoddy buggy software infesting the repositories. Understandable. As Martin and others have noted, the Windows store in particular has a lot of cruft floating the surface right now; I wouldn’t be surprised if MS refines its app vetting process too.
Personally, I would prefer a simple 2-part system: a category of “recommended” add-ons, which have been vetted and approved, and a category of “unchecked, wild” add-ons. Both types could be installed, but it would be on the user to check the validity, hash, PGP/GPG signing, etc.
https://wiki.mozilla.org/Apps
Something like that may yet happen. This front is expanding rapidly, and evolution continues. What if https://wiki.mozilla.org/Apps, the section of Mozilla’s wiki dealing with apps, could become a user-driven public encyclopedia of apps and add-ons — users and developers post reviews, bug reports, warnings, etc?
The reason for some developers not to use AMO (beside those Q mentioned) can also be that it takes a long time before add-ons are reviewed. It takes far too long before critical updates can be retrieved over AMO. I wonder how fast this registering process will be. Especially how fast the add-on is added to the whitelist; not being able to install an update because it hasn’t been whitelisted is bad.
Other stuff is experimental in AMO, as well, if I install it it might do bad things. No security gain here. The process let’s me see if the file I downloaded has been tampered with (the hash wouldn’t match), while downloading. This could be also avoided by using SSL encryption. Some security gain. The developers of add-ons can sign there add-ons with PGP/GPG and I can verify them before installing them. Well, there’s the problem that I have to get the right key the first time I check the correct signature, but someone could also be able to upload the modified add-on and it might still get whitelisted. Maybe some security gain.
Mozilla gets much more control, especially if they deny the installation of add-ons that have not been whitelisted. Like “Q” mentioned this couldn’t be just add-ons with malicious behavior, it also could be add-ons that add functions Mozilla removed previously. (Once I would have said, they wouldn’t do something like that, but I’m not sure anymore.)
This article mainly focuses on Add-Ons meant for public distribution.
Entities that use add-ons that are not meant for third-party distribution or general third-party distribution such as add-ons developed for a group or person for private or commercial use.
Such often is in consideration of a fee.
Some examples:
A company employee writing extensions to better use browser in the company. It may be quite undesirable to release such extensions to a third-party such as Mozilla Foundation (especially for free).
An natural person writes an extension for his personal use.
There are also other issues that arise, such as:
Mozilla benefiting from the code submissions that would not have otherwise been submitted.
Political issues that may come to exist or design changes unwanted by Mozilla (an example could be: Mozilla wants the User Interface to behave a certain way and may not approve extensions that do not behave that certain way).
In my opinion, the change that all add-ons must be submitted to Mozilla is particularly negative, especially for professionals or their clients.
Do not fool yourselves, this move is about Mozilla gaining more control over the users and the developers. This has nothing to do with the security of the add-ons or about Mozilla caring for their user base…
What about browser integration add-ons for download managers ?
As far as I understood it, all add-ons need to be submitted.
Great. Another step in the direction of dumbing-down and ruining Firefox. I use 5 add-ons that have been abandoned years ago. they still work with another add-on that overrides compatibility checks installed.
On the bright side – Palemoon will probably never introduce this.
It’s also worth mentioning that not all add-ons on AMO have been checked by Mozilla. Most are considered “experimental”, “not revieved” or “have been only preliminarily reviewed by Mozilla” so there is no difference between downloading them from AMO and another site.
bit strange. all Mozilla needs to do is progressively build a database of all add-ons by checking add-ons whenever a user tries to install one. check against a central registry. if the add-on isn’t passed as legit, ask the user to upload it for review by Mozilla. if Mozilla eventually approves the extension, and a notification back to the user alorng if the user wants too install the now-vetted extension. too easy. works much better for the end user than simply refusing to install.