Google has now taken to its official blog with an in-depth look at exactly why its much-debated Manifest V3 changes are really needed, highlighting severe privacy issues as well as disruptions to performance and how those can be fixed.
The biggest change in question is the proposed shift away from Web Request API completely, with developers being required to rely on Declarative Net Request instead. Google has addressed the matter in previous public discussions directly with developers, providing a vague overview of why changes are really needed. Now, Google is laying out its concerns in detail.
Current iterations of ad-blocking extensions are fundamentally reliant on Web Request API, Google says that the negative impacts of the API are not a good tradeoff for the removal of some advertisements. In direct contrast to widespread reports and developer claims that the search giant is seeking to gain greater control so that its own ads can be served without interference, the biggest concern is data privacy.
Why break ad blockers?
While ad blockers are often utilized to prevent cross-site tracking as well as to bolster page performance on ad-heavy websites, Google says that the API behind the tools has been abused. In fact, the API effectively provides extension the user has enabled that are utilizing Web Request to both read and modify everything a user does or accesses in Chrome.
Summarizing why that is, Google’s example image shows that when a user clicks a link while such an extension is active, the request is sent to the extension first. The extension can read and modify the request before sending it through to the server. The server responds and then passes off to the extension again, allowing further reading and modification. All of that happens before the page is rendered and then sent through to the user.
As many as 42% of bad extensions have used the API to malicious ends since January of last year.
By contrast, Declarative Net Request API starts at the extension, with a set of rules to look for after the user clicks a given link and an expected response to certain requests from the server. The initial version of the API limits the number of rules per extension to a global maximum of 150k rules.
After the click, the browser checks the request against that set of rules and applies requested programmed-in changes based on those. The changes are implemented after being passed to and from the server prior to rendering for consumption by the user.
The company has recently added the ability to register and remove dynamic rules that can be specified at runtime rather than just in the manifest, opening capabilities up to suit a much broader variety of needs without compromising the end user. The capability to remove common tracking headers, such as Referer, Cookie, and Set-Cookie have been added too, to prevent some other functionality from being completely broken.
In short, the tool should still work for ad-blocking, albeit through different methods and in a somewhat limited fashion to begin with but further expansions are being explored to make everything even better.
What else does this fix and why the discrepancy between consumers and enterprise?
Some of the speculation surrounding Google’s impending changes for extensions has centered on concerns that Google may be attempting to make some of its Chrome features available only to paid users. Namely, those would be users who have subscribed to enterprise-level services.
The speculation has stemmed from the fact that the original API will, to a certain extent, still be available to schools, businesses, and others in that category. The search giant says that decision is based on the needs of enterprise consumers as compared to the general user base and developers.
While general consumers are free to use their web browser essentially however they like, users in those environments are often required to follow a set of rules and policies put in place by administrators. The new API simply doesn’t allow for that level of control by an administrator and removing access could potentially break the enterprise environment itself in many cases, the company explains.
At the same time and while not common, extensions can impact performance negatively. The performance hits don’t necessarily stem from the extensions themselves but from other code that is interacting with the extension. When it comes to lazy loading, the API is all but completely incompatible.
Lazy loading is a newer feature Google is working to add to ensure that content loads as it is needed instead of all at once — significantly reducing data use and resources required at loading. That secondary impact on the overall performance of Chrome affects future improvements to the browser itself.
