Google Argues That It's Chrome API Changes are Good for Browser Extension Developers

Google's plan to limit developers' access to the Chrome API browser extensions which is commonly used to perform ad blocking and push them to use a new API sparked a developer firestorm. In response, Google engineers altered their plans slightly. Instead of limiting the Web Request API universally, they announced that the full API would remain available to paying enterprise Chrome users.

Not surprisingly, that failed to appease the developer community, so Google is making an effort to better explain its rationale for the changes being made.

In a blog post, Google's Devlin Cronin, a member of the Chrome Extensions Team, stated that the Chrome team is not killing off ad blockers but rather "making them safer." He revealed that efforts to improve the security, privacy, and performance of Chrome browser extensions, which include a 300% expansion of the size of the team that deals with extension abuse, have reduced malicious installations by 89%.

Cronin explained that the move away from the Web Request API to the Declarative Net Request API is part of a broader push to rethink how the most powerful Chrome APIs work. "Instead of a user granting each extension access to all of their sensitive data, we are creating ways for developers to request access to only the data they need to accomplish the same functionality," he wrote.

"At a high level, this change means that an extension does not need access to all a user’s sensitive data in order to block content. With the current Web Request API, users grant permission for Chrome to pass all information about a network request - which can include things like emails, photos, or other private information - to the extension. In contrast, the Declarative Net Request API allows extensions to block content without requiring the user to grant access to any sensitive information."

In a separate blog post, Simeon Vincent, Google's Developer Advocate for Chrome Extensions, provided a more detailed technical explanation. In addition to the security and privacy weaknesses of the Web Request API, which Vincent noted was used by 42% of malicious extensions identified since 2018, he laid out an argument that the new Declarative Net Request API is far more efficient.

"As it’s designed today, the blocking version of the Web Request API requires a persistent, long-running process, and is fundamentally incompatible with 'lazy' processes - processes that can be set up or torn down as-needed, conserving valuable system resources," he wrote. "The Declarative Net Request API works differently than the Web Request API. Instead of Chrome sending all the information about a request to the listening extensions at the time of the request, extensions register rules that tell Chrome what to do if certain types of requests are seen."

According to Vincent, the performance gains from using the Declarative Net Request API are "significant" and the API will aid in making browser extensions viable on Resource-constrained platforms.

All of this said, Vincent noted that Google is listening to developer concerns and highlighted a number of modifications and additions being made to the Declarative Net Request API based on feedback received from developers. For instance, the API has been updated to support the dynamic addition of rules at runtime, eliminating the need for developers to register their rules beforehand as part of their extensions' manifests.

Beyond words, Google has reportedly also created its own ad blocker extension to test the performance improvements delivered by the use of the new API over the Web Request API.

Is it Enough?

The question is whether or not Google's explanations and changes will change the perceptions of those within the developer community who believe that the limits being placed on the Web Request API are motivated by Google's desire to protect its own interests, namely its massive advertising business that is obviously threatened by the rise of ad blocking software.

In a Hacker News discussion, some argued that Google's approach makes technical sense and won't affect end users, and even pointed out that the number of rules permitted by the Declarative Net Request API is higher than the number permitted by Apple in the Safari API its ad blockers are implemented with.

Even so, it appears that substantial skepticism remains. The Declarative Net Request API is "an objectively less powerful API that does very little to improve privacy for the sake of performance improvements that aren't necessary," one commenter suggested.

Time will tell us at some point, the impact of the new API, or lack thereof, should become evident.

In the meantime, it is clear is that while Google might continue to refine its changes, it will not reverse course. Put simply, the Declarative Net Request API is here to stay and developers who want to continue building and maintaining extensions that previously relied on the Web Request API will with limited exceptions need to embrace the new API.

What isn't clear is how Google's handling of this matter might affect ongoing antitrust investigations. Worth considering: Microsoft's handling of its Internet Explorer browser played a prominent role in the antitrust charges it fought nearly two decades ago and it seems like that the narrative being presented by critics of Google's Chrome API changes -- that Google is taking away developers' ability to create ad blockers in an effort to protect its ad business -- isn't helpful at this critical juncture in the company's history.

Be sure to read the next Browsers article: Microsoft Announces Updated WebView 2 SDK for Edge