Manifest V3’s First Developer Preview: Why Ad Blocker Makers Sounded the Alarm

Google first previewed Manifest V3 to developers in 2019, and by the time Chrome’s early developer-channel builds made the proposed API changes testable in 2020, the reaction from a specific and vocal segment of the extension ecosystem — ad blocker and privacy extension developers — had crystallized into open alarm. The concern wasn’t abstract. It centered on one specific, concrete proposal: replacing the webRequest API’s blocking capability with a new, more restrictive API called declarativeNetRequest, and the developers whose entire product depended on the capability being removed were the ones raising the loudest objections.

What webRequest Blocking Actually Let Extensions Do

To understand the controversy, you need to understand what was on the chopping block. The webRequest API, in its blocking form, lets an extension’s background script intercept a network request before it’s sent, inspect its full details programmatically, and decide in real time whether to allow it, block it, redirect it, or modify its headers. This is imperative, JavaScript-driven decisioning: the extension’s own code runs, makes a judgment call based on whatever logic the developer wrote, and the browser acts on that judgment.

This is the mechanism that made sophisticated ad and tracker blocking possible. A filter list with complex rules, exceptions, and contextual logic — different behavior depending on the requesting page, the resource type, or content inspected from the response — could all be expressed as JavaScript running against live request data. uBlock Origin, in particular, built its reputation partly on filter-list sophistication that leaned on this flexibility.

What declarativeNetRequest Proposed Instead

declarativeNetRequest, the proposed replacement, inverts the model. Instead of running extension JavaScript against every request as it happens, the extension declares a static or semi-static set of rules ahead of time — “block requests matching this pattern,” “redirect requests matching that pattern” — and the browser itself evaluates and applies those rules internally, without ever handing control back to the extension’s code during the decision.

Google’s stated rationale, laid out in the Manifest V3 proposal documentation and reiterated by Chrome’s extensions team in developer forum discussions throughout 2019 and 2020, centered on two arguments. First, performance: evaluating rules natively in the browser is faster and lower-overhead than invoking an extension’s JavaScript for every single network request, particularly for extensions with large filter lists. Second, and more controversially, security and privacy: an extension with unrestricted webRequest blocking access can inspect the full content of every request a user makes, including data that never needed to pass through third-party code merely to decide whether to block a resource. Removing that capability, Google argued, closed off a real vector for a malicious or compromised extension to exfiltrate browsing data at scale.

Why the Ad Blocker Community Pushed Back So Hard

The pushback wasn’t a dispute over Google’s stated security rationale in the abstract — most extension developers agreed unrestricted request inspection is a genuine risk surface. The dispute was over whether declarativeNetRequest, as initially proposed, was actually capable of replicating the filtering sophistication that made the best ad and privacy blockers effective, and the early answer from developers actually testing the preview builds was clearly no.

The initial dynamic rule caps in the developer preview were far lower than what large filter lists like EasyList and EasyPrivacy required to load in full. There was no path in the initial proposal for JavaScript to inspect a response body and make a blocking decision based on its contents — a pattern some privacy extensions relied on for specific detection logic. And critically, the declarative rule format itself lacked expressiveness for some of the more complex conditional logic sophisticated filter lists used, meaning a direct rule-for-rule translation from an existing filter list to the new format was not always mechanically possible.

Raymond Hill, the developer of uBlock Origin, became one of the most cited critical voices during this period, publishing detailed technical breakdowns of specific filtering capabilities that would not survive the transition as initially specified, and arguing publicly that the proposal, in its 2019-2020 form, would force a meaningful regression in blocking capability regardless of Google’s stated intent. The Electronic Frontier Foundation also weighed in publicly, framing the change as one that would disproportionately affect privacy and security-focused extensions specifically, since ordinary utility extensions rarely relied on the deep request-inspection capability being restricted.

How the Objection Actually Reached Google

The pushback wasn’t confined to blog posts and forum threads, though there was plenty of both. Filter-list maintainers and privacy-extension developers used the exact channels Google had built for this purpose: the public Manifest V3 developer preview feedback repository and the chromium-extensions Google Group, where detailed, reproducible test cases showing specific filter rules that could not be expressed under the proposed declarativeNetRequest rule schema were filed as concrete bug reports rather than general complaints. This distinction mattered for how seriously the feedback was received internally — a specific, reproducible gap (“this exact EasyList rule cannot be translated because the declarative schema has no equivalent for this conditional”) is a fundamentally different kind of input than a general objection to the direction of the change, and it’s the former that tends to move a large organization’s engineering priorities.

