You open Chrome on a Monday morning to check a scraper’s output, and there it is in the toolbar: a little warning badge next to uBlock Origin. Click it. Google is telling you the extension may soon be disabled. Not broken, not deprecated with a migration path. Disabled.
If you build bots, this moment should feel familiar in a bad way. You have been here before, just from the other side of the browser.
What actually happened
Google has pulled Manifest V2 extensions from the Chrome Web Store, uBlock Origin included. Per Tech Times, the June 30 cutoff ends dynamic filtering, and the reporting is blunt about what comes next: no workaround remains. All About Cookies has already written up the last remaining trick as dead. BleepingComputer covered the warning banners users are seeing now. Android Authority put it plainly: Chrome users are losing their best ad blocker.
Cybernews notes that development continues on Firefox. That is the part worth sitting with, because it tells you where the extension model still has room to breathe.
Why a bot builder should care
I spend most of my time writing automation that lives inside or alongside a browser. Puppeteer, Playwright, the occasional homegrown extension that watches a page and pokes an API when something changes. Extensions are one of the cheapest ways to ship browser-side automation: no binary to install, no driver to manage, a permissions model users already understand.
Manifest V2 was the version that made that cheap. Persistent background pages meant your bot could hold state. Blocking webRequest meant your bot could inspect and modify traffic as it happened, not just describe rules in advance and hope. That second capability is exactly what dynamic filtering needed, and it is exactly what a lot of automation needs too.
Manifest V3 replaces the blocking hook with declarative rules. You register patterns up front. The browser enforces them. Your code does not get to look at the request and decide. For an ad blocker fighting a moving target, that is a fundamental downgrade. For a bot that reacts to what the network is doing, it is the same downgrade wearing a different hat.
The lesson is about platform risk, not ads
The uBlock Origin story is a clean case study in something every builder eventually learns the expensive way. You did not lose a feature. You lost a capability that your entire design assumed would exist. There was no version of clever engineering that saved it, because the thing being removed was the ground floor.
Ask yourself an uncomfortable question about your own stack. If the platform you build on removed one API tomorrow, is your project inconvenienced or is it over? For a lot of extension-based bots I have seen, honestly including a couple of mine, the answer was closer to over than I wanted to admit.
How I would restructure
None of this means stop building browser automation. It means stop putting the load-bearing logic somewhere you do not control.
- Move decisions out of the extension. Treat the extension as a thin sensor and actuator. It observes the DOM, it clicks things, it reports. The logic that decides what to do lives in your own service, where nobody revokes your permissions in a version bump.
- Prefer CDP over extension APIs for anything network-shaped. If your bot needs to see or alter traffic, drive the browser from outside with Playwright or Puppeteer. Request interception there is not subject to the same manifest rules, and you own the runtime.
- Build for two browsers from day one. Firefox keeping the older extension model alive is not a footnote, it is a hedge. Testing against a second engine costs a little upfront and buys you an exit.
- Write down your platform assumptions. An actual list, in the repo. “This needs persistent background state.” “This needs to modify requests in flight.” When a platform announcement lands, you diff the announcement against the list instead of guessing.
- Assume declarative is the direction. Whether or not you like it, the trend in browser extension design is toward describing intent and letting the browser execute. Designs that survive are the ones that can express their rules in advance.
What I am doing this week
Auditing my own extensions for V2-only dependencies, and moving anything that touches network behavior into an external use driven by Playwright. The extensions that are pure DOM work will migrate to V3 fine. The ones that were quietly doing traffic inspection are getting rewritten, because that door is closed.
The ad blocking fight will keep going, on Firefox and in whatever forks appear. But the transferable lesson for anyone who builds on someone else’s runtime is simpler and older than this news cycle: know which of your assumptions are load-bearing, and never let all of them belong to a single vendor.
🕒 Published: