Google has said that it will revise the proposed changes to Chrome’s extension API that would have broken or reduced the functionality of a wide range of ad-blocking extensions, to ensure that the current variety of content-blocking extensions is preserved. The initial plans generated a wide backlash from both the developers and users of those extensions, but Google maintains that “It is not, nor has it ever been, our goal to prevent or break content blocking” [emphasis Google’s] and says that it will work to update its proposal to address the capability gaps and pain points.
The advertising company is planning an overhaul of its extension interface to, among other things, increase user privacy, make it harder for extensions to perform malicious actions, and make the browser’s performance more consistent. Together, this work is documented as Manifest V3.
One of these changes in particular had grave consequences for ad blockers. Currently, ad blockers make extensive use of an API named webRequest. This API allows extensions to examine every single network request made by a page and either modify it (to, for example, redirect it to a different address or add or remove cookies), block it altogether, or allow it to continue unhindered. This has both a substantial privacy impact (an extension can see and steal your cookies and hence masquerade as you) and, Google said, some performance impact, as every single network request (of which there may be dozens in a single page) has to wait for the extension to perform its analysis.
Google was proposing that instead, ad blockers could provide the browser with a list of blocked sites and have the browser itself perform the blocking, using a new API called declarativeNetRequest. This prevented the use of more complex algorithms, and the size of this list was capped at 30,000 entries—far fewer than many ad blockers typically use.
The change would have gutted many ad blockers, along with other legitimate extensions using the same API. For example, there are extensions that block phishing sites or URLs known to be distributing malware. Though their purpose is different, they function in the same way as ad blockers and were similarly threatened by the proposed changes.
Performance not always a problem
Developers of the Ghostery extension put together some benchmarks that measured the overheads imposed by a few ad-blocking extensions. The benchmarks didn’t test full extension but instead used the extensions’ request-blocking engines running inside the Node.js JavaScript runtime, measuring the performance of nearly a quarter of a million requests, of which about 20 percent were blocked.
The results show that while some blockers can introduce a meaningful performance delay—a version of the DuckDuckGo blocker had a median delay of 8 milliseconds—the overheads from Ghostery, uBlock Origin, and Adblock Plus were negligible, all coming in at well under a tenth of a millisecond. As such, while Google’s performance rationale is not without merit, blocking all such extensions because some perform poorly feels heavy-handed—though other concerns with the current extension platform, such as privacy, remain.
Google’s response to the pushback makes some concessions to the developers, though it’s far from a complete reversal. The company does still intend to limit the webRequest API and does still want extensions to switch to declarativeNetRequest. However, both of these API alterations are works in progress. The new declarativeNetRequest is going to have its capabilities beefed up; extensions will be able to use dynamic blocklists (where blacklisted URLs are added and removed at runtime), and the overall blocklist size is going to be increased from 30,000 (though Google maintains that there will be some limit, and that blockers should strive to remove stale URLs from their block lists).
Google also intends to allow more flexible blocking criteria such as resource size and is investigating ways to permit modification of requests. But its response also notes that some of the modifications that extensions performed can be made using other APIs and as such don’t need to be part of declarativeNetRequest and aren’t grounds for retaining the current webRequest API.
The company also underscored that Manifest V3 remains a work in progress and that even when Manifest V3 goes into production, there will be a transition period. The current Manifest V2 platform won’t be removed until Manifest V3 is good enough. As things stand, it looks like the extension developers still won’t be able to do everything that they can currently do with webRequest, but they will be able to cover more of their bases than the initial proposal permitted.
https://arstechnica.com/?p=1458443