Chrome is closing the last MV2 escape hatch. uBO dies on schedule.

What happened

Google is shutting the final door on Manifest V2 extensions in Chrome. According to Neowin's reporting on the latest Chromium release notes, the `ExtensionManifestV2Availability` enterprise policy — the one knob administrators (and power users running with `--enable-policy`) have been using to keep uBlock Origin alive past the official MV2 sunset — is being phased out. Microsoft Edge and Opera, both Chromium downstreams, have already signaled they'll mirror the change on their usual lag.

This is the end of a deprecation arc that started in 2019, accelerated in mid-2024 when Chrome began disabling MV2 extensions for stable users, and now closes the last legitimate workaround. The bypass wasn't a bug — it was an enterprise policy Google deliberately shipped to give large customers a transition window, and that window is now closing. Raymond Hill, uBO's maintainer, has been clear for years that uBlock Origin proper cannot be ported to MV3 without losing core capabilities. The MV3 fork — uBlock Origin Lite — exists, but it is a fundamentally different product.

The Chromium changelog frames this as a security and performance win. The practical effect is that every Chromium-based browser except a small number of forks (Brave, Vivaldi to a degree) will, by end of this cycle, refuse to run the extension that has consistently topped independent ad-blocker benchmarks for years.

Why it matters

The technical substance here gets lost in the politics. MV3's replacement for blocking content interception is the `declarativeNetRequest` API. Instead of an extension inspecting each request in JavaScript and deciding what to do, the extension declares a static rule set up front, and the browser enforces it. Google's stated motivation is real: the old `webRequest` blocking path runs extension JS on every network event, which is genuinely expensive and a non-trivial attack surface.

The trade-off is that `declarativeNetRequest` is rule-list shaped, and a lot of what uBO does is not. Cosmetic filtering, scriptlet injection, per-site dynamic rules, the element picker, and on-the-fly filter compilation from custom lists all depend on logic that runs at request time — exactly the capability MV3 removes. Google raised the rule limits over time (currently ~330,000 static rules across all extensions and 30,000 dynamic per extension, after community pressure), but the limits aren't the core complaint. The core complaint is the loss of dynamic decision-making.

uBlock Origin Lite is what's left. It's an honest piece of engineering — gorhill ships it without pretending it's the same product — and for many users it's adequate. But independent tests (Cory Doctorow flagged this; ArsTechnica ran numbers in 2024) consistently show uBO Lite missing trackers and ad variants that full uBO catches. The gap is not 5%; on some sites it's a different category of blocking. If you care about YouTube ad-block durability specifically, the gap is the entire point of the product.

Community reaction has been weary rather than outraged. The Hacker News thread on Neowin's piece (200+ points) is mostly people comparing migration plans, not litigating Google's motives. The dominant sentiment isn't anger — it's the realization that the multi-year telegraphed migration is finally happening on schedule, and the workarounds were always a stay of execution, not a reprieve. A recurring counterpoint: Google ships an ad business and an ad blocker is hostile to that business, and no amount of declared technical rationale fully escapes that conflict of interest. Whether you find that dispositive depends on whether you weight motive or mechanism.

Edge following is the more interesting downstream signal. Microsoft has historically been the Chromium fork willing to keep features Google dropped (it shipped its own version of MV2 support, briefly). That it's lining up to follow on this one suggests the engineering cost of maintaining a fork of the extension API surface is real, and Microsoft is unwilling to pay it indefinitely for a feature that's user-facing but doesn't move the needle on Edge's market share story.

What this means for your stack

If you're a developer who relies on full uBlock Origin — for noise reduction during research, for dogfooding ad-heavy sites without poisoning your own analytics, for blocking the tracker pixels that distort your sessions when you visit your own product — your migration options are now narrow and concrete.

Firefox is the answer if you want zero changes to your blocking setup. Mozilla committed to keeping blocking `webRequest` indefinitely and ships MV3 with it intact. Full uBO continues to work. Performance on Firefox has closed most of the historical gap with Chrome; if you haven't tested Firefox as a daily driver in two years, your priors are stale. Firefox is now the only mainstream browser where the version of uBO that benchmarks at the top continues to function.

Brave keeps a custom path: it forks Chromium and re-implements the MV2 surface enough to keep certain extensions working, plus ships its own built-in blocker that's competitive on most lists. If your concern is content blocking specifically, not extension portability, Brave's built-in blocker covers it without depending on uBO.

Chromium proper, with uBO Lite, plus a network-level blocker. This is the pragmatic compromise if you're locked into Chrome for DevTools, profile sync, or corporate policy. Pair uBO Lite with NextDNS, Pi-hole, or a local resolver running a blocklist. You lose cosmetic filtering and element-picker workflows but recover most of the network-level blocking the MV3 API can't do. The setup cost is one afternoon; the maintenance cost is near zero.

For extension authors, the lesson is broader. The MV2-to-MV3 transition is the clearest recent example of a platform owner using a security-justified API migration to constrain a category of extension that competes with the platform's economics. Whether or not Google's stated rationale is honest, the shape of the outcome — declarative-only, no dynamic interception — happens to closely match what an ad-funded browser would want its extension surface to permit. If you build extensions that depend on intercepting platform behavior at runtime, plan as if the next API migration will narrow your surface further, not widen it.

Looking ahead

The interesting question isn't whether Chromium browsers will block ad blockers — that's now decided — but whether Firefox's divergence becomes a meaningful product wedge. Mozilla has spent a decade losing share to Chrome on performance and ecosystem grounds; content blocking fidelity is the first feature in a long time where Firefox is unambiguously, structurally better than its competition, and the gap will widen as MV3 fully lands. Whether Mozilla can market this without sounding defensive is a separate question. For developers, the practical move is simple: install Firefox, install full uBO, set it as the browser you use when you actually want to read something. Keep Chrome for the work that depends on it. The era of the universally-installable blocker is over; the era of choosing your browser based on what it lets you block is starting.