As netizens, devs scream bloody murder over Chrome ad-block block, Googlers insist: It's not set in stone (yet)

Analysis Following uproar from developers and netizens over proposed changes to Chrome that threaten to break content and ad blockers, and knacker other browser extensions, Google software engineer Devlin Cronin has offered reassurance that the plans aren't set in stone.

"This design is still in a draft state, and will likely change," he said in a message posted to the Chromium extensions user group.

"Our goal is not to break extensions. We are working with extension developers to strive to keep this breakage to a minimum, while still advancing the platform to enhance security, privacy, and performance for all users."

Cronin stressed that transparency and openness are central to Chromium – the open-source project upon which Google Chrome is built – and that the project welcomes technical input.

Google also issued a follow-up statement suggesting willingness to work with the developer community: "These changes are in the design process, as mentioned in the document and the Chromium bug. We want to make sure all fundamental use cases are still possible with these changes and are working with extension developers to make sure their extensions continue to work."

Google's intent appears to represent an effort to push back against the assumption voiced by some developers that these changes were driven by a desire to protect its ad business from content and ad blocking extensions.

Floating a test balloon

Google first floated the changes in October last year in a blog post describing a plan to make browser extensions more trustworthy. The plan outlined user controls to restrict which sites extensions can access, banning extension developers from using obfuscated code and changing the Chrome extension review process.

Google also announced Manifest v3, a draft revision of its Chrome Extension platform and the source of current developer distress. The company at the time acknowledged the revised specification might require extension developers to rewrite their code, but it insisted any breaking changes "will be worth that effort for all users, developers, and for the long term health of the Chrome extensions ecosystem."

But many developers see Google's plan to improve user privacy and security doing just the opposite. "I believe these changes will prevent numerous security extensions from functioning correctly," said Claudio Guarnieri, senior technologist and researcher at Amnesty International, in a post to the Chromium Extensions discussion group where Cronin asked people to offer input (rather than Chromium's bug tracker).

Manifest v3 describes various changes to the application programming interfaces (APIs) available to developers of Chrome Extensions. The most troubling of these for makers of extensions is the effort to encourage a switch from the webRequest API to the declarativeNetRequest API.

The declarativeNetRequest API is designed as an alternative for webRequest, which is used – among other things – for content blocking applications. Google intends to limit webRequest's ability to manipulate network requests, for the sake of security, performance, and privacy, while offering declarativeNetRequest as the preferred API going forward.

Google's stated reasons for making these changes sound reasonable, even if the consequences may not have been completely thought out. Extensions can pose a security risk and extension developers can get access to more information than necessary.

As the company notes in its Manifest v3 documentation, as of August 2018, 80 per cent of the top 1,000 extensions request access to all domains, allowing them to inject scripts, intercept network requests, and read cookies for any domain. As with phone apps that demand broader-than-necessary permissions, this is a matter of legitimate concern, although not necessarily an indication of bad behavior.

Developers aren't pleased

But the consequence of enhanced security and privacy looks to mean less capable extensions and limitations on the kinds of tools available to browser users. Raymond Hill creator of uBlock Origin called attention to problems with the Manifest v3 proposal by warning that his extensions won't work under the more limited API.

Following Hill's complaint, others made their concerns known through the Chromium extensions user group. Daniel Glazman, co-CTO and veep of engineering at Privowny, said the proposed changes would drastically affect his company's software.

The declarativeNetRequest API does not (as presently drafted) allow extensions to modify network requests as the webRequest API does. It can only block or redirect requests, which makes content blockers much less capable. It also limits the number of rules that can be applied to process network requests to 30,000.

That may be sufficient for an extension like Adblock Plus that relies on a fairly limited filter list, but it falls short for more ambitious extensions. Stefano Traverso, CTO of Ermes Cyber Security, said some anti-phishing lists contain millions of entries.

For what it's worth, Adblock Plus uses a filter list with more than 70,000 entries, twice that of the proposed API limit. And while this means Adblock Plus will be affected to some degree by the suggested changes, which has irritated its makers, other extensions, such as the more advanced uBlock Origin, that do more than apply a simple filter list will be hit harder by the API overhaul.

Cronin acknowledges the tightening of access will upset some developers. "I certainly understand that there are a number of concerns around limiting the power of the webRequest API in favor of a declarative API – it is much more restrictive, and doesn't offer the flexibility the webRequest API does," he wrote in a post to the discussion group.

But there's more to it than one API change. Manifest v3 includes a variety of other changes that will affect extension developers. For example, it directs developers to replace background pages, by which extensions could run code in the background, with a more modern background process API called Service Workers, a change that Glazman says will mean months of work for his company.

He warns that Mozilla and Apple in the past both took steps that harmed their extension ecosystems with ill-advised changes. And he said the WebExtensions API isn't managed like a web standard and should be, noting that Microsoft's effort to address standardization through a W3C Community Group failed miserably.

"I urge Google to resurrect a real and active standardization effort around WebExtensions," he said.

"This is the only part of the browser space that is not handled that way, and we clearly see today with the v3 proposal that it is not workable for third-party implementers any more. We just cannot cope with deep changes of high magnitude in a timely manner. The financial impact of the proposed changed on extension vendors is vastly underestimated (if estimated at all), and that alone should be a showstopper signal from a strategic point of view." ®