Chrome Finished Removing MV2 Extensions and uBlock Origin Went With Them

On 31 August, Manifest V2 extensions were removed from the Chrome Web Store. uBlock Origin among them. The Hacker News thread hit 476 points and 379 comments inside a day.

This has been telegraphed for years, and the interesting part is not that it happened. It is that the thread spent most of its energy arguing about whether the replacement is actually worse, and the people saying it is came with specifics.

The timeline, so the dates are straight

The removal ran in stages rather than landing at once:

uBlock Origin shipped a final stable update to the Web Store days before the cutoff, which its maintainer confirmed would be the last. Google's stated reasoning is technical debt, complexity and the security surface of maintaining the old extension APIs.

What actually changes for a user

MV3 replaces the webRequest blocking API with declarativeNetRequest. Instead of an extension inspecting each request and deciding, it registers rules in advance and the browser applies them.

That distinction produces two concrete limits, both raised in the thread by people who had clearly hit them.

u/tentacleuno described the timing problem: content can load before the blocker is ready to filter it, because the extension is no longer sitting in the request path. The same comment noted that filter rules are simply less flexible than arbitrary code inspecting a request.

u/judge2020 raised the operational one. Blocklists now require Web Store updates to change, and there are upper limits on how many rules can be registered. A filter list that used to update itself now moves at review speed.

u/vamsipk put the outcome bluntly, reporting that YouTube ads are now getting through under MV3.

The pushback was better than the complaint

The thread would have been unremarkable if it were only people annoyed at Google. The most-replied comment was a defence.

u/insanitybit argued that Chrome's multiprocess sandboxing genuinely made browsing safer for the general public, and that the era of malware arriving through Java and Flash exploits ended largely because of architectural decisions of this kind. The implication being that Google's security rationale is not simply cover for an advertising interest.

u/wtallis accepted the improvement and disputed the price, arguing the overhead cost was steep and that Firefox with NoScript achieved comparable protection by other means.

That is the actual disagreement, and it is not really about ad blocking. It is whether a browser vendor gets to remove a capability because the capability is dangerous, when that vendor also benefits commercially from its removal.

The security argument and the advertising interest point the same direction. That does not make the security argument false, and it does not make it disinterested either.

The comment worth reading twice

u/btown flagged something further out than the current change: Tag Gateway, and a direction where dynamically loaded code not bundled with the extension becomes prohibited.

If that lands, the workaround space closes further. An extension that cannot fetch and apply rules it did not ship with is an extension whose behaviour is fixed at review time. Everything downstream of that, including every filter list that updates faster than a store review, becomes structurally impossible rather than merely discouraged.

Nobody in the thread had a rebuttal to that, which is usually a sign the point is sound rather than a sign it is settled.

What replaces it, honestly assessed

MV3 blockers are not nothing. uBlock Origin Lite exists, ships under MV3, and blocks a great deal. The question is what it gives up, and the answer is specific rather than vague.

Under webRequest, an extension saw a request and decided. Under declarativeNetRequest, it registers rules and the browser decides. Three consequences follow directly from that swap:

• Rules are static between updates. A list that previously refreshed hourly now refreshes when a new extension version clears review.
• There is a ceiling on rule count. Large community filter lists have to be trimmed to fit rather than merged.
• Nothing can inspect a response body. Techniques that depended on reading what came back, rather than matching the URL going out, are gone rather than harder.

For most people most of the time, that is a downgrade they will not consciously notice. For the specific cases where sites adapt faster than a review cycle, it is the whole game.

What we did not test

We have not run comparative ad-blocking benchmarks across MV2 and MV3, so we are not going to tell you how much worse it is in percentage terms. The reports above are attributed to the people who made them.

What is verifiable without any testing: the flag is gone, the extensions are delisted, and the API that made the old approach possible is not coming back.

Where this actually lands

The thread's practical consensus was Firefox, which is the predictable answer and also an incomplete one. Edge and Opera are Chromium downstreams and follow the same manifest. Brave has shipped its own accommodations. The choice is not between Chrome and everything else, it is between Chromium and not-Chromium, and that is a much shorter list.

Our read: the ad-blocking argument is the visible part of a duller and more consequential one. A browser engine with the market share Chromium has is infrastructure, and this is what it looks like when infrastructure narrows what is possible on top of it. The extensions are the thing people noticed because they use them daily.

For developers, the practical consequence is narrower and more immediate. If you build extensions, your users on Chromium now have a capability ceiling set by a review process. Plan for rules that change at store speed, not at network speed.