In June 2026, two browsers running the same Chromium engine took irreconcilable positions on the same extension API. Google deleted the Manifest V2 code from Chromium upstream. Opera announced it would maintain it “for as long as possible.” That divergence exposes an architectural question every team running Chrome needs to answer before the next extension API shift lands, and understanding what Manifest V3 actually is provides the foundation for answering it.
By the end of this article you’ll understand not just why Opera kept MV2 support, but how to map your own exposure to extension API changes, across extension-based blocking, native browser filtering, and DNS-level coverage.
What Is Manifest V3 and Why Has It Divided the Browser Extension Ecosystem?
Manifest V3 is not a version bump. It’s an architectural redesign that replaces the blocking webRequest API with the declarative declarativeNetRequest API. Under MV2, extensions could inspect and modify every network request in real time using arbitrary JavaScript. Under MV3, extensions submit pre-compiled JSON rule sets that Chrome evaluates natively inside its own network stack. The extension never sees the traffic.
Then there’s the rule cap. MV3 allows 330,000 static rules and 30,000 dynamic rules per extension. uBlock Origin‘s default filter lists alone exceed 300,000 rules, and its dynamic filtering has no declarative equivalent. Background pages also move to ephemeral service workers that terminate when idle, breaking extensions that rely on long-lived state.
Google’s stated rationale is security, performance, and privacy. A reduced permission surface stops malicious extensions from intercepting all browser traffic. Declarative rules run faster than per-request JavaScript. And users can audit what rules an extension declares rather than trusting opaque scripts. The “Save Image As Type” extension incident, hijacked to steal affiliate commissions from hundreds of thousands of users, illustrates the risk.
The controversy turns on whether those same security restrictions also structurally limit content blockers in ways that happen to benefit Google’s advertising business. The Electronic Frontier Foundation called it “another example of the inherent conflict of interest” from Google controlling “both the dominant web browser and one of the largest internet advertising networks,” noting Google has trackers installed on 75 percent of the top one million websites. AdGuard CTO Andrey Meshkov put it differently: “nobody has ever convincingly explained how MV3 helps” on security, but “MV3 genuinely reduces the impact that poorly written extensions can have on the browser” performance-wise.
The timeline made this a now-problem in June 2026. Chrome removed the enterprise policy workaround ExtensionManifestV2Availability in version 139, then deleted the kExtensionManifestV2Disabled flag and all MV2 support code in versions 150 and 151. MV2 extensions cannot be installed, loaded in developer mode, or run in Chrome stable.
Why Did Opera Decide to Keep Supporting Manifest V2 Extensions When Chrome Abandoned Them?
Opera’s decision is a calculated strategic move. The browser maintains its own extension store and policy infrastructure, giving it the technical independence to diverge from upstream when user value justifies the maintenance cost. As Opera stated in September 2025: “You can keep using your existing MV2 extensions on Opera for the foreseeable future” and “we did that because many users made it clear that maintaining access to their extensions was important to them.”
The strategic logic is straightforward. When Chrome users lose access to uBlock Origin and other MV2 content blockers, Opera becomes one of the few Chromium-based browsers where those extensions still function. It’s a concrete, easily communicated reason to switch that doesn’t require adopting an entirely different browser engine. Opera’s Paste Protect launch in July 2026 is evidence that MV2 support sits within a broader security-differentiation strategy rather than standing alone.
The enterprise angle matters too. Chrome’s MV3-only approach forces organisations to choose between abandoning MV2-dependent extensions, including some enterprise security tools, or migrating browsers. Opera’s dual support eliminates that forced choice.
The security counterargument is that continuing MV2 support exposes users to the permission-abuse risks MV3 was designed to close. Opera’s response is that its extension review process and user-warning dialogues mitigate this risk without requiring API removal. Firefox has taken the same position on MV2, retaining the blocking webRequest API in its own MV3 implementation, but Firefox uses Gecko rather than Chromium, avoiding the fork maintenance problem entirely.
The durability question is the one Opera hasn’t answered. Opera has not published a roadmap or resource commitment for MV2 maintenance, and it recommends users begin researching MV3 alternatives alongside continued MV2 use.
Manifest V2 vs Manifest V3: The Capability Differences That Matter
Network-level blocking, stopping requests to known ad servers and tracker domains, works under both MV2 and MV3. The declarativeNetRequest API handles this acceptably for mainstream users, and a January 2026 peer-reviewed study across 924 websites found no statistically significant reduction in raw ad-blocking effectiveness at the network layer.
What disappears is three specific capabilities. Cosmetic filtering hides ad-related page elements by CSS selector after page load, eliminating the blank spaces where blocked ads were. Dynamic filtering uses real-time JavaScript interception that adapts to new tracker domains without waiting for extension updates. The element picker lets users manually select page elements to hide.
Anti-adblock scripts exploit the MV3 latency gap. Under MV2, filter list maintainers could push updates in near-real-time as new circumvention techniques appeared. Under MV3, filter list updates require a full extension update through the Chrome Web Store review process, a window anti-adblock developers can exploit.
uBlock Origin versus uBlock Origin Lite is the living laboratory of this divide. uBOL blocks the same ad networks at the network level but cannot clean up the visual aftermath, cannot let users zap individual elements, and cannot create per-site rule exceptions on the fly. Power users notice. Casual users may not.
The “good enough” threshold varies by user. For someone who just wants fewer ads, MV3 blocking is adequate. For someone who wants a clean reading experience with no blank spaces, responsive circumvention, and per-site control, MV2 remains the only option. The difference is a capability cliff, not a sliding scale.
What Actually Happens to uBlock Origin When Chrome Removes the Last Workarounds
That capability cliff becomes concrete when you look at what happens to the most widely used MV2 extension. Raymond Hill, uBlock Origin’s developer, has been unambiguous: “There is no Manifest v3 version of uBO.” Hill has stated definitively that the extension’s architecture cannot be ported to MV3 without becoming a different product.
uBlock Origin Lite is the deliberate alternative, a separate MV3-native extension built to operate within declarativeNetRequest constraints. It offers three filtering modes, Basic, Optimal, and Complete, that escalate the rule set size but are structurally limited to what the API permits.
The workarounds fell in sequence. The ExtensionManifestV2Availability enterprise policy was removed in Chrome 139. The kExtensionManifestV2Disabled developer flag was deleted in Chrome 150. Community Chromium forks like Ungoogled Chromium and Helium that patch MV2 support back in face an escalating maintenance burden now that the MV2 code is gone from upstream.
What Chrome users see is a block. Existing uBlock Origin installations are disabled with a “this extension is no longer supported” message. The Chrome Web Store no longer serves the MV2 version. Sideloading fails.
For Chrome-locked users, the mitigation path is uBlock Origin Lite for browser-level blocking, supplemented by DNS-level filtering through NextDNS or Pi-hole for coverage outside the browser, and accepting that cosmetic filtering is gone.
The Engineering Burden of Maintaining MV2 After Upstream Removal
Maintaining MV2 code after Google deletes it from Chromium is not a configuration toggle. The assessment comes from the team deleting the code: Google’s own engineers described the MV2 code as “complex and reaches deep into a large number of browser components” in the Chromium code review that removed it.
The AdGuard CTO noted that maintaining MV2 after upstream removal requires dedicated engineering resources specifically because the code is integrated across the network stack, extension framework, and security model. It’s not a self-contained module that can be cleanly patched back.
Brave has taken the most assertive approach among Chromium forks. Instead of maintaining full MV2 support, Brave hardcodes support for four specific extensions, uBlock Origin, AdGuard, NoScript, and uMatrix, at the browser level. It’s a targeted strategy that reduces maintenance surface area while preserving the extensions most users care about. Brave also rebuilt its ad-blocking engine in Rust, running at the browser level rather than through the extension framework, making it immune to extension API changes.
Opera’s approach of maintaining general MV2 support is broader and costlier. Every Chromium release requires backporting MV2 compatibility, regression testing across the extension ecosystem, and handling edge cases as Chromium’s internals evolve away from MV2 assumptions. No browser has published engineering headcount or budget figures for MV2 maintenance. That undisclosed analysis is the largest unanswered question in the topic, and Opera’s “for as long as possible” is a function of a cost-benefit calculation whose inputs may shift.
How Opera’s Built-In Ad Blocker Differs from Extension-Based Blocking
Since maintaining MV2 extension support carries an escalating engineering cost, Opera’s native blocker is the structural fallback. Opera describes its native ad blocker as operating at the browser’s network stack level, entirely outside the extension API. It uses Opera-maintained filter lists applied at the browser level rather than JavaScript running inside an extension sandbox subject to API constraints. This means it is immune to MV3’s rule caps, service-worker constraints, and filter-update latency.
Under MV3, uBlock Origin Lite must operate within the declarativeNetRequest rule cap, cannot perform cosmetic filtering beyond its static ruleset, and cannot update filter lists without a Chrome Web Store review cycle. Opera’s native blocker, by Opera’s own account, is subject to none of these constraints because it never touches the extension API. It can update filter lists independently of any extension store review, has no rule cap, and continues to function regardless of what happens to MV2 extension support. Opera’s recommendation is that their built-in features provide “the smoothest and most secure experience” independent of extension policy.
The trade-off is configurability. uBlock Origin’s element picker, request logger, per-site JavaScript toggle, and custom filter creation are extension-UI features with no equivalent in Opera’s native blocker, which provides on/off toggles and blocklist selection but not granular per-page control. Opera’s strategy appears to be a dual layer: native blocking for mainstream users who want ads gone without configuration, plus MV2 extension support for power users who want uBlock Origin’s full toolkit. Neither layer alone covers all users, but together they span the capability spectrum.
Understanding those architectural layers is the prerequisite for the assessment every organisation now faces.
How to Assess Whether Your Browser’s Ad-Blocking Will Survive
The assessment identifies whether MV3 enforcement creates a capability gap in your specific extension inventory, and then evaluates whether native browser features, MV3-compatible replacements, or a migration closes that gap with acceptable operational cost.
The first question is an extension inventory. Audit every deployed browser extension and identify which are MV2-only. If any are security-adjacent, content blockers, privacy tools, enterprise DLP extensions, Chrome’s MV3 enforcement creates a gap.
The second question is replacement assessment. Determine whether MV3-compatible versions exist for each MV2 extension and whether their reduced functionality is acceptable. uBlock Origin to uBlock Origin Lite is a downgrade. Some enterprise security extensions may have no MV3 path at all.
The third question is native feature coverage. Evaluate whether your browser provides built-in ad blocking, tracking prevention, or content filtering that reduces dependency on extensions. Opera, Brave, and Vivaldi all ship native blockers. Chrome’s built-in protections are less aggressive and are not configurable as content blockers.
The fourth question is deployment control. Can your organisation enforce extension policies via group policy or MDM? Does the browser vendor offer enterprise support channels? And does your regulatory environment create compliance obligations? The Australian Government’s Information Security Manual explicitly recommends browsers “do not process web advertisements from the internet,” which creates a concrete compliance dimension for Australian organisations in regulated industries. If Chrome’s MV3 enforcement reduces ad-blocking effectiveness below what the hardening guide envisions, the browser choice becomes a compliance question.
The framework is diagnostic. It helps you determine whether you have an MV3 problem without dictating which browser to choose. The answer may be “stay on Chrome with layered DNS blocking” for one organisation and “migrate security-sensitive users to a browser with native blocking and MV2 support” for another. The broader browser security architecture comparison contextualises where each vendor sits.
DNS-Level vs Browser Extension Ad Blocking: Which Is More Future-Proof?
DNS-level blocking resolves ad and tracker domain names to 0.0.0.0 at the DNS layer, preventing the browser from ever connecting to those servers. It works for every device on the network, every browser, and every app, independent of extension APIs. NextDNS, Pi-hole, and AdGuard Home are the common implementations.
The granularity gap is real. DNS blocking can only block or allow entire domains. It cannot hide specific page elements, cannot apply per-site rules, cannot respond to inline ads served from first-party domains, and cannot clean up blank spaces left by blocked ad iframes. These are the capabilities that make browser extensions important for a clean reading experience.
The future-proofing argument is that DNS blocking is unaffected by Manifest V3, Manifest V4, or any future extension API change. It operates outside the browser entirely. For organisations building long-term content-blocking strategy, DNS-level blocking is the foundation. As one Hacker News commenter put it: “I don’t need to waste my time anymore worrying about which browser ruins their extension API by following Google’s nonsense.”
For Chrome-locked users, the layered strategy is uBlock Origin Lite at the browser level plus DNS-level filtering for network-wide coverage. DNS catches what MV3 extensions miss, and the user accepts that cosmetic filtering is gone. Opera’s native blocker sits architecturally between the two: it shares DNS blocking’s immunity to extension API changes while retaining more page-level context than a pure DNS resolver provides. AdGuard’s CTO frames it simply: “Network-level and system-wide solutions don’t depend on Chrome’s extension platform at all.”
Where This Leaves You
Opera’s MV2 decision reveals something larger than one browser’s policy choice. Content blocking exists on at least three architectural layers: extension APIs, native browser filtering, and DNS-level blocking. Each layer carries different cost profiles, capability trade-offs, and immunity to vendor policy changes. An organisation that evaluates its exposure through only one lens is making a decision on partial information.
The assessment that matters is your dependency on each architectural layer, and where your single points of failure sit when a vendor changes the rules. Opera’s bet on MV2 is one data point in that assessment. It’s strategically revealing and explicitly time-limited, but it’s not the foundation a long-term deployment strategy should rest on.
The MV3 transition is not the last extension API change. It’s the first major architectural shift in a browser ecosystem where the dominant vendor also operates the largest advertising network. Organisations that build layered, vendor-independent blocking strategies now won’t need to repeat this exercise when Manifest V4 arrives. Whether that strategy involves migrating to a browser with native protections, adding DNS coverage, or both, the time to map the dependencies is before the next deadline, not after.
Frequently Asked Questions
Is Google really killing ad blockers to protect its advertising business?
The conflict is structural rather than conspiratorial. Google operates both the world’s largest browser and the world’s largest advertising network, so any change that limits content blocking also benefits its ad revenue. The EFF and ad-blocker developers have documented how MV3’s constraints on the webRequest API disproportionately advantage Google’s business model. Whether this influenced the design or was an incidental effect is the genuine point of contention.
Should I switch to Opera or Firefox to keep my Manifest V2 extensions?
Firefox offers stronger long-term MV2 certainty because Mozilla controls its own Gecko engine rather than maintaining forked Chromium code. Opera’s “for as long as possible” language carries more uncertainty. However, Firefox’s single-digit market share raises sustainability questions given its financial dependency on Google’s search deal. Choose Firefox if MV2 permanence is your priority; choose Opera if Chromium site compatibility matters more.
What is Microsoft Edge doing about Manifest V3?
Microsoft Edge follows Chrome’s MV3 timeline. It shares Chromium upstream, and Microsoft has not invested in maintaining forked MV2 code. Edge’s enterprise policy for MV2 extensions was removed on the same schedule as Chrome’s. Organisations using Edge should assess their extension inventory with the same urgency as Chrome users. Edge does offer built-in tracking prevention but not a full native ad blocker comparable to Opera’s.
Can I stay on an older version of Chrome to keep using uBlock Origin?
Technically possible but inadvisable. Older Chrome versions stop receiving security patches, leaving every newly discovered browser vulnerability exploitable. Running an unpatched browser to preserve extension compatibility trades one risk (reduced content blocking) for a larger one (exposure to drive-by exploits). The better path is migrating to a browser that supports MV2 with active security maintenance, or adopting a layered blocking strategy with DNS filtering.
Does Manifest V3 actually make Chrome meaningfully more secure?
Yes, in specific ways. MV3 reduces the permission surface: extensions can no longer request blanket access to all browser traffic, and ephemeral service workers limit persistence of compromised extension state. These are genuine improvements for users who install poorly vetted extensions. In enterprise environments with reviewed extension allowlists, however, those risks were already mitigated, so the marginal security benefit for organisations is smaller.
Will other Chromium browsers like Brave and Vivaldi eventually drop MV2 support too?
Probably, but on different timelines. Brave hardcodes support for four specific extensions rather than maintaining general MV2 compatibility, which reduces its maintenance burden and extends viability. Vivaldi has not published an MV2 roadmap. Every Chromium fork faces the same escalating cost curve as upstream diverges further from MV2 assumptions. The question is not whether MV2 support disappears but when, and whether alternatives are in place before it does.
How do I check which of my Chrome extensions will stop working?
Navigate to chrome://extensions in Chrome. Any extension flagged with a warning that it “may soon no longer be supported” or listed as Manifest V2 in its details is at risk. For enterprise deployments, Chrome Browser Cloud Management can export an inventory of installed extensions with manifest versions. The definitive check is each extension’s manifest_version field: version 2 extensions stop working when Chrome removes MV2 support entirely.
If I switch to Opera for MV2 support, what do I lose compared to Chrome?
Opera lacks Chrome’s deep integration with Google services (profile sync uses an Opera account, not a Google account), some Chrome-exclusive extensions, and the Google Admin Console enterprise management ecosystem. Opera offers its own sync, a native ad blocker, and a built-in VPN but has a smaller extension catalogue. For most individual users the trade-off is manageable; for organisations dependent on Chrome Enterprise policies, the gap requires thorough evaluation.
Will ad blocking still work on Chrome at all after Manifest V3 enforcement?
Yes, but less effectively. uBlock Origin Lite under MV3 blocks most network-level ad and tracker requests using declarativeNetRequest rules. What disappears is cosmetic filtering (removing blank spaces where blocked ads were), dynamic filtering (real-time adaptation to new tracker domains), and the element picker. For casual users who just want fewer ads, MV3 blocking is adequate. For anyone who wants a clean, ad-free reading experience, the difference is immediately noticeable.
Does Opera’s MV2 support work on Opera for Android?
No. Opera’s MV2 commitment applies to its desktop browser only. Opera for Android, like all mobile Chromium browsers, operates under different extension constraints. Mobile Opera includes a built-in ad blocker that filters at the network level, independent of the extension framework, but it does not support installing desktop-style extensions like uBlock Origin at all. The MV2 conversation is a desktop browser conversation.
