A clarion call from the Electronic Frontier Foundation (EFF) warning about upcoming changes to the Chrome browser's extension API was not the first such—from the EFF or from others. The time of the switch to Manifest V3, as the new API is known, is growing closer; privacy advocates are concerned that it will preclude a number of techniques that browser extensions use for features like ad and tracker blocking. Part of the concern stems from the fact that Google is both the developer of a popular web browser and the operator of an enormous advertising network so its incentives seem, at least, plausibly misaligned.

Manifest V3 was first proposed in late 2018 as an eventual replacement for Manifest V2, which is the current extension API that is supported by both Chrome and Firefox. These APIs provide the tools that extensions use to manipulate the browser state to customize the web-browsing experience in some fashion. Extensions can change the user interface in various ways, observe and modify the browser behavior for things like bookmarks and tabs, manipulate the requests (and their content) that the browser makes, and more.

There are two main changes that Manifest V3 makes which are problematic for various types of content blockers. The first is the removal of the ability for extensions to block requests that the browser makes using the webRequest API. Instead, extension developers would need to use the much more restrictive declarativeNetRequest API, which has limits on the number of rules that can be used for blocking sites. The EFF described the impact of that change in a mid-2019 post highlighting problems with Manifest V3:

Currently, an extension with the right permissions can review each request before it goes out, examine and modify the request however it wants, and then decide to complete the request or block it altogether. This enables a whole range of creative, innovative, and highly customizable extensions that give users nearly complete control over the requests that their browser makes.

Manifest V3 replaces these capabilities with a narrowly-defined API (declarativeNetRequest) that will limit developers to a preset number of ways of modifying web requests. Extensions won't be able to modify most headers or make decisions about whether to block or redirect based on contextual data. This new API appears to be based on a simplified version of Adblock Plus. If your extension doesn't work just like Adblock Plus, you will find yourself trying to fit a square peg into a round hole.

[...] For developers of ad- and tracker-blocking extensions, flexible APIs aren't just nice to have, they are a requirement. When particular privacy protections gain popularity, ads and trackers evolve to evade them. As a result, the blocking extensions need to evolve too, or risk becoming irrelevant.

The second change is a switch away from background pages, which are currently used by extensions to perform tasks behind the scenes, to service workers, which are meant for a different use case than extensions. Content blockers currently use background pages to continue to monitor requests being made from pages for as long as the user still has the page open in a tab. In that way, ads and other undesirable content that gets requested well after the main page gets loaded can be handled based on the extension's requirements. But service workers are shut down after five minutes, which means that any initialization done for the extension is lost; meanwhile, any background processing stops too. The shutdown is meant to reclaim the memory being occupied by those worker processes, but extension developers sometimes need to keep it around. The EFF described some of the problems with all of that in a November blog post:

In short, Service Workers were meant for a sleep/wake cycle of web asset-to-user delivery—for example, caching consistent images and information so the user won't need to use a lot of resources when reconnecting to that website again with a limited connection. Web extensions need persistent communication between the extension and the browser, often based on user interaction, like being able to detect and block ad trackers as they load onto the web page in real time. This has resulted in a significant list of issues that will have to be addressed to cover many valid use cases.

The timeline for Manifest V2 support in Chrome, which was published in September, shows a limited runway for extension authors before they need to "upgrade". In January 2022, the Chrome Web Store will stop accepting new Manifest V2 extensions, except for those marked "private", which means they are only available to users in a specific organization. In June 2022, new private V2 extensions will be banned. Any existing V2 extensions can be updated until January 2023, but after that, Chrome is effectively V3-only.

Some of the changes in Manifest V3 seem unambiguously positive, however, including the removal of remotely hosted code for extensions. It is, of course, impossible to ensure that an extension does what it is supposed to, and does not, for example, send tracking information off to some dodgy site, if the code can be changed from afar.

The reasons behind Manifest V3 seem reasonable as well. In the announcement of its availability in Chrome beta versions, almost exactly a year ago, those reasons come down to security, performance, and privacy, though much of that is overblown or inaccurate according to the EFF. There seems to be a clear disconnect between how existing content-blocker extensions work—how their users want them to work—and how Google views the privacy threats inherent in the existing extension API:

For extensions that currently require passive access to web activity, we're introducing and continuing to iterate on new functionality that allows developers to deliver these use cases while preserving user privacy. For example, our new declarativeNetRequest API is designed to be a privacy-preserving method for extensions to block network requests without needing access to sensitive data.

The declarativeNetRequest API is an example of how Chrome is working to enable extensions, including ad blockers, to continue delivering their core functionality without requiring the extension to have access to potentially sensitive user data. This will allow many of the powerful extensions in our ecosystem to continue to provide a seamless user experience while still respecting user privacy.