Some browser extension developers also took the more public route of open letters and coordinated statements, timed around Chrome developer conferences and Manifest V3 milestone announcements throughout 2020, explicitly asking Google to either delay enforcement timelines or commit to specific capability parity benchmarks before requiring migration. Google did not commit to the specific asks in most of these public statements, but the enforcement timeline for mandatory Manifest V3 migration did slip repeatedly over the following years — whether that reflects the pressure from this feedback, the sheer scale of the ecosystem migration, or some combination of both is difficult to disentangle cleanly, but the delays themselves are a matter of public record across Chrome’s own developer communications.

Google’s Response and the Iteration That Followed

To Google’s credit, the developer preview period functioned as a genuine feedback loop rather than a formality. Chrome’s extensions team incrementally raised dynamic rule caps, added new rule condition types, and adjusted specific limitations in response to concrete feedback from filter-list maintainers over the following development cycles — the dynamic rule cap present in the 2020 preview builds was substantially lower than what eventually shipped in later stable releases.

Whether the eventual shipped version of declarativeNetRequest fully closed the capability gap the 2020 critics identified remained a live, contested question well beyond this preview period, and different developers reached different conclusions about how much of a regression the finished API represented compared to unrestricted webRequest blocking. What’s not contested is that the earliest developer preview builds tested in 2020 were meaningfully more limited than what eventually reached general availability, and that the public pressure from ad blocker and privacy extension developers during this exact window materially shaped which limitations Google prioritized relaxing first.

Why This Preview Period Mattered Beyond the Technical Details

There’s a broader point worth drawing out. Manifest V3’s declarativeNetRequest transition is a case study in how a browser vendor’s platform decisions ripple asymmetrically across an extension ecosystem: a change framed as a general security and performance improvement lands hardest on the specific category of extensions whose entire value proposition depends on the exact capability being restricted. Utility extensions, productivity tools, and most ordinary browser extensions were barely affected by this specific controversy. Ad blockers, privacy tools, and security extensions were affected enormously, because request-level JavaScript decisioning wasn’t an incidental feature for them — it was close to the whole product.

That asymmetry is why the loudest objections to a platform-wide change often come from a narrow, technically sophisticated slice of the developer ecosystem, and why dismissing that feedback as unrepresentative would have been a mistake. The developers objecting during this preview period were the ones who understood the API surface deeply enough to identify exactly which capabilities would break and why — which is precisely the feedback a genuine developer preview period exists to surface before a change ships broadly.

FAQ

Was declarativeNetRequest completely unable to replicate webRequest blocking in 2020? Not entirely unable, but meaningfully more limited in the developer preview builds tested that year. Dynamic rule caps were lower than large filter lists needed, some conditional logic patterns had no declarative equivalent, and response-body inspection had no path forward at all. Later revisions relaxed several of these constraints, though the debate over full capability parity continued well past this initial preview period.

Why did Google want to remove blocking webRequest at all? The stated rationale combined performance (native rule evaluation is faster than invoking extension JavaScript per request) and security (unrestricted request-content access is a real data-exfiltration risk if an extension is malicious or compromised). Critics didn’t generally dispute the risk existed; they disputed whether the proposed replacement adequately preserved legitimate filtering capability while closing it.

Did every extension developer oppose Manifest V3 during this period? No. The controversy concentrated specifically among ad blocker, privacy tool, and security extension developers whose products depended on unrestricted request-level JavaScript decisioning. The overwhelming majority of extensions — productivity tools, utilities, UI enhancements — used little or none of the capability being restricted and were largely unaffected by this specific debate.

Did Chrome eventually raise the dynamic rule caps developers were worried about? Yes, over successive development cycles following the concerns raised during this preview period, Chrome’s extensions team incrementally increased dynamic rule limits and added rule condition types in direct response to filter-list maintainer feedback, though the pace and sufficiency of those increases remained a point of ongoing debate among affected developers.

Does this affect extensions built for other Chromium-based browsers besides Chrome? Yes, since Edge, Brave, and other Chromium derivatives share Chrome’s extension platform. Whatever Chrome’s extensions team decides for declarativeNetRequest effectively becomes the shared standard across the entire Chromium browser family, not a Chrome-only quirk.

Edge’s own move to that shared platform, after retiring its separate EdgeHTML engine earlier the same year, is covered in detail here.