A grim outlook on the future of browser add-ons

A few days ago Mozilla announced the release of their new Android browser. This release, dubbed “Firefox Daylight,” is supposed to achieve nothing less than to “revolutionize mobile browsing.” And that also goes for browser extensions of course:

Last but not least, we revamped the extensions experience. We know that add-ons play an important role for many Firefox users and we want to make sure to offer them the best possible experience when starting to use our newest Android browsing app. We’re kicking it off with the top 9 add-ons for enhanced privacy and user experience from our Recommended Extensions program.

What this text carefully avoids stating directly: that’s the only nine (as in: single-digit 9) add-ons which you will be able to install on Firefox for Android now. After being able to use thousands of add-ons before, this feels like a significant downgrade. Particularly given that there appears to be no technical reason why none of the other add-ons are allowed any more, it being merely a policy decision. I already verified that my add-ons can still run on Firefox for Android but aren’t allowed to, same should be true for the majority of other add-ons.

Historical Firefox browser extension icons (puzzle pieces) representing the past, an oddly shaped and inconvenient puzzle piece standing for the present and a tombstone for the potential future
Evolution of browser extensions. Image credits: Mozilla, jean_victor_balin

Why would Mozilla kill mobile add-ons?

Before this release, Firefox was the only mobile browser to allow arbitrary add-ons. Chrome experimented with add-ons on mobile but never actually released this functionality. Safari implemented a halfhearted ad blocking interface, received much applause for it, but never made this feature truly useful or flexible. So it would seem that Firefox had a significant competitive advantage here. Why throw it away?

Unfortunately, supporting add-ons comes at a considerable cost. It isn’t merely the cost of developing and maintaining the necessary functionality, there is also the performance and security impact of browser extensions. Mozilla has been struggling with this for a while. The initial solution was reviewing all extensions before publication. It was a costly process which also introduced delays, so by now all add-ons are published immediately but are still supposed to be reviewed manually eventually.

Mozilla is currently facing challenges both in terms of market share and financially, the latter being linked to the former. This once again became obvious when Mozilla laid off a quarter of its workforce a few weeks ago. In the past, add-ons have done little to help Mozilla achieve a breakthrough on mobile, so costs being cut here isn’t much of a surprise. And properly reviewing nine extensions is certainly cheaper than keeping tabs on a thousand.

But won’t Mozilla add more add-ons later?

Yes, they also say that more add-ons will be made available later. But if you look closely, all of Mozilla’s communication around that matter has been focused on containing damage. I’ve looked through a bunch of blog posts, and nowhere did it simply say: “When this is released, only a handful add-ons will be allowed, and adding more will require our explicit approval.” A number of Firefox users relies on add-ons, so I suspect that the strategy is to prevent an outcry from those.

This might also be the reason why extension developers haven’t been warned about this “minor” change. Personally, I learned about it from a user’s issue report. While there has been some communication around Recommended Extensions program, it was never mentioned that participating in this program was a prerequisite for extensions to stay usable.

I definitely expect Mozilla to add more add-ons later. But it will be the ones that users are most vocal about. Niche add-ons with only few users? Bad luck for you…

What this also means: the current state of the add-on ecosystem is going to be preserved forever. If only popular add-ons are allowed, other add-ons won’t get a chance to become popular. And since every add-on has to start small, developing anything new is a wasted effort.

Update (2020-09-01): There are some objections from the Mozilla community stating that I’m overinterpreting this. Yes, maybe I am. Maybe add-ons are still a priority to Mozilla. So much that for this release they:

  • declared gatekeeping add-ons a virtue rather than a known limitation (“revamped the extensions experience”).
  • didn’t warn add-on developers about the user complains to be expected, leaving it to them to figure out what’s going on.
  • didn’t bother setting a timeline when the gatekeeping is supposed to end and in fact didn’t even state unambiguously that ending it is the plan.
  • didn’t document the current progress anywhere, so nobody knows what works and what doesn’t in terms of extension APIs (still work in progress at the time of writing).

I totally get it that the development team has more important issues to tackle now that their work has been made available to a wider audience. I’m merely not very confident that once they have all these issues sorted out they will still go back to the add-on support and fix it. Despite all the best intentions, there is nothing as permanent as a temporary stopgap solution.

Isn’t the state of affairs much better on the desktop?

Add-on support in desktop browsers looks much better of course, with all major browsers supporting add-ons. Gatekeeping also isn’t the norm here, with Apple being the only vendor so far to discourage newcomers. However, a steady degradation has been visible here as well, sadly an ongoing trend.

Browser extensions were pioneered by Mozilla and originally had the same level of access as the browser’s own code. This allowed amazingly powerful extensions, for example the vimperator extension implemented completely different user interface paradigms which were inspired by the vim editor. Whether you are a fan of vim or not (few people are), being able to do something like this was very empowering.

