The Sunset of Manifest V2
The long-heralded deprecation of Manifest V2 extensions in Google Chrome has officially crossed the threshold from developer warnings to active enforcement. Users visiting the Chrome Web Store or checking their local browser management pages are now encountering explicit notices: legacy extensions built on the Manifest V2 framework are marked as incompatible, disabled, or purged entirely from public distribution lists.
Chief among the high-profile casualties of this transition is uBlock Origin—the open-source, highly customizable content blocker maintained by Raymond Hill (gorhill). For nearly a decade, uBlock Origin served as the definitive benchmark for efficient memory management, aggressive tracking protection, and granular script control. Its removal from the Chrome Web Store marks the end of an era for browser customization and highlights a fundamental shift in how extension APIs govern what users can—and cannot—control on their screens.
While Google has framed the transition to Manifest V3 (MV3) as a necessary evolution for security, performance, and user privacy, the developer community and privacy advocates view the move with intense skepticism. The enforcement leaves millions of users forced to choose between pared-down alternatives, changing their browser of choice, or relying on network-level workarounds.
The Architectural Rift: webRequest vs. declarativeNetRequest
To understand why the retirement of Manifest V2 has triggered such intense backlash, one must examine the fundamental architectural changes between the old framework and Manifest V3.
Under Manifest V2, content blockers relied heavily on the webRequest API. This interface allowed an extension to register background scripts that intercepted outgoing network requests in real time, prior to execution. When Chrome initiated a request to fetch an image, script, or advertisement, webRequest paused the request and handed evaluation over to the extension. The extension could check the request against complex rule sets, execute dynamic JavaScript, modify HTTP headers, and decide whether to allow, block, or redirect the connection instantly.
Manifest V3 completely alters this model by replacing dynamic interception with the declarativeNetRequest (dNR) API. Under dNR, extensions are no longer permitted to inspect and evaluate network requests on the fly using arbitrary programmatic logic. Instead, the extension must hand a static list of pre-compiled rules to the browser itself. The browser engine—not the extension's background process—then evaluates outgoing connections against this rule list.
Google argues that this shift offers two major benefits:
- Performance and Battery Efficiency: Browsers do not need to pause network requests to wait for third-party JavaScript code inside background extensions to execute.
- Security: Malicious extensions can no longer covertly inspect sensitive user traffic, read cookie headers, or steal session tokens under the guise of content blocking.
However, this security model comes at a steep structural cost: it strips extensions of the ability to make intelligent, dynamic decisions based on live context.
Why uBlock Origin Could Not Simply "Upgrade"
A common misconception among casual web users is that software creators were simply reluctant to update their code. However, Raymond Hill detailed extensively throughout the MV3 development cycle why a direct, feature-parity port of uBlock Origin to Manifest V3 was technically impossible.
Classic uBlock Origin relies on sophisticated dynamic filtering mechanisms. It doesn't merely check URLs against a blocklist; it injects specialized "scriptlets" to neutralize anti-adblock scripts, modifies DOM elements dynamically, rewrites requests based on surrounding document contexts, and updates rules dynamically in memory without requiring full extension package re-submittal or browser reloads.
Manifest V3 imposes several restrictive guardrails:
- Rule Limits: Chrome caps the number of active rules an extension can submit to the
declarativeNetRequestAPI. While Google raised initial proposed caps after widespread outcry, strict limits remain on dynamic and static rulesets, constraining the comprehensive filter lists (such as EasyList, EasyPrivacy, and regional blocklists) that advanced users rely on. - No Arbitrary Code Execution: MV3 disallows extensions from executing remotely hosted code or dynamically evaluated scriptlets, severely hampering the community's ability to patch rapidly evolving tracker scripts in real time.
- Loss of Dynamic Response: Because extensions cannot analyze live traffic payloads or context before a decision is made, advanced techniques used to defeat modern anti-adblock walls are virtually non-functional under pure dNR.
To accommodate Manifest V3, Hill created uBlock Origin Lite (uBOL). While uBOL is an impressive engineering feat that utilizes MV3 to its maximum potential, Hill has been upfront about its limitations: it is a declarative content blocker, not a true replacement for uBlock Origin. It lacks dynamic filtering, custom element hiding rules on the fly, and granular network request inspection.
Google's Dual Role: Web Steward vs. Ad Monopoly
It is impossible to contextualize the Manifest V3 rollout without acknowledging Google’s dual role in the tech ecosystem. Alphabet operates both Chrome—the dominant global web browser commanding roughly 65% of the desktop market share—and the world’s largest digital advertising network, bringing in over $200 billion annually from search, display, and video ads.
Critics contend that Manifest V3 represents a structural conflict of interest. Over the past several years, media platforms—most notably Google’s own YouTube—have waged an increasingly sophisticated arms race against content blockers. High-performance extensions like uBlock Origin were frequently able to deploy hotfixes within hours to circumvent aggressive anti-adblock popups.
By restricting the extension architecture to declarative rules and pre-approved webstore packages, Google effectively gains structural control over the speed and capability of content-blocking tools. While Google maintains that privacy and security are the sole drivers behind MV3, critics point out that the primary beneficiary of a weakened ad-blocking ecosystem is Google’s core business model.
Beyond Ad-Blocking: The Broader Developer Fallout
While ad blockers dominate the headlines, the enforced transition to Manifest V3 impacts a much broader software category:
- Privacy Tools: Extensions like Privacy Badger and EFF-backed privacy utilities that rely on algorithmic detection of tracking behaviors across sites are severely degraded because they cannot learn and adapt to tracking patterns dynamically during a browsing session.
- Developer Tools and Security Analysis: Security researchers and web developers who use extensions to inspect, modify, or mock API headers and network responses on the fly find their tools constrained by MV3’s strict declarative limits.
- Custom Script Managers: Power-user tools like Tampermonkey and Violentmonkey must navigate strict execution rules, complicating how users run custom userscripts across the web.
While enterprise environments have been granted temporary administrative policies (ExtensionManifestV2Availability) to extend Manifest V2 support slightly longer, these enterprise overrides are strictly temporary and are slated for removal in upcoming Chrome releases.
The Migration Map: Where Do Privacy-Conscious Users Go Next?
With Chrome’s gates closed to classic MV2 extensions, the desktop browser ecosystem is fragmenting along architectural lines.
1. Moving to Firefox
Mozilla’s Gecko-based browser, Firefox, has taken a fundamentally different stance on Manifest V3. While Firefox implemented MV3 compatibility to ensure developers can port extensions easily, Mozilla chose to retain support for the blocking version of webRequest. This means classic uBlock Origin remains fully functional and officially supported on Firefox, making it the primary destination for users seeking uncompromised content filtering.
2. Built-in Blocking Browsers (Brave, Vivaldi)
Browsers built on the open-source Chromium engine face a unique challenge. While they inherit Chrome's underlying rendering engine, several alternative browser vendors have implemented native blocking engines outside the extension layer:
- Brave: Features a native, Rust-based ad blocker integrated directly into the core browser engine, bypassing the JavaScript extension layer and
declarativeNetRequestlimitations entirely. - Vivaldi: Offers a built-in tracker and ad blocker that operates independent of extension store APIs.
3. Network-Level Filtering
Many users are turning to DNS-based and network-level solutions like Pi-hole, AdGuard Home, or NextDNS. While network filtering effectively blocks requests to known tracking and ad domains across an entire home network, it cannot perform cosmetic filtering—meaning it cannot remove the blank spaces, DOM containers, or anti-adblock script overlays left behind on web pages.
Conclusion: The Fracture of the Open Web Extensions Landscape
The final phase-out of Manifest V2 extensions in the Chrome Web Store represents a permanent shift in desktop browsing. By shifting power from client-side dynamic extensions to declarative engine rules, Google has successfully hardened the Chrome browser against unauthorized network manipulation—at the cost of user agency and advanced privacy controls.
For millions of web users, the era of set-it-and-forget-it extension setups on Chrome is over. As Chrome solidifies its strict Manifest V3 rules, the choice between convenience and control will likely drive a permanent wedge between mainstream browser defaults and the privacy-focused open web community.
