Google is currently in the process of updating the API used by Chrome extensions. This isn't something that typical users would have cared much about, until extension developers pointed out that one of the proposed changes could prevent many content blockers (including uBlock Origin) from functioning. While Google hasn't completely backtracked from its plans, it has made concessions amidst public outcry and legal threats.
First, a bit of backstory — the current API level for Chrome extensions, called 'Manifest V2,' was introduced in 2012. Since then, Chrome has been subject time and time again to malicious extensions. With Manifest V3, currently under development, Google hopes to reduce the possible damage that malicious extensions could do, while also increasing performance and adding new features.
One of the proposed changes is a new declarativeNetRequest API, designed to replace the webRequest API that many extensions (including AdBlock Plus and uBlock Origin) currently use. Simply put, instead of extensions doing the network filtering themselves, they would provide a filter list that Chrome itself would parse. In the Manifest V3 design document, Google claims the current API can have a "significant effect" on browser performance:
On the surface, it seems completely reasonable that sending every network request to an extension and pausing the browser until the extension sends a response would slow down performance. Cliqz, the company behind the popular Ghostery browser extension, decided to perform a study of the real-world performance impact of ad blockers, and the results didn't quite line up with what Google stated.
(Image credit: ZDNet)
The study performed by Cliqz showed that the average performance impact across popular ad blockers — including Ghostery, uBlock Origin, and AdBlock Plus — was often less than 0.05 milliseconds. While the design document did say that the existing API could only "potentially" slow down Chrome, in practice, it's not something that the average user would encounter.
Ghostery/Cliqz previously made its distaste for the proposed API changes well known. In a blog post, the company wrote, "They pretend to do this for the sake of privacy and browser performance, however in reality, users would be left with only very limited ways to prevent third parties from intercepting their surfing behavior or to get rid of unwanted content. Whether Google does this to protect their advertising business or simply to force its own rules on everyone else, it would be nothing less than another case of misuse of its market-dominating position. If this comes true, we will consider filing an anti-trust complaint."
In response to the outcry from both developers and users, Chrome engineer Devlin Cronin wrote on Google Groups that new features are being added to the replacement API:
I’d like to reiterate that all of these changes are still in the draft and design stage, as explicitly called out in the document and the tracking bug. The declarativeNetRequest API is still being expanded and is under active development, and the exact changes that will be implemented as part of Manifest V3 are not finalized. Feedback during this time is crucial, and we absolutely want to hear your comments and concerns.
Another clarification is that the webRequest API is not going to be fully removed as part of Manifest V3. In particular, there are currently no planned changes to the observational capabilities of webRequest (i.e., anything that does not modify the request). We are also continually listening to and evaluating the feedback we’re receiving, and we are still narrowing down proposed changes to the webRequest API.
The forum post also outlines other changes being made to the proposal based on developer feedback, such as adding dynamic rule support to the upcoming declarativeNetRequest API and increasing the maximum ruleset size. In summary, the old API will still eventually stop being able to block network requests, but Google has relaxed some of the limitations for the new API.
This post previously stated that Google had completely backtracked on the proposed changes, but that is not true. The webRequest API will still eventually lose its ability to block network requests, under current plans. The text has been corrected.