Mozilla needs to adjust new review process for Firefox add-ons
Mozilla switched to a new Firefox add-ons review system recently which reduces the time it takes before extensions are listed on Mozilla AMO (the official Firefox add-ons store).
Firefox add-ons are scanned automatically when developers upload them, and when the add-ons pass the checks, are published on the website.
Mozilla employees and volunteers will continue to review all add-ons and add-on updates manually, but that happens after the publication of the add-on.
This means that there is a period of time in which add-ons are available for download and installation, or automatic update, in which they have only been vetted by automation.
A first batch of add-ons with mining scripts included was detected and reported recently. These add-ons were publicly available on Mozilla AMO, and have since been removed by Mozilla.
The add-ons in this case revealed the integration of mining scripts in the description, and that made detection relatively easy.
Mozilla's system is still better than that of Google Chrome, as Google does not manually review extensions for Chrome unless they are flagged for review.
The past years have shown that automation is not enough when it comes to protecting Chrome users from malicious, spying or otherwise problematic browser extensions. It seems likely, and the mining script extensions seem to confirm that, that Mozilla's automated system won't be 100% bulletproof either.
Incidents like this one paint the new WebExtensions system in a bad light, considering that it was advertised as being safer than the previous system. This is the case, as legacy add-ons could have done much worse if Mozilla would have implemented an automatic system back then already.
Here is what I think needs to be done to adjust the system:
- Mozilla needs to mark extensions that have not been reviewed manually. There is no distinction currently between add-ons that have been reviewed manually, and those that were reviewed automatically only up to that point.
- Firefox needs an option to block extension updates unless they have been reviewed manually.
Other options that Mozilla may want to consider include limiting the exposure of extensions that have been reviewed automatically only, or whitelisting very popular extensions from trusted developers only.
It seems highly unlikely that Mozilla will return to the manual review process for all extensions. While I would love to see that happen, as it is a big advantage over how Google handles things, I cannot see that happening.
Chrome is painted in a bad light time and time again when extensions manage to slip by the Store's automatic detection system, and it looks as if Firefox is heading the same way in this regard, maybe with faster responses to these incidents.
Now You: How would you handle this?
“The add-ons in this case revealed the integration of mining scripts in the description”
For the sake of clarity, DISCLOSED (vs “revealed”)
I agree that there should be a badge indicating whether or not the addon has been reviewed manually. I mean, I understand that Mozilla will be loathe to do so because it will highlight how much has yet to be done, but is there any other way for us as users to know which have undergone review?
Perhaps also there should be a badge that says “previous version reviewed” or something like that. So that even if the absolute latest version of Ublock Origin hasn’t been reviewed yet, users can still recognize that the developer has been found trustworthy in the past.
> How would you handle this?
I wouldn’t whitelist anyone. Accounts can be hacked, sold, and what a “trusted developer” should be is hard to define.
Limiting exposure is acceptable, it is how the review system works for legacy add-ons. You can publish them before manual review but the add-on should only be accessible on AMO with a direct link. Not search, not featured. But it kind of defeats the point: There will be legacy add-on death and a surge of new add-ons to compensate. This is important for users and Firefox itself, so if only throughout next year, new add-ons shouldn’t have to wait weeks and months before being accessible through search or featured.
So IMO a good solution is to make things clear, as you said a notice on AMO saying that such and such add-ons have been automatically reviewed but are yet to be manually reviewed is pretty fine. Like a yellow button with one line of text below. ( Similar to this https://addons.mozilla.org/en-us/firefox/addon/easy-access/ )
For updates, I would cut that into manual updates and automatic updates. Manual updates are done through about:addons, and this page can display information like AMO in between checking for an update and actually downloading and installing it.
Automatic updates are trickier. An option like you suggest is a decent solution, but why would the least secure option be the default ? But we can’t make the most secure option the default either, at least not during the coming year where many add-ons will be brand new and therefore bugged or in need to better fit user requirements based on feedback, which translates to a need for quick updates. So I agree that the simplest route is an option for people to opt into “manually reviewed updates only” mode.
But we can also prompt people who are relying on automatic updates, and have a default ON “don’t ask me again” checkbox. Each add-on would have an independent permission and prompt. Firefox can infer on its own that people who installed an add-on that had not been manually reviewed will be ok for non-manually reviewed updates, and so no need to prompt for these. This system requires more work and is built on top of the switch talked about in the previous paragraph, so whatever is done in the end the first (and perhaps only) step is the opt-in “manually reviewed updates only” mode.
Your idea that Mozilla needs to mark extensions that have not been reviewed manually is a good idea (suggestion).
Maybe it’s also wise to add a progress meter to explain how far the reviewing is in the total process.
And to make it possibel that people can distinction between add-ons that have been reviewed manually, is also a great idea.
The review itself doesn’t take days, it’s just the queue that can be long, and since add-ons that are new can jump right atop the queue if they are doing something sensitive, it can’t really be predicted when an add-on will actually get manually reviewed. So a progress meter would not happen.
Informing users about the present status of an add-on is pretty good and should be done without thinking twice. Dealing with updates to already installed add-ons is a slightly more involved fix that should also happen.
What happens to already installed bad addons? Is there a mechanism in place that Mozilla will notify users and remove the addon (extension) from their system?
Firefox has a daily-updated blocklist system ( https://wiki.mozilla.org/Blocklist ) that can automatically disable and immediately warn about bad add-ons.
Thank you! Excellent information.
off the top of my head, i think the only way to largely solve the manual review overload problem might be to automate the review process only for trusted devs – trusted being those who have been around for ‘x’ time and code cleanly
then all new/untrusted devs would be auto-flagged for a manual review
add to that a 1 to 3-strikes rule or something to drop repeat offenders
perhaps the community could help if the ‘report abuse’ thingy contained specific flagging options that could be processed auto-magically by moz, like checkboxes for ‘malware confirmed’, ‘malware suspected’, ‘adware confirmed’, etc.
regarding these mining scripts, i find this very interesting – i wrote a little about this here…
But does Google actually look at those flagged extensions? ‘Cause I’ve reported comments on YouTube multiple times and mistakes on Google Maps but rarely did they ever do something about it. Sometimes I even got a reply “no, we’re not going to fix that ’cause it’s not a mistake” from the GMaps team. That happened in the case where I reported a bus stop in the previous city I lived in. They placed the stop somewhere in the water even though it was supposed to be in the bus lane next to it. But they rejected my complaint ’cause they thought it did belong in the water. Really, a bus stop in the middle of the water instead of the bus lane? What kind of people work on GMaps?
So no, I don’t think Google takes flagged stuff seriously and I highly doubt they’re doing any better in case of the extensions website.
To be honest, I think that’s just laziness in the case of Google staff – I could list literally 100s of nonsense locations in Google Maps. But then you only have to look at the malware-nest their Android division laughingly call Google Play Store to realise there’s precious little safety in any Google-approved product.
So… all that talk and justifications about “legacy” extensions being unsafe and the outcome is this? Malicious stuff just coming through? Not that those claims about “legacy” were anything but PR nonsense but this is, well, funny.
“Firefox needs an option to block extension updates unless they have been reviewed manually.”
Amen to that!
I’d also like to see something similar to release channels but for add-on updates. That is if set to developer/nightly you’d get add-on updates quickly, while beta get the update one month later and “regular” one more month later.
If there an update is pushed to fix a known vulnerability then beta/regular users could get a notification about it and can choose to (A) update right away or (B) disable the addon until it reaches the beta/regular channels update time or (C) take the risk and keep using the add-on.
About review process itself, the automatic code review is “in plain english” “pure shit”, Google use it on Google Play and Chrome Webstore for years (yeah The Great Omnipotent and Teocratic Google) and a lot of malware and crapware pass it, even “mining crap” recently on Webstore too, so the correct approach is semi-automatic, but you need “volunteers” or “employees” or users to do it (right know), but users don’t know they are the “testers”, well that compromise “security” of users (but who cares no?)
My conclusion, Apple has a more coherent “review” system based on quality criteria, better than above examples, the fail is Apple applies “censorship” and “bad practices” like “… delete an extension and develop one like the previous one days later”, delete p2p and other extensions “ad blockers” etc or simply “competitors” (documented cases)
We as users, and me, specifically want to control my environment and to be free and have choices no imposition, “dictatorship” and control are “grey line” concepts… when approach to “repositories control and review”, a community approach and be conservative is the best way (flag potentially dangerous if not “explicitly safe” etc)