So it’s not surprising that Mozilla attracted a very active community of extension builders. There has been lots of innovation, extensions showcasing the full potential of the browser. Some of that functionality has been eventually adopted by the browsers. Remember Firebug for example? The similarity to Developer Tools as they are available in any modern browser is striking.

Historical Firefox browser extension icons (puzzle pieces) representing the past, an oddly shaped and inconvenient puzzle piece standing for the present and a tombstone for the potential future
Firebug screenshot. Image credits: Wikipedia

Once Google Chrome came along, this extension system was doomed. It simply had too many downsides to survive the fierce competition in the browser market. David Teller explains in his blog post why Mozilla had no choice but to remove it, and he is absolutely correct of course.

As to the decision about what to replace it with, I’m still not convinced that Mozilla made a good choice when they decided to copy Chrome’s extension APIs. While this made development of cross-browser extensions easier, it also limited Firefox extensions to the functionality supported by Chrome. Starting out as a clear leader in terms of customization, Firefox was suddenly chasing Chrome and struggling to keep full compatibility. And of course Google refused to cooperate on standardization of its underdocumented extension APIs (surprise!).

Where is add-on support on desktop going?

Originally, Mozilla promised that they wouldn’t limit themselves to the capabilities provided by Chrome. They intended to add more functionality soon, so that more powerful extensions would be possible. They also intended to give extension developers a way to write new extension APIs themselves, so that innovation could go beyond what browser developers anticipated. None of this really materialized, other than a few trivial improvements to Chrome’s APIs.

And so Google with its Chrome browser is now determining what extensions should be able to do – in any browser. After all, Mozilla’s is the only remaining independent extensions implementation, and it is no real competition any more. Now that they have this definition power, Google unsurprisingly decided to cut the costs incurred by extensions. Among other things, this change will remove webRequest API which is the one most powerful tool currently available to extensions. I expect Mozilla to follow suit sooner or later. And this is unlikely to be the last functionality cut.

Conclusions

The recent browser wars set a very high bar on what a modern browser should be. We got our lean and fast browsers, supporting vast amounts of web standards and extremely powerful web applications. The cost was high however: users’ choice was reduced significantly, it’s essentially Firefox vs. Chrome in its numerous varieties now, other browser engines didn’t survive. The negative impacts of Google’s almost-monopole on web development aren’t too visible yet, but in the browser customization space they already show very clearly.

Google Chrome is now the baseline for browser customization. On mobile devices this means that anything beyond “no add-on support whatsoever” will be considered a revolutionary step. Mozilla isn’t the first mobile browser vendor to celebrate themselves for providing a few selected add-ons. Open add-on ecosystems for mobile browsers are just not going to happen any more.

And on desktop Google has little incentive to keep the bar high for add-on support. There will be further functionality losses here, all in the name of performance and security. And despite these noble goals it means that users are going to lose out: the innovative impact of add-ons is going away. In future, all innovation will have to originate from browser vendors themselves, there will be no space for experiments or niche solutions.

