Google does seem set on its plans to remove the webRequest API and replace it by the declarativeNetRequest API. This is being justified on technical and security grounds, but the spinoff effect is that ad-blockers will find it harder to work.

Google's main cash stream comes from advertising. Google makes the current number one browser - Chrome. At the moment Chrome supports quite powerful ad-blocking and logically this must hurt Google profits. If you were in Google's place, wouldn't you try to find a way to make ad-blocking harder?

This seems obvious, but Google has a problem - there are alternative browsers and if it simply blocks ad-blockers Chrome would most likely not be the top browser any more. Equally, the users who switched would simply use other ad-blockers and hence the effect on Google's bottom line wouldn't be as much as you might predict. To get it right, Google would have to make ad-blockers less effective, but not so much that users vote with their feet and give up using Chrome. Guess what - this is exactly what  it seems to be trying for.

The webRequest API is ludicrously powerful. It allows an extension to intercept and redirect any and all web requests made by a program. The extension handles the requests using JavaScript and this is said to be an efficiency problem and a security problem both in one. The solution is to replace it by declarativeNetRequest, which requires a list of URLs that need attention - hence "declarative". The actual work in implementing the list is done internally by the browser, making it faster and more secure. The only problem is that the number of URLs and the nature of the URLs is limited.

This proposal, which came to light at the start of the year, met with quite a lot of criticism and Google withdrew it to think things over. Now it is back and, on the surface, there have been some changes and webRequest will not be removed, but it might as well be:

webRequest will become read only. Additionally, webRequest will not be able to see requests that have been blocked, redirected, or modified by declarativeNetRequest (DNR) rules. There's currently no plan for Manifest V3 extensions to modify requests other than DNR actions. Currently DNR only supports three actions: "block", "redirect", and "allow", but the extensions team is considering adding  support for other actions (e.g. stripping cookies from a request).

This basically means that webRequest can be used to observe requests, but not to do anything about them. However, not everyone is going to be so limited:

Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments). Extensions with appropriate permissions can still observe network requests using the webRequest API. The webRequest API's ability to observe requests is foundational for extensions that modify their behavior based on the patterns they observe at runtime.

Notice the exemption for enterprise deployments. This has been headlined in some reports as "Google Limits Ad Blocking To Enterprise Installations". It really isn't clear what this means, because if ad-blockers give up on Chrome because of the API changes, they are not likely to be available for limited installation on enterprise sites. Presumably enterprise sites have other requirements for the webRequest API.

A Google spokesperson stated:

“Chrome supports the use and development of ad blockers. We’re actively working with the developer community to get feedback and iterate on the design of a privacy-preserving content filtering system that limits the amount of sensitive browser data shared with third parties.

For managed environments like businesses, we offer administration features at no charge.”

So still some hope of change but no real hint as to why businesses should be exempt.

One big improvement is that now it is proposed that rules can be modified dynamically, i.e. at runtime. In the previous proposal the rule set was fixed when the extension was installed. With a limit of 30,000 rules this seemed to ensure that ad-blocking would be difficult to achieve and difficult to keep up to date. The reason for the limit is said to be due to working out what is efficient to implement. Efficiency is a good excuse for limiting rule sets whatever the real motivation for doing so.

If Google does implement this change, not only will it be able to control ad-blocking, it will also be able to collect data on what is blocked and how often.

Time to switch to Firefox?

User inertia is not something to be underestimated. Users tend to stick with what they have installed unless it becomes unusable or something much, much better is on offer. You may well switch, they probably won't.

Is this just paranoid and is Google in fact trying to make the web browser more efficient and secure? As the sage once said - you may be paranoid, but it doesn't mean they are not out to get you.

For what it is worth, I can think of a much more effective way for Google to stop all ad-blocking in one simple move and really take over the web in one step.

More Information

Manifest V3: Web Request Changes

Related Articles

Google Changes API Making Chrome Adblocking Harder

Chrome Takes Over Web - Blocks Edge

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.

Comments

Make a Comment or View Existing Comments Using Disqus

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