Of course, content blockers are perfectly positioned to have a lot of detailed information about what their users are doing on the web. That is, obviously, exactly the point. As long as those extensions only use that information locally, and for the benefit of their users—not the developers or corporate owners—all should be well. That's not to say we have not seen malware in web extensions, including ad blockers, but those are the kinds of problems best addressed through extension vetting, both by browser-extension stores and the user community. Restricting content blockers to the actions Google (or anyone) thinks they should be able to do might seem safer, perhaps it even is, but it seems to mean that the kinds of content blocking available to users is being drastically curtailed in Manifest V3.

The EFF had some suggestions for better ways to address the problems in its November post. Not requiring a switch to declarativeNetRequest was first on the list. Extensions that only need the functionality provided in that API could make the switch, while: "Extensions that use the blocking webRequest API, with its added power can be given extra scrutiny upon submission review."

For its part, Mozilla has decided to take something of a middle course. It wants to support cross-browser extension development, so it will implement Manifest V3, but will not force the use of declarativeNetRequest (which Mozilla abbreviates as "DNR"), at least for now:

After discussing this with several content blocking extension developers, we have decided to implement DNR and continue maintaining support for blocking webRequest. Our initial goal for implementing DNR is to provide compatibility with Chrome so developers do not have to support multiple code bases if they do not want to. With both APIs supported in Firefox, developers can choose the approach that works best for them and their users.

We will support blocking webRequest until there's a better solution which covers all use cases we consider important, since DNR as currently implemented by Chrome does not yet meet the needs of extension developers.

That Mozilla blog post is from May, but it is in keeping with Mozilla's position as described in its Manifest V3 FAQ from 2019. While the company wants to be as compatible with Chrome as it can be, Mozilla says that it will not blindly follow Google's lead if those changes negatively impact its users and developers. The question of background pages versus service workers is less clear, however, though Mozilla was still working on the feature as of May. It is being tracked in a Bugzilla bug, which mentions several use cases where service workers will not provide an adequate replacement.

In general, this seems like a fairly heavy-handed approach from Google. It has a dominant position in the browser market and plausible reasons to want to restrict ad blocking, so the claims that Chrome is simply making ad blockers safer is not completely believable, at least for some. In addition, extension authors have said that it will be difficult or impossible to accomplish their tasks using Manifest V3. For example, the EFF's Privacy Badger extension for blocking invisible trackers will be hampered:

It appears that Privacy Badger will no longer be able to dynamically learn to block trackers, report what it blocked on a page, block cookies from being set or sent, strip referrer headers, nor properly support EFF's Do Not Track policy.

If you remove what makes Privacy Badger unique, replacing it with basic list-based blocking, what are you left with?

Similarly, the uBlock Origin ad-blocking extension will be unable to continue doing its job, as described in a GitHub issue. UBlock Origin developer Raymond Hill ("gorhill") has commented multiple times in the bug about problems stemming from the switch to Manifest V3. Most recently, he said:

Given how the deprecation of a blocking webRequest API put a lid on innovations (and regressions in capabilities in the case of uBO [uBlock Origin]) regarding content blocking, it does seem the move could be the "Not-Owned-But-Operated" strategy applied to content blocking -- the declarativeNetRequest API means the capabilities of (not-owned) content blockers are ultimately operated by Google through the limitations of the API the content blockers must use.

In a lengthy Reddit thread about the EFF's most recent Manifest V3 post (naturally there is another on Hacker News), "Brawl345" wrote that Manifest V3 made a lot of things easier for them, but did recognize that there are a number of shortcomings, including the ability to do dynamic filtering.

In general, Manifest v3 is a good idea but executed in the wrong way. I'm actually one of the few people in this thread (I bet) that actually ported some of my extensions to Manifest v3 and there are many good parts and some bad that make the whole experience kinda bad.

What seems clear, though, is that Chrome users will have less-capable content-blocking extensions available starting next year. That will, perhaps, decrease the capabilities of malicious extensions, thus increase the security of Chrome users from those kinds of threats. But privacy-conscious users, who seemingly only make up a tiny fraction of browser users anyway, will want to make a switch to Firefox—if they haven't already.

Hopefully, by 2023 (or sooner), Google will relent on the most onerous restrictions, but that hope may well be forlorn. On the other hand, there is good reason to believe that Mozilla will keep providing features that are useful for content blocking even if it means extension developers have to maintain two versions. And in the meantime, maybe "everyone" can come up with a standard for browser extensions that serves the needs of all web users, regardless of their interest in being the product. Hope springs eternal.