On 10 August 2026, Mozilla posted a short message on Bluesky: “Our support for uBlock Origin isn’t going anywhere.” Five days later it was near the top of Hacker News with more than 1,500 points. A browser announcing it will keep supporting an extension it has always supported should not be news. That it is tells you exactly where the extension platform has ended up.
Most of the coverage framed this as an ad blocking story. It is a bigger one than that: Manifest V3 is the clearest recent example of a capability being narrowed by the vendor who owns the runtime, and the lessons apply well beyond content blocking.
TL;DR
- Chrome’s remaining Manifest V2 extensions leave the Chrome Web Store on 31 August 2026; Edge’s consumer phase-out began in August 2026, with enterprise in early 2027.
- Firefox is now the only major browser running the full uBlock Origin. uBlock Origin Lite is a deliberately reduced product, not a port.
declarativeNetRequestreplaceswebRequest: rules are declared in advance, not decided at request time, within hard limits (30,000 guaranteed static rules, 30,000 dynamic, 1,000 regex per type, 50 enabled rulesets).- Manifest V3 bans remotely hosted code, so every logic change now ships at the speed of store review, not your CI pipeline.
- If you do not ship an extension, the exposure is your measurement stack: blocking is migrating to DNS and network layers your analytics cannot detect at all.
- The transferable lesson is capability ownership. If a feature depends on a vendor API rather than a standard, you hold a licence, not a feature.
What actually changed, and when
The Manifest V3 migration has been running for years, but 2026 is when the escape hatches closed. Google removed the ExtensionManifestV2Availability enterprise policy in Chrome 139, which had allowed organisations to keep internal MV2 extensions alive on managed fleets. The remaining MV2 extensions are set to leave the Chrome Web Store on 31 August 2026.
Microsoft Edge followed, beginning its consumer phase-out in August 2026 with completion targeted for the end of the year and enterprise deprecation in early 2027. Because the change lives in Chromium, it propagates to everything built on it: Opera, Vivaldi, Samsung Internet and, depending on their own patching, Brave. Safari and DuckDuckGo never supported uBlock Origin in the first place. That leaves Firefox as the last major browser where the full extension runs, which is precisely why a routine reassurance from Mozilla became a front page story.
Why declarativeNetRequest is not webRequest
Under Manifest V2, the blocking webRequest API let extension code observe every network request and decide, in JavaScript, at request time, whether to allow it. That is enormously powerful, and it is also, to be fair to Google, an enormous amount of trust to hand to arbitrary third-party code. An extension with that permission is one supply chain compromise away from becoming a network interceptor inside every tab your staff have open, which is not hypothetical: we wrote about the AI browser extension blind spot and its 900,000 compromised installs earlier this year.
Manifest V3 replaces it with declarativeNetRequest. The extension declares its rules ahead of time; the browser evaluates them; the extension never sees the traffic. The security argument stands on its own merits. So does the capability cost, which is measurable:
- A maximum of 100 static rulesets, of which 50 may be enabled at once
- A guaranteed minimum of 30,000 static rules per extension
- 30,000 dynamic rules, of which 5,000 may be “unsafe”
- 5,000 session rules
- 1,000 regular expression rules per type
Combined with the ban on remotely hosted code, the practical effect is that anything requiring a runtime decision, whether based on response content, on accumulated state across requests, or on a rule set larger than the budget, is no longer expressible. Filter lists that once updated daily now update at the speed of store review.
If your team ships a browser extension
Five constraints that regularly get discovered late, usually after someone has scoped the migration as a manifest version bump:
Your background page is now a service worker, and it terminates. In-memory state does not survive. Anything held in a module-level variable moves to chrome.storage.session, and anything on a setTimeout becomes an alarm. This is the largest source of migration effort and the likeliest source of intermittent bugs that only appear after a machine has been idle.
No remotely hosted code. Everything executable ships in the package and passes review, so your effective release cadence is review latency rather than your CI pipeline. Feature flags still work, but only if the remote call returns configuration data that already-shipped code interprets, never code itself.
Rule budgets are an architecture decision. If your extension does any request filtering, the limits above belong in the design document, not in a bug report six months later.
The enterprise exemption is gone. Internal tooling built on MV2 has no policy-based reprieve on current Chrome. If you have an internal extension nobody has touched since its author left, that is a live issue.
Firefox is now a genuinely separate target. Mozilla supports Manifest V3 but retained blocking webRequest alongside it: good news for capability, awkward news for maintenance, because you are supporting two behaviours rather than one manifest.
If you do not ship an extension, your measurement assumptions are the exposure
Roughly 30% of internet users globally run some form of ad blocking. Desktop figures sit closer to 37%, and parts of the EU run considerably higher, with Germany reported as high as 49%. Estimates vary substantially by methodology, so treat any single figure as directional rather than precise.
The tempting conclusion is that Manifest V3 pushes those numbers down. It does not. It moves them, and it moves them somewhere worse for you: to layers the browser vendor does not control, including DNS resolvers such as NextDNS and Pi-hole, network-level filtering, VPN-integrated blockers, browsers with blocking built into the engine, and Firefox.
An extension-level block was at least visible from inside the page. A DNS-level block is not. The request never resolves, your tag never loads, and nothing reports back. Your analytics do not record a blocked session; they record no session at all. That is a silent hole in attribution.
The practical response is to stop letting business-critical metrics depend on a client-side third-party script. Move conversion and revenue events to first-party server-side collection, reconcile against server logs on a regular cadence, and treat the delta as a number you understand rather than noise.
The pattern underneath
Strip out the specifics and this is a shape we have written about repeatedly: Twitter’s API repricing in 2023, Reddit’s client ecosystem the same year, Facebook’s Graph API lockdown in 2018. In every case the engineering was sound and the dependency was the defect.
The browser extension platform has the same shape, with a wrinkle that is hard to ignore: the vendor setting the rules also runs the advertising business those rules affect. Whether that is the motive is arguable, and the security case for declarativeNetRequest would be sound regardless. But the structural point does not require motive. A capability granted at a vendor’s discretion can be narrowed at a vendor’s discretion, and no amount of code quality on your side changes that.
The useful question is not whether to trust a given vendor, but whether you know, for each capability your product depends on, if you are standing on a web standard or on someone’s API, and whether anyone has written down what happens if the second kind goes away.
What to do this quarter
- Inventory the extensions your business depends on, including internal tooling and vendor-supplied ones: SSO helpers, security agents, session recorders, accessibility tools. Establish MV3 status for each and get vendor dates in writing.
- Cost any MV3 migration honestly. Budget for service worker lifecycle rework and the intermittent bugs it produces, not for a manifest edit.
- Measure your blocked cohort. Run a week of client-side analytics against server logs. The gap is not a rounding error, it is a segment of your audience you cannot currently see.
- Move revenue-critical events server-side so no commercial decision rests on a script a resolver can quietly refuse to answer for.
- Make Firefox a deliberate line in your browser support policy, particularly if your audience skews technical or privacy-conscious. Small share of the market, unrepresentative share of your buyers.
- Record the exit path in an ADR for every vendor-controlled capability in your stack. It costs an hour and is worth having on the day it stops being theoretical.
Where we come in
At REPTILEHAUS we spend a lot of time on this class of problem: platform dependencies that look stable until they are not, measurement stacks that quietly stopped reflecting reality, and migrations scoped as configuration that turn out to be architecture. If you are facing a Manifest V3 migration, an analytics reconciliation that is not adding up, or a wider review of where your product stands on borrowed ground, get in touch.
📷 Photo by NordWood Themes on Unsplash
