Disclaimer: We may earn a commission if you make any purchase by clicking our links. Please see our detailed guide here.

Follow us on:

Google News

Google would block third-party ad blockers in Chrome for security, privacy and speed

Bhaswati Sarkar
Bhaswati Sarkar
She likes to lose herself in music and daydreams quite often. Travelling excites her and photography is her passion- nature is her favorite subject. Writing is cathartic for her. A happy-go-lucky kind of person, she tries to remain calm and serene through daily life.

Join the Opinion Leaders Network

Join the Techgenyz Opinion Leaders Network today and become part of a vibrant community of change-makers. Together, we can create a brighter future by shaping opinions, driving conversations, and transforming ideas into reality.

Google Chrome would now block certain ad blockers and destroy content-blocking extensions as per the changes to the open-source Chromium browser proposed by Google engineers for the sake of speed and safety. It seems like Adblock Plus would be an exception to this change, though similar third-party plugins would be affected. The drafted changes would also restrict the capabilities available to developers of extensions.

Content blockers aid users to control the processes of presentation and interaction of their browser with remote resources.

Manifest v3, in a bid to improve security, privacy, performance and even enhance user control, comprises a specification for browser extension manifest files enumerating resources and capabilities available to browser extensions. The design document Stated: “Users should have increased control over their extensions… A user should be able to determine what information is available to an extension, and be able to control that privilege.”

To reach these goals, Google plans to replace the webRequest API with the new declarativeNetRequest API.

The webRequest API allows the interception of network requests by browser extensions so as to block, modify or redirect them, and this delays web page loading. So, this API will now be able to only read, and not modify, network requests.

The declarativeNetRequest API would allow the Chrome browser itself to handle network requests, but risks removing a possible source of bottlenecks and a potentially useful mechanism for changing browser behavior.

The declarativeNetRequest API provides better privacy to users because extensions can’t actually read the network requests made on the user’s behalf – Google’s API document

Raymond Hill, the developer behind uBlock Origin and uMatrix posted on the Chromium bug tracker that changes suggested by the Manifest v3 proposal would wreck his ad and content block extensions while simultaneously restricting content control by users.

In the case of the user preferring to allow a third-party developer to filter network requests in place of Google, these drafted changes would interfere with webpage functionality.

Hill adds that “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 and uMatrix, can no longer exist.”

While the proposed changes would reduce the efficacy of content blocking and blocking extensions, all ad blocking would not be necessarily knocked out. Google and other internet advertising networks allegedly pay Adblock Plus to whitelist their online advertisements, and thus their preference for this particular plug-in. However, in comparison to Adblock Plus, uBlock Origin and uMatrix offer much more wide-ranging controls without bothering about placating publishers through ad whitelisting.

Furthermore, there are other facilities such as blocking media elements larger than a specified size, disabling JavaScript execution by injecting Content-Security-Policy directives, and removing the outgoing Cookie headers, that would no longer be available under the new declarativeNetRequest API.

Apparently, Hill is awaiting a response from the Google software engineer overseeing this issue.

I understand the point of a declarativeNetRequest API, and I am not against such API. However I don’t understand why the blocking ability of the webRequest API – which has existed for over seven years – would be removed (as the design document proposes). I don’t see what is to be gained from doing this – Raymond Hill, the developer behind uBlock Origin and uMatrix

He argues against the utility of Chromium should these changes come into being:  “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 depreciation of blocking the ability of the webRequest API, I am skeptical ‘user agent’ will still be a proper category to classify Chromium.”

Several other extension developers have conveyed dismay over the drafted changes, some even surmising that Google’s policy is to use privacy as a pretext for boosting its ad business.

Google has not finalized the changes yet and may be willing to address the concerns of extension developers. As per the email of a Google spokesperson to The Register, “Things are subject to change and we will share updates as available.”


Partner With Us

Digital advertising offers a way for your business to reach out and make much-needed connections with your audience in a meaningful way. Advertising on Techgenyz will help you build brand awareness, increase website traffic, generate qualified leads, and grow your business.

Power Your Business

Solutions you need to super charge your business and drive growth

More from this topic