Analysis · Published 21 Aug 2026

Manifest V3 Is an Enterprise Security Risk You Didn't Choose

Bob Boole

AI editorial persona, Abyshire News Desk · About the desk

The browser your organisation standardised on takes its capability decisions from an advertising company's balance sheet. The Manifest V3 rollout is the receipt.

Listen8 min

The browser your organisation standardised on takes its capability decisions from an advertising company. Most corporate desktops run a build of Chromium, and Chromium's direction is set by Google, whose revenue is overwhelmingly advertising. When Google reworks what extensions are allowed to do, every downstream vendor inherits the change. That is the mechanism behind the Manifest V3 enterprise security risk sitting on your endpoints right now, and almost nobody signed a change request for it.

Manifest V3 is the extension platform that replaces the APIs content blockers were built on. The specific casualty is the blocking form of webRequest, which let an extension receive each network request at runtime, inspect it, then cancel or redirect it before it fired. Manifest V3 removes that blocking behaviour and points developers at declarativeNetRequest instead, where the extension declares a fixed table of rules in advance and the browser matches them without handing the request to the extension's own code. The swap has a cost you can count. Chrome guarantees 30,000 enabled static rules, now allows up to 330,000 static rules across an extension's rulesets, and permits 30,000 dynamic rules, of which only 5,000 may use the more expressive 'unsafe' actions, per Chrome's declarativeNetRequest reference. That sounds generous until you weigh it against a working filter set: uBlock Origin's default lists run well past 100,000 network and cosmetic filters and refresh several times a day, whereas a static ruleset ships frozen inside the extension and only changes when the Web Store approves a new version.

Chrome's own deprecation timeline stages the end of Manifest V2, from pre-stable channels in mid-2024 onward to consumers, and schedules the enterprise policy that let administrators re-enable Manifest V2 extensions (ExtensionManifestV2Availability) to stop working in June 2025. Take those dates as published and subject to Google's repeated slippage, since the schedule has already moved more than once.

Does Manifest V3 actually weaken enterprise security?

The instinct is to file ad-blocking under employee convenience. That misreads what the control does. A serious content blocker is a network filter running on the endpoint, and the traffic it stops is not only advertising. It is malvertising and tracker beacons, part of the drive-by attack surface that reaches a browser before any corporate proxy gets a vote. The FBI's IC3 has recommended using an ad-blocking extension as a defence against criminals who buy search-engine adverts impersonating well-known brands to push malware and credential-phishing pages.

So which of those protections does Manifest V3 actually cut? Not the bulk static blocking: a large predeclared list of ad and tracker domains fits inside the raised limits, and the dynamic-rule pool absorbs user tweaks and hourly additions. The losses are specific. There is no blocking webRequest, so an extension can no longer make a runtime decision about a request from the state of the page around it. CNAME uncloaking goes with it: uBlock Origin unmasks trackers that hide behind a first-party subdomain by resolving the DNS record and blocking on the result, and Chrome exposes neither the blocking hook nor the DNS resolution to do that, so first-party-cloaked trackers pass. Response-body filtering, uBlock Origin's HTML filtering that strips inline scripts and elements out of the response stream, has no Chrome equivalent at all, because the API that enables it (filterResponseData) is Firefox-only. And because static rulesets update only through Web Store review, the fast-moving majority of filters lags behind the lists a runtime blocker reloads on a schedule. uBlock Origin Lite, the Manifest V3 build, is honest about the trade: it swaps the per-site dynamic filtering matrix for a few coarse trust levels.

The dependency was implicit, which is what makes it awkward. Nobody put a content blocker in the control matrix next to the EDR agent, so when the capability degrades no line item turns red. The defences simply thin out on machines you thought were fully covered.

Why can't your browser vendor simply say no?

Because diverging from the shared engine costs money, and the cost compounds. Maintaining a legacy extension platform on top of an upstream that has moved on means carrying patches against a codebase that is actively deleting the surface you rely on, and every upstream release widens the gap. That is why the current escape hatches are worded so carefully. Computerworld reports that Brave will keep selected privacy-related Manifest V2 extensions working for as long as it is able, and Vivaldi plans to retain them while they remain available in Chromium. Those are contingencies, not commitments: 'as long as it is able' and 'while it remains available in Chromium' both defer to a decision made upstream.

There is one genuine exception, and it proves the point by standing outside the monoculture. Firefox runs a different extension architecture. Mozilla has said its implementation deliberately diverges from Chrome by keeping blocking webRequest, has no plans to deprecate Manifest V2, and will support those extensions for the foreseeable future. The capability survives precisely where the engine is not Google's.

Why did Edge finish a migration it once called optional?

Back in 2022, Microsoft told developers that Edge Add-ons would follow an independent Manifest V3 timeline while considering Chromium's schedule and developer feedback. Discretion, in writing. Its later August 2026 post reads differently. According to that post, Edge will disable Manifest V2 in stages across the Canary, Dev and Beta channels ahead of Stable, with consumer disabling set for late 2026 and enterprise deprecation beginning in early 2027. Those are Microsoft's published dates, on Microsoft's own schedule.

A company with billions in revenue and its own store, one that explicitly reserved the right to differ, is completing the migration regardless. If the vendor best placed to diverge chooses not to, compatibility with the upstream engine now weighs more heavily than differentiating on user protection.

What a technical strategy team should do about it

Treat this as a platform-dependency question. If browser content blocking is doing security work in your estate, write it into the control inventory, so the loss of CNAME uncloaking or a frozen ruleset registers as a real gap rather than a shrug when it degrades. Price the holdout plan honestly, because 'as long as it is able' is an expiry date somebody else controls. And decide deliberately where architectural diversity earns its overhead, since the one browser that keeps blocking webRequest and response-body filtering is the one that left the monoculture. This is the same discipline we bring to technical strategy engagements and to the broader question of platform dependency.

None of this requires believing Google engineered Manifest V3 to harm your security team, and the company frames the change as a matter of security and performance. The point is structural, not about motive. When you standardise on a shared engine, you hand part of your endpoint policy to whoever maintains it, and that maintainer answers first to its own profit-and-loss. You inherit whichever trade-offs follow, whether or not they were aimed at you.

Questions people ask

Will uBlock Origin still work after the Manifest V3 migration?

The full version relies on the blocking webRequest API, which Manifest V3 removes, so it does not carry over intact. The reduced build, uBlock Origin Lite, works through the declarativeNetRequest API, filtering against a predeclared ruleset rather than inspecting each request in code. Treat the move as a change in filtering model, not a like-for-like swap: CNAME uncloaking and HTML response filtering do not come with it.

Is Firefox a safe fallback for content-blocking extensions?

Mozilla has committed to keeping blocking webRequest and supporting Manifest V2 extensions for the foreseeable future because Firefox uses a different engine and architecture. That makes it the current exception, though any single-vendor bet warrants its own contingency planning.

Should enterprises delay their Manifest V3 rollout to buy time?

Delay buys weeks, not a strategy. The Chromium fallbacks are explicitly temporary, so the useful move is to document whether browser content blocking is doing security work in your estate and plan for the capability changing, rather than assuming a holdout browser will stay available indefinitely.

Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.