Google has been working on a new platform for Chrome extensions for quite a long time now, dubbed Manifest V3. Quite a lot of focus has been put on ad blockers, but there are plenty of other extensions out there that will stop working, too.

If you have extensions that are still built on Manifest V2, those will stop working very, very soon. Developers have been told for a long time that this change was coming as well, with Google pausing the upgrade process to address developer feedback and later resuming it in December last year. Since then, many apps have taken the plunge and switched over to Manifest V3.

While Manifest V3 certainly makes things harder for ad blockers, despite the headlines, ad blockers are not going away. Things are going to get harder with Chrome 127 and later, but it's not the death of ad blockers by any stretch.

What is Manifest V3? What browsers will be using it?

Extensions are built on Manifest versions

Manifest V3 is the latest extension platform for Chromium-based browsers, and it represents an overhaul of the architecture and policies that govern browser extensions. It's a massive update, though new Manifest versions are rare. Manifest V2 came out in 2012, and extensions on Manifest V1 were also expected to update or become incompatible with later Google Chrome versions.

With Manifest V3, there are implications for security, privacy, and performance. The biggest security improvement is the one that has most people concerned for the future of content blockers, and that's the replacement of the webRequest API with the declarativeNetRequest API. There are also more restrictive permission models, explicit declarations of what websites the extension should have access to, and script injections are now more restricted.

Other browsers will also be supporting Manifest V3 in the future, though most do not intend to remove support for Manifest V2. Mozilla's Firefox is a prime example of this, which has reverse-engineered Chrome's extensions API. While Mozilla has said that Firefox will support Manifest V3 in the future, there are no plans to deprecate support for Manifest V2. Most notably, Mozilla will still specifically support the webRequest API for Manifest V3 extensions that want to continue blocking content using it.

As for Vivaldi, the developers behind it have already confirmed that they will continue to support Manifest V2 until it's eventually removed from Chrome. However, how that will work is not exactly clear. Vivaldi installs its extensions through the Chrome Web Store, and Google will start hiding Manifest V2 extensions there very soon. The likes of Brave Browser are in the same spot as Vivaldi, though Brave has said that they will explicitly work to support a few Manifest V2 extensions, including uBlock Origin.

All Manifest V2 extensions are going to be removed from the Chrome Web Store entirely in June 2025, so for those browsers that do not have their own central extension repository, things may get a little bit difficult when it comes to installing these older, unsupported extensions.

How does Manifest V3 break content blockers like uBlock Origin?

The changes to webRequest make it harder to block content

Going back to 2019 when Google first announced that Manifest V3 would be coming, the developer of uBlock Origin Raymond Hill famously said that "this would be the death of uBO and uMatrix." Furthermore, he went on to say that he found the change unnecessarily restrictive towards extensions, mentioning that "issues of performance and privacy lie with websites" rather than extensions.

To be clear, though, Google absolutely had a problem with the webRequest API and how it was used by extension developers. This API allowed for an extension to see all of your traffic and web browsing, giving it complete access to everything you do online. In 2019, Google said that as of January 2018, 42% of all extensions were using this API, which I can only imagine rose even further after that.

Furthermore, there are performance concerns that come with using the webRequest API. For any extension that does, all network requests must run through the processing of that extension first. If an extension isn't optimized for performance or if you have a lot of extensions that run on your PC using this API, then you may find that pages are slow to load. uBlock Origin has already rebutted this point, but given that 42% of extensions back then were using the API, it's probably fair to say that not all of them were as optimized as the likes of uBlock were.

Where things are different with the declarativeNetRequest API is that rather than the extension doing all of the filtering, it tells Chrome what to filter, and the browser does the filtering instead. While the API was lackluster at the start, Google kept working on improving it and adding more features as a result of developer feedback from the likes of AdGuard and Adblock Plus. When it was first revealed, it was unnecessarily restrictive and lacked many features to make it an apt replacement, but that has improved with time and has now become significantly better for developers.

While Google has some skin in the game when it comes to preventing ad blocking, there are plenty of reasons to believe this isn't actually related to the company's position as an advertiser. There certainly were plenty of valid concerns surrounding the abundance of extensions using the webRequests API, both from a performance perspective and a privacy perspective. While the likes of uBlock Origin and Adblock Plus arguably improve performance significantly, there's no question that plenty of extensions almost certainly made it worse.

Google also says about the declarativeNetRequest API:

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.

While the company would want you to believe its stance is the correct one, keep in mind that the company has been undergoing multiple anti-trust suits over the years. There are a lot of eyes on Google all of the time, and playing nicely with ad blockers is something that the company will have to do in order to maintain some semblance of fairness. The company is already trying to find ways to prevent the usage of ad blockers on services like YouTube, but directly targeting extensions that use the biggest browser in the world would almost certainly land the company in hot water.

What's happening to uBlock Origin?

There's already a replacement

If you want to continue using uBlock Origin, there's already a new version called uBlock Origin Lite. It has all of the same filtering as uBlock Origin, it hands over processing to Chrome instead of the extension, and you can still give it more advanced filtering options by granting it more permissions. I've been using uBlock Origin and haven't noticed any real differences at all, and it's just as good as regular uBlock, but with added privacy and performance benefits.

If you want to find a list of the technical differences between uBlock Origin and uBlock Origin Lite, Hill has published a page on GitHub outlining the differences between them. There are some filtering capabilities that still can't be ported to Manifest V3, and there are quite a few. These include:

Because the declarativeNetRequest API does not support the ability to enforce rules according to the top context, i.e. the URL in the address bar, the following capabilities can't be supported:

• No remote fonts and no scripting per-site switches
• Dynamic filtering
• Dynamic URL filtering

The declarativeNetRequest API does not allow to filter according to the content of response headers, thus not possible:

• No large media elements per-site switch (webextensions #461)
• header= filter option (webextensions #460)

The following filter options can't be translated into DNR rules:

• strict1p, strict3p: whether a network request is same-origin as its initiator
• Entity-based values for domain= filter option (webextensions #394)
• redirect-rule=: the DNR API does not support redirect-if-blocked concept (webextensions #493)
• Regex-based removeparam= modifier filter options
• Exceptions for all modifier filter options are not possible
• Many very useful regex-based filters used in uBO are not allowed, or are rejected by the DNR API (webextensions #344)

CNAME-uncloaking is up to each DNR implementation; no DNR implementation supports this capability at the time of writing.

There have also been accusations that uBlock Origin Lite is a bad-faith attempt at transitioning to Manifest V3, and that Hill is purposefully sabotaging the transition to try and fight back against Manifest V3. There is no evidence to support that, and uBlock Origin Lite is a fully declarative implementation of uBlock. This means that it can fall behind in some ways, but is built with the spirit of Manifest V3 fully in mind.

How can I tell which extensions will stop working?

Chrome has a built-in checker for you

If you want to see which of your extensions will be going away, you can go to Settings at the top right and click Extensions. This will bring you to a page with all of your extensions, including the ones that will be unsupported by a future update of Chrome. These are the extensions that are not built on Manifest V3 and will stop working at a later date.

If you want to find an alternative, clicking the Find alternative button will show you extensions that are similar and are built on Manifest V3. For most extensions, you'll find replacements pretty easily, and it's simply the case that the ones you were using were outdated and have been replaced anyway.