Firefox Is the Last Browser Where uBlock Origin Works

On 10 August, the Firefox account posted eight words on Bluesky: “Our support for uBlock Origin isn’t going anywhere.”

It read as a marketing line. It was closer to an obituary for everyone else. Microsoft Edge is moving to Manifest V3 and locking out the extensions still running on Manifest V2, uBlock Origin among them, which leaves Firefox as the only major browser where the thing still works.

That story went to the top of Hacker News with over twelve hundred points and several hundred comments, which tells you it touched something. It is worth working out what, because the ad-blocking argument is the least interesting part of it.

What follows is the technical change stated accurately, the strongest version of the argument in its favour, the argument against that does not depend on assuming bad faith, and an adjacency that has gone unremarked because the two halves are usually covered by different people on different days.

Where things actually stand

Google began the migration from Manifest V2 to V3 in Chrome and in Chromium, the engine underneath most browsers now shipping. Edge is Chromium-based and is following. So are Opera, Brave, Vivaldi and Samsung Browser, because they are built on the same foundation.

Firefox is one of the few major browsers not built on Chromium, and it has now said publicly that it will keep supporting the extension as the others phase it out.

The two other significant non-Chromium options do not help here. Neither Safari nor DuckDuckGo supports uBlock Origin at all.

One correction to the version of this story that circulates on social media, because it matters and gets flattened: this is not the end of content blocking in Chrome. uBlock Origin Lite exists, is built for Manifest V3, and works. It has fewer capabilities and its author is explicit that it is not a like-for-like replacement, which is a real difference and not the same as nothing.

The technical change, briefly

Under Manifest V2, an extension could register a blocking listener and inspect every request the browser was about to make, then decide in code whether to allow it, redirect it, or cancel it.

// Manifest V2: the extension sees the request and decides.
chrome.webRequest.onBeforeRequest.addListener(
  details => {
    return { cancel: shouldBlock(details) };  // arbitrary logic
  },
  { urls: ['<all_urls>'] },
  ['blocking']
);

That is enormous power. The extension runs code on every request, sees every URL, and its decision procedure can be anything at all.

Manifest V3 replaces that with a declarative model. The extension ships rules, the browser evaluates them, and the extension is not in the loop at request time.

// Manifest V3: the extension declares rules, the browser decides.
{
  "id": 1,
  "priority": 1,
  "action": { "type": "block" },
  "condition": { "urlFilter": "||ads.example.com", "resourceTypes": ["script"] }
}

The consequence, as the reporting puts it, is that ad-blocking extensions lose access to the functions needed to properly identify and block ads. Pattern matching against a URL is a different tool from arbitrary logic with full visibility, and the gap shows up on exactly the cases that are hard: content served from the same origin as the page, ads assembled at runtime, anything requiring the extension to reason rather than to match.

What the declarative model is actually good at

Being fair to the design, because the declarative approach is not a toy.

For the overwhelming majority of blocking, a pattern against a URL is entirely sufficient. Third-party ad servers, tracking pixels, analytics beacons and the rest live at identifiable hostnames, and a rule that matches a hostname handles them without any code running. That covers most of what most blocklists do.

The browser can also evaluate those rules faster than an extension can, because it is doing the matching internally rather than crossing into extension code and back for every request. And rules that ship as data can be reviewed before they reach users, in a way that arbitrary code cannot be.

Where it falls down is the residue. Content served from the page’s own origin, so no hostname distinguishes it. Elements that only become identifiable after the page has assembled itself. Anything where the decision depends on context rather than on the URL. That residue is small as a fraction of requests and large as a fraction of the cases people install a blocker to deal with.

Which is the honest summary of uBlock Origin Lite: it handles the bulk and gives up the tail. Whether that matters depends entirely on whether the tail was the reason you installed it.

The case for Manifest V3, made properly

Most writing on this treats the rationale as a fig leaf. That is lazy, and it makes the criticism weaker rather than stronger, so here is the argument at full strength.

A Manifest V2 blocking extension has, by design, total visibility of a user’s browsing. Every URL, in real time, evaluated by code the browser cannot inspect. If you were designing a permission model today, you would not invent that voluntarily.

And extensions get bought. A useful extension with a modest install base is acquired, an update ships to an existing user base that trusts it, and the new owner now has that visibility over everyone. This has happened repeatedly and it is not hypothetical. The permission was granted to one party and inherited by another.

There is a performance argument too. A synchronous listener in front of every request is a cost on every request, and a declarative ruleset the browser evaluates internally is straightforwardly cheaper.

