Chrome Killed uBlock Origin. Here's What Enterprise IT Can Still Control

What can enterprise IT still control after Chrome killed uBlock Origin?

There is no Chromium-based way to keep uBlock Origin's full filtering power in Chrome, Edge, Brave, or Opera anymore. Enterprise teams that need that level of control have two real paths: run Firefox ESR with the original uBlock Origin, or drop to network-level blocking (Pi-hole, NextDNS) alongside a lighter in-browser extension like uBlock Origin Lite, AdGuard, or Ghostery.

That's the fix. The bigger story is what it took to get there.

What happened to uBlock Origin in Chrome?

Google didn't nudge extensions toward a new API. It ran a multi-year, hard-deadline phaseout and held to it. Manifest V2, the extension format that let uBlock Origin use the blocking webRequest API to intercept and kill requests in real time, is gone. Manifest V3 replaced it with declarativeNetRequest, which caps the number of filtering rules an extension can apply and removes real-time dynamic blocking entirely.

The rollout on Chromium browsers started quietly in October 2024 and widened through early 2025, with Chrome disabling uBlock Origin outright for a growing slice of users and pointing them to uBlock Origin Lite instead, a rewrite with meaningfully weaker filtering.

By Chrome 138, released July 24, 2025, Manifest V2 was disabled for every user on every channel, with no flag to turn it back on. The final act came with Chrome 150 and 151 in 2026, when Google stripped out the last workarounds that had kept old MV2 extensions partially alive. Google engineer Devlin Cronin put it plainly on the Chromium review site: MV2 extensions are "no longer allowed in any supported version of Chrome," citing "complexity and tech debt, as well as the security risks it entails." All remaining MV2 extensions come off the Chrome Web Store for good on August 31, 2026.

Was enterprise really exempt, or just delayed?

For a while, IT admins had a lifeline: the ExtensionManifestV2Availability enterprise policy let managed fleets keep running Manifest V2 extensions past the consumer cutoff. It felt like proof that enterprise control still meant something.

It didn't last. Google removed that policy with Chrome 139, hitting every enterprise user simultaneously the moment the update landed. The exemption was never a carve-out IT negotiated. It was a grace period Google set, timed, and revoked on its own schedule. Nobody on the enterprise side got a vote.

Why is this a rented-browser problem, not an ad-blocker problem?

It's tempting to read this as an ad-blocker story. It isn't. The real event is that a single vendor rewrote the extension platform underneath software your organization had already deployed, tested, and depended on, and there was no contractual or technical lever to stop it.

That's the defining trait of rented software, not owned infrastructure. Install a binary on a server you control, and nobody removes its capabilities on a date set by someone else's roadmap. Chrome isn't like that. It's a continuously-updated, cloud-tethered client that Google can and does modify out from under you, enterprise policy or not. "Your browser" turns out to mean "the browser Google currently permits you to run."

Which browsers still support uBlock Origin?

The fallout splits cleanly along engine lines, not brand lines.

• Chrome, Edge, Opera. All Chromium/Blink under the hood, all subject to whatever Google decides for the extension platform. Edge began its own consumer-facing MV2 retirement on August 7, 2026, aiming to finish by year-end and start enterprise deprecation in early 2027. Microsoft says 95% of top MV2 extensions on its store already moved to MV3, but 58 still see meaningful use, and three of those have no MV3 replacement at all.
• Brave. Chromium-based, but sidestepping the Chrome Web Store entirely. Brave now hosts uBlock Origin and other Manifest V2 extensions on its own servers, a workaround the company itself describes as "swimming upstream" against the underlying engine it doesn't control.
• Firefox. Built on Mozilla's own Gecko engine, not Chromium. Firefox still supports the blocking webRequestBlocking API and has no stated plan to drop Manifest V2. Mozilla's official Firefox account stated flatly: "Firefox support for uBlock Origin is not going anywhere."

Engine ownership decided the outcome. Everyone running Blink inherited Google's decision, whatever their brand promised. Only the browser built on an independently governed engine kept the door open.

What are the Chrome Manifest V3 enterprise alternatives to uBlock Origin?

For teams that need to lock down browser policy today, the realistic options split into two categories.

Stay in Chromium, accept the ceiling:

• uBlock Origin Lite. Google's blessed MV3 successor, limited by the declarativeNetRequest rule cap and no dynamic filtering.
• AdGuard and Ghostery. MV3-compliant extensions with solid filter lists, subject to the same architectural ceiling as any other Chromium extension.
• Brave Shields. Built-in blocking plus Brave's self-hosted MV2 extension option, if you're willing to depend on Brave's continued willingness to maintain that workaround.
• Network-level blocking. Pi-hole or NextDNS filtering at the DNS layer, independent of browser or extension API entirely. This is the most durable option because it doesn't care what Manifest version your browser supports.

Leave Chromium, keep full control:

• Firefox ESR with the unrestricted uBlock Origin. Security analysts are blunt about the gap: "Firefox + uBlock Origin is the gold standard, with full dynamic filtering and no MV3 restrictions. No other browser-based combination comes close for sheer control and effectiveness."

For most enterprise security teams, the honest answer is a mix: Firefox ESR on the machines where filtering matters most, network-level blocking as a fleet-wide backstop, and MV3 extensions as a fallback everywhere else.

What is the bigger enterprise move toward browser and OS stacks you actually control?

The uBlock Origin episode is a small, visible instance of a pattern IT teams have lived with across their SaaS stack for years: the vendor changes the platform, and you adapt on their timeline, not yours. It's the same dynamic covered in 5 Self-Hosted Alternatives to Enterprise SaaS That Actually Save Money, just showing up in a piece of software most people never thought to interrogate.

Firefox ESR earns a specific mention here because it's not just a browser choice, it's a governance choice. UK government guidance recommends Firefox ESR for enterprise browser security precisely because it supports enterprise policy files and locked-down group policy deployment across Windows, Linux, and macOS. That's the kind of centralized, IT-owned configuration surface that Chrome's enterprise policy just proved it can't guarantee.

Firefox's market share is still small, 3.7% of the US market as of September 2024, which is part of why this shift matters less as a consumer trend and more as an infrastructure decision. Security teams evaluating LibreWolf, Waterfox, ChromeOS Flex, or Linux desktop rollouts aren't chasing market share. They're hedging against the next platform-level change nobody outside Mountain View gets a vote on.

What does this mean for software ownership as a discipline?

Treat browser and extension architecture as infrastructure risk, not a UI preference. The question isn't "which ad blocker do we standardize on." It's "which parts of our security stack sit on a platform we can't fork, patch, or delay if the vendor changes course."

Manifest V2's death is a clean data point: enterprise policy exemptions bought time, not permanence, and the engine underneath the brand is what actually decides what you keep. Any team serious about software ownership should run that same audit across the rest of its rented stack, not just the browser.