PCLinuxOS Magazine

PCLinuxOS

Google To Block Modern Ad Blocking On Chrome

by Paul Arnote (parnote)

You just knew, in your heart of hearts, that it HAD to happen. After all, Google's primary source of revenue is selling advertising. And putting out a browser that makes it relatively easy for users to block ads is just completely counterproductive to a business model that is centered around selling ads. If the ads aren't seen (or cannot be seen), there is no money to be made.

Forget, for a moment, that almost NO ONE clicks through on those ads, which makes it puzzling why advertisers would want to waste their money in such a manner. I know that in all the years I've been on the web, I have clicked through on an ad only a handful of times. Plus, in the past ten-plus years, I have NEVER clicked through on an ad. And, they never influence my buying decisions in a positive way. More than anything, they irritate me enough to vow to never buy that product -- ever.

Source: Statistica.com

Forget, for a moment, that Google Chrome is the most used web browser in the world (consistently between 65% and 70% market share over the past year), by far. Firefox is a distant second place, with around 10% market share. Google's browser market share is astronomical, compared to all the other web browsers. Now that they are on the top of the heap, so to speak, they want to change the rules. I suspect this move will put a serious dent in those numbers, as users flee the advertising onslaught that this change will likely bring. A meteoric rise in popularity is usually followed by a meteoric fall from grace.

So, let's look at this proposed change. Currently, modern day ad blockers such as uBlock Origin and AdGuard use Chrome's webRequest API to block ads, often before they can even be downloaded. But, according to an article at 9TO5 Google, the webRequest API will be deprecated, and replaced with the declarativeNetRequest API. The latter is more akin to the method used by Adblock Plus to block ads. Called Manifest V3, you can read all of the proposed changes here (Google Docs), in a document that spells out all of the proposed changes.

Herein lies the limitation. The declarativeNetRequest API is limited to 30,000 rules. So, ads that don't fit within the "rules" are allowed to come through.

I've used Adblock Plus in the past, and it does an ok job at blocking ads. Just ok, but not great. Since I've switched to using uBlock Origin, I've noticed a LOT fewer ads slipping through, which makes for a much, much nicer, more enjoyable time browsing.

Raymond Hill, the creator of uBlock Origin, came out with a strong statement against the proposed change in January, 2019.

In the design document, it is said that the webRequest API will no longer allow to be used in blocking mode:
> 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). It is unlikely
> this will account for 100% of use cases (e.g., onAuthRequired),
> so we will likely need to retain webRequest functionality in
> some form.
From the description of the declarativeNetRequest API, I understand that its purpose is to merely enforce Adblock Plus ("ABP")-compatible filtering capabilities. It shares the same basic filtering syntax: double-pipe to anchor to hostname, single pipe to anchor to start or end of URL, caret as a special placeholder, and so on. The described matching algorithm is exactly that of a ABP-like filtering engine.
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.
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).
Key portions of uBlock Origin and all of uMatrix use a different matching algorithm than that of the declarativeNetRequest API. Block/allow rules are enforced according to their *specificity*, whereas block/allow rules can override each other with no limit. This cannot be translated into a declarativeNetRequest API (assuming a 30,000 entries limit would not be a crippling limitation in itself).
There are other features (which I understand are appreciated by many users) which can't be implemented with the declarativeNetRequest API, for example, the blocking of media elements which are larger than a set size, the disabling of JavaScript execution through the injection of CSP directives, the removal of outgoing Cookie headers, etc. -- and all of these can be set to override a less specific setting, i.e. one could choose to globally block large media elements, but allow them on a few specific sites, and still be able to override these rules with ever more specific rules.
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 web sites 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.

Google has indicated that the proposed changes are not yet set in stone, and that they are willing to work with developers to insure that their extensions continue to work under the proposed changes. As reported on 9TO5 Google, a Google spokesperson stated:

These changes are in the design process, as mentioned in the document and the Chromium bug. We want to make sure all fundamental use cases are still possible with these changes and are working with extension developers to make sure their extensions continue to work.

The time may be ripe for Firefox and other browsers to dethrone Google Chrome as the most popular and most used web browser. It may even be easier than anticipated, with Google helping the process along by shooting themselves in their own foot. The browser wars may have just entered a new phase, and the end users will determine the winner.

Previous Page Top Next Page