Home / Technology / Google plans to make changes to Chrome that could lead to ad blockers

Google plans to make changes to Chrome that could lead to ad blockers

  Google plans to make changes to Chrome that could break ad blocking

Google plans to change the integration of extensions into the Chrome browser. The company says the changes are necessary and motivated to counter malicious extensions that undermine users' privacy and security as part of the company's continued efforts to make extensions more secure. The move also means that popular extensions to block ads like uBlock Origin and uMatrix no longer work according to their developer.

The plans, called Manifest V3, are described in a public document. Google suggests a number of changes to how extensions work. The overall intention is to improve extension security, give users better control over what extensions do and with which websites they interact, and make expansion performance more robust. For example, extensions may no longer be able to load code from remote servers. Therefore, the extension sent to the Chrome Web Store contains exactly the code that is executed in the browser. This prevents malicious actors from sending an extension to the store that loads benign code during the submit and approve process, but changes to a malicious element after the extension is published. Manifest V3 also changes the permissions system to prevent extensions from being queried for full access to each site, eliminating the need for universal access at the time of the expansion installation.

The problem for ad blockers is with an API named webRequest . For the current API webRequest the browser prompts the extension to check every network request that the extension is interested in. The extension can then modify the request before sending it (eg, cancel queries to some domains, add.) Remove cookies or remove certain HTTP headers from the request). This is an effective tool for ad blockers. You can review any request and claim it for ads that are considered ads.

The API can also be used to modify the response to the query. Z Block JavaScript or block requests for large media files.

Because the extension needs to validate each request and return the result, cancel the request, allow the request, change the request, or redirect it. Google states that it is slow. Extensions are written in JavaScript and can take any length of time to validate requests, potentially allowing long delays to be inserted into the browser. On the other hand, this gives the API a lot of power ̵

1; the extension can use all the appropriate algorithms to choose which requests are allowed and which ones are blocked. This power is not necessarily used for the good. An API that allows cookies to be checked and changed also allows cookies to be stolen.

Out with the old, with the new

To replace webRequest Google has proposed a new API. declarative NetRequest . With this new API, the browser does not need to ask the extension what to do with each individual request, but the extension that "blocks" the browser requests that look like X redirect requests that look like Y and allow everything else. "These declarations can use some simple wildcard characters, but are otherwise very simple. Chrome itself can then compare each URL with X and Y and take action.

On the top of that, it should be faster." All placeholders and comparisons are in Chrome and is not addressed in an extension's JavaScript so that a request can no longer be indefinitely delayed The new API is also better for privacy Because the request is not sent to the extension, the cookie does not display any cookies or other potentially sensitive information. It also robs you of the flexibility of its extension, making it harder to use more complex patterns or matching criteria, which means that the list of blocked or redirected URLs must be static (the list must be saved as a JSON file in the extension) and also limited to 30,000 items s For comparison, uBlock Origin ships with 90,000 filters by default and works well with half a million filters.

The new API also does not provide a way to modify the response.

Not every ad-blocker will necessarily go into a wrong state of new limitations. The syntax for declaring blocked URLs for the new API declarativeNetRequest is very similar to the one already used by AdBlock Plus, so the blocker can easily adapt to the new API. But anything that has more rules or more complex rules will not be lucky. In a Bug Tracking manifest V3 and the associated discussion thread, both the authors of NoScript and uBlock Origin say that the new API is not enough for their extensions.

Developers of other blocking tools also expressed concern. The same API is used by a number of anti-phishing / anti-malware extensions. These extensions work in the same way as the ad blockers – URLs are blacklisted – but have additional privacy concerns. As the developer of anti-phishing extension blockade.io explains, the URLs for their extension blocks are only saved in hash form. The new API requires that the URLs be provided in clear, readable text. By using a plain text list, malware distributors and phishers can more easily see that their sites have been blacklisted. This would also make the list a useful resource for anyone looking for sites that actively exploit browser bugs.

Manifest V3 is still ongoing, and even once implemented, there will be a period for extensions to continue. Use the latest APIs. However, it seems that a wide range of enhancements will become significantly less significant in the foreseeable future and even stop working altogether.

Source link