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.

Advertisement
By Jagmeet Singh | Updated: 13 June 2019 14:15 IST
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 announced Manifest v3 standard for Chrome back in October 2018

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.

Advertisement

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.

Advertisement

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.

Advertisement

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

Advertisement

 

"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.

 

Get your daily dose of tech news, reviews, and insights, in under 80 characters on Gadgets 360 Turbo. Connect with fellow tech lovers on our Forum. Follow us on X, Facebook, WhatsApp, Threads and Google News for instant updates. Catch all the action on our YouTube channel.

Further reading: Google Chrome, Chrome, Google
Advertisement

Related Stories

Popular Mobile Brands
  1. Realme 16 Pro 5G Harry Potter Edition First Impressions
  2. Realme 16 Pro 5G Harry Potter Edition Launched in India
  3. CMF to Become a Standalone Indian Firm, Nothing's Carl Pei Announces
  4. Motorola Signature 27 Launch Date Revealed
  5. Flipkart Big Billion Days Sale Early Deals Announced: What to Expect
  6. OnePlus 16 Design, Colours and Storage Variants Revealed
  7. Samsung Galaxy S26 FE With Exynos 2500 Chip Goes on Sale in India
  8. Vivo X500 Pro Series With MediaTek Dimensity 9600 Pro SoC Debuts: See Price
  1. Vivo Buds Clip With Open-Ear Design, Up to 42 Hours of Battery Launched: Price, Features
  2. Googlebook Render Leaked Again Ahead of Launch; Reveals Slim Profile
  3. Boat Airdopes Prime 800D With Google Gemini-Based Crest AI, Up to 45 Hours of Battery Life Launched in India
  4. Vivo X500 Pro Max, X500 Pro Launched With MediaTek Dimensity 9600 Pro Chipset, Vivo X500 Tags Along: Price, Features
  5. Gmail Adds ‘Copy Code’ Shortcut for Copying Verification Codes on Android and iOS
  6. CMF to Become Indian, Nothing’s Carl Pei Announces While Highlighting India’s ‘Inevitable’ Growth Potential
  7. Samsung Galaxy S26 FE With Exynos 2500 Chip Goes on Sale in India: Price, Offers
  8. WhatsApp May Let You Share Custom Wallpapers and Chat Themes With Others
  9. Vivo Y600K Turbo Surfaces on Google Play Console; Launch Seems Imminent
  10. BGMI Redeem Codes for September 21: How to Get Secret Legacy Backpack and Other Free Rewards
Download Our Apps
Available in Hindi
© Copyright Red Pixels Ventures Limited 2026. All rights reserved.