Here's what's happening to ad blockers in Google Chrome

Google has been working on a new platform for Chrome extensions over the past few years, called Manifest V3. The update has been controversial, with some changes negatively affecting content blocking extensions (ad blockers). Most of the focus has been on the uBlock Origin extension, as developer Raymond Hill stated back in 2019 that the changes “would be the death of uBO and uMatrix.”

Google just announced that the transition to Manifest V3 is back on the calendar, and extensions not updated to the new platform will start to be turned off as early as June 2024. The news lead to headlines like “Google's Manifest V3 changes will soon disable uBlock Origin on Chrome” and “Google to Force-Block Ad Blockers — Time to Get Firefox?” This is a pretty technical topic that can get confusing, and using rage bait in headlines has led to a lot of people thinking uBlock Origin and other ad blockers will be completely removed from Chrome, which is not the case.

This is my attempt to explain what’s going on with Manifest V3 and content blocking extensions in Google Chrome. I’ve been developing Chrome extensions for over a decade, so I can talk about this more in depth than others, but I will be referring to Hill and other developers for the exact specifics on how content blockers are affected.

What is Manifest V3, and why does it matter?

Manifest V3 is an updated software platform for Google Chrome extensions, which was first announced as a draft proposal in 2018 and became available to use in January 2021 (with the release of Chrome 88). It adds some new features for extensions, but it also changes some behaviors and removes a few APIs. In the software development world, this is called a “breaking change.” The last time Google did this was in 2012, with the introduction of Manifest V2, so it’s been a while.

Manifest V3 generally has the goal of making browser extensions safer, less resource-intensive, and more aligned with modern web development. Many extensions on Manifest V2 require background packages to function, which are essentially browser tabs that are hidden in the background, and Manifest V3 replaces these with service workers that are only activated when needed. Manifest V3 also blocks remotely-hosted code in extensions because it could be used to update extensions outside of the Chrome Web Store safety review process (remote lists or configuration files are still allowed). It’s also adds support for Promises to many Chrome APIs, which allows developers to write cleaner code, and there are other minor changes as well.

Google explains in its developer documentation, “Manifest V3 is a major step towards our vision for the extensions platform. Manifest V3 focuses on the three pillars of that vision: privacy, security, and performance, while preserving and improving our foundation of capability and webbiness.”

Google initially planned to stop accepting new Manifest V2 extensions in the Chrome Web Store starting in 2022, then start turning off Manifest V2 extensions in early 2023, culminating in the removal of all Manifest V2 extensions in January 2024. However, there were so many missing features and complaints that the timeline was paused in December 2022. Google started adding more APIs to Manifest V3 to close the functionality gap, including the Offscreen Documents API (for audio playback and other functions that don’t work in Service Workers) and User Scripts API.

With many (but not all) of the complaints now addressed, Google has resumed the timeline for migrating to Manifest V3. Chrome will start turning off Manifest V2 extensions as early as June 2024, but Chrome browsers deployed in organizations with custom extensions get to live until June 2025. After that, Google will (presumably) rip out all the code required to run Manifest V2 extensions.

Why are content blockers affected?

The most controversial change in Manifest V3 is replacing the Web Request API with a new Declarative Net Request API. The Web Request API is used by all content blocker and ad blocker extensions (except extensions already ported to Manifest V3) to monitor incoming network traffic, and then decide if a specific request should be allowed, blocked, or modified. The Declarative Net Request API is a completely different architecture.

The Web Request API allows an extension to monitor nearly all of your web browsing activity, especially if the same extension also has access to your active browser tabs. That’s a lot of trust to put into a browser extension, akin to giving an application Administrator access on a Windows PC.

Google said in a blog post from 2019, “because all of the request data is exposed to the extension, it makes it very easy for a malicious developer to abuse that access to a user’s credentials, accounts, or personal information. Since January 2018, 42% of malicious extensions use the Web Request API.”

