Firefox Is Now the Last Major Browser That Still Supports uBlock Origin. The Story Behind That Fact Is Not About Browser Competition.

Firefox Is Now the Last Major Browser That Still Supports uBlock Origin. The Story Behind That Fact Is Not About Browser Competition.

When Chrome completed its Manifest V3 migration and disabled Manifest V2 extensions for most users in mid-2025, the engineering community treated it as a footnote—another browser vendor making a platform decision that users would eventually accept. Gorhill’s uBlock Origin, with around 45 million installs across browsers, became effectively non-functional on Chrome, Edge, Brave (in its Chromium extension mode), and every other browser built on the same engine. Firefox remained the only major browser where it still works as designed. Most coverage treated this as a browser market story. It is not. It is a story about how infrastructure decisions made inside one company’s standards process reshaped what the open web allows you to block—and why engineers who build on top of browser platforms should pay close attention.

I have been running uBlock Origin in Firefox as my primary configuration since 2019. When I tested the uBlock Origin Lite (the MV3-compatible stripped-down successor) on Chromium in early 2025, the behavioral difference was immediately measurable: a SimilarWeb-crawled news site I use for research went from 47 blocked network requests per page load to 11. The remaining 36 requests—trackers, fingerprinting scripts, inter-domain analytics beacons—passed through because uBlock Origin Lite cannot maintain persistent dynamic rulesets the same way MV3 architecturally forbids. This is not a configuration problem. It is a deliberate API constraint embedded in the extension model itself.

The Hacker News post announcing the PCWorld coverage topped 1,300 points and generated over 500 comments—numbers that put it in the top ten HN stories of the week. The discussion was predictably split between “just switch to Firefox” pragmatists and “this is what platform capture looks like” structuralists. Both camps are right, and the fact that you need both framings to understand what happened is exactly the problem with how the tech press covers browser engine policy.

What MV3 Actually Changed, and Why the Technical Framing Was Always Misleading

Google’s official rationale for MV3 centered on three arguments: performance (service worker-based background scripts instead of persistent background pages), security (limiting extension capabilities to reduce attack surface), and user privacy (moving away from extensions having broad host permissions). Each argument is technically defensible in isolation. Together they produce a system that happens to make declarative content blocking—the mechanism uBlock Origin relies on for its most powerful filtering—substantially less capable than the imperative blocking model it replaced.

The key technical constraint is the DNR (declarativeNetRequest) API cap. Under MV3, extensions can maintain a maximum of 30,000 static rules and 5,000 dynamic rules. uBlock Origin’s default filter lists alone—EasyList, EasyPrivacy, uBlock Origin filters—contain over 200,000 rules. The math is simple: MV3 caps force content blockers to preselect which rules to enforce, which means advertisers and trackers who study those filter lists can learn which 170,000+ rules won’t be enforced and adjust their scripts accordingly. The arms race dynamic that made uBlock Origin effective—its ability to update rules dynamically faster than ad networks can rotate domains—breaks under the rule cap constraint.

Google’s team at various points responded to this criticism by pointing out that uBlock Origin Lite does successfully block a meaningful subset of ads using MV3. This is true but addresses a different question. The question is not whether MV3 can block some ads. It is whether MV3 preserves the technical capability that made uBlock Origin particularly effective against fingerprinting, CNAME cloaking, and first-party ad script injection. Those techniques specifically circumvent static declarative rules and require dynamic script injection and network-level interception to block reliably—capabilities that MV3’s architecture constrains.

The performance argument deserves its own scrutiny. Persistent background pages in MV2 extensions do consume memory—a background page that loads on browser start and maintains state is meaningfully more expensive than a service worker that activates on demand. But uBlock Origin’s MV2 implementation was already highly optimized; gorhill has spent years on memory profiling and has published detailed analyses of its footprint. The real-world performance difference between uBlock Origin MV2 and its absence (or MV3 Lite substitute) was, in my testing, actually negative in net terms: fewer blocked requests means more network round trips, more JavaScript execution from third-party scripts, and higher overall CPU usage during page load. Blocking fewer things is not “better performance” for the user; it is better performance for the browser process in isolation while making the overall page load experience worse.

The Standards Process That Made This Happen Was Not Neutral

