On August 31, 2026, Google removed the last Manifest V2 extensions from the Chrome Web Store, and uBlock Origin — the ad blocker somewhere between 30 and 40 million Chrome users had installed — stopped working the way it used to. The story first surfaced via webiterate.dev and was trending on Hacker News within hours, with the top comment threads doing the thing HN does best: relitigating a decision Google actually announced back in 2019. Seven years of warning, and the day it landed still felt like a rug pull to a huge number of users and the small teams who’d built around it.
That’s not really a story about ad blockers. It’s a story about what happens when your product’s core functionality lives inside an API surface owned entirely by someone else, and that someone else has a roadmap you don’t get a vote on.
Manifest V2 was never a secret, and it still caught people off guard
Manifest V3 was announced in 2019, went live for new extensions in 2021, and Google spent years publicly narrowing the on-ramp for anything built on the old model. The core change — replacing the `webRequest` blocking API with the far more limited `declarativeNetRequest` — was explicitly framed by Google as a security and performance improvement, and just as explicitly understood by the ad-blocking community as a functional ceiling. uBlock Origin’s author wrote detailed technical breakdowns of exactly what would and wouldn’t survive the transition, years in advance. None of that prevented the August 31 cutover from being treated, correctly, as a genuine break in functionality for millions of end users.
That gap — between “documented years in advance” and “still an incident when it ships” — is the actual lesson. Deprecation notices don’t get triaged with the urgency of an outage. They get filed under someday, until someday is the release notes for Chrome 151.
What a real dependency-risk audit catches before the deadline is a deadline
If uBlock Origin’s situation were a client engagement, this is exactly the kind of thing we’d flag in a code and architecture audit, not because we have any special insight into Google’s roadmap, but because the pattern is generic and the checklist is boring:
- Any feature that depends on a vendor-controlled API — a browser extension permission, a platform’s push notification service, an OS-level background execution allowance, a third-party auth provider’s token scope — gets an explicit owner and an explicit “what if this changes” answer, not an implicit assumption that it won’t.
- Deprecation notices for dependencies you rely on for core functionality get tracked with the same seriousness as security advisories, with a real date attached, not a mental note.
- You separate “features that are nice because the platform allows them” from “features the product cannot survive without,” and you know which category each dependency falls into before you’re forced to find out live.
- For anything in that second category, you either build a fallback path or you consciously accept the risk in writing — which is a very different posture than discovering the risk when your users start filing bug reports.
uBlock Origin’s team did almost everything right here — public technical writeups, community migration guidance, a Manifest V3-compatible “Lite” version shipped well ahead of the deadline. And it still landed as a disruption, because the underlying architecture had a hard ceiling that no amount of good engineering on their side could raise. That’s the part worth sitting with: sometimes the audit doesn’t produce a fix, it produces an honest answer about how much of your product’s fate is actually yours to control.
This isn’t a browser-extension problem
Swap the specifics and this same failure mode shows up constantly in the apps and backends we get asked to look at. A mobile app that leans on an OS’s background-refresh allowance for a feature users think of as “real-time,” until an iOS or Android update tightens it. An AI feature wired directly to one model provider’s API with no abstraction layer, so a pricing change, a deprecated endpoint, or a rate-limit policy shift becomes an emergency rewrite instead of a config change. A whole product built on a platform’s “free” tier of some infrastructure service, with no plan for what happens when that tier gets restructured — which, on a long enough timeline, it always does.
None of these are exotic risks. They’re the ordinary cost of building on top of anything you didn’t write, which is all software, always. The difference between a team that handles it well and one that doesn’t is whether someone actually looked at the dependency list and asked “what’s the failure mode here, and when’s it due” before the vendor’s changelog answered the question for them.
Where this fits into how we work
This is a big part of what a code audit or architectural review from orithLabs is actually for — not a style-guide pass, but going through a codebase’s real dependency surface and being straight about which of them are load-bearing, which ones have a public deprecation clock already running, and what it would cost to be wrong about either. We’ve built that discipline into how we’ve shipped our own apps, Crumb Count and Kompete included, and we’d rather have that conversation with a client in a calm room in 2026 than in a panic when their equivalent of Chrome 151 ships.