This month Chrome removes the last support for Manifest V2, the older extension
framework. Chrome 150, due around 30 June, deletes the final flag that kept Manifest V2 extensions running, and Chrome 151 in July clears out the rest. Some headlines say it will kill ad blocking, but the truth is more nuanced.
The older version of Chrome’s extension system, Manifest V2, let an ad blocker work like a bouncer at the door. Every request a page tried to send passed the blocker first. It read each one, used whatever judgment it liked, and decided what to let through. Because it watched everything in the moment, it could catch almost every trick in the book, even ones it had never seen before.
Manifest V3 replaces the bouncer with a doorman. The extension hands Chrome a fixed blacklist, written out in advance, and Chrome does the checking itself. The blocker never sees the traffic, so if the ads show up under a new name or a good enough disguise, it doesn’t matter how clever the blocker is — the list was printed days ago, and the polite doorman can only do so much.
Concretely, two things are lost. The first is complete visibility into the traffic flow. Manifest V2 handed the extension each request and response and let it run arbitrary logic to determine the blocking verdict on the fly via the API called webRequest. V3 replaces that with declarativeNetRequest, or DNR – a special filtering rule syntax with a limited set of capabilities. The extension must also hand all the rules ahead of time, and can’t perform any analysis during runtime.
This reduces the precision and sophistication an extension can apply. The resulting set of V2 functionality that can’t be ported to V3 isn’t large, but isn’t small either. It also limits future ad-blocking techniques against new ad-insertion methods, since I don’t expect Google to add support for any new filtering rule syntax in V3.
The second loss is subtler: how the rules get updated. Previously, an ad-blocker could
fetch new rules on its own schedule – faster than an ad network could rotate domains and tricks. Now, both the rules and the blocker’s own code have to ship inside the extension.
They can only change when a new version clears Chrome’s review process – a few hours at least. To be clear, this won’t kill ad-blocking in Chrome completely – the amazing work of extension developers means the experience will stay good enough for most users.
Nevertheless, this is a big shift in the balance of power in this cat-and-mouse game.
A convenient fix
Why was Manifest V3 introduced at all? Let’s look at Google’s case: the reasons are real, but their solution breaks down under any scrutiny.
From Chrome Manifest V3 documentation.
How convenient that all these reasons also let Google curb ad-blockers.
Google says that V3 improves extension security. It’s true that many browser extensions have carried malware for years, including attacks that have targeted millions of people. Manifest V3’s defences against this, banning remotely hosted code and tightening what an extension can touch, are worth having.
But none of that required taking the blocking API away. Firefox adopted Manifest V3 and kept webRequest blocking alongside the new declarative one. Recent academic work also shows that attackers have already adapted to the new limitations, and designing extensions that steal data and redirect to malicious links is still possible. As it turns out, the one change that isn’t needed for security is the one that weakens ad blocking, brought to you by the company that sells most of the web’s ads.
Another stated reason is performance. Again, this seems legitimate – the static filtering rule syntax could be better optimised. However, we shouldn’t forget that ads are resource-hungry — they inflate page-load times, memory, CPU, and battery drain. Ad-blockers have been proven to significantly aid all these metrics, so designing anything that limits their abilities in the name of performance is at best misleading.
And finally, Google claims privacy as one of the reasons. I honestly don’t even know where to begin with this, but hearing it from a company that has its own Privacy Concerns Wikipedia page is hilarious. The online ad ecosystem is one of the worst offenders against online privacy, and ad-blockers are one of the few defences a user has against it – so kneecapping them in privacy’s name protects no one but the people selling the ads.
Make of that what you will.
Why this will not stop
You can read Manifest V3 as one isolated decision, now finished. The money says
otherwise. The ad business, roughly three quarters of Google’s revenue, is now paying for the largest infrastructure build-out the company has ever attempted. Its planned 2026 spending, most of it focused on data centers and AI, is $180-190 billion – more than the $174 billion the business generated over the past year.
None of this created Manifest V3, which was drawn up back in 2018. But a company
spending at this scale, on the back of the ads you see, has every reason to squeeze you a little more and little reason to make blocking ads easier.
What you can do
If you want full filtering inside the browser, move to Firefox, which keeps the old
webRequest API. The longer answer moves filtering out of the browser altogether. That is what we work on.
Zen is an open-source system-wide ad-blocker that runs as a local proxy outside the browser, so it also blocks ads and trackers for every other app. Living outside the browser, Zen was never subject to Manifest – its bouncer was never Chrome’s to take away. It still reads every request as it happens, runs whatever logic the moment calls for, and fetches fresh rules on its own schedule with no review queue. Forget about the blacklist printed days ago and filtering syntax handed down by the company that sells the ads.
Check us out at irbis.sh/zen.
