MV3 is lacking features

Max Baumann

You probably have heard of Chrome's war with browser add-ons. In a few months, ~80% of all add-ons on the Chrome Store will stop working as Google forces everyone to migrate to its new manifest version 3 (MV3). How can a company at the core of browser security be so irresponsible with their decisions?

Update (31. Aug.)

This is what a Googler added to the thread today:

Short term, our plan is to address background access to the clipboard through the introduction of offscreen documents. Longer term, we would like to bring the Clipboard API – and as many other capabilities that currently require DOM access as reasonably possible – to extension service workers.

The obvious question, whether any of this will land before the deprecation date of MV2 was not answered yet.

Wait, what are manifest versions?

The entrypoint for a Web Extension is the manifest.json file. This file declares actions, commands, permissions but also basic information like name and version. It also declares what manifest version the extension has. It's like an API version where every manifest version is a breaking change and does things differently.

If you ask yourself who standardizes these manifest versions, the answer is the Chromium team and, by extend, Google. When Mozilla noticed people where developing add-ons for Chrome but not for Firefox they started to deprecate their own system and build the Web Extensions APIs. It is pretty much the same as the Manifest v2 (MV2) for Chrome, with lots of differences here and there, but nothing a polyfill can't fix.

In 2018 Google announced manifest version 3, with the goal of making things more Secure, performant, private (Google LOL) and webbier, whatever that means. They also announced they won't accept new MV2 add-ons to their store starting January 2022 and fully deprecate MV2 add-ons starting 2023.

Recent Criticism

It did not take long before people started to get angry:

Users don't like it, developers don't like it, security and privacy advocates don't like it. What reached me at the time was mainly "Web Blockers are going to die when MV3 is forced upon us", which for some reason I did not give too much attention to.

Quick explainer

Web Blockers like uBlock Origin use the webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight. Kind of makes sense for a blocker to do that. Using this API an Extension can make it's own rules on how to block requests. Want to block a list of domains? Sure. Want to build complex Regexes to find what URLs to block? Have fun! Use state-of-the-art artificial intelligence to block a request based on it's response body? Knock yourself out. You can also use it to replace the content of a response or redirect it somewhere else for example. It allows any extension to become your personal air traffic controller for the Web.

And it's gone in MV3!

You heard that right. No add-ons should access your traffic anymore. According to the privacy violating, power abusing and product killing advertising company Google that change was made to protect your privacy.

The replacement is called declarativeNetRequest. An API to register filters and modifiers with the browser using a ruleset. This is a problem. Take it from Raymond Hill (uBlock origin):

An example that the declarativeNetRequest API is an obstacle to innovation in content blockers. In discussion with filter list maintainers, last year I implemented a new feature, the ability to use "entity" in domain= option. The DNR API does support domain= option, but it does not support "entity", which is the ability to use a wildcard in place of the effective TLD, to avoid to list all domains belonging to an entity. I can count over 420 filters currently in the default filterset which uses this feature, clearly a benefit to filter list maintainers. These filters would cease to exist in a DNR-based blocker. The core issue is the lid on innovation, which is key for content blocker to stay reliable. If the DNR API had been designed in 2014 according to the requirements of the time, content blockers would be awfully equipped to deal properly with the current landscape. The DNR API as designed now not only to set back content blockers, but to condemn content blockers to stagnate innovation-wise

But that's not why I'm here

A couple of days ago I had an idea for an add-on that could help me improve my workflow. Yesterday I got to work, nothing fancy just a 30 LOC project. It registers a background script, that itself then registers a Context Menu for github.com. You can right-click on a user's profile and it will copy their @users.noreply.github.com email address to the clipboard.

To do that we have the the Clipboard API. You are only allowed to use this API as a result of a user interaction. Turns out the onclick handler of a context menu is not called by a user interaction.

Fortunately there are the clipboardWrite and clipboardRead permissions for Extensions. Add-ons with this permission can access the clipboard anytime.

It is a MV2 add-on and therefore only works on Firefox. It took maybe an hour to get everything set up and working so I thought porting it to MV3 would be a piece of cake, because I use both Chromium-based browsers and Firefox on a daily basis.

I was wrong.

My rant

In MV3 add-ons don't have background pages anymore. They were replaced by Service Workers, which don't have access to DOM APIs, because they don't have a DOM.

If you clicked on the mdn link for the Clipboard API previously you may have stumbled across this:

Note: This API is not available in Web Workers

The Clipboard API is not available for Service Workers.

Turns out developers are not happy with this. Here is a bug filed on Chromium's issue tracker. In it developers of lots of different kinds of add-ons explained their need for this API, that Google just took away without replacement.

Only then it looks like (after the deprecation of MV2 was announced) the developers at Google were asked to think about this.

This is one API and you get bet that there are a lot more out there with some kind of compatibility issue. As one commenter put it:

So this will be yet another feature out of dozens butchered by ManifestV3 under the promise given by the Chromium team that switching to service workers is a step forward and a big improvement? So far this promise is a factual lie as there isn't a single improvement

Conclusion

A major browser company, tasked with making new standards in the WHATWG, W3C and so on is making changes without any consideration of how it will affect the developers that make their platform worth using.

There is a reason, why MV3 adoption is super low.

Quoting a commenter on HN:

V3 is, unfortunately, nowhere near usable. It'd be as if Microsoft had discontinued the Windows 95 user interface in favor of Microsoft Bob, in 1995. It's that not-done. I'd be opposed to the transition if it were done, but V3 is nowhere near workable. Documentation, APIs, the whole shebang. It's just unfinished.

I think I now know, what they meant by increasing "Webbiness" of Add-ons.

Less features = more secure I guess...