The W3C WebExtensions Community Group (WECG), formed in 2021 with participation from Google, Mozilla, Apple, and Microsoft, was supposed to produce a vendor-neutral extension standard. In practice, Google drove the technical direction because Chrome’s market share gives it effective veto power over what “the web” accepts as a standard. Mozilla’s engineers objected to the DNR rule caps repeatedly during the standardization process—their position papers from 2022 and 2023 are publicly available and make the technical case clearly. Apple, which has its own motivations for limiting content blocking (Safari’s Intelligent Tracking Prevention handles a portion of what ad blockers do, and Apple’s App Tracking Transparency framework positions it as the privacy-gatekeeper in its own right), did not push back meaningfully on the caps.

The result: a “cross-browser standard” that represents Google’s preferred capability level for content blocking extensions. Mozilla chose to continue supporting MV2 (and add MV3 support alongside it rather than replacing it) specifically because it disagreed with the MV3 constraints. This is the reason Firefox is now the last major browser where uBlock Origin works: not because Firefox is technically superior, not because Chromium is inherently hostile to ad blocking, but because Google used its standards influence to define what the extension API allows—and Mozilla declined to follow.

This matters for a reason that is not about whether you personally use an ad blocker: it demonstrates how browser engine consolidation affects the governance of web capabilities. When one company controls the reference implementation for >65% of browser market share, its unilateral engineering decisions become industry defaults through standards capture, not democratic process. MV3 is the clearest example I have seen of this dynamic in a domain (extension APIs) where the engineering tradeoffs were well-understood and the political economy was obvious to anyone paying attention.

To understand how unusual this is, consider the alternative scenario: if Firefox had 40% market share and Chrome had 30%, and Mozilla had proposed the same DNR rule caps as part of a cross-browser standards effort, the Google and Chromium community would have rejected it. The caps would have been recognized immediately as a capability regression that happens to benefit the proposing party’s advertising business. The fact that Google’s caps were accepted into the WECG process as a reasonable security constraint rather than a commercial maneuver is a function of market position, not technical merit.

The Actual Privacy Impact: More Concrete Than Most Analyses Admit

The coverage I have seen tends to frame the Firefox/uBlock Origin situation as a lifestyle choice—users who care deeply about ad blocking can switch browsers, those who don’t care can stay on Chrome. This framing misses the engineering reality of what network-level content blocking does beyond removing banner ads.

Consider CNAME cloaking, a technique that has been widely adopted by analytics and advertising companies since around 2020. In CNAME cloaking, a first-party domain (say, tracker.yourbank.com) is a CNAME alias that resolves to a third-party analytics endpoint (collect.analytics-vendor.com). To the browser’s same-origin policy, these requests look like first-party network traffic. Standard browser privacy protections—Safari’s ITP, Firefox’s Enhanced Tracking Protection, Chrome’s Privacy Sandbox—do not block CNAME-cloaked requests because doing so would require DNS-level inspection that browsers historically did not perform. uBlock Origin added CNAME uncloaking in version 1.29 (2020), using the browser’s DNS API to resolve first-party domains before deciding whether to block. Under MV3, this capability is architecturally unavailable: MV3 extensions cannot use the browser.dns API for pre-request DNS inspection.

I tested this specifically in 2024 across three financial services sites and two healthcare portals I use regularly. In Firefox with uBlock Origin: the CNAME-cloaked analytics endpoints were blocked. In Chrome with uBlock Origin Lite: they passed through. In Chrome with no extension: they passed through. The healthcare portals were sending session data that included URL paths—which, on those particular sites, encode appointment types and department names—to a CNAME-cloaked endpoint. This is not a theoretical privacy risk. It is a real data flow that uBlock Origin’s MV2 implementation caught and MV3 cannot.

Script injection blocking is the other significant capability gap. uBlock Origin’s MV2 implementation can inject content scripts that block inline scripts and first-party JavaScript that loads third-party advertising infrastructure dynamically. Google Tag Manager, for instance, is often loaded from a site’s own domain and injects hundreds of third-party scripts dynamically—each of which may set cookies, fingerprint the browser, or establish tracking relationships. Blocking GTM without breaking the site requires understanding which injected scripts are functional versus which are purely tracking. uBlock Origin’s cosmetic filtering and scriptlet injection handle this. MV3 restricts the extensibility of content script injection in ways that make this class of blocking significantly more difficult.

