Mozilla on Wednesday launched a Developer Preview program to solicit feedback on Firefox extensions that implement Manifest v3, a Google-backed revision of browser extension architecture.
Mozilla last year said it intended to support MV3 in Firefox extensions, though with some differences. Its implementation of the WebExtensions API in Firefox has now incorporated enough of MV3 plumbing that developers can set the appropriate browser flags and experiment with MV3 extensions in Firefox v101, now in beta and due for release at the end of May.
Google Chrome is expected to stop supporting extensions created under the old MV2 specification in about a year, June 2023. And given Chrome’s share of the browser market – about 64 per cent currently – extension developers will want to have updated their code by then and to have accounted for how MV3 works – or doesn’t – in different browsers.
Google engineers conceived of MV3 back in 2018 to address supposed security, privacy, and performance issues arising from the MV2 Chrome extension architecture. Though advocacy groups, makers of privacy extensions, and rival browser vendors have challenged Google’s justifications, the MV2 model did have demonstrable security and privacy problems.
So despite objections that MV3 “harms privacy, security, and innovation,” the other major browser vendors – Apple, Microsoft, and Mozilla – have said they will support MV3 in some form. The result is likely to be that content blocking and privacy extensions become less capable, though the degree to which that is true, or whether it is at all, won’t be known until the MV3 API gels.
Browsers mostly all in, with qualifications
MV3 is being implemented within Chromium, the open source browser code upon which Chrome is based, so other browsers built atop Chromium get Google’s interpretation of the new API as part of the package. Microsoft Edge appears to be accepting MV3 as is, while Brave has committed to retaining support for important MV2 features like the blocking WebRequest API – used for observing and analyzing network traffic and intercepting, blocking, or modifying network requests in-flight.
Even Apple, fond of claiming the privacy high-ground over Google, has gotten with the program: MV3 support appeared in Safari 15.4 in March.
The broad browser maker support for MV3 can be attributed in part to the formation last June of a W3C WebExtensions Community Group (WECG). Therein, representatives of browser makers and extension developers have been trying to find common ground and minimize incompatibilities while preserving differences deemed critical for product differentiation.
Rob Wu, senior software engineer at Mozilla, explained in a blog post that Firefox will diverge from Chrome in several ways.
“One of the most controversial changes of Chrome’s MV3 approach is the removal of blocking webRequest, which provides a level of power and flexibility that is critical to enabling advanced privacy and content blocking features,” he said. “Unfortunately, that power has also been used to harm users in a variety of ways.”
Chrome has chosen to create a replacement API called declarativeNetRequest (DNR) which while safer than the blocking webRequest also lacks the ability to make content blocking decisions one the fly – filters for DNR have to be static, which makes privacy extensions that rely on this API less effective.
Raymond Hill, creator of content blocking extension uBlock Origin, described how MV3 will make content blockers less able to innovate in a GitHub Issues post last December. He explained how he had implemented a feature in uBlock Origin as a result of discussions with the maintainers of filter lists (which are used in content blocking extensions to decide what to block).
“The DNR API does support
domain= option, but it does not support
entity, which is the ability to use a wildcard in place of the effective TLD, to avoid listing all domains belonging to an entity,” he wrote. “I can count over 420 filters currently in the default filterset [that use] this feature, clearly a benefit to filter list maintainers. These filters would cease to exist in a DNR-based blocker.”
The DNR APIs inability to handle a wildcard character means every domain to be blocked must be declared in advance – previously unknown tracking domains would be missed. As Google’s DNR documentation puts it, “The webRequest API is more flexible as compared to the declarativeNetRequest API because it allows extensions to evaluate a request programmatically.”
Practically speaking that means it’s unlikely uBlock Origin will survive in its current form, at least for Chrome, once MV2 support vanishes next year. But that could prompt Chrome users to look for a browser that retains MV2 support – uBlock Origin is a must-have extension for many technically demanding users.
It’s difficult, however, to determine what MV3 will ultimately allow because MV3 continues to evolve as a result of the back and forth between Google, other browser makers, and the developer community. The DNR API, for example, has gained limited support for dynamic rules – 5000 presently – that get evaluated at runtime rather than being pre-declared in the manifest file. And Chrome, criticized for failing to block CNAME manipulation, has implemented support for CNAME uncloaking and plans to expose this for extension developers through the DNR API.
If Google ultimately fails to respond to extension developers who want MV3 to be more capable, other vendors appear keen to step in. Apple, for example, has implemented support for dynamic rules for Safari extensions.
Inside Mozilla’s MV3 plans
Mozilla intends to keep webRequest for Firefox extensions, just as Brave has said it will do in its customized Chromium-based browser. (Strictly speaking, Google has not removed the blocking version of webRequest but has hidden it so it’s only available to forced-install extensions under enterprise versions of Chrome.)
“Mozilla will maintain support for blocking webRequest in MV3,” said Wu. “To maximize compatibility with other browsers, we will also ship support for declarativeNetRequest. We will continue to work with content blockers and other key consumers of this API to identify current and future alternatives where appropriate. Content blocking is one of the most important use cases for extensions, and we are committed to ensuring that Firefox users have access to the best privacy tools available.”
Mozilla also plans to support Event Pages, to handle use cases ill-suited to Background Service Workers, the MV3 replacement for persistent Background Pages, which MV2 extensions use to run code in the background. Event pages, like Service Workers, are designed for an event-driven environment (e.g. button gets pressed, something happens, then code stops) rather than a persistent process that’s always running and consuming resources. But crafting extension code for starting and stopping tends to be more complicated than just loading resources and calling on them as needed.
Wu said he hopes Firefox extension developers will give MV3 a spin and that support for MV3 should reach Firefox users by the end of the year.
Extension devs not overjoyed
It wasn’t supposed to be that way, according to Google. “Our goal is not to break extensions,” wrote Devlin Cronin, a software engineer on the Chrome team in 2019, in response to a bug report filed about the webRequest API. “We are working with extension developers to strive to keep this breakage to a minimum, while still advancing the platform to enhance security, privacy, and performance for all users.”
Yet among those participating in Google’s Chrome extensions forum, there’s no shortage of complaints about broken code. Last month, a developer pointed out how badly Cronin’s statement had aged.
“That statement is completely rotten by now,” the developer wrote. “MV3 is a massive breakage to the point that ALL extensions require significant modifications in order to work under MV3. But worse, a significant percentage of them require major re-engineering.”
“It’s also clear by now, that the Extensions Team has been lying all along about the true reason for this massive breakage,” the forum participant continued.
“What they are actually going after is an extensions platform that can work under Android, which forces lifetime constraints on all processes. This is why they removed the background page; they cannot guarantee under Android that the background page is persistent.”
“So, their solution is simple, they want to force everybody to adopt the lifetime constraints of Android, even for extensions that don’t make sense to be used in a mobile OS.” ®