All of that is true. An engineer designing an extension platform from scratch, with no incumbent ecosystem and no commercial interest in advertising, could arrive at something like Manifest V3 honestly.

The case against, which is not really about ads

The counter-argument is not that the security reasoning is fake. It is that the party making the tradeoff is not neutral about which capabilities survive it.

Google’s revenue is advertising. The capability being reduced is the one most useful for blocking advertising. Both facts can be true alongside a genuine security rationale, and pointing at the coincidence is not conspiracy thinking, it is the ordinary observation that we usually apply to every other vendor.

The structural problem sits underneath. When one engine powers Chrome, Edge, Opera, Brave, Vivaldi and Samsung Browser, a decision taken once propagates to nearly the whole market without any of those vendors choosing it independently. Edge did not evaluate Manifest V3 and agree. Edge is downstream.

That is the part worth caring about even if you have never installed an ad blocker. The web platform now has one place where a capability can be removed for almost everyone, and one remaining major implementation that can say no.

Why the fork argument does not save you

The standard reply to any complaint about Chromium is that it is open source, so anybody unhappy can fork it. Brave and Vivaldi are downstream and could in principle diverge.

In practice that costs more than it sounds. Keeping a browser engine current against a web that changes weekly is a permanent engineering commitment, not a one-off patch. Every downstream vendor that wants to keep a capability upstream removed has to maintain that difference against a codebase moving underneath it, indefinitely, and absorb the merge cost every time the surrounding code is refactored.

Some vendors do carry patches, and some have said they will keep aspects of the older extension support working for longer. That is real and worth crediting. It is also a smaller promise than it appears, because it is a promise to keep swimming upstream for as long as it stays affordable, made by companies far smaller than the one setting the direction.

The availability of the source is not the same as the availability of a genuine alternative. That distinction is the whole reason a second independent engine matters more than a dozen downstream skins of the first.

The adjacency nobody is naming

Here is the part that made me want to write this, and it is uncomfortable because we published the other half of it yesterday.

Chrome is currently running an origin trial for WebMCP, which lets a page declare the purpose of its interface elements so that an AI agent can operate the site accurately. It shipped a Lighthouse category that scores how ready your site is for agents. We covered that work approvingly, and the practical advice in it stands, because agents read the accessibility tree and the accessibility work pays off either way.

Now put the two next to each other.

The same platform is expanding what automated software may do on a page, deliberately and with new APIs, while reducing what an extension chosen by the user may do on that same page. Both are described as improvements. They point in opposite directions on the question of who the browser works for.

I do not think that is a plot. The teams are different, the timelines are different, and neither decision was made with reference to the other. But the net effect is a browser where the agent gets richer affordances and the user’s chosen tooling gets poorer ones, and it is worth saying out loud rather than covering each story separately and never putting them on the same page.

There is a version of the agentic web that is genuinely good for users, and it depends on the user’s agent being under the user’s control. An extension is the closest thing the current platform has to that, and it is the thing being narrowed.

What this means if you build for the web

Four practical consequences, in descending order of how likely they are to affect you.

Your analytics are about to shift, slightly

If a meaningful share of your audience is technical, some of them are running full uBlock Origin today. As Chromium browsers complete the transition, a portion of that blocking gets less effective, and requests that were previously cancelled will start completing.

That looks like a traffic increase in your analytics. It is not one. It is the same people, measured more completely. Anyone reporting on year-over-year numbers across this period should note it rather than take the credit.

The size of the shift depends entirely on your audience. A site read by developers may have a substantial blocked share; a site read by the general public much less. If you have ever compared your server-side request logs against your client-side analytics, the gap between them is roughly the population this affects, and it is worth measuring now so you have a before.

Annotate the date in whatever analytics tool you use. Six months from now, somebody will be asked to explain a step change in a chart, and the honest explanation will be far easier to give if a note is sitting on it.

If you ship an extension, the deadline is real

Plenty of WordPress-adjacent tooling ships browser extensions: preview tools, admin helpers, QA utilities, screenshot and annotation tools. If yours still targets Manifest V2, its life on Chromium browsers is finite.

// The line that decides whether your extension has a deadline.
{
  "manifest_version": 2,   // migrate
  "background": { "scripts": ["background.js"], "persistent": true }
}

Most migrations are mechanical: a service worker instead of a persistent background page, and the declarative rules API instead of blocking listeners. The exception is anything whose entire purpose was inspecting requests in code, which does not have a clean port because the capability is the thing being removed.

Test in Firefox, deliberately

If Firefox becomes the browser of choice for a technically-minded slice of users, that slice is over-represented among the people who file good bug reports and who evaluate developer tools. A rendering fault that only appears in Firefox now costs more than it did.

