Chrome Pulls the Last Nail on MV2: Ad‑Blocker Era Ends, MV3 Changes & Migration Paths

Timeline Clarified

The Verge reported that Chrome 150 (late June) and Chrome 151 (July) will strip the remaining Manifest V2 references from the browser code.

Although this appears to be routine cleanup, it marks the final step for a ten‑year extension ecosystem, exemplified by uBlock Origin, on Chrome.

Google’s Explanation

“MV2 extensions have been disabled in all supported Chrome versions; we are removing support and related functionality. We cannot maintain this indefinitely due to complexity, technical debt, and security bugs—recently we discovered several bugs that exist only in MV2. Other browsers can continue support if they wish.”

Three reasons are cited: complexity, technical debt, and security bugs.

MV2’s model, introduced in 2012, relied on extensive webRequest interception and a persistent background page. Maintaining both the old MV2 paths and the newer MV3 architecture (service workers, declarative rules) would be costly.

What MV3 Removed

Key API changes include:

webRequest blocking mode is removed, leaving only the observe mode. Extensions can no longer synchronously inspect a request before it is sent. The replacement is declarativeNetRequest, where rules are declared in advance and the browser performs matching.

Declarative rules have limits. Current MV3 caps are 300,000 static rules per extension, 5,000 dynamic rules, and 5,000 session rules. uBlock Origin’s default subscriptions plus EasyList, EasyPrivacy, and other lists easily exceed one million rules.

background page is replaced by Service Worker. Background scripts are terminated after 30 seconds of inactivity, making long‑lived connections and complex state management harder.

uBlock Origin author Raymond Hill (gorhill) noted that a full‑featured uBlock Origin cannot be built on MV3; only a “Lite” version is feasible, acknowledging a loss of functionality.

Impact Across Browsers

While Chrome ends MV2 support at version 151, the broader browser ecosystem varies:

Firefox retains the webRequest blocking API, allowing the original uBlock Origin to continue working.

Chromium‑based browsers such as Brave, Vivaldi, Opera, and Edge align with Chrome’s MV2 fate; none are expected to maintain the removed code paths.

Mozilla’s stance indicates that continued support in other browsers is technically possible but unlikely.

Implications for Extension Developers

For ordinary users the impact is limited, as most have already migrated to uBlock Origin Lite or alternative browsers. For developers, three key points emerge:

Do not attempt to keep MV2 alive via hacks (enterprise force‑install, Chromium flags, third‑party packages). These will cease to work after Chrome 151.

If your extension relies on webRequest blocking, you have two migration paths: rewrite using declarativeNetRequest (accepting rule limits and reduced dynamism) or move core functionality to a desktop application or system‑level proxy.

Watch Firefox as a viable alternative for users who need full blocking capabilities, since Mozilla has kept the blocking API unchanged for the past four years.

The suitability of uBlock Origin Lite varies: it covers basic scenarios but struggles with complex cases, a situation that may evolve as MV3 APIs mature.

End of an Era

The legacy Chrome extension model represented an open‑platform era where browsers granted developers extensive powers to control network traffic. MV3 introduces a new paradigm where the browser defines capability boundaries and developers compose declarative rules within those limits.

Debate continues over which paradigm is superior, but Chrome’s direction is now clear. After July, the environment that allowed the original uBlock Origin to run on Chrome will exist only in memory.

Inspiration: The Verge, “Google Chrome is closing the loopholes that let old ad blockers keep working” (Stevie Bonifield, 2026‑06‑16), https://www.theverge.com/tech/950005/google-chrome-removing-ad-blocker-loopholes