Google Claims Chrome 'Isn't Killing Ad Blockers', But 'Making Them Safer'

Google says the new move will significant performance implications and provide user security and privacy.

By Jagmeet Singh | Updated: 13 June 2019 14:15 IST

Google announced Manifest v3 standard for Chrome back in October 2018

Highlights

Google claims WebRequest API opens an avenue for malicious extensions
The proposed API is claimed to make the experience faster
Google is planning to increase the limit to a maximum 150,000 rules

Google Chrome has been in the news for restricting ad blockers. The search giant last year proposed the Manifest V3 standard that is designed to replace the existing WebRequest API with the new DeclarativeNetRequest API to limit ad blocking capabilities of browser extensions. But now, a detailed blog post has been released to clarify that the new move isn't to kill ad blockers -- instead, it is claimed to be aimed at making them safer and bringing a faster Web browsing experience altogether. The shift to the new extension API is also touted to enable developers to build better performing ad blockers.

In October 2018, Google announced the arrival of its Manifest v3 that ultimately debuted in January to set the pitch for the DeclarativeNetRequest API. The company faced a growing chorus of criticism for restricting ad blockers through its new API. Late last month, it announced that it will continue to support full ad blocking features for enterprise users.

This time, Google has once again detailed its move and highlighted that instead of completely killing ad blockers on Chrome, the adoption of the new extension API will make them safer for users. The company alleges that while the traditionally used WebRequest API enables extensions to have access to read and manipulate "everything a user does" on the browser, the DeclarativeNetRequest API register rules that limit the access of user information.

Google claims that the WebRequest API requires the Chrome browser to send all the data in network request to the extension, including sensitive data such as photos and emails. This, in the company views, has led to malware activities on the Web. It even mentioned that since January last year, 42 percent of malicious extensions use the WebRequest API.

In addition to giving user data access to extensions, the WebRequest API is also said to have an overall performance impact on browsers and requires serialisation of the request data as well as inter-process communication.

The proposed DeclarativeNetRequest API, on the other hand, is claimed to bring significant performance implications and provide user security and privacy alongside supporting ad blockers.

Google highlights the structural difference between WebRequest API (left) and DeclarativeNetRequest API (right)

"With a declarative approach, Chrome does not need to expose any sensitive data to the extension," writes Simeon Vincent, Developer Advocate for Chrome Extensions, in the blog post. "The browser can perform the action requested by the extension without sending it all the data associated with the network request, because the extension already specified the conditions under which different actions are taken."

Google affirms that the new API doesn't enable extensions to access any sensitive data from Chrome. At the same time, the latest implementation provides extensions the ability to perform content blocking -- but without requiring access to all the user information from a webpage.

Extension developers have criticised the proposal that underlines a complete move to the new API. But Google says that continuing with the old and less secured WebRequest API alongside providing the new and more secured DeclarativeNetRequest API isn't possible. "[H]istorically, when extension developers are given the choice between capability and security, the vast majority of developers choose capability. We've seen this repeatedly on the extensions platform with event pages, optional permissions, and activeTab," says Vincent.

Having said that, the Chrome team at Google is set to retain the WebRequest API for enterprise users but through a blocking version. "The blocking version of the Web Request API remains available for managed extensions because of the deep integrations that enterprises may have between their software suites and Chrome," the developer advocate mentioned.

Developers largely complained about the limit of 30,000 rules under the DeclarativeNetRequest API and urged Google to increase the limit to make it capable of blocking a large number of content elements beyond a certain size and stripping headers from cookies.

Google's Vincent in the blog post underlined that the team is planning to change the rule limit from the maximum 30,000 rules per extension to a global maximum of 150,000 rules. "We are actively exploring other ways to expand this API, including adding methods to get feedback about matched rules, and support for richer redirects leveraging URL manipulation and regular expression," he says.

Google hasn't confirmed any concrete schedule for its Manifest V3 standard that will bring the controversial DeclarativeNetRequest API to the mainstream. However, it seems that before the formal debut, it is set to take the developer feedback into consideration for bringing a neutral experience for extension developers.

Comments

For the latest tech news and reviews, follow Gadgets 360 on X, Facebook, WhatsApp, Threads and Google News. For the latest videos on gadgets and tech, subscribe to our YouTube channel. If you want to know everything about top influencers, follow our in-house Who'sThat360 on Instagram and YouTube.