Google has proposed changes to its Chrome Extension renovation plan that answer some but not all of the concerns its Manifest v3 technical specification.
The initial changes, announced in October last year, set off alarm bells last month when a critical mass of Chrome plugin developers finally realized what Google intended.
The Manifest v3 changes represent an attempt to address real issues for users of the Chrome browser, specifically the security and performance implications of third-party code that has access to sensitive data.
But the fixes Google initially suggested have broad implications. The Manifest v3 specification would break content and ad blockers, privacy extensions, and a host of other browser add-on code that relies on the ability to intercept requested web content before it gets rendered in the browser.
Much of the angst arises from planned changes to the
webRequest API, through which Chrome extensions handle incoming web content; Google wants to limit the API and replace it with a neutered version, the
The trouble is that as initially outlined,
declarativeNetRequest is far too limited to accommodate current use cases. If implemented, existing extensions like uBlock Origin will have to be rewritten and won't have the same functionality regardless.
Other technical changes have been floated that represent potential problems for existing code, like changes to background pages, but
declarativeNetRequest represents the major sticking point.
On Friday, Google software engineer Devlin Cronin published an update on Google's plans, insisting that there's too much abuse to maintain the status quo.
As netizens, devs scream bloody murder over Chrome ad-block block, Googlers insist: It's not set in stone (yet)READ MORE
"Users need to have greater control over the data their extensions can access," he wrote in a message posted to the Chromium Extensions discussion group.
At the same time, he reiterated Google's interest in input from the developer community and offered evidence that Google is listening by outlining a less awful version of the
The tweaked spec will include support for dynamic rules – which content blockers formulate based on incoming content rather than declaring them ahead of time. "We agree that this is valuable in creating sophisticated content blocking extensions, and will be adding support for declarative rules that can be added or removed at runtime to the
declarativeNetRequest API," Cronin said.
The API will also be able to handle more than 30,000 rules, though how many isn't clear. Cronin insists the number cannot be unbounded to ensure adequate performance. And it will include expanded matching capabilities – necessary for effective filtering – and some request modification capabilities, like the ability to strip cookies.
"We are also investigating other conditions and actions that may make sense to add, such as matching based on top-level domain," said Cronin.
Other potential issues, like the difficulty of using ServiceWorkers as a replacement for persistent background pages to handle resource-intensive background processes like decryption and DOM parsing, are also being evaluated.
"We won’t launch Manifest V3 until it is ready, and there will be a migration period in which we can continue to address feedback and issues," said Cronin. "We will not remove support for Manifest V2 until we are confident in the platform." ®