The Web Request API can also slow down the entire browser because Chrome must wait for an extension to process every single network request, and the extension’s code might not be optimized for performance. That performance cost seems to be negligible in uBlock Origin and other popular ad blockers that have focused on optimization (uBO has an explainer wiki page), but there were probably other extensions not doing that well. It’s not hard to see a situation where multiple poorly-optimized extensions installed using the Web Request API could dramatically slow down Chrome, and the user would have no way of knowing the issue.

Google’s solution to those problems is the Declarative Net Request API. Instead of Chrome sending every network request to the extension, which then does all the filtering and processing and sends the result back to Chrome, the extension provides the list to Chrome and the browser does all filtering on its own.

The same blog post explains, “This approach has advantages for both user security and privacy, as well as performance. With a declarative approach, Chrome does not need to expose any sensitive data to the extension. The browser can perform the action requested by the extension without sending it all the data associated with the network request, because the extension already specified the conditions under which different actions are taken. This enables the extension to perform content blocking without needing access to all of a user’s personal information.”

That all sounds great! However, for the Declarative Net Request API to be a fully complete replacement, the Chrome browser must implement similar filter rules as content blocker extensions. Initially, it only supported AdBlock Plus-like syntax for filters and didn’t allow more than 30,000 filtering rules for each extension — for context, EasyList is just one of the lists enabled by default in uBlock Origin and other ad blockers, and it has over 75,000 rules. Updating most of those rules also required a full extension update, instead of the extension downloading new lists as needed on its own.

Raymond Hill, the main developer for uBlock Origin, wasn’t a fan of the original proposal. He said in one GitHub comment, “That new declarativeNetRequest API seriously reduces what blockers can do, to the point they will become distinguishable only by their UI, not their capabilities. As a user, I personally wouldn't accept browsing the world wild web without the advanced features in uBO, I find this unthinkable.”

Thankfully, Google kept working on the Declarative Net Request API to make it more capable. Chrome now allows extensions to include 100 rule lists, with up to 50 lists active at once. There are also additional filtering options, including an option to have case-insensitive rules, which cuts down on duplicates in filter lists. The maximum number of filter rules now varies by use case — an extension can now have up to 30,000 dynamic rules (filters downloaded by the extension) if they are deemed as “safe” (block, allow, allowAllRequests or upgradeScheme), an additional 5,000 other types of dynamic requests, and more filters included in the extension package.

It’s incredibly easy to see these changes as Google clamping down on ad blockers to protect its monopoly in online advertising. I don’t think that’s necessarily the case: Google knows as well as I do that a total crackdown would give governments like the European Union and United States more ammo for antitrust lawsuits. It would also be a motivator for more people to switch browsers, which would weaken Google’s browser monopoly. The stated claims about security benefits also make sense, because that’s just how software development works — old features that can cause security or performance issues are replaced with better (but sometimes less capable) solutions. A lot of people were upset 23 years ago when Windows ME removed real mode DOS, too.

The new Declarative Net Request API is still a downgrade in capability compared to the older API, but the feature gap has closed significantly. If a certain website finds a workaround for ads that Manifest V3 extensions can’t block, then you probably should just switch browsers or stop going to that site. I would like to see the rules limit continue to increase, though.

What’s happening to uBlock Origin?

With the general explainer about all content blockers out of the way, we can talk about uBlock Origin. It might be the most popular Chrome extension (at least among tech and privacy enthusiasts) that is affected the most by the new Declarative Net Request API, because it has implemented more complex filtering than most other ad blocking tools. Interestingly, Google’s recent blog post about improvements to the API mentioned AdGuard and Adblock Plus by name, but not uBlock Origin — even though most news coverage and online conversations have been focused exclusively on uBO.

Raymond Hill already has a spin-off extension, called uBlock Origin Lite, which runs as a Manifest V3 extension using the new API. It includes the same default rule lists as uBlock Origin, it’s more efficient on resources (because Chrome handles all the content filtering), and it doesn’t require permission to all pages like regular uBlock Origin. You can enable more advanced filtering by granting all permissions, though.

I tried browsing around with Chrome 119, switching between no ad blocking extensions, regular uBlock Origin, and uBlock Origin Lite. I didn’t notice a significant difference between Origin and Origin Lite on popular websites, except that Origin Lite doesn't have the element zapper for removing arbitrary elements in a page. That limitation seems to mostly be a design restriction to keep Origin Lite as lightweight as possible, rather than something enforced, but there is a discussion on implementing it. A full list of technical differences between uBO and UBO Lite is available on GitHub.