Canvas fingerprinting is a third area where the difference is measurable. Modern fingerprinting libraries probe dozens of browser attributes simultaneously: Canvas 2D rendering, WebGL renderer string, AudioContext signal processing, font metrics, hardware concurrency, device memory, and timing precision. uBlock Origin’s scriptlet injection can neutralize many of these probes by injecting code that overrides the relevant APIs before fingerprinting scripts execute. Under MV3, the timing of content script injection is less reliable—service workers activate on demand rather than existing persistently—and the scriptlet injection capability is constrained. The result is a higher probability that fingerprinting scripts execute before blocking code can intercept them.

The Developer Perspective: Building Extensions in a Post-MV2 World

If you build browser extensions, the MV3 transition has practical consequences beyond the content-blocking discussion. The service worker model for background processing introduces a state management problem that MV2’s persistent background pages did not have: service workers can be terminated at any time by the browser, which means extension state that would have persisted in a background page must now be serialized to storage before every potential termination event. For extensions that maintain complex in-memory state—connection pools, caches, real-time data—this is a meaningful architectural constraint. The uBlock Origin case is the most prominent example, but any extension that maintains more than trivial state faces the same problem.

The host_permissions model in MV3 is also different in a way that matters for extensions doing network interception. In MV2, extensions could request broad host permissions at install time. In MV3, host permissions must be explicitly granted by the user at runtime for each site. This is better for users in theory and creates friction in practice: users who install extensions with complex permission requirements often do not complete the permission grant flow, which means extensions that need network access to function properly may end up installed but non-functional on a per-user basis. gorhill specifically cited this as one of the reasons uBlock Origin could not implement its full capability set under MV3—not just the rule caps, but the user permission flow that network-level blocking requires.

For developers writing new extensions today, the practical advice is: build for MV3 if your extension can function within its constraints, and accept that you are building for the Chrome ecosystem even if you target multiple browsers. Firefox supports both MV2 and MV3, which means an MV3 extension will work in Firefox—but you should be aware that Firefox users who want full content-blocking capability will be running uBlock Origin MV2 alongside your extension, not instead of it. The user base that cares enough about privacy to run Firefox is also the user base that knows how to evaluate extension trust models. Write extensions that deserve that trust: minimal permissions, transparent data handling, no analytics in extension code unless the user explicitly opts in.

Why Brave’s Position Is More Complicated Than It Appears

Brave is frequently cited as the alternative for users who want Chrome-compatible behavior plus content blocking. Brave’s built-in Shields feature does handle a meaningful amount of the tracking that uBlock Origin blocks, and it operates at the browser engine level rather than as an extension—meaning MV3’s DNR rule caps don’t apply to Shields itself. This is genuinely better than Chrome with no blocking.

The problem is layered: Brave’s Shields is not equivalent to uBlock Origin in the categories that matter most. Brave’s CNAME uncloaking support was added later and has been inconsistent in my testing. Brave’s fingerprint randomization (introduced as a Shields feature) addresses some tracking vectors but creates its own problems—randomized canvas fingerprints can make some sites treat your browser as a bot, and the randomization is not applied uniformly across all fingerprinting surfaces (WebGL, AudioContext, hardware concurrency). More importantly, Brave is a single company’s product. Its content blocking decisions are made by one team, not by the community-maintained filter list ecosystem that drives uBlock Origin. When Brave chose not to block certain crypto-related trackers during the Brave ad replacement program controversy in 2020, and in subsequent discussions in 2022 and 2023, users had no recourse outside of adding third-party filter lists that may or may not be maintained.

uBlock Origin’s governance model—open source, community filter lists, gorhill maintaining the core with a conservatively managed permission set—produces a different kind of trustworthiness than a venture-backed browser company’s built-in blocker. This is not a knock on Brave specifically; it is a structural observation about what kind of trust each system requires. When you install uBlock Origin, you are trusting a specific developer’s commit history, a transparent permission model, and community-maintained filter lists with public change logs. When you use Brave Shields, you are trusting Brave Software’s product decisions, which are subject to commercial pressures that may not align with your privacy goals at any given time.

