Google Chrome May Block Ad Blockers: What This Means for You

UPDATED with comment from Google.

Google is moving ahead with a rule change for Chrome browser extensions that would deactivate many ad blockers and other content blockers, including parental-control extensions and malicious-website screeners. But not all blockers will be affected, and the earliest the rule would go into effect would be this fall.

Credit: Shutterstock

(Image credit: Shutterstock)

In a posting last week to a Chrome/Chromium developer discussion board, Simeon Vincent, developer advocate for Chrome extensions at Google, said that Google would indeed restrict the functions of an application-program interface (API) function called webRequest in Manifest V3, the third version of the declaration, or manifest, that all Chrome extensions must present to the browser to explain what they do.

Manifest V3 is expected to come into force this fall at the earliest, after which only enterprise deployments of Chrome (i.e., versions deployed in-house by large companies and organizations) will be able to fully use the webRequest API to block content.

What you can do to keep ad blockers working

If Google does eventually neuter many ad blockers with this move, there are plenty of other browsers that share the same Chromium codebase, will not be affected by Google's decision and for which ad-blocking extensions are available.

Among them are Brave and the most recent versions of Opera, which come with their own ad blockers; Vivaldi, a fairly new browser from Opera's creators; beta versions of Microsoft Edge, including one for macOS; and Chromium itself, which Google doesn't offer as a precompiled package but which can be downloaded from third-party sites such as https://chromium.woolyss.com/.

Of course, there's always Firefox, which uses a different browser layout and has strong ad-blocking extensions available, and Safari for macOS, which has fewer ad-blocking offerings.

MORE: Best Google Chrome Privacy Extensions

The implementation of the new rules would effectively negate extensions such as uBlock Origin and the Electronic Frontier Foundation's Privacy Badger, both of which use the webRequest API to block ads and other content before it even reaches the browser. Google wants extensions to instead use a different API called declarativeNetRequest, which lets Chrome decide whether to block content based on a set of up to 30,000 rules.

Google's argument is that the extensions using the webRequest API slow performance because the browser has to wait for the extensions to decide whether to display content. declarativeNetRequest is arguably faster because the browser can start loading content while it decides what to block.

"Currently, with the webRequest permission, an extension can delay a request for an arbitrary amount of time, since Chrome needs to wait for the result from the extension in order to continue processing the request," states Google's current draft of Manifest V3. "This can have a significant effect on every single network request."

One of the best-known ad blockers, AdBlock Plus, already use rules to block ads and should have little trouble adjusting to declarativeNetRequest. But AdBlock Plus is widely seen as less effective than some other ad blockers. So is Chrome's built-in ad blocker, which blocks only ads that Google finds too obtrusive or annoying.

Is it all about the money?

Raymond Hill, developer of uBlock Origin, argues that Google, a dominant player in the online ad market, is making this change so that more ads show up in Chrome.

"Google strategy has been to find the optimal point between the two goals of growing the user base of Google Chrome and preventing content blockers from harming its business," Hill wrote this past Sunday (May 26) in a GitHub discussion forum. "The blocking ability of the webRequest API caused Google to yield control of content blocking to content blockers. Now that Google Chrome is the dominant browser, it is in a better position to shift the optimal point between the two goals which benefits Google's primary business."

Eva Galperin, director of cybersecurity at the EFF, summed of the feelings of many Twitter users following this news: "This is a really disappointing decision by Google. I will be switching to Firefox."

Your correspondent is a bit bummed because his favorite Chrome extension, ScriptSafe, does indeed seem to use the webRequest API to work its magic. We've asked the developer of ScriptSafe for clarification.

UPDATE: Google reached out to us and provided this comment: "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."

Paul Wagenseil

Paul Wagenseil is a senior editor at Tom's Guide focused on security and privacy. He has also been a dishwasher, fry cook, long-haul driver, code monkey and video editor. He's been rooting around in the information-security space for more than 15 years at FoxNews.com, SecurityNewsDaily, TechNewsDaily and Tom's Guide, has presented talks at the ShmooCon, DerbyCon and BSides Las Vegas hacker conferences, shown up in random TV news spots and even moderated a panel discussion at the CEDIA home-technology conference. You can follow his rants on Twitter at @snd_wagenseil.