Why MV3 kneecapped uBlock Origin — and what Lite actually loses

What happened

As of this week, Firefox is the last major browser that still ships full uBlock Origin. Chrome finished its Manifest V2 sunset earlier this year, and the Chromium downstreams — Edge, Opera, Brave, Vivaldi — have all followed. Raymond Hill's original uBO extension either won't load or has been silently disabled in each of them. What remains on the Chrome Web Store is uBlock Origin Lite, a rewritten MV3-compatible cousin that Hill himself has repeatedly said is not a drop-in replacement.

The PCWorld piece that surfaced on Hacker News this week (1,372 points, over 700 comments) is the moment the community collectively acknowledged the migration is done. The interesting story isn't "Google killed uBO" — that shipped a year ago. The interesting story is what MV3 actually forbids at the API level, and why no amount of engineering can put those capabilities back.

The short version: MV2's `webRequest` API let an extension see every network request and decide, in JavaScript, whether to block, modify, or redirect it. MV3 replaces that with `declarativeNetRequest` (DNR), where the extension hands the browser a static list of match rules ahead of time and the browser does the filtering. Chrome enforces it in native code. It's faster and safer against malicious extensions. It also removes roughly half of what uBO does.

Why it matters

Start with the hard limits. DNR caps the number of dynamic rules at 30,000 per extension and static rules at 330,000 across all enabled rulesets. EasyList plus EasyPrivacy plus a couple of regional lists blows past 300,000 rules before you add anti-annoyance or anti-tracking lists. uBO users routinely run filter sets with 500,000+ rules. The ceiling isn't a policy choice you can appeal — it's compiled into Chromium.

Second, DNR is declarative. You cannot make a blocking decision based on runtime state — the request's timing, prior requests from the same page, whether the user just clicked something, or what a scriptlet observed in the DOM. uBO's dynamic filtering, temporary rules, per-scope exceptions, and its logger-driven "why was this blocked" debugging all depend on being in the request path. Under MV3, an extension is a compiler that emits rules; it is not a runtime that makes decisions.

Third — and this is the one Lite users trip over first — MV3 severely constrains cosmetic filtering and scriptlet injection. uBO's procedural cosmetic filters (`:has-text`, `:matches-css`, `:xpath`) run JavaScript against the live DOM to hide elements that pure CSS can't target. Its scriptlets neutralize anti-adblock scripts by patching page-side JS before it runs. Both require the kind of dynamic content-script injection MV3 tightened. Lite ships a subset, but the arms race with ad networks that specifically fingerprint adblockers is fought in exactly this layer.

Fourth, and least discussed: the monoculture angle. Brave's own ad-blocker is native, not extension-based, so Brave users aren't losing much day-to-day. But the ecosystem effect is real. When five of the six major browsers share one engine and one extension API, one vendor's product decision becomes the entire web's product decision. Google's stated reason for MV3 is security and performance, and both claims are defensible. The side effect is that the most sophisticated privacy tool on the web now runs on a browser with roughly 3% desktop share.

Hill has been unusually blunt in the GitHub issue tracker about what Lite can and can't do. His pinned FAQ notes that Lite "cannot match the filtering capabilities of uBlock Origin" and specifically calls out that dynamic filtering, the element picker's advanced modes, per-site switches, and the request logger are gone. Not "coming soon." Gone, because DNR doesn't expose the primitives.

What this means for your stack

If you're a developer who uses adblocking as a privacy layer — not just to hide banners — the practical choices have narrowed. Firefox with full uBO remains the reference implementation and will for the foreseeable future; Mozilla has publicly committed to keeping MV2's `webRequest` blocking API. Brave with its native shields is fine for most users but doesn't give you uBO's filter list flexibility. Chrome with uBO Lite covers the top 90% of ads and trackers and is a reasonable default for non-technical users you support, but don't expect it to handle sites that actively fight back.

For teams building browser extensions, MV3 is now non-negotiable on Chromium. If your extension does anything in the request path — corporate proxies, security tooling, developer devtools that intercept fetch, VPN clients, password managers with auto-fill on network events — you've probably already discovered that the migration is not mechanical. Rewriting an intercept-and-decide extension as a declare-rules-upfront extension isn't a port; it's a redesign, and some designs simply don't survive it.

There's also a testing implication worth naming. If your product's marketing or analytics stack depends on any tracker that EasyPrivacy blocks, your funnel numbers from Firefox users have always been different from your Chrome numbers. That gap is about to invert: Chrome users will suddenly look more trackable than they did a year ago, because Lite blocks less than full uBO did. Don't attribute the delta to a real behavior change.

Looking ahead

The pragmatic bet is that Firefox will hold this line for years — it's cheap for Mozilla to keep, it's the clearest differentiation they have left, and the users who care are exactly the users who write about browsers. The longer-term question is whether the DNR ceiling gets raised. Google has already bumped the static rule limit once under community pressure, and there's an active thread of proposals to extend DNR with more expressive matching. None of them get you back dynamic filtering or scriptlets. If you rely on those, your browser choice is now a one-item list, and that list has a footnote about market share that isn't going to get better on its own.