Comments

  • DavidGB

    Clearly you haven't been following the Github issues and Mozilla bugtracker bugs for Firefox Fenix/Daylight where the devs are posting that unrestricted installing of any extensions is very near to roll-out in Android Firefox Nightly.

    Wladimir Palant

    I have looked through quite a few Github issues, trying to understand what the issue with add-on support really is. I've seen lots of confused add-on developers but no clear statements on what to expect. Do you have a link for me?

  • Kim Cosmos

    The real reason for the addons problem was that when developers submit an addon they can choose which platform it runs on, OR check the 'all' box. Because firefox crowed cross compatability the developers always ticked 'all' despite android FF having no toolbar for launching these addons. The developers were assuming FF would check, FF assumed the developers would check. Consequently about 2/3 of all the android addons never worked. I reported this solution years ago but like google, mozilla sees the tablet market dominated by ipads and thus didn't give a shit. Poor peoples access to functionality, and thus adoption, has never been a developer concern. So their one killer app - extensions, which first made them dominate the desktop market and later could have let them dominate the android market was never implemented. All because of 1 check box

    Wladimir Palant

    It seems that you are right, I didn't realize that. This checkbox was implemented back when compatibility was declared in the add-on manifest for each Gecko-based application separately. So checking “all” was usually the right thing to do, it would allow any application from the add-on manifest. But with WebExtensions Mozilla dropped the ball here – rather than declaring compatibility per application, it's a single “gecko” entry in the add-on manifest now. But the AMO user interface didn't adapt to this change.

    If this is indeed the reasoning here, then it's rather sad. It would have been fairly easy for Mozilla to flag extensions using APIs that aren't implemented on mobile.

  • DaveRo

    I think that the Fenix team have been instructed to get more users at all costs. My guess is that Mozilla has decided that the current tiny and reducing 'market' share doesn't justify the expense of maintaining it. And I think they've decided that incremental change, and copying Chrome, won't achieve that: they have to build something new and different. They;re probably right about that.

    Addon users are collateral damage. It's been obvious for months that the team is only interested in 'popular' addons, ones with thousands of users. They've said that more addons will be allowed in the future - but there's no commitment and no timescale. And they don't sound sincere - nobody seems to believe them.

    They've now, belatedly, said they'll allow sideloading in nightly: https://github.com/mozilla-mobile/fenix/issues/14034 The wording of that - "In the near-term we want to..." doesn't make it sound important and imminent.

    Call me cynical, but I think it's a way of shifting the discussion off github to here: https://discourse.mozilla.org/t/add-on-support-in-new-firefox-for-android/53488/9

    I hope I'm wrong, that they're actually working on this, and it will go into beta at least.

  • PJ

    These two threads are the clearest messaging I've been able to find:

    https://github.com/mozilla-mobile/fenix/issues/11308#issuecomment-642075690, in which a Mozilla dev states: "We will likely never support sideloading on Release (or even Beta)"

    And the related issue: https://github.com/mozilla-mobile/fenix/issues/14034, which suggests that Mozilla has finally decided that maybe allowing at least addon devs/Nightly users to load non-whitelisted addons might be a useful idea.

    See also this PR: https://github.com/mozilla-mobile/android-components/pull/8052, which allows the internal addon manager component to be pointed at other "collections" on AMO.

    So it sounds like Moz has committed to the idea that users who want to use the stable release will not have permission to install their own addons.

    Fortunately, once the code is in Nightly it won't be hard to make a unrestricted fork of Stable. Even now, with the minimal case of choosing a different list from AMO, the PR for android-components is tiny, and the changes to expose it as a pref shouldn't be much larger.

    It's just sad to see where Moz's priorities have changed.

    Wladimir Palant

    To be fair, I think that “sideloading” means installing add-ons from sites other than AMO here. It doesn't say that installing arbitrary add-ons from AMO is never going to happen in release.

    Also, this pull request is in my understanding about a consistency change, for functionality mainly meant for testing pre-release versions of the browser. Does not really tell much about the plans.

    It doesn't look like Mozilla is really committed on anything at this point. And that's actually an issue…

  • davidpiano

    If there was good news, Mozilla would emphasize it. The fact that it has become hard to find any news, is a nearly-certain signal that all the news is bad... so bad that no one will admit to it.

  • sfink

    I'm not close enough to it to be confident, but from what I've heard you're off base with the gatekeeping argument. My understanding is that this is not at all a policy decision, but purely a technical one: specifically, the way Fenix is set up makes custom work required for each WebExtension API. You don't inherit everything that Gecko supports anymore. So to get the top 9 addons working, then looked at the union of APIs needed by those 9 and implemented those, with the intention of adding more in the future. I definitely can't speak to how realistic those future intentions are, though I'm guessing it's too early to judge yet because I imagine the team is still busy with the results of the wide-scale rollout right now.

    I wish I could point to a source for the architectural limitation I'm talking about here, but I don't remember where I heard it.

    I can't speak to your other complaints. Personally, I see addons as the main competitive advantage of Firefox on mobile, so I would have trouble understanding a product decision that didn't include them. But I don't get paid to make product decisions; maybe there's a reason for that? ;-) I could imagine future drivers, eg integration with desktop content and identity, but that feels further out and addons are the ones that are closest to hand.

    Wladimir Palant

    Yes, I was probably wrong when I said that this was purely a technical decision. The reason why I formulated it like this was: the union of the APIs used by these top 9 add-ons is already massive. For example, there is one ad blocker on the list, and I happen to know that ad blockers are very demanding. So maybe the implementation isn't mature yet, maybe it isn't quite complete, but it is definitely good enough for a large portion of the existing add-ons (yes, I checked with mine). Add to this a complete lack of documentation/progress tracking on what APIs work and what don't. I mean, with that documentation it should have been fairly easy for AMO to check compatibility on their end, they've done it before. But coming from outside, my impression is that this hasn't even considered.

    Personally, I sincerely hope that I got it all wrong and proper add-on support will be restored in Firefox on Android really soon. But seeing this mess sadly doesn't instill confidence. Add-ons are a messy affair, no doubt about that. So now that the rollout is complete, we have a status quo where any voices in favor of extending add-on support will have to fight other metrics.

  • Mozuser

    https://blog.mozilla.org/addons/2020/09/02/update-on-extension-support-in-the-new-firefox-for-android/

    Wladimir Palant

    Yes, I've seen it. Doesn't really add anything new however. So Mozilla will add more add-ons to the Recommended Extensions, like I said. They will also make it easier to test add-ons, in Nightly. But the important part is still missing, namely that the plan is to give up gatekeeping and to allow arbitrary add-ons.