Google partly backtracks on ad blocker modifications for Chrome

After harsh criticism, the planned API changes to Chrome and Chromium-based browsers, which would have virtually killed off external ad and tracking blockers, will not come – for the time being.

Chrome-Werbeblocker

Björn GreifEditor

After massive criticism from extension developers, Google has for now moved away from its original plans to make fundamental technical changes to Chrome and all Chromium-based browsers that would have rendered ad blocker and privacy extensions largely useless.

One of the arguments the company used to justify the API modifications was that existing content blocking extensions had a negative impact on browser performance. However, this argument was invalidated by a study by Cliqz, the owner of Ghostery and WhoTracks.me. Only a few hours after its publication, Google developer Devlin Cronin of the Chrome team announced they would backtrack on some planned modifications and make further changes to Manifest V3.

Google's performance argument does not hold

The Cliqz study found that common ad blocker extensions only have a minimal impact on browser performance. The time they need to decide whether or not to block a network request is usually less than a millisecond. This sub-millisecond impact can hardly be called a performance hit.

“From the measurements, we do not think this claim holds, as all popular content blockers are already very efficient and should not incur any noticeable slow-down for users,” write the study authors. “Moreover, the efficiency of content-blockers is continuously improving, either thanks to more innovative approaches or using technologies like WebAssembly to reach native performance.” According to the benchmark results, Ghostery is the fastest ad blocker in comparison with uBlock Origin, Adblock Plus, Brave and DuckDuckGo.

Old webRequest API to be retained for now

Google developer Cronin emphasizes that the exact API changes to Chrome/Chromium that will be implemented as part of Manifest V3 are far from being finalized. He asked the developer community to continue giving feedback on the proposed changes. Cronin also clarified that the old webRequest API is not going to be fully removed as part of Manifest V3. It should – at least for the time being – be kept parallel to the new declarativeNetRequest API.

While Google relaxed some constraints on the declarativeNetRequest API, it seems they still plan to proceed and cripple the old webRequest API. Current browser extensions can use the webRequest API to block requests, which is the prerequisite to block ads and more importantly tracking scripts used to monitor users’ behavior and build personal profiles.

The outcome is still open

Initially, Google had planned to replace the old webRequest API with the new declarativeNetRequest API. This would have brought exactly the application programming interface under Google’s control that ad and tracking blockers need to run efficiently. This would virtually kill off external ad blockers and privacy tools because they would not be able to offer any substantial added value over Google’s built-in technology, which of course does not block Google’s own ads and trackers. In the end, the Internet giant would again have abused its dominant market position.

Although Google has now accommodated the developers of ad and tracking blockers, the final changes to Manifest V3 are still unclear. For example, Google still wants to limit the number of blocking rules that extensions can register for performance reasons. Depending on the level of this upper limit, users might be left with only very limited ways to prevent third parties from intercepting their surfing behavior or to get rid of unwanted content. Not only Chrome users would be affected by this, but also users of Brave, Opera, Vivaldi and future versions of Microsoft Edge, which all build on Chromium. But fortunately, there are still browsers that are not based on Google technology: