The editorial argues this is not a UX regression but the explicit design of MV3: extensions describe rules, the browser applies them. With EasyList alone exceeding the ~30,000 static rule cap before adding EasyPrivacy or regional lists, and uBO's default compiling to hundreds of thousands of rules, there is no arithmetic where the full filter set fits within DNR's limits.
Hill maintains uBO Lite specifically to live within MV3's constraints but has been blunt that Lite is not a drop-in equivalent to the original uBlock Origin. The two share a name and author but almost nothing else architecturally — Lite cannot replicate uBO's real-time webRequest filtering, cosmetic rules, scriptlets, or per-site logic.
The article frames Chrome's next stable update as the closing of the door on popular ad blockers, finally disabling MV2 extensions for the last cohort of holdouts who relied on enterprise policies, dev channels, or stale flag overrides. After a multi-year migration, the original uBlock Origin will no longer load for nearly all desktop Chrome users.
By submitting the 9to5Google story with the framing that this update marks the end of popular ad blockers, speckx amplifies the position that MV3 enforcement is a watershed moment for the Chrome extension ecosystem. The 238-point score signals broad community agreement that this is a meaningful loss, not a minor migration.
The editorial emphasizes that uBO and uBO Lite share a name and an author and almost nothing else architecturally. The original used a JavaScript filtering engine on webRequest to evaluate every request in real time with cosmetic rules and per-site logic; Lite ships static rule sets the browser enforces via DNR, meaning extensions no longer see the request stream at all.
Google is rolling out the next Chrome stable update that finally disables Manifest V2 extensions for the last cohort of users who'd been clinging to enterprise policies, dev channels, and stale flag overrides. The 9to5Google story (238 on HN) is the latest reminder that the multi-year Manifest V3 migration has reached the point where, for nearly all desktop Chrome users, the original uBlock Origin no longer loads.
The replacement Google points users toward is uBlock Origin Lite, a separate extension Raymond Hill maintains specifically to live within Manifest V3's constraints — and Hill himself has been blunt that Lite is not a drop-in equivalent. The two extensions share a name and an author and almost nothing else architecturally. uBO ran a JavaScript-based filtering engine on top of the `webRequest` API, which let it evaluate every network request in real time against compiled filter lists, cosmetic rules, scriptlets, and per-site logic. uBO Lite ships static rule sets that the browser itself enforces via `declarativeNetRequest` (DNR).
The shift is not a bug or a UX regression. It is the explicit design of MV3: extensions describe rules, the browser applies them. Extensions no longer get to see the request stream.
The ceiling everyone keeps running into is numeric. Chrome's declarativeNetRequest API caps a single extension at roughly 30,000 static rules in the enabled rule set, plus a smaller dynamic rule budget — a hard limit imposed by the browser, not a soft guideline. EasyList alone is well north of that before you add EasyPrivacy, regional lists, annoyance lists, or anti-tracking filters. uBO's default filter selection on a typical install routinely compiles to hundreds of thousands of rules. There is no version of arithmetic where the full set fits.
Google has raised the cap incrementally over the MV3 saga — early drafts were 5,000 — but the structural problem is unchanged. DNR is a declarative system: rules are static patterns evaluated by the browser, which means anything requiring runtime logic (per-element cosmetic filtering with `:has-text()`, scriptlet injection to defuse anti-adblock detection, dynamic CNAME uncloaking) is either impossible or degraded to a heuristic. The most effective anti-tracking techniques of the last five years were built on exactly that runtime flexibility.
The community reaction on Hacker News was the predictable mix of resignation and 'I told you so.' The thread surfaced the same three counter-arguments that have circulated since 2019: enterprise policy can keep MV2 alive (true, until June 2025, when even that escape hatch closed for most users); Chromium forks like Brave and Vivaldi may patch around it (true for a while, but they inherit Google's extension API surface and patching DNR limits is non-trivial); and the security argument for MV3 — that extensions with full request visibility are a phishing and exfiltration risk — has merit (also true, but it's the justification, not the explanation; the same goal could have been achieved with stricter review of `webRequest` permissions).
What's actually new in this round is the timing. Chrome's enterprise force-installed extensions and the `ExtensionManifestV2Availability` policy were the last legitimate way to keep full uBO running. Both are being phased out. The 'just wait for a policy fix' camp has run out of road.
If you maintain a browser extension that depends on `webRequest` blocking — corporate DLP tooling, security extensions that inspect request bodies, dev tools that hook into network traces — your MV3 port is either done or overdue. The pattern most teams settled on: move the request inspection into a native-messaging host or a local proxy, and use the extension only for UI and message passing. This works but it is a real architectural change, not a manifest version bump.
For end users who want the pre-MV3 blocking experience, the practical answer is Firefox. Mozilla shipped MV3 support but kept `webRequest` in blocking mode available to extensions, which is why the full uBlock Origin still runs there unchanged. It's the cleanest migration path that doesn't involve trusting a Chromium fork to indefinitely maintain a delta against upstream. Safari has its own content-blocker API with a 150,000-rule limit per extension — higher than Chrome's, but still static, and the ecosystem of filter-list-maintained extensions is thinner.
The second-order effect is on the rest of the extension ecosystem. Password managers, tab managers, and accessibility extensions are mostly fine — they didn't need `webRequest` blocking. But anti-tracking and privacy tooling has bifurcated: AdGuard now ships a separate MV3 build with reduced capabilities, Ghostery the same, Privacy Badger the same. Read the changelog of any privacy extension you trust and check whether the Chrome build is the full version or the diminished MV3 sibling — the names are usually identical, the behavior is not.
There's also a small but real testing implication. If your product relies on QA running with ad blockers off to test ad-rendering or analytics paths, the MV3 transition has been quietly reducing what those blockers catch. A test rig that 'has uBO installed' on Chrome in 2026 is testing against a meaningfully weaker filter than it was in 2023.
The MV3 fight as a public controversy is over; the technical consequences are settling in for the long haul. Chrome's market share — still north of 65% on desktop — means the practical baseline for what a web extension can do is now the DNR ceiling, and ad-tech infrastructure is already adjusting to exploit the gap. The interesting question isn't whether uBO Lite is good enough today; it's whether Firefox can hold the line on `webRequest` long enough to remain the meaningful alternative, given how much of Mozilla's revenue still flows from a Google search deal. For now, the answer for anyone who actually cares about content blocking is the same one it's been for two years: install Firefox, install uBlock Origin, move on.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.