Manifest V2 is leaving Chrome | Irbis

Products

Zen<br>System-wide ad-blocking and privacy protection

Zen VPN<br>Built-in encrypted traffic

Community<br>GitHub<br>GitHub<br>Mastodon<br>Mastodon<br>Bluesky<br>Bluesky<br>Reddit<br>Reddit<br>Discord<br>Discord

Manifest V2 is leaving Chrome<br>Jun 20, 2026<br>by Ansar Smagul<br>Crashing Waves, Alfred Thompson BricherThis 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.<br>The older version of Chrome&rsquo;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.<br>Manifest V3 replaces the bouncer with a doorman. The extension hands Chrome a fixed blocklist, 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&rsquo;t matter how clever the blocker is – the list was printed days ago, and the polite doorman can only do so much.<br>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&rsquo;t perform any analysis during runtime.<br>This reduces the precision and sophistication an extension can apply. The resulting set of V2 functionality that can&rsquo;t be ported to V3 isn&rsquo;t large, but isn&rsquo;t small either. It also limits future ad-blocking techniques against new ad-insertion methods, since I don&rsquo;t expect Google to add support for any new filtering rule syntax in V3.<br>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&rsquo;s own code have to ship inside the extension. They can only change when a new version clears Chrome&rsquo;s review process – a few hours at least.<br>To be clear, this won&rsquo;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.<br>A convenient fix<br>Why was Manifest V3 introduced at all? Let&rsquo;s look at Google&rsquo;s case. The reasons are real, but their solution breaks down under any scrutiny.<br>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&rsquo;s true that many browser extensions have carried malware for years, including attacks that have targeted millions of people. Manifest V3&rsquo;s defences against this, banning remotely hosted code and tightening what an extension can touch, are worth having.<br>But none of that required taking the blocking API away. Firefox adopted Manifest V3 and kept webRequest blocking alongside the new declarative one. Recent security research 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&rsquo;t needed for security is the one that weakens ad blocking, brought to you by the company that sells most of the web&rsquo;s ads.<br>Another stated reason is performance. Again, this seems legitimate – filtering based around a static rule syntax could be better optimised. However, we shouldn&rsquo;t forget that ads are resource-hungry – they inflate page-load times, memory, CPU, and battery drain, at times by more than 50%. 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.<br>And finally, Google claims privacy as one of the reasons. I honestly don&rsquo;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&rsquo;s name protects no one but the people selling the ads.<br>Make of that what you will.<br>Why this will not stop<br>You can read Manifest V3 as one isolated...