Google sets burial date for legacy Chrome Extensions, fears for ad-blockers grow

Google this month said Chrome browser extensions written under its Manifest V2 specification will stop working in January 2023.

Thereafter, only Manifest V3 extensions will be supported in Chrome, a change that critics fear will hobble the add-ons and make them little more than toys.

"Years in the making, Manifest V3 is more secure, performant, and privacy-preserving than its predecessor," said David Li, product manager for Chrome extensions and the Chrome Web Store, in a blog post. "It is an evolution of the extension platform that takes into consideration both the changing web landscape and the future of browser extensions."

Li said that as of January 17, 2022, new Manifest V2 extensions will no longer be accepted to the Chrome Web Store (though existing V2 extensions can be updated). And in January 2023, Chrome will no longer run Manifest V2 extensions and no updates to V2 extensions will be allowed. Those operating Chrome under enterprise policies have until June 2023 before V2 stops working.

Despite Google's insistence that this is a good thing, doubts about the renovation plan remain. "Our criticism still stands," said Alexei Miagkov, senior staff technologist at the Electronic Frontier Foundation, told The Register. "The reasons they have stated publicly [for this transition] don't fully make sense."

Working on a fix

The Chocolate Factory began work on Manifest V3, a revised set of APIs available to extension developers, in 2018 to address security and performance concerns. The legacy extension spec, Manifest V2, provided powers that while useful to legitimate developers were also easily misused to create malware.

In early 2019, Raymond Hill, developer of the popular uBlock Origin content blocking extension, took note of the planned API change and warned that Manifest V3, as Google described it, would break uBlock Origin. After that, other developers of popular content blocking and privacy extensions realized they would have to revise their extensions to fit Manifest v3 and perhaps rethink functionality that would no longer be available under the new regime.

With Google telling investors that ad blocking represented a potential threat to its revenue, many assumed the company had ulterior motives for developing Manifest V3 – the elimination of content/ad blocking and privacy extensions under the pretense of safety is something Google's publishing partners would clearly endorse.

However, the ad giant, faced with a backlash from developers and organizations like the EFF, attempted to quell discontent in June 2019 by insisting that its goal with Manifest V3 is not to kill ad blockers but to help developers create better ad blockers.

"In fact, this change is meant to give developers a way to create safer and more performant ad blockers," wrote Simeon Vincent, developer advocate for Chrome Extensions, in a blog post at the time.

A 'blunt instrument'

The message didn't go down so well. A month later, in July 2019, Alexei Miagkov, Jeremy Gillula, and Bennett Cyphers published an EFF blog post that challenged Google's claims about the security benefits of Manifest V3, calling it "a blunt instrument that will do little to improve security while severely limiting future innovation".

The EFF makes an extension for blocking online tracking called Privacy Badger that relies on powerful Manifest V2 APIs like the blocking version of webRequest, which allows the interception and alteration of network data prior to its display in the browser.

Miagkov, Gillula, and Cyphers argued that if Google really wants to improve the security of its Chrome Web Store, it should "start properly enforcing existing Chrome Web Store policies."

But that would require Google to invest in staffing and technical resources to support Chrome Web Store, which developers have described as understaffed and underfunded.

Extension developers are trying to adapt to Google's V3 rules, but there's still uncertainty about whether that will be possible for every affected extension. In July, Hill in a GitHub Issues post for uBlock Origin indicated that declarativeNetRequest, V3's replacement for the blocking version of webRequest, still wasn't adequate. "Summary, latest version of declarativeNetRequest, as per documentation, still breaks dynamic filtering in uBO, due to the inability to implement the noop concept," he wrote.

One of his major concerns is that there's not yet a way to update filter lists with new blocking patterns without republishing the entire extension. In other words, marketers will be able to alter their ad presentation to evade extension-based intervention but extensions will not be able to respond immediately. Hill argues, "having the matching algorithm set in stone in the browser will cripple innovations in content blockers."

In the Chromium Extensions developer forum, one concerned developer responded to the V2 sunset timeline by posting a list of what's said to be unresolved technical issues with V3.

There are also longstanding bugs that haven't been fixed. Miagkov pointed to an issue raised in November 2019 where Service Workers, a replacement for background pages under V2, go to sleep and can't be woken. And there are broader technical arguments that Service Workers are fundamentally unsuitable for many legitimate functions.

"Service Worker-based extensions are Event Pages (persistent: false background pages) made mandatory and with additionally degraded capabilities," wrote Miagkov in a GitHub Issues post at the end of July.

"Some extensions fit the non-persistent/ephemeral model well. Many do not. Requiring all extensions to become non-persistent appears to be a fundamentally extension developer and user hostile requirement. It violates 'user-centered,' 'compatibility,' 'performance' and 'maintainability' design principles."

Not all bad news

The situation isn't entirely grim among those pushing Google for additional revisions to its extension spec. With Microsoft, Mozilla, and even Apple now supporting Manifest V3, a W3C WebExtensions Community Group (WECG) was formed in June.

So there's now a more visible forum than the Chrome Extensions Google Group where developers can go to advocate for improving web extensions. But there's no guarantee griping will alter Google's V3 plans.

Li in his blog post noted Google's interest in working with other browser makers through the WECG and promised further enhancements to V3.

"In the coming months, we'll also be launching support for dynamically configurable content scripts and an in-memory storage option, among other new capabilities," he said.

Miagkov said he wished Mozilla would stand up more for users instead of politely supporting Google's proposals, with a few minor variations. Brave, Opera, and Vivaldi have all said they will try to support the blocking webRequest API that Google is replacing.

Pointing to promised but undelivered capabilities and to longstanding bugs, Miagkov wished Google would be more responsive to developer concerns.

"I'm getting really mixed signals," he said. "Are they serious about this push or are they only serious about enabling toy extensions?" ®

from Hacker News https://ift.tt/3ujNEqs