This article is more than 1 year old
Google: We're not killing ad blockers. Translation: We made them too powerful, we'll cram this genie back in its bottle
We want to make Chrome safer... by taking away the API we used to race Firefox
'This breaks uBlock Origin and uMatrix'
Vincent insists Google's goal isn't to prevent or weaken ad blockers. Yet as initially described, that would be Manifest v3's effect.
As Raymond Hill, the developer behind uBlock Origin, said in response to an inquiry from The Register last month, the problem is losing the powerful blocking abilities of the webRequest
API. He told us his software needs the highly flexible webRequest
interface to perform its advanced filtering, and the proposed replacement, declarativeNetRequest
, was too basic.
"This breaks uBlock Origin and uMatrix, these are incompatible with the basic matching algorithm they [Google] picked, ostensibly designed to enforce EasyList-like filter lists," he explained.
So Google's intentions may be good – to make Chrome extensions more secure by regulating how much they can do – but its actions threaten collateral damage to its developer community.
Essentially, with declarativeNetRequest
, an extension submits a set of rules for blocking requests for unwanted content, and Chrome does the actual filtering. With webRequest
, the extension sees all requests and can modify as it desires. The latter API can be abused by bad plugins whereas with the former, the browser handles all the inspection. The rules list makes sense on the face of it, though it's been argued it is too rigid and limited. In any case, Google thinks there's too much risk with webRequest
.
Since the issue first blew up in January, Google engineers have attempted to address these aforementioned concerns by promising to carry over or reimplement useful API capabilities that failed to make the draft change proposal: the low-limit on blocking rules has been lifted to a more reasonable ceiling, 150,000; the Declarative Net Request API has been tweaked to let developers register and remove dynamic rules at runtime; and the ability to remove common tracking headers has been added.
The entire controversy could have been averted if Google engaged with Chrome extension developers from the outset and responded to their concerns by drafting changes after obtaining broad support. But Google, which has repeatedly celebrated the benefits of community involvement in successful open-source projects like Kubernetes, doesn't show much interest in consensus for its own platforms. It declared its intent to change Chrome extensions last October, and only decided to accommodate concerns after complaints began flooding in. And still, its stance is: deal with the pain.
"We understand that these changes will require developers to update the way in which their extensions operate," explained Cronin. "However, we think it is the right choice to enable users to limit the sensitive data they share with third-parties while giving them the ability to curate their own browsing experience."
There are other ways to handle APIs that touch sensitive data. With Gmail and Drive, Google is requiring developers utilizing these APIs for apps that interface with these cloud services to pay for security audits. A reasonably priced audit for using webRequest
might serve everyone better than the current paternalistic approach.
Meanwhile, rival browser makers have indicated they may take countermeasures. Brave, Opera and Vivaldi have all said they may re-implement the blocking capability of webRequest
or address the change in some other way.
"We are not proposing a fork," said Jon von Tetzchner, CEO of Vivaldi Technologies, in an email to The Register. "That being said, we do maintain some differences with Chromium as needed, so if necessary, we could do that again."
As Hill tells it, Google implemented webRequest
in 2011 when trying to gain market share from Firefox, because ad blocking and privacy extensions were popular among users. If Manifest v3 fails to accommodate effective content blocking and privacy code, new market leaders may emerge. ®