New Chromium ad blocking mechanism puts Microsoft’s new browser in a bind OnMSFT.com

Google is taking a lot of flack over its proposed deprecation of a set of webRequest APIs for extensions that specifically deal with how 3rd party brokers utilize ad blocking.

While it’s becoming almost passe to mock and ridicule Google over some of its seemingly anti-consumer oriented decisions as of late, the new set of rules dubbed Manifest V3, look to affect more than just the internets search giant, in fact, it appears to be something that will be baked into all updated versions of Chromium and thus could have an effect on users of Microsoft’s new Edge browser.

Google’s initial adoption of Manifest V3 in its upcoming update to Chrome comes under the veil of privacy protection for end users.

The sole motivation here is correcting major privacy and security deficiencies in the current system. I know, because I set that focus, and the team reports up through me. And here's a bit more context on the uBlock assertions. https://t.co/aSK5HquB1x

— Justin Schuh 🤬 (@justinschuh) May 30, 2019

More specifically, based on an open source Manifest V3 documentation, ad blockers who utilized the webRequest API’s to help decided what to show on screen and how it’s displayed will have restrictions tightened. Chrome’s new implementation of Manifest V3 will set a maximum of 30,000 rules and in turn kneecap software that makes use the long list of advertiser internet addresses, sometimes upward of 90,000.

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.

Fortunately, Google isn’t without a heart and has made an exception to its implementation plan by allowing enterprise a chance to exempt themselves.

Critics of the proposal cite Google’s massive advertisement business and dominant browser market share as the motivation to deprecate functionality of previous Manifest version APIs wholesale. Some of the most vocal critics have understandably come from ad blocker services providers such as uBlock Origin, Privacy Badger, Ghostery and AdBlock Plus who have built businesses entirely on the backs of those webReqeust APIs.

All of this is to say that Microsoft’s new Chromium development now puts the company in a sorta precarious position as to follow what will be an industry standard by sheer Google force and contributions to Chromium, or offer an alternative by supporting a full-featured ad blocking platform for extensions.

So this Google change that will impact ad blockers. Is this only in Chrome? Or is it also in Chromium? (And thus would impact the new Edge.)

— Paul Thurrott (@thurrott) May 31, 2019

Following the above thread, it seems that it isn’t a done deal for all Chromium browsers but that it will be a call for Microsoft to make on how to implement Manifest V3, especially if they continue to leverage Chrome-specific extension access to the browser.

As it stands now, Microsoft’s new Chromium-based web browser will eventually be updated with Manifest V3, but the company can either offer developers targeting access to the older Manifest versions or implement an entirely different 3rd party ad blocking platform in its new offering akin to browser providers such as Brave.

With Microsoft looking for ways to attract new users, persuade Chrome converts and assuage enterprise developer fears, Google’s reluctance to budge on this ad blocking issue could be the company’s opening to steal a bit of market share by enticing developers to create extensions for a browser that considers privacy over advertisement access.

Further reading: Ad Block, AdBlock Plus, Brave, Chrome, Chromium, Google, Manifest V3, Microsoft, uBlock

Comments are closed.