Google Changes API Making Chrome Adblocking Harder
Written by Mike James   
Wednesday, 23 January 2019

This story has potential for conspiracy theory and hate. It is enough to make you vow to never use Chrome again, and yet the important point is that most users will continue to use Chrome no matter what.

Why does Google put so much effort into creating a browser?

This is the question that might now have a partial answer. After gaining most of the browser market, Google is able to change things to suit its own purposes.

chromlogo2018

This is all about the extensions API and webRequest in  particular. If you want to write a Chrome extension then you have to use the public API and you have to declare in a manifest what you are using. The webRequest API allows extensions to interact with each and every request to download a file or resource. It essentially allows the extension to monitor, analyze and block web traffic. In particular, it allows adblockers to detect when a web page tries to download an ad and block it. To do this the extension has to ask for a webRequestBlocking permission in the manifest. Notice that this is a locked down system in the sense that Google vets all extensions and only grants access to the facilities it deems are secure and don't effect efficiency. Yes, this is a walled garden.

Firefox used to be completely open about extensions and what they could do as, being written in HTML and JavaScript, you could access and interact with almost anything in the internals of the browser. This is no longer the case as Firefox has been completely redesigned and now uses the same extensions API as Chrome.

The problem started when a revision of the manifest to V3 was posted:

"In Manifest V3, we will strive to limit the blocking version of webRequest, potentially removing blocking options from most  events (making them observational only). Content blockers should instead use declarativeNetRequest (see below). "

This prompted a reaction from Raymond Hill, the developer behind uBlock Origin and uMatrix

"If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin ("uBO") and uMatrix, can no longer exist."

Google is saying that it is up to ad blocker writers to migrate their code to use declarativeNetRequest, which is what Adblock Plus uses to load a list of filter rules. It is claimed that this method of blocking is not strong enough and crippled by the limited number of rules that can be specified - 30,000, which is less than existing lists of blocked resources. As Raymond Hill goes on to say:

"Beside causing uBO and uMatrix to no longer be able to exist, it's really concerning that the proposed declarativeNetRequest API will make it impossible to come up with new and novel filtering engine designs, as the declarativeNetRequest API is no more than the implementation of one specific filtering engine, and a rather limited one (the 30,000 limit is not sufficient to enforce the famous EasyList alone)."

It is also worth noting that Google pays Adblock Plus to whitelist its ads. Of course there is nothing to stop others creating ad blockers that use declarativeNetRequest and which do block Google ads.

If you read through the comments you will find lots of "I'm never using Chrome again" and worse. The point is that most users won't be following this argument and will just discover that their ad blocker no longer works. Chances are that they will simply adopt another, weaker ad blocker. Chrome will lose a few percentage points in market share and things will probably continue as before.

This is probably not the way most of us would have guessed that the ad blocking wars would come to a resolution.

spookygoogle

More Information

Extensions: Implement Manifest V3

Related Articles

A Real World Ad Blocker

Microsoft To Go Chromium Update: Confirmed

Adblocking - Looking For A Solution

Fear And Loathing In The App Store 17 - The Strange Case Of AdNauseam

Brendan Eich Launches Brave New Browser

Rationality, advertising and profit

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

 

Banner


Office Development Kit For VS Code
18/09/2024

Microsoft has released a preview version of a new development tool for developing Office add-ins in Visual Studio Code.



Windows Community Toolkit Adds Controls
10/09/2024

Microsoft has released version 8.1 of the Windows Community Toolkit, with support for .NET 8 alongside new controls and initial AOT annotations.


More News

kotlin book

 

Comments




or email your comment to: comments@i-programmer.info

Last Updated ( Wednesday, 23 January 2019 )