Firefox to adopt Chrome's new approach to extensions – sans the part that threatens ad blockers

Mozilla says Google's content-filter API doesn't meet developer needs, others agree

Firefox maker Mozilla on Thursday said it plans to mostly adopt Manifest v3, a controversial revision of the Chrome browser extension framework that Google undertook to address the glaring security problems in the browser.

Mozilla, which relies on Google for the majority of its royalty revenue, found much that's worthwhile in Manifest v3. But it plans to retain the blocking webRequest API that's among the most consequential casualties of the technical transition in Firefox, at least until there's a replacement more suitable to the web community than Google's alternative, declarativeNetRequest (DNR).

"We will support blocking webRequest until there’s a better solution which covers all use cases we consider important, since DNR as currently implemented by Chrome does not yet meet the needs of extension developers," said Rob Wu, senior software engineer at Mozilla, in a blog post.

This is a more definitive position statement than Mozilla made in September, 2019, when the company said it would wait and see how the spec evolved – a process that's still ongoing.

Knock-on effects

The issue web developers have with Manifest v3 is that Google's efforts to limit harm from misbehaving extensions also threaten collateral damage to capabilities used by legitimate content blocking and privacy extensions, among others. The blocking webRequest API (which will be retained in Chrome for enterprise users) can be abused for injecting malicious code but it's more commonly employed to alter network requests and content headers on the fly as a means of thwarting intrusive ad tech.

By offering declarativeNetRequest, which requires a limited set of filtering rules to be declared in advance rather than formulated on the fly and imposes other limitations to certain permissive Manifest v2 capabilities, Google aims to let "extensions modify network requests without intercepting them and viewing their content, thus providing more privacy."

Google insists that it's not deliberately targeting content blocking and privacy extensions, which are none too loved by the ad industry and ad giants like Google. Company representatives have gone so far as to state they are "working closely" with developers of ad blockers. And they've cited supportive commentary from Adblock Plus maker Eyeo to underscore that point, even if Eyeo isn't the most committed content blocking biz due to it willingness to allow Acceptable Ads by default.

Raymond Hill, creator of the open source uBlock Origin content blocking extension, has been unsparing in his criticism of Manifest v3 as a threat to user agency. And Bennett Cyphers, technologist for the Electronic Frontier Foundation, has argued that Manifest v3 "will curtail innovation and hurt the privacy and security of Chrome users."

Microsoft has expressed support for Manifest v3 and acknowledged that there's concern about the weaker Manifest v3 APIs while simultaneously brushing off those concerns by expressing optimism in Google's ability to make the new rules work for everyone.

"We recognize the value of content blocking extensions and appreciate the role they play in honoring user’s choice by blocking advertisements and enhancing privacy by blocking cookies and we want developers to continue to offer these capabilities," Microsoft said last October, even as it it added, "we believe that a majority of those concerns have been resolved or will be resolved before Web Request API is deprecated."

An extension for extensions

Other competitors have been less willing to give Google the benefit of the doubt. Brave, Opera, and Vivaldi have all said they plan to continue to support the blocking webRequest API, or at least consider as much.

There's more to Manifest v3 than declarativeNetRequest and some changes, like the decision to disallow remotely hosted code, have obvious security benefits. But after debuting in early form as part of Chrome 88 in January, it remains unclear when the API revision will be complete and when extensions built with Manifest v2 will cease to function.

Features promised to appease disgruntled developers, like a way to use declarativeNetRequest to implement rules to block or redirect network requests based on response headers – helpful for blocking content or trackers – await the resolution of bugs.

Service workers, touted as a replacement for background pages (for running background processes in an extension), continue to be buggy, and extension developers have argued they're an entirely inadequate replacement. Meanwhile, there's a method used for authentication that hasn't yet been incorporated into Manifest v3 APIs.

Mozilla says it hopes to get Manifest v3 for Firefox Add-ons into a state for developer testing by Q4 2021 and to accept compliant Add-ons in early 2022, though it allows the schedule "may be pushed back or delayed due to unforeseeable circumstances." Google has more than a few code fixes to deal with if that's to be a smooth transition. ®