Google Chrome extension developers were fuming last week over a new approach in the way that the browser will handle extensions. It will limit the way that Chrome lets browsers block content – unless you’re an enterprise user.
In November 2018, Google proposed an update to the Manifest system, which restricts what extensions can do in Chrome. In its forthcoming Manifest v3, it wants to change the way that browser extensions intercept and modify network requests from the browser.
The proposed change would limit the functions of a specific application programming interface (API). APIs define how a piece of software can be spoken to by other bits of software.
Today, extensions running on the Chromium browser use the webRequest API to intercept network requests. They can use it to analyze and block requests from online domains like advertising networks.
Chromium’s developers want to limit the blocking form of webRequest, instead allowing only a neutered version that simply observes network requests. If developers want to block a site, they’d need to use another API called declarativeNetRequest.
The move would improve performance and improve user privacy, said Chromium’s developers. When using webRequest, Chrome gives the network request to the extension and waits for its decision. Under declarativeNetRequest, the extension tells Chromium its rules and lets the browser use those to handle the decisions itself.
Google hinted at the changes as far back as 1 October 2018, when it announced Manifest v3 in a blog post, promising:
More narrowly-scoped and declarative APIs, to decrease the need for overly-broad access and enable more performant implementation by the browser, while preserving important functionality
Nevertheless, several developers aren’t happy. They have been voicing concerns since at least January 2019. One of them is Raymond Hill, developer of the ad blocking software uBlock. He complained that declarativeNetRequest only features 30,000 rules, which isn’t nearly enough to support the filters his product uses. In a complaint posted to the Chromium bugs mailing list, Hill added:
If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin (“uBO”) and uMatrix, can no longer exist.
Ad blocking isn’t the only activity at risk according to extension developers. Claudio Guarnieri, senior technologist at Amnesty International is concerned:
We, at Amnesty International, have also been working on browser extension to support at-risk communities in protecting from targeted attacks.
Another extension developer, Kristof Kovacs, added that the move would effectively kill the product he is working on in Google’s browser:
… We are the developer of a child-protection add-on, which strives to make the internet safer for minors. This change would cripple our efforts on Chrome.
Then Cliqz, creator of privacy extension Ghostery, analyzed the performance impact of the most popular ad blockers and found that the extensions were fast and efficient. The study showed that:
The manifest v3 performance claim does not hold based on our measurements.
Shortly afterwards, in a post on 15 February 2019, Google software engineer Devlin Cronin said that:
It is not, nor has it ever been, our goal to prevent or break content blocking.
He also announced that webRequest wouldn’t be entirely removed, and committed to increasing the ruleset limits in declarativeNetRequest.
This didn’t appease developers much. For example, the Electronic Frontier Foundation (which makes the Privacy Badger Chrome extension) published a document in April asking Google to reconsider messing with the blocking capabilities of the webRequest API.
Simeon Vincent, developer advocate for Chrome Extensions at Google, tried to clear things up a bit with a post about the issue on Google Groups in late May, but caused a stir with this sentence:
Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments).
So the current proposal limits blocking capabilities unless you’re an organization that uses an enterprise version of Chrome.
Developers were incensed. One said:
It looks like they don’t have the guts to force this unjustified, user-hostile change on enterprises.
Others criticized the company for not addressing the Cliqz performance study.
Raymond Hill posted an angry retort on Github last week, accusing Google of ceding control to ad blockers only for as long as it took to build market share:
The deprecation of the blocking ability of the webRequest API is to gain back this control, and to further now instrument and report how web pages are filtered since now the exact filters which are applied to web page is information which will be collectable by Google Chrome.
He also pointed to Google’s 10-K filing which states that ad blocking technologies could affect its profits.