Peter Bright* says Google is planning to introduce changes to its Chrome browser that could lead to many ad blockers failing to work.
Google is planning to change the way extensions integrate with its Chrome browser.
The company says that the changes are necessary for and motivated by a desire to crack down on malicious extensions, which undermine users’ privacy and security, as part of the company’s continued efforts to make extensions safer.
The move also means that popular ad blocking extensions such as uBlock Origin and uMatrix will, according to their developer, no longer work.
The plans, called Manifest V3, are described in a public document.
Google is proposing a number of changes to the way extensions work.
The broad intent is to improve extension security, give users greater control over what extensions do and which sites they interact with, and make extension performance more robust.
For example, extensions will no longer be able to load code from remote servers, so the extension that’s submitted to the Chrome Web store contains exactly the code that will be run in the browser.
This prevents malicious actors from submitting an extension to the store that loads benign code during the submission and approval process but then switches to something malicious once the extension is published.
In a bid to discourage extensions from asking for blanket access to every site, Manifest V3 also changes the permissions system, so universal access can no longer be demanded at extension install time.
The problem for ad blockers comes with an application programming interface (API) called webRequest.
With the current webRequest API, the browser asks the extension to examine each network request in which the extension is interested.
The extension can then modify the request before it’s sent (for example, cancelling requests to some domains, adding or removing cookies, or removing certain HTTP headers from the request).
This provides an effective tool for ad blockers; they can examine each request that is made and choose to cancel those that are deemed to be for ads.
The API can also be used to perform limited modification of the response to the request, which can be used to do things such as block JavaScript or block requests for large media files.
Because the extension needs to examine each request and deliver its verdict — cancel the request, allow the request, modify or redirect the request — Google says that it’s slow.
Extensions are written in JavaScript and can take arbitrarily long times when examining requests, meaning that potentially long delays can be inserted into the browser.
On the other hand, this gives the API a lot of power — the extension can use whatever matching algorithms it likes to pick and choose which requests are allowed and which are blocked.
That power isn’t necessarily used for good; an API that allows cookies to be examined and modified also allows cookies to be stolen.
Out with the old, in with the new
To replace webRequest, Google has proposed a new API, declarativeNetRequest.
With this new API, instead of having the browser ask the extension what to do with each and every request, the extension declares to the browser “block requests that look like X, redirect requests that look like Y, and allow everything else.”
These declarations can use some simple wildcards but are otherwise very simple.
Chrome itself can then compare each URL to X and Y and take appropriate action.
On the upside, this should be faster.
All the wildcards and comparisons are handled within Chrome rather than an extension’s JavaScript, so it’s no longer possible to delay a request indefinitely.
The new API is better for privacy, too.
Because the request doesn’t get sent to the extension, it means that the extension no longer gets to see cookies or other potentially sensitive information.
But it also robs the extensions of their flexibility.
More complex patterns or matching criteria can no longer be used.
It also means that the list of blocked or redirected URLs must be static (the list must be stored as a JSON file within the extension) and, further, constrained to 30,000 items.
By way of comparison, uBlock Origin ships with 90,000 filters by default and works fine with half a million filters.
The new API also offers no way to modify the response at all.
Not every ad blocker will necessarily fall afoul of the new restrictions.
The syntax for declaring blocked URLs for the new declarativeNetRequest API is very similar to that already used by AdBlock Plus, for example, so that blocker should be able to adapt to the new API easily enough.
But anything with more rules, or more complex rules, is going to be out of luck.
In a bug tracking Manifest V3’s progress and related discussion thread, authors of, among other things, NoScript and uBlock Origin both say that the new API is not sufficient for their extensions.
Developers of other blocking tools have also expressed concern.
The same API is used by a range of anti-phishing/anti-malware extensions.
These extensions work in much the same way as the ad blockers — matching URLs against a blacklist — but they have additional secrecy concerns.
As the developer of anti-phishing extension blockade.io explains, the URLs for their extension blocks are stored only in a hashed form.
The new API requires the URLs to be provided in plain, readable text.
Using a plaintext list would make it easier for malware distributors and phishers to see that their sites have been blacklisted; it would also make the list a useful resource for anyone on the lookout for sites actively exploiting browser flaws.
Manifest V3 isn’t finalised yet, and even once it is implemented, there will be a period during which extensions can continue to use the current APIs.
However, the way things stand, it appears that a wide range of extensions are going to become considerably less capable — and may even stop working altogether — within the near future.
* Peter Bright is Technology Editor at Ars Technica. He tweets at @drpizza.
This article first appeared at arstechnica.com.
