Chrome Strips the Last Manifest V2 Escape Hatches — Time to Audit Your Browser Tooling

The long, telegraphed funeral for Manifest V2 has reached the part where the gravedigger fills in the hole. Google is no longer just disabling MV2 extensions in Chrome by default — it is now removing the very code paths and enterprise flags that determined administrators and tinkerers used to keep them running. The practical casualty everyone names is uBlock Origin, Raymond Hill's content blocker, which depends on MV2's blocking webRequest API that MV3 deliberately retires.

This was always the plan. What's new is that the bypasses are going too, and other Chromium downstreams are signalling they'll follow. If your only exposure to this is a slightly emptier extensions list, fine. If you ship browser-based scrapers, ad-aware test harnesses, or anything that assumes a request-interception extension will load in a Chromium build, this is your cue to read the changelog before it reads you.

What's actually being removed

The change surfaced in the W3C WebExtensions Community Group's GitHub discussions, where Chromium contributor Andrey Bershanskiy flagged recent commits and Google engineer Devlin Cronin spelled out the reasoning. The headline: kExtensionManifestV2Disabled, the Chromium feature flag that gated MV2 availability, has been removed outright.

"The kExtensionManifestV2Disabled feature has been default-enabled for over a year. Remove the feature and the effectively-dead code," Cronin wrote, adding that tests relying on the old "warning" phase were stripped "since this stage is no longer reachable."

Crucially, that takes the enterprise and developer escape hatches with it. Per the timeline laid out in the discussion and reported by Neowin:

The Windows Registry policy mod that some used to extend MV2 life is expected to stop working after Chromium 151. Cronin was careful to note the teardown isn't instantaneous — "we won't be removing all the MV2 code wholesale right away, so many of these things will continue working for awhile" — but the direction is one-way. He cited tech debt, implementation complexity, and security as the drivers: "we've actually found a number of bugs that are specific to MV2 lately."

That security framing is worth taking seriously rather than dismissing as PR. A persistent background page with broad, synchronous interception over every network request is a large, privileged attack surface; MV3's service-worker model and declarative ruleset exist partly to shrink it. The trade-off — and the reason this remains contentious — is that the same constraints that reduce risk also kneecap the most capable content blockers.

Advertisement

Shadow GPS — know where it is, always Real-time GPS tracking for vehicles, gear and loved ones. No monthly contracts.

Why MV3 breaks the blockers

The substance here isn't the flag names; it's the API model underneath. MV2 extensions can register a blocking webRequest listener and make per-request decisions in JavaScript at runtime. MV3 replaces that with declarativeNetRequest, where the extension hands Chrome a static (or dynamically updated) set of rules and the browser does the matching internally. The extension never sees most requests; it just declares intent.

For a lot of extensions that's a clean upgrade. For a filter engine that mixes large, frequently-updated blocklists with cosmetic filtering and procedural logic, it's a different sport with smaller fields. That's why Google's own answer for Chrome users is uBlock Origin Lite, an MV3 build — and why, by most hands-on accounts including Neowin's, uBO Lite doesn't match the original. It's not laziness on the developer's part; it's the platform telling you what's expressible.

If you've built tooling on top of webRequest blocking — request mocking, header rewriting, traffic shaping in an automated browser — the migration question is concrete: can your logic be expressed as declarative rules, and can it stay under the engine's matching model? For anything genuinely dynamic, the honest answer may be to move the interception out of the extension layer entirely, into a proxy (mitmproxy, a CDP network-domain hook via the DevTools Protocol, or your test framework's built-in interception) where you still control the request lifecycle.

The Chromium downstream isn't a safe harbor

The tempting assumption is that another Chromium-based browser buys you time. Mostly, it doesn't.

• Edge reportedly began disabling uBlock Origin back in February — unsurprising, since it tracks Chromium closely.
• Opera had publicly committed in October 2024 to supporting MV2 for longer, but Hill says he received email indicating Opera now plans to abandon MV2 extensions, and suspects review resources for such extensions are drying up. The notice developers cite is blunt: update to Manifest V3 "as soon as possible to ensure continued compatibility."
• Brave and possibly Vivaldi appear, for now, to be the Chromium holdouts still committed to MV2 — but "for now" is doing real work in that sentence, because they inherit the same upstream code removals Cronin described. Maintaining MV2 against an upstream that's actively deleting it is a recurring cost, not a one-time decision.

The one genuinely different platform is Firefox, which supports MV3 while keeping MV2 — including blocking webRequest — alive. Mozilla implemented MV3 without dropping the API that makes full-strength content blocking possible, which is precisely why Firefox keeps coming up as the off-ramp.

What developers should do now

This is a dependency-deprecation problem dressed up as a browser-politics story. Treat it like one:

• Inventory anything that loads an MV2 extension in CI, headless runs, or developer machines pinned to specific Chrome/Chromium versions. A pinned old Chromium is a temporary reprieve, not a strategy.
• Move request interception out of the extension where you can. CDP network interception, an explicit proxy, or framework-level mocking survive the manifest churn entirely.
• If you depend on real content blocking in test environments (e.g. reproducing how a page behaves with ads/trackers stripped), validate whether declarativeNetRequest-based blocking — uBO Lite or equivalent — actually reproduces the behavior you need before you assume parity.
• Pick your browser deliberately. Chrome and the closely-tracking Chromium downstreams are converging on MV3-only. Firefox is the mainstream option that still supports the older blocking model; Brave and Vivaldi are betting on maintaining MV2 against the upstream current.

None of this is an emergency this week — Cronin was explicit that the code won't vanish all at once. But "some may go away sooner than others" is the kind of sentence that ends with a broken pipeline three releases from now. The bypasses are gone or going; build on the model the platform is keeping, not the one it's deleting.