Chrome Saying Bye Bye To Ad-Block Extensions With an Upcoming Update

Published by Caleb Macauley on

Google vs extensions

Google intends on cutting down on some ad blockers after applying some major adjustment to their extension behavior in Chrome.

Earlier on this week, Raymond Hill, developer for the open-source, cross-platform browser extension – uMatrix – stated on the Chromium bug tracker that he was worried that the modification of some of Chrome’s software class will cause Adblocking extensions to be completely wiped out. The proposed modification of the Chrome Extensions that Hill pointed out was in reference to that which was outlined in Google’s Manifest V3 file.

Raymond was more concerned about Google’s intentions to stop ad blocking via the webRequest API and restrict the blocking feature to that of the brand new DeclariveNetRequest API.

A probable concern was how the Adblock Plus would not be affected by the latest API as it bearly invokes the blocking procedure of that actual ad blocker. This will make way for Google and the rest of those paying Adblock Plus to have their ads blocked. The application of Google’s ad blocking in Chrome tailgates with the current regulation on intermediary ad blockers.

Hill finds it alarming, however, that the declartiveNetRequest is the only software class that the ad blocks can use since it has been curbed; causing uMatrix and uBlock Origin to be subverted. At this point, there’s no chance for other ad-blocker programmers to come up with a new filtering system that will break down intricate contents.

Google vs extensions
Google to burn extensions with an upcoming update

It is mentioned in the declarativeNetRequest API’s Google record; “Thus, instead of the above flow where Chrome receives the request, asks the extension, and then eventually gets the result, the flow is that the extension tells Chrome how to handle a request and Chrome can handle it synchronously.”

“This allows us to ensure efficiency since a) we have control over the algorithm determining the result and b) we can prevent or disable inefficient rules.  This is also better for user privacy, as the details of the network request are never exposed to the extension.”

Hill argued that “Extensions act on behalf of users, they add capabilities to a ‘user agent’, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of websites, which obviously would be happy to have the last word in what resources their pages can fetch/execute/render.”

“With such a limited declarativeNetRequest API and the deprecation of blocking ability of the webRequest API, I am skeptical ‘user agent’ will still be a proper category to classify Chromium.”

It’s likely that some changes will include the new declarativeNetRequest API, which will take the place of the webRequest API as suggested. That is an obvious setback, although the performance benefits are salient. Any extensions that depend on intensely altering system demands will be cut off as the extensions will never again have to give a go-ahead for Chrome to permit or impede every circuitry request.

Source


Caleb Macauley

Music and tech are where my heart is. Chrome OS is where the future is. Of course, I chose to stick with the future ... Come join the cool kids; you have nothing to lose.

Leave a Reply

avatar
  Subscribe  
Notify of