Firefox won’t follow Chrome’s anti-ad-blocker changes, says Mozilla

Mozilla has told developers not to fret – it won’t follow Google in tweaking its browser to be unfriendly to ad blocking software.

The Foundation made its announcement on Tuesday in an FAQ updating developers on its plans for the WebExtensions application programming interface (API).

WebExtensions is a set of interfaces that browser vendors offer to the developers of extensions, which are programs that extend the browser’s functionality. The WebExtensions interface gives the extensions a way to exchange instructions and information with the browser.

WebExtensions is used in Chromium, the open-source browser project on which Chrome is based, but Mozilla decided to support it too back in August 2015. By supporting the same API as Chrome, Mozilla ensured that extensions written for Chrome could easily port to Firefox.

Last November, Google announced changes to the way that it would implement the WebExtensions API as part of Manifest, the system that restricts what extensions can do in Chrome. Manifest v3 would restrict the webRequest API, it said. This is the API that extensions use to intercept network requests from the browser. One use for this API is to analyze and block traffic sent to advertising networks, making it a popular tool among ad blocking software. Under the new proposals, it would use a different API called declarativeNetRequest, which restricts the rules available to the blocking process.

Google’s Chrome developers said that this was a change designed to make the browser more efficient and increase performance, but it landed them in hot water after extension developers – especially those of ad blocking software – criticised the move.

Developers also asked Mozilla how it would handle the WebExtensions API in forthcoming versions of Firefox, and it published an FAQ on Tuesday. The upshot? The existing content-blocking API stays. It said:

We have no immediate plans to remove blocking webRequest and are working with add-on developers to gain a better understanding of how they use the APIs in question to help determine how to best support them.

Mozilla said that it’s tracking the development of Manifest v3, which is still in the draft and design phase. Refining its own support for WebExtensions is, therefore, a little like hitting a moving target, because it wants to make Firefox extensions as compatible as possible with Chrome without crossing any red lines with its own extension developers. So later this year, it will begin experimenting with the changes that it thinks are most likely to make it into Manifest v3 “and that we think make sense for our users,” it said.

Once Google has finalized their v3 changes and Firefox has implemented the parts that make sense for our developers and users, we will provide ample time and documentation for extension developers to adapt.

It also won’t kill off the v2 API until developers have a “viable path” to migrate to v3, it added.

Aside from Safari, which is only available on macOS and iOS, Firefox is the only major browser that isn’t now based on Chromium. Here’s how other Chromium-based browsers plan to support WebExtensions…

Jon von Tetzchner, CEO of Vivaldi, was noncommittal. He told us:

We are working on alternative approaches of our own, but it is too early to say exactly what the final result will be like.

A spokesperson for Opera told us that it wasn’t an issue for that browser, as it had its own ad blocker.

All the Opera browsers, both on mobile and PC, come with a built-in ad blocker that users can choose to enable. This means that Opera users aren’t really exposed to these changes – unlike users of most other browsers. We might also consider keeping the referenced APIs working, even if Chrome doesn’t, but again, this is not really an issue for the more than 350 million people who have chosen Opera.

Like Opera, the privacy-focused browser Brave already includes an ad blocker in its product.