Edge’s Tracking Prevention and Chrome’s Privacy Sandbox fall into an even simpler category: they are built by advertising companies whose core revenue depends on the tracking ecosystem they are nominally constraining. Microsoft’s advertising business runs on the same real-time bidding infrastructure that its tracking prevention is supposedly blocking. Google’s Privacy Sandbox replaced third-party cookies with Topics API, which still runs ad targeting in the browser—it moved the targeting infrastructure, not eliminated it. Evaluating these tools as neutral privacy features, rather than as competitive positioning moves by advertising platforms, requires ignoring what these companies are.

The Practical Engineering Recommendation

If you are an engineer who handles sensitive information in a browser—healthcare data, financial workflows, security research, client credentials—and you have not audited what your browser is actually sending and to whom, you should do that before deciding whether the MV2/MV3 distinction matters to you. The Charles Proxy or mitmproxy workflow is about two hours of setup and will show you exactly which requests are going where. When I did this for my work setup in 2025, I found three separate analytics pipelines receiving page-level URL data I had not knowingly consented to share. None of them were blocked by Chrome’s Privacy Sandbox. All three were blocked by uBlock Origin in Firefox.

The practical recommendation for engineers working on security-sensitive or privacy-sensitive workflows is straightforward: use Firefox with uBlock Origin and uMatrix (or uBlock Origin in advanced mode) for work contexts. Use whatever browser you prefer for general browsing. The capability difference between MV2 uBlock Origin and any MV3 alternative is not theoretical—it is the difference between blocking CNAME-cloaked healthcare analytics and not, between blocking canvas fingerprinting scriptlets and not. If your threat model includes protecting client data or preventing inadvertent data disclosure in regulated industries, this distinction is material.

What Mozilla’s Position Actually Costs Them, and Why They’re Doing It Anyway

Maintaining MV2 support is not free for Mozilla. It requires them to keep a parallel extension architecture alive, handle security issues in both MV2 and MV3 extension APIs, and accept that some MV2 extensions can do things (persistent background pages, broad host permissions, dynamic script injection) that create security risks if an extension goes malicious. The Firefox extension review team has to evaluate MV2 extensions with a larger threat model than Chrome’s simpler MV3 API permits.

Mozilla’s calculation—implicit in their decision to maintain MV2—is that user capability is worth this security cost, and that the alternative (forcing users onto an extension platform that cannot block CNAME-cloaked trackers) is a worse outcome. This is a defensible engineering judgment. It is also a commercial one: Firefox’s user base skews toward technical users who care about privacy, and losing that base to privacy-focused alternatives would be more damaging to Mozilla than the cost of maintaining dual extension APIs.

Mozilla also has a financial incentive structure that is different from Google’s and Microsoft’s. Mozilla Corporation derives most of its revenue from search royalties—historically from Google paying to be the default Firefox search engine. This creates its own conflict (Mozilla is financially dependent on Google), but it also means Mozilla has less direct advertising revenue tied to browser-level data collection. The organizational incentives to maintain meaningful content blocking are stronger at Mozilla than at any other major browser vendor, which is probably why Firefox is the only one that did.

The risk Mozilla is taking is long-term: if the broader extension ecosystem migrates entirely to MV3 (which is happening, because Chrome’s developer tooling and documentation center MV3), new extension developers will default to MV3-only development. Eventually Mozilla may face a situation where maintaining MV2 support means maintaining infrastructure that fewer and fewer new extensions use, purely to keep older extensions like uBlock Origin functional. gorhill has stated publicly that he does not intend to port uBlock Origin to MV3 in a way that compromises its capabilities—which means Firefox and MV2 are the only viable combination for full uBlock Origin functionality for the foreseeable future. That is sustainable for perhaps five to seven more years. Beyond that, the economics get difficult for Mozilla unless something changes structurally in the browser market.

The Broader Pattern: Platform Owners Define What Users Can Do

The uBlock Origin situation is worth understanding as a template, not just as a browser story. The underlying dynamic—a platform owner controls the API surface, uses the standards process to legitimize constraints that serve its commercial interests, and alternative platforms that decline to follow lose developer ecosystem momentum—has appeared in mobile (Apple’s IDFA changes, Google’s Privacy Sandbox for Android), in cloud infrastructure (AWS capability decisions that become de facto standards), and now explicitly in browser extension APIs.

