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 API called webRequest. With the current webRequest API, the browser asks the extension to examine each network request that the extension is interested in. The extension can then modify the request before it's sent (for example, canceling 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.
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.
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 finalized 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.