PWInsider with no content blocker: 2.3GB RAM

PWInsider with uBlock Origin Lite: 430MB RAM

PWInsider with uBlock Origin: 393MB

Fandom Wiki with no content blocker: 1.6GB RAM

Fandom Wiki with uBlock Origin Lite: 295MB

Fandom Wiki with uBlock Origin: 297MB

It’s worth noting that the memory usage of each example above (as reported by Chrome’s task manager) doesn’t reflect the memory consumed by extensions. There’s some additional overhead in uBlock Origin, but uBlock Origin Lite isn’t running any processes at all unless the settings panel is opened.

Since there’s already a Manifest V3 version of uBlock Origin, there’s only one question left: what will be the fate of the uBlock Origin extension currently on the Chrome Web Store? Will everyone with uBlock Origin installed be automatically updated to Lite, or will the Lite version remain a separate install? I asked Raymond Hill, and he’s still figuring out the best plan:

I haven't decided yet how this will work, and I don't know what is feasible. Forcing uBO Lite on people might not be the best move, as this would essentially obliterate all customization they might have made to uBO -- uBO Lite is too different from uBO to make a seamless transition. People can already move on their own to uBO Lite if they want, probably safest approach is to explicitly opt-in to uBO Lite, some might prefer to install a another MV3-based content blocker.

uBlock Origin for Chrome has over 34 million installations according to the Chrome Web Store. We’ll have to wait and see what happens.

What are other web browsers doing?

There’s a lot of confusion about how Manifest V3 and the Declarative Net Request API will affect other web browsers. Generally, this is the same situation as the Privacy Sandbox: Chromium web browsers are probably going to follow Google’s lead, while Firefox and Safari have more flexibility.

Mozilla Firefox

Mozilla has a reverse-engineered implementation of Chrome’s extension API, which is missing some APIs found in Chrome but also has some unique additions. The extra functionality already allows uBlock Origin on Firefox to work better than the Chrome version.

Firefox is working on support for Manifest V3, including the Declarative Net Request API, so that extensions created for Chrome can still be broadly compatible with Firefox. However, Mozilla does not currently have plans to remove support for Manifest V2 extensions, and V3 extensions on Firefox are allowed to continue using the older Web Request API. This comes with some potential performance and security issues, but Mozilla seems willing to deal with that. uBlock Origin is not going anywhere on Firefox.

Apple Safari

Apple also has a reverse-engineered implementation of Chrome’s extension API, again with some differences compared to Chrome. Safari 15.4 in 2021 included initial support for Manifest V3 extensions.

Safari’s implementation of the Web Request API was already more limited than Chrome, and there is a version of the Declarative Web Request API available for Manifest V3 extensions. Safari seems to require the newer Declarative Web Request API in Manifest V3 extensions — just like Chrome, but not Firefox. As far as I’m aware, Apple has not stated a timeline for extensions to migrate to Manifest V3.

Chromium browsers

Microsoft Edge has the same Manifest V3 support and extension APIs as Google Chrome. Microsoft initially planned the same migration timeline, but it was paused around the same time as Google stopped its timeline, and there’s no new plan just yet. Edge is moving forward with the same API changes to remain aligned with Chrome.

It should be easy enough for Chromium web browsers, such as Edge, Vivaldi, and others, to maintain Manifest V2 extension support if they want, until Google rips out the code sometime in 2025. After that point, each browser would have to maintain Manifest V2 (or at least some its APIs) without Google’s help, which would be a significant task. Even if that is accomplished, most of them use the Chrome Web Store as the main repository for extensions, which will remove all Manifest V2 extensions in 2024.

I expect most Chromium-based browsers to just build ad blocking directly into the browser, instead of trying to support external extensions with special APIs. Vivaldi did that in 2020, with the launch of Vivaldi Ad Blocker. For other content blocking needs, the Manifest V3 extensions in the Chrome Web Store will probably suffice.