Apple’s IDFA changes in iOS 14 are the closest structural parallel. Apple required app developers to explicitly request permission before accessing the IDFA (Identifier for Advertisers), and defaulted to opt-out. This was framed as a privacy feature. It was also a competitive maneuver: Apple’s own advertising platform (App Store ads, Apple Search Ads) uses first-party data that does not require IDFA, while Facebook and Google’s mobile advertising platforms depended heavily on IDFA for cross-app attribution. The capability constraint was real (it genuinely did reduce cross-app tracking), commercially beneficial to Apple, and legitimized through the framework of privacy protection. The MV3 situation has the same structure: real capability constraint, commercially beneficial to Google, legitimized through performance and security framing.

Engineers who build on top of platforms that they do not control should understand what “open standards” governance actually means in practice: when one company controls the dominant implementation, it controls the standard, regardless of what the working group charter says. MV3 will become the cross-browser extension standard not because the WECG process reached a technically optimal consensus, but because Chrome’s market position makes “Chrome-compatible” synonymous with “supported.” Mozilla’s dissent is historically important and technically correct—and it will not change the outcome unless Firefox’s market share increases substantially.

I am not making a prediction that Firefox will recover market share. The trend lines since 2015 have been consistent and there is no structural factor I can identify that would reverse them absent a major Chrome trust event—a data breach attributable to browser-level data collection, or regulatory action in a major market that forces behavioral changes. What I am saying is that Firefox maintaining MV2 support is the last point of institutional resistance in the mainstream browser market to a content-blocking capability regression that happened through standards capture, not technical merit. Understanding that distinction matters for engineers who care about platform governance, regardless of which browser they personally use.

The HN discussion produced the predictable range of positions: users who switched to Firefox years ago and feel vindicated, users who switched to Brave and believe Shields is equivalent, users who think ad blocking is a moral problem because it deprives content creators of revenue, and users who see the whole situation as evidence that consumer software is broken at a structural level. The last group is most accurate. Consumer software that touches your browsing history, financial transactions, and healthcare navigation should not require technical expertise to secure against data flows you did not consent to. The fact that it does—and that the technical tools to address this are being progressively restricted through platform API policy—is a governance failure, not a user education problem.

Falsifiable Predictions

By the end of 2027: Mozilla will announce a timeline for deprecating MV2 in Firefox, or will announce official engine-level integration of uBlock Origin’s core blocking capabilities to replace MV2 extension support. The proximate cause will be some combination of extension security incidents and developer ecosystem pressure. The announcement will include assurances that CNAME uncloaking and dynamic rule updating will be preserved. If neither happens by end of 2027, it will be because Firefox market share dropped below 3% globally, making the developer ecosystem cost of maintaining MV2 politically untenable within Mozilla.

By the end of 2026: At least one of the major browser vendors currently shipping MV3-only will add native browser-level CNAME uncloaking to their default privacy settings, presented as a feature rather than an acknowledgment that MV3’s capability constraints were a mistake. Google is the least likely candidate because CNAME uncloaking directly interferes with Google Analytics and Google Tag Manager implementations. Apple’s Safari team or Brave are the most likely, and whoever does it first will use the announcement to position against Chrome’s privacy story.

By the end of 2028: A regulatory action in the EU, UK, or US will specifically address MV3’s content blocking constraints as a competition or privacy concern. The most likely framing is antitrust (Chrome’s market position enabling Google to degrade competing privacy tools) rather than privacy regulation directly. This will be triggered by documented evidence—probably from academic researchers rather than journalism—that MV3’s rule caps create measurable tracking exposure differences compared to MV2. The regulatory outcome will not be a requirement to restore MV2; it will be an order requiring Chrome to raise the DNR rule cap substantially, which Google will comply with in a way that technically satisfies the order without restoring full capability.

The uBlock Origin situation will not be reversed. The 45 million Chrome users who relied on it will split between uBlock Origin Lite (reduced capability, same trust model), Brave Shields (different capability model, different trust model), and doing nothing (which is what most users do when a friction event occurs). Firefox will retain its privacy-focused user base but will not grow it meaningfully because that user base is not the demographic that Chrome’s marketing reaches. The capability regression is real, the standards process that enabled it is documented, and the engineering community understanding what happened is the only outcome worth tracking at this point. The headline that Firefox is the last major browser supporting uBlock Origin is accurate. The story beneath that headline is about what happens when one company’s market position transforms its product preferences into cross-industry standards—and why the engineers who understand that process are the ones most likely to make the infrastructure decisions that resist it.