Firefox is the last browser where uBlock Origin still works properly

What happened

Google's multi-year Manifest V3 rollout crossed its final threshold this summer: Chrome now disables Manifest V2 extensions across stable channels, and every downstream Chromium browser — Edge, Brave, Opera, Vivaldi, Arc — has either followed or is on a countdown to follow. That leaves Firefox as the only major browser where uBlock Origin, in its full and unrestricted form, still runs.

The distinction matters because uBO's author, Raymond Hill, has been unusually blunt for years: the MV3 replacement, uBlock Origin Lite, is not a drop-in equivalent. It cannot dynamically update filter lists between browser updates, cannot do the heavier cosmetic filtering, cannot run the same advanced scriptlets, and cannot make runtime decisions about network requests the way the MV2 `webRequest` blocking API allows. Hill's own repo documents the tradeoffs in a table that reads less like release notes and more like an obituary.

Firefox, by contrast, ships an MV3 implementation that keeps blocking `webRequest` alongside `declarativeNetRequest`. That is the single technical decision that separates it from Chromium here. Mozilla was explicit about it when they announced their MV3 plans: they would implement the new manifest but keep the APIs that content-blocking extensions actually need. Two years later, that promise is what leaves Firefox standing alone.

Why it matters

The common framing — "Google is killing ad blockers" — is both true and slightly beside the point. The real story is that a browser API surface that a huge chunk of the privacy tooling ecosystem was built on has been deprecated by the vendor that controls roughly 65% of the desktop market and effectively 100% of the mobile market outside iOS. Every serious content-blocking extension, tracker blocker, and anti-fingerprinting tool that relied on runtime request inspection has had to either rewrite, degrade, or exit Chromium.

Google's stated rationale has always been performance and security: MV2 extensions can see every request, they run persistent background pages, and a malicious one has enormous surface area. That's not wrong. What's harder to accept is the framing that `declarativeNetRequest` — a static rules API with hard caps on the number and complexity of rules — is a like-for-like replacement. It isn't. Filter lists like EasyList routinely exceed those caps. Dynamic rules based on request context (say, blocking a third-party script only when loaded from a specific first-party) are structurally impossible to express. This is well-trodden ground on HN, where the top comment on the current thread is some variation of "we told you this would happen five years ago."

Brave is the interesting asterisk. Its native ad-blocking engine is built into the browser itself and doesn't depend on the extension API, so Brave users lose less than users of vanilla Chrome or Edge. But that's a workaround, not a solution — if you want a specific filter list, a specific scriptlet, or the exact behavior uBO gives you, Brave's engine doesn't get you there. The same goes for Vivaldi's built-in blocker and Edge's tracking prevention. The MV3 transition has quietly turned "which ad blocker do you use" into "which browser do you use," because the extension is no longer the meaningful unit of choice.

There's also a developer-workflow dimension that gets underdiscussed. uBO's element picker, its logger, and its ability to surgically block a single request while you're debugging a page are tools a lot of frontend and security engineers reach for daily. The Lite version doesn't have the logger. If you've used uBO's request log to figure out why a page is 12MB of third-party JavaScript, you already know why this matters.

What this means for your stack

If you're on Chrome or Edge and you care about the full uBO feature set, your realistic options are three: switch to Firefox, switch to Brave and accept the native-engine tradeoffs, or move to uBO Lite and accept the degradation. There is no fourth path that keeps you on Chromium with the extension you had six months ago. For most developers reading this, the practical answer is Firefox as a primary or a dedicated secondary browser, with Chrome kept around for the sites and dev tools that only work there.

For teams shipping browser extensions, the calculus is different but related. If your extension relied on `webRequest` blocking for legitimate reasons — enterprise DLP, security scanning, custom analytics filtering — you've either already migrated or you're running out of runway. The MV3 rewrite is not just a manifest change; it's often an architectural rewrite, because the underlying capability model is genuinely different. Budget accordingly.

For teams building web apps, this cuts the other way. The population of users with strong ad blockers just got more concentrated in Firefox. If your product uses third-party scripts for analytics, A/B testing, or feature flags, and you're seeing weird gaps in your data, the Firefox-user cohort is now disproportionately likely to be the source. This is not a reason to fight blockers — it's a reason to have server-side fallbacks for anything you actually care about measuring.

Looking ahead

Mozilla now has an unusual amount of leverage here, and the interesting question is whether they'll use it. Firefox's desktop market share has been sliding for a decade, but privacy tooling is a durable wedge, and "the browser that still runs uBlock Origin" is the kind of positioning that writes itself. Whether Mozilla can turn a technical moat into actual users is a separate question — one that depends less on the extension API and more on whether they can ship a browser that competes on speed, sync, and mobile parity. The MV3 story has handed them a rare, clean marketing message. It would be a very Mozilla move to fumble it.