Google Chrome Extension Developers Protest Proposed API Change That Will Disable Ad Blockers

Google is apparently considering major changes to Chromium, the open-source software project that underpins the Google Chrome browser as well as Chrome OS and various other browsers including Opera, Vivaldi, Brave, and soon, Microsoft Edge. The proposed changes would require Chrome extensions to change the way they interact with the content of a Web page. The reasoning for the change is to stop extensions from acting as middle men because this is an extra step that can slow down page loads. The changes are outlined in a public Manifest document published by the Chromium developer team and discussions are taking place on the Chromium bug report portal.

Many ad blockers currently use the Chrome webRequest API to filter the HTTP traffic coming from known ad sources as defined in each extension's block list. According to the Manifest, this API could lose its ability to be used to block content. In part, it reads: “In Manifest V3, we will strive to limit the blocking version of webRequest, potentially removing blocking options from most events (making them observational only).  Content blockers should instead use declarativeNetRequest”.

The proposed alternative API, declarativeNetRequest, would severely limit the ways in which extensions can be used to filter Web traffic. It is limited to only 30,000 entries and cannot allow for rules such as blocking content elements beyond a certain size, blocking JavaScript, and stripping headers from cookies. These are specific objections that have been raised by Raymond Hill, developer of the popular uBlock Origin and uMatrix extensions.  

Hill goes on to say that the declarativeNetRequest API favours other extensions, particularly AdBlockPlus, but deprecating webRequest would completely disable uBlockOrigin and uMatrix because of the fine-grained controls they use. Part of Hill's comment reads: “Extensions act on behalf of users, they add capabilities to a user agent, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render.”

Other extension developers have contributed their objections as well. The Chromium team has declined to recognise this as a bug, but has opened a discussion thread on the Chromium Google Group where the debate is continuing.

The full reasoning, as laid out in the Manifest, reads: “Currently, with the webRequest permission, an extension can delay a request for an arbitrary amount of time, since Chrome needs to wait for the result from the extension in order to continue processing the request.  The basic flow is that when a network request begins, Chrome sends information about it to interested extensions, and the extensions respond with which action to take.  This begins in the browser process, involves a process hop to the extension's renderer process, where the extension then performs arbitrary (and potentially very slow) JavaScript, and returns the result back to the browser process.  This can have a significant effect on every single network request, even those that are not modified, redirected, or blocked by the extension (since Chrome needs to dispatch the event to the extension to determine the result).”

As The Register points out, AdBlockPlus uses much more basic filtering than other extensions, but also has been reported to be working with ad networks including Google itself to whitelist some ads and allow them to pass through to users, in exchange for payment. Several users install blocking extensions not only so that they don't see ads, but also to avoid having their online activity tracked and profiled by ad networks.