[ad_1]
Google is updating the API used by Chrome extensions. This is not something that users are very concerned about until extensions developers point out that one of the proposed changes might prevent many content blockers (including uBlock Origin) from working. Although Google has not completely returned to its plans, it has made concessions despite the outcry and legal threats.
First, a bit of background: The current level of the API for Chrome extensions, called "Manifest V2", was introduced in 2012. Since then, Chrome has been subjected to many malicious extensions. With Manifest V3, under development, Google hopes to reduce the damage that could be caused by malicious extensions, while increasing performance and adding new features.
One of the proposed changes is a new declarativeNetRequest API, designed to replace the webRequest API used by many extensions (including AdBlock Plus and uBlock Origin). In other words, instead of the extensions filtering themselves on the network, they provide a list of filters that Chrome itself would analyze. In the Manifest V3 design document, Google claims that the current API can have a "significant effect" on browser performance:
The basic flow is as follows: when a network request starts, Chrome sends information about it to the interested extensions and the extensions respond to the action to take. This starts in the browser process, involves a process jump in the rendering process of the extension, where the extension then executes arbitrary (and potentially very slow) JavaScript code and returns the result to the browser process. This can have a significant effect on every network request, even those that are not modified, redirected or blocked by the extension (because Chrome has to send the event to the extension to determine the result).
In appearance, it seems quite reasonable that sending each network request to a post and suspending the browser until the post sends a response will slow down performance. Cliqz, the company behind the popular Ghostery browser extension, decided to do a study of the actual impact of ad blockers on performance, and the results do not quite match those of Google .
The company told ZDNet: "This work was motivated by one of the claims made in the Chromium Project's Manifest V3 proposal:" The extension then executes arbitrary (and potentially very slow) JavaScript code. " , which discusses the processing capacity of content blockers, which we believe is not valid because all current content blockers are already very effective and should not cause significant slowdowns from users. "
(Image credit: ZDNet)
The study by Cliqz showed that the average impact on the performance of popular ad blockers – including Ghostery, uBlock Origin, and AdBlock Plus – was often less than 0.05 millisecond. Although the design document indicates that the existing API can only "potentially" slow down Chrome, in practice this is not something that the average user would encounter.
Ghostery / Cliqz had already made known his aversion to the proposed changes to the API. In a blog post, the company wrote: "They claim to do so for reasons of privacy and browser performance, but in reality, users would have only very limited means to prevent third parties from intercepting it. their surfing behavior or getting rid of Whether it is to protect their advertising business or simply to impose its own rules on all others, Google would constitute nothing less than another case of misuse of its leading position on the market, an anti-trust complaint ".
Devlin Cronin, an engineer at Chrome, reacted to the outcry from developers and users: he added that new features were added to the replacement API:
I would like to reiterate that all these changes are still in draft and design state, as stated explicitly in the document and tracking bug. The declarativeNetRequest API is still being expanded and is currently under active development. The exact changes that will be implemented in Manifest V3 are not finalized. Reactions during this time are crucial and we are very interested in hearing your comments and concerns.
Another clarification is that the webRequest API will not be completely removed as part of Manifest V3. In particular, there is currently no planned modification of the webRequest observation features (that is, anything that does not change the request). We are constantly listening to and evaluating feedback we receive and we continue to limit the proposed changes to the webRequest API.
The forum message also describes other changes to the proposal based on developer feedback, such as adding dynamic rule support to the next declarativeNetRequest API and increasing the maximum size of the ruleset. In summary, the old API will always end up being unable to block network requests, but Google has relaxed some of the limitations imposed on the new API.
Source link
