Chrome's June 2026 MV3 cutoff finally kills uBlock Origin for real

What happened

Google has confirmed the final removal date for the `ExtensionManifestV2Availability` enterprise policy that has, for the past 18 months, let admins and power users keep Manifest V2 extensions alive in Chrome. Starting with Chrome 139 — rolling out to the stable channel through June 2026 — the policy is a no-op, and any MV2 extension still installed will be force-disabled on next browser launch.

The affected list is short but consequential: uBlock Origin, uMatrix, NoScript, the original Tampermonkey builds, and a long tail of niche privacy and developer tools. Raymond Hill (gorhill), uBO's maintainer, has not changed his position from the 2024 thread — uBlock Origin proper will not be ported to MV3 because the `declarativeNetRequest` API cannot express what uBO does. The replacement, uBlock Origin Lite, is a separate codebase with deliberately reduced scope: a static ruleset capped at 30,000 entries per file (Chrome raised the per-extension static rule cap to 330,000 last year, but that's still below uBO's working set), no on-the-fly filter compilation, and no scriptlet injection that depends on runtime page state.

The 9to5Google piece that hit 238 on HN frames this as the death of "popular ad blockers," which is half right. AdBlock Plus, AdGuard, and Ghostery all shipped MV3 versions months ago and will keep working. What dies is the category of extension that treats the browser as a programmable proxy — the ones senior developers actually run.

Why it matters

The technical argument has been litigated to exhaustion since 2019, but the load-bearing claim is worth restating. `declarativeNetRequest` requires you to declare your blocking rules up front, in a static manifest, which Chrome's network stack then enforces without invoking your extension's code. `webRequest` (the MV2 API) lets your extension see each request and decide. The first model is faster and more auditable; the second model is the only one that can implement filter lists that mutate based on what the page is doing, which is approximately every modern anti-anti-adblock countermeasure.

The HN thread (currently 940+ comments) splits along predictable lines. The security-team faction points out that MV2 extensions are a genuine supply-chain risk — a compromised popular extension has near-total visibility into your browsing — and that the enterprise managed-extension story under MV3 is meaningfully better. The privacy faction notes, correctly, that the same Google whose ad business is structurally threatened by uBO is the one writing the API spec, and that Mozilla's Firefox implementation of MV3 deliberately kept `webRequest` blocking precisely because the technical objections weren't dispositive.

Both are right. The thing to internalize is that this is no longer a debate about extension architecture — it's a debate about who gets to define what "a browser" is, and the answer in Chrome's case is now "whoever ships the rendering engine." That matters because Chromium-derived browsers (Edge, Brave, Opera, Arc, Vivaldi) inherit the API surface. Brave can keep its built-in shields because they live in the browser binary, not an extension; the same is true of Edge's tracking prevention. The extension-based long tail of customization gets squeezed.

Worth noting: Firefox's market share has ticked up roughly 0.4 points in the regions where tech-forward users concentrate (Germany, Czech Republic, parts of Scandinavia) over the past 18 months, per StatCounter. It's not a stampede, but it's the first sustained directional move for Firefox since 2017. Mozilla's bet that the MV2 holdouts are worth courting is, on the numbers so far, paying out.

What this means for your stack

If you're running uBlock Origin on a work machine via the enterprise policy, audit your fleet now. The policy will silently stop being honored — there's no warning banner, no telemetry event you can hook, the extension just disappears from the toolbar on next launch. Affected users will assume their browser is broken or their employer pushed an update, and the first signal IT hears about it will be tickets.

For your own machine, the real options are: (1) install Firefox or a Firefox derivative (LibreWolf, Zen) and accept the rendering-quirks tax, (2) move to a Chromium fork that has committed to maintaining MV2 compatibility — Brave has said it will, Vivaldi has not committed either way, (3) install uBlock Origin Lite and accept the degraded filtering, or (4) move blocking to the network layer with Pi-hole, NextDNS, or AdGuard Home, which sidesteps the browser argument entirely but doesn't handle cosmetic filtering.

For developers shipping extensions: the MV3 porting work is mostly done if you haven't started, but the `service_worker` lifecycle is the trap. Background scripts no longer have persistent state — they get killed after 30 seconds of inactivity and restarted on the next event, which means any in-memory caching, WebSocket connections, or long-running computations need to be redesigned around `chrome.storage.session` and event-driven re-hydration. Test on a cold-started service worker, not on whatever's still in memory from your last reload.

Looking ahead

The interesting second-order question is what happens to the filter-list ecosystem. EasyList, EasyPrivacy, and the regional supplements are maintained by volunteers who optimize for uBO's expressiveness. If uBO Lite becomes the dominant blocker, list maintainers will rewrite for the lowest-common-denominator API, which means even Firefox users — who could keep using the more expressive lists — will see degradation by default. The browser API change reshapes the upstream content too. Whether that's a problem your users notice in 2027 depends entirely on whether the Firefox-and-friends camp can sustain enough share to keep a parallel filter-list track alive.