The limited extensions on Android is for technical reasons. Instead of having zero extension support on release, they focused on supporting the APIs needed for popular extensions first and are working on adding the rest. It's an entire rewrite of the browser. There's still a lot of missing APIs they need to implement. Allowing every extension from AMO to work would be almost pointless because so many would be broken.
The fact of limiting the list of extensions that can be installed is indeed for technical reasons — I'm sure there are some extensions that don't work. But the list of which extensions can be installed is not restricted solely for technical reasons.
I use several extensions in Iceraven — Privacy Redirect; Bypass Paywalls Clean; I don't care about cookies — that work usefully. If there are any missing APIs, I haven't noticed them. These extensions can't be installed in Firefox for Android.
There's no technical difference between Iceraven and Firefox, except that Iceraven has a more generous allow-list. This isn't a technical restriction; it's a choice by Mozilla.
It's a valid choice — if they're aiming to curate a set of high-quality extensions, and prevent the use of lower-quality extensions — but it's a choice nonetheless.
> It's a valid choice — if they're aiming to curate a set of high-quality extensions, and prevent the use of lower-quality extensions — but it's a choice nonetheless.
Mozilla is also looking at monetizing their extension ecosystem by allowing the top makers of extensions to pay for placement. Perhaps, Mozilla could start letting only the highest paid extensions on Android.
Would this be "valid"? Uh . . . sure. It is also blatantly user hostile. I would rather Mozilla allow me to choose what I run, but Mozilla definitely isn't going to give the users that sort of freedom on release builds.
It seems that they've also talked themselves into believing that running extensions in the main process has all of a sudden become totally unsafe and absolutely irresponsible, while at the same time the solution employed on desktop (run extensions in a separate process) unfortunately isn't possible because on Android secondary processes might randomly be targeted by the low-memory killer at any time, which would break a lot of add-ons.
So a few extensions have been grudgingly permitted with extra scrutiny given during review, but they don't want to extend that effort to all add-ons, they don't want to back down to accepting the previous level of security, either, Android won't change its handling of child processes (and even if – any change there would take years to percolate throughout the phone ecosystem, plus a number of OEMs somewhat infamously are even more aggressive about killing seemingly unused processes), and re-architecting add-ons to cope with randomly being killed isn't an easy and immediate solution either.