Do not build on a capability one vendor can withdraw

The general lesson, and the one that outlives this particular fight. Manifest V2 was a stable platform capability for over a decade, and businesses were built on it. It is going away because the platform owner decided, and no amount of usage protected it.

The same reasoning applies to any origin trial you are tempted to build a product around, including the agent APIs. We said in the piece on the Abilities API exposure flag that a permission check is the only thing that reliably holds, and this is the platform-level version of the same rule: a capability you do not control is one you are renting.

The WordPress-shaped version of this problem

Two things worth drawing out for anyone whose work sits inside WordPress rather than inside a browser.

The first is that WordPress has the same structural shape, at a smaller scale. A very large share of the web runs one CMS, and decisions taken in core propagate to every site that updates. That is usually a benefit, and it is the reason a security release can reach a substantial fraction of the web in days. It is the same mechanism as Chromium, pointed at something people mostly like.

The difference is governance and the licence. Anyone can fork WordPress, keep a capability core decided to drop, and continue. That has happened, it produced usable software, and the possibility itself constrains what core can get away with. Chromium is open source too, but forking a browser engine and maintaining it against the modern web is not a project a disgruntled community completes in a weekend, which is why the theoretical right to fork does less work there than it does here.

The second is more concrete. If you build plugins that assume a particular client-side environment, this is a reminder that the environment is not yours. Consent banners, anti-adblock detection, lazy-loading tricks that depend on request interception, analytics that assume requests complete: all of these sit on top of behaviour a browser vendor can change without consulting anyone.

Anti-adblock scripts are the sharpest example, since a good number of WordPress sites run one. Their entire function is to detect the presence of a tool the user chose to install and then withhold content until it is disabled. Whatever you think of that as a business practice, its technical foundation has always been a race it eventually loses, and betting on a browser vendor to win the race on your behalf is a strategy with an obvious dependency.

If you run an ad-supported site

Worth addressing directly, because a fair number of people reading this make money from advertising and the honest answer is not entirely comfortable.

In narrow commercial terms this is good news for you. Blocking gets less effective on most browsers, and impressions that were previously lost start being counted.

The reason to hold that lightly is that ad blocking was always a signal rather than a problem in itself. People install blockers because the experience got intolerable: interstitials, layout shift, autoplay, trackers, pages that take longer to become usable than to read. Removing the ability to block does not fix any of that. It removes the symptom while leaving the cause, and the underlying feeling about the web does not improve because a tool stopped working.

The sites that come out of this well are the ones whose advertising a reasonable person would not have blocked in the first place. That was true before Manifest V3 and it is unaffected by it.

Which suggests a use for the next year or so that is more productive than counting the extra impressions. If blocking is going to be less effective for a while, that is a window in which the cost of a bad ad experience is temporarily hidden from you. Spending it on making the experience good enough to survive the next tool is a better use of the window than getting used to the numbers.

What I would actually do

• Check the manifest version of anything you ship. One line, and it tells you whether you have a deadline.
• Annotate your analytics around this period, so a measurement change does not get read as growth later.
• Keep Firefox in your test matrix rather than treating it as an afterthought, particularly for developer-facing products.
• Separate the two questions when you argue about it. Whether Manifest V3 is defensible engineering, and whether one engine should be able to make the decision for the whole market, are not the same question and the second is the one that matters.

And if you have never thought about which browser you personally use as a decision with consequences, this is a reasonable moment to. Not out of loyalty to a vendor, but because engine diversity is the only mechanism by which any of this gets contested, and it only exists while people use the alternative.

The part that will still be true in five years

Ad blocking will get sorted out. It always does. The tools adapt, the ecosystem shifts, and in three years there will be a different arrangement that mostly works for the people who care enough to configure it.

What will not resolve itself is the structure that made this possible. One engine, one vendor whose business is advertising, and a capability that could be reduced across nearly the entire market by a single decision, with one remaining implementation in a position to refuse.

Firefox’s eight words were not a product announcement. They were a reminder that the web still has somewhere for a decision like this to be argued with, and that this is contingent rather than permanent.

One last thought for anyone who finds the whole argument overheated. It is entirely reasonable to conclude that Manifest V3 is a sensible security decision, that uBlock Origin Lite is good enough, and that none of this will affect your work. Plenty of thoughtful engineers hold exactly that view and they are not being naive.

The position worth resisting is the one that skips the question entirely. Whether or not this particular capability mattered, the mechanism that removed it is the same mechanism that will decide the next one, and the next one may be something you do depend on. Noticing how the decision got made is useful even when you agree with the outcome.