Chrome ad blocker update: what MV3 actually changed for users

The story that the Chrome ad blocker update would kill your ad blocker was wrong. A peer-reviewed study published earlier this year in Proceedings on Privacy Enhancing Technologies by researchers at Goethe University Frankfurt tested MV3 versions of four major blockers against their MV2 predecessors, using default settings to replicate what a typical user actually runs. The result: no statistically significant reduction in blocking effectiveness. The MV3 versions actually blocked marginally more tracking content, averaging 1.8 additional tracking scripts per site (Extenshi).

That "default settings" qualifier matters. It is what the research establishes, and it is the limit of what it establishes.

The argument here is narrower than "ad blocking is dead on Chrome." It isn't. The argument is this: the Chrome Manifest V3 ad blocker transition has permanently removed the ability of browser extensions to inspect, modify, and intervene in network behavior in real time. That capability is what a specific class of privacy and security tools depends on. For ordinary users running a standard blocker, the change is largely invisible. For users relying on tools that do more than match requests against a list, Chrome has closed off a range of protective functions that have not been restored. MV2 was disabled in Chrome 138, with complete removal arriving in Chrome 139 this month (Extenshi).

Manifest V3 vs Manifest V2 ad blocking: what actually changed

Under MV2, extensions had access to the webRequest API, a live intercept point that let an extension observe, modify, or block network requests as they happened. Think of it as a security guard who can stop traffic at the gate and inspect it in real time. MV3 replaces that with declarativeNetRequest (DNR), a declarative system where an extension submits a rulebook in advance and Chrome's engine does the filtering on its behalf. The extension no longer watches the gate. It files a list with building management and waits (Extenshi).

Google's stated rationale was improved privacy, security, and performance, the argument being that persistent background access gave extensions too much power. The EFF has noted that Google provided no empirical evidence for the performance claims (EFF). One narrow security benefit is real: MV3 bans remotely hosted code, which is a legitimate measure against certain classes of malicious extension behavior. The early rule-limit controversy has also largely resolved. DNR launched with a 30,000 static rule cap that was untenable against blockers like uBlock Origin, whose default filter lists exceed 300,000 rules, but Google raised that floor to 330,000, sufficient for the majority of blocking use cases (Extenshi). Those early objections, the ones that generated the loudest headlines, are mostly stale.

What the ad-blocking study proves, and what it doesn't

The Goethe University study tested Adblock Plus, AdGuard, Stands, and uBlock Origin, comparing their MV2 and MV3 versions on default settings (Extenshi). Its finding is meaningful for Chrome browser extension ad blocking at the consumer level: when users install a mainstream blocker and leave it at defaults, the transition to MV3 has not degraded their protection. That's a real result, and it directly contradicts the doomsday headlines that circulated when Chrome Manifest V3 ad blockers first became mandatory.

What the study does not prove is that MV3 is neutral across all extension types. It measured list-based blocking, where an extension matches outbound requests against a set of known tracking domains and stops them. That is what mainstream ad blockers do. It did not measure tools that need to read what is inside a request, make a dynamic decision about it, and act before the browser completes the navigation.

Those are different tools with different requirements, and effectiveness metrics don't capture the gap. A blocker that stops a known tracker from loading is working correctly under MV3. An extension that needs to intercept a redirect, inspect its parameters, and rewrite the destination URL before the browser follows it is not.

The real loss: privacy tools that need to act on traffic, not just filter lists

Privacy Badger's link-cleaning feature strips Google's tracking parameters from URLs in Search, Docs, Gmail, and Maps, parameters that allow Google to follow users across the web when they click outbound links. Under MV2, Privacy Badger could intercept and rewrite those redirect requests at the network layer using webRequest. MV3 removes that ability: as the EFF documented in a 2023 post on the change, MV3 extensions cannot properly fix redirects at the network layer. Privacy Badger can still show the user a clean link in the page text, but it cannot stop the redirect before the browser follows it. The tracking mechanism operates; the protective tool becomes a cosmetic patch.

Privacy Badger is not a special case. It illustrates a category. Two additional groups of tools have been significantly constrained under MV3's service-worker architecture, where extensions fire reactively on events rather than running persistently in the background. The first is early-stage script injection: running extension code into a page's context before the page's own scripts execute, which anti-fingerprinting tools need to intercept browser characteristics before a site's tracking code can read them. The EFF identified this as broken under MV3 when the spec was introduced. The second is background observation: the always-on awareness that tools tracking behavioral patterns across sessions depend on. A 2020 study from Princeton and the University of Chicago found that privacy extensions, precisely the category MV3 constrains, actually improve browser performance, which cuts against one of Google's core justifications for the restrictions (EFF).

The distinction for users is straightforward. If your extension works from a filter list and matches outbound requests against it, it survived MV3 largely intact. If it needs to see what's inside a request, make a dynamic decision, and act on that decision before the browser completes it, Chrome no longer allows that.

Why Google's security case doesn't hold up

Over 85% of actively maintained Chrome Web Store extensions have already migrated to MV3, and all major ad blockers have MV3 versions available (Google Chromium Blog). The transition happened without the broad user-facing collapse some predicted. That is worth acknowledging.

But once you accept that MV3 preserved list-based blocking while removing real-time network intervention, the security rationale becomes harder to accept. At the 2020 AdBlocker Dev Summit, Firefox's Add-On Operations Manager said that malicious extensions are mostly interested in observing browser traffic, behavior that uses the non-blocking, observational webRequest API, which MV3 still permits (EFF). The capability that was removed, blocking and redirecting webRequest, is not the capability malicious actors primarily exploit. It is the capability that user-protective extensions depend on. Google's approach secured the browser by restricting good actors. As the EFF noted, Chrome has not announced a parallel strengthening of its extension review process (EFF).

The conflict of interest in the background is too large to dismiss. Google's trackers appear on at least 85% of the top 50,000 websites, part of an advertising business that generated over $225 billion in 2022 (EFF). As the EFF noted in 2021, Chrome remains the only major browser without meaningful built-in tracking protection, no equivalent to Firefox's Enhanced Tracking Protection or Safari's Intelligent Tracking Prevention (EFF). That combination, dominant browser, no native protection, constrained third-party tools, is not proof of deliberate harm. It is a conflict substantial enough that the security rationale alone cannot settle the question.

Which users should actually care, and what to do about it

Three groups of users need different answers.

Ordinary users running a mainstream ad blocker on Chrome with default settings are broadly fine. The peer-reviewed evidence is clear: MV3 versions of major blockers perform comparably to their predecessors for typical use cases (Extenshi). If blocking banner ads and standard trackers is the goal, the transition has not materially changed what Chrome can do.

Privacy-conscious users who rely on tools that go beyond list matching, link cleaners, anti-fingerprinting extensions, behavioral tracking blockers, are in a different position. The network-layer intervention those tools depend on is no longer available in Chrome. Firefox retains support for blocking webRequest alongside DNR, keeping the full capability set these tools require (EFF). For this group, the browser choice matters.

Extension developers face a narrowed canvas for what is buildable on Chrome at all. The shift to service workers constrains what a new privacy or security tool can do before it's written, not just after it's deployed. Some features that used to be routine, intercepting a redirect, injecting code before a page initializes, watching traffic continuously across a session, are now off the table on Chrome regardless of how well the extension is built.

The "MV3 kills ad blockers" story was a cleaner narrative than the facts supported. Google got to respond simply and correctly. The actual story, that Chrome has permanently narrowed which protective tools are architecturally possible, is harder to land in a headline. For anyone whose threat model extends past banner ads, it is also the one that matters.