Google planning changes to Chrome that could break ad blockers

Google Chrome logoGoogle 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.

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 verdictcancel the request, allow the request, modify or redirect the requestGoogle says that it's slow. Extensions are written in JavaScript and can take arbitrarily long 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 powerthe 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.

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 blockersmatching URLs against a blacklistbut 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 capableand may even stop working altogetherwithin the near future.

Source: Ars Technica

Tags: browsers, Chrome, Google

Comments
Add comment

Your name:
Sign in with:
or
Your comment:


Enter code:

E-mail (not required)
E-mail will not be disclosed to the third party


Last news

 
Galaxy Note10 really is built around a 6.7-inch display
 
You may still be able to download your content
 
Facebook, Messenger and Instagram are all going away
 
Minimize apps to a floating, always-on-top bubble
 
Japan Display has been providing LCDs for the iPhone XR, the only LCD model in Apples 2018 line-up
 
The 2001 operating system has reached its lowest share level
 
The entire TSMC 5nm design infrastructure is available now from TSMC
 
The smartphone uses a Snapdragon 660 processor running Android 9 Pie
The Samsung Galaxy A5 (2017) Review
The evolution of the successful smartphone, now with a waterproof body and USB Type-C
February 7, 2017 /
Samsung Galaxy TabPro S - a tablet with the Windows-keyboard
The first Windows-tablet with the 12-inch display Super AMOLED
June 7, 2016 /
Keyboards for iOS
Ten iOS keyboards review
July 18, 2015 /
Samsung E1200 Mobile Phone Review
A cheap phone with a good screen
March 8, 2015 / 4
Creative Sound Blaster Z sound card review
Good sound for those who are not satisfied with the onboard solution
September 25, 2014 / 2
Samsung Galaxy Gear: Smartwatch at High Price
The first smartwatch from Samsung - almost a smartphone with a small body
December 19, 2013 /
 
 

News Archive

 
 
SuMoTuWeThFrSa
 123456
78910111213
14151617181920
21222324252627
282930    




Poll

Do you use microSD card with your phone?
or leave your own version in comments (15)