Google Chrome ad-blocker overhaul plan still sucks – EFF

Analysis The Electronic Frontier Foundation on Tuesday renewed its campaign to convince Google to listen to criticism of the tech goliath’s plan to overhaul its browser extension platform and to make changes while there’s still time.

In the advocacy organization’s latest broadside against Google’s three-year-old extension renovation effort, EFF technologists Alexei Miagkov and Bennett Cyphers take the search biz to task for limiting innovation, crippling capabilities, and hindering performance by forcing Chrome extension developers to adopt a revised set of application programming interfaces (APIs) known as Manifest v3.

“According to Google, Manifest v3 will improve privacy, security and performance,” said Miagkov. “We fundamentally disagree. The changes in Manifest v3 won’t stop malicious extensions, but will hurt innovation, reduce extension capabilities, and harm real world performance.”

For those using Chrome browser extensions, Manifest v3 looks likely to either break popular extensions that rely on Manifest v2 APIs, such as content blocker uBlock Origin and the EFF’s own Privacy Badger, or force developers to rework their extension code to produce a Manifest v3 update that’s less powerful, less capable, and less effective.

The primary reason for this is that a powerful Manifest v2 API known as the blocking version of webRequest – which allows extensions to intercept incoming network data and process/filter it before it gets displayed in the browser – is being replaced by a more limited API known as declarativeNetRequest. And this has obvious implications for extensions that need to intercept data.

Google argued it needs to water down the capabilities of Chrome extensions so that their powers to observe and alter the contents of pages are not so easily abused by bad or hijacked extensions. Doing so limits the abilities of good, trusted extensions, though.

On top of this, there are many more technical changes in Manifest v3 that affect what extensions can do, like the replacement of background pages (processes that persist in the background) with “service workers,” which only run in the background for a limited period of time.

Google maintains that it needs to move from a persistent model to an event-based (where tasks start and stop) to allow Chromium or the host operating system to free up computing resources in order to prevent the end user’s device (particularly a resource-constrained mobile device) from slowing to a crawl due to poorly coded extension.

But Google’s performance claims have been challenged. A 2019 study by Ghostery found the overhead hit imposed by ad blocking extensions is in the sub-millisecond range. “Google’s Manifest V3 is trying to solve a performance issue that does not exist,” the company said last week.

It’s not just high profile extensions related to content blocking and privacy that are being affected. The Google Groups “Chromium Extensions” group is full of developers voicing frustration about functionality that they cannot (or, where alternative Manifest v3 APIs exist, don’t understand how to) replicate under Manifest v3.

For example, a school district administrator posted last month about trying to rewrite his extension under the new APIs and finding that his extension can no longer use geolocation to track lost or stolen devices or monitor battery percentage to know when a battery needs replacement.

More than a few extension developers have voiced their concern to the EFF, such as Krzysztof Modras, director of engineering and product at Ghostery: “Nearly all browser extensions as you know them today will be affected in some way: the more lucky ones will ‘only’ experience problems, some will get crippled, and some will literally cease to exist.”

Many of these issues are filed as bugs. According to Miagkov and Cyphers, observational webRequest, native messaging. background tasks, WebSockets, user script extensions, and WebAssembly are all broken under Manifest v3 presently.

The hope is that Google will fix the bugs and fill in the platform gaps in time, but time is running out. The Chrome Web Store will stop accepting Manifest v2 extensions come January 17, 2022, and plans to disable existing Manifest v2 extensions come January, 2023, though that date may slide: Google developer Devlin Cronin in 2019 said, “We will not remove support for Manifest v2 until we are confident in the platform.”

At the moment, there’s not much confidence in the platform outside of Google and the other major browser makers who like the idea, with some caveats – Apple, Microsoft, and Mozilla.

The EFF has been particularly emphatic about scolding Google over Manifest v3, having only a week ago issued a similar warning.

“Manifest V3, or Mv3 for short, is outright harmful to privacy efforts,” wrote EFF staff technologist Daly Barnett earlier this month. “It will restrict the capabilities of web extensions – especially those that are designed to monitor, modify, and compute alongside the conversation your browser has with the websites you visit. Under the new specifications, extensions like these – like some privacy-protective tracker blockers – will have greatly reduced capabilities.”

Manifest V3 is outright harmful to privacy efforts … Extensions like some privacy-protective tracker blockers will have greatly reduced capabilities

The issue is whether browser extensions will be able to do the same powerful (and potentially abusable) things that native platform code can do. Those opposed to Manifest v3 argue extensions should remain fully functional programming tools rather than being downgraded to toys. And this isn’t simply a technical disagreement of no consequence: the capabilities of Chrome’s web extension platform under Manifest v3 will determine what kinds of businesses can operate there.

“Under Manifest v2, extensions are treated like first-class applications with their own persistent execution environment,” said Miagkov and Cyphers. “But under v3, they are treated like accessories, given limited privileges and only allowed to execute reactively.”

Moreover, the EFF’s repeated harping on this point reflects a sense in the developer community that Google says it listens to community input but fails to translate that input into meaningful changes to its plans. And it also reflects the persistent dominance of Google’s Chrome browser – with close to two-thirds of the global browser market, other browser makers lack the clout to force Google to compromise or consider other points of view.

On top of that, makers of rival browsers like Brave and Microsoft Edge rely on Google’s open-source Chromium project for most of their browser foundation, which limits the extent to which they can push back. And competitors like Apple have shown little interest in competing with Google to shape the technical direction of the web – Apple with Safari and WebKit has focused more on saying no to Google web technology than making the web platform more powerful, for fear of cannibalizing its App Store business.

That leaves Mozilla, which, as the EFF sees it, has failed to resist Google’s plan.

“Instead of following Google into Manifest V3, Mozilla should be fighting tooth and nail against Google’s proposal,” said Miagkov and Cyphers. “It should be absolutely clear that Google acts alone despite overwhelmingly negative community feedback. A proposal cannot become a standard when everyone else stands in opposition. Mozilla’s behavior is obscuring Google’s betrayal of the extensions ecosystem. Moreover, it gives a false sense of competition and consensus when in reality this is one of the prime examples of Google’s market dominance and anti-competitive behavior.”

Mozilla’s position

Asked about this, Mozilla’s director of communications Ellen Canale expressed confusion when presented with the EFF’s criticism.

“We’ve been really clear about our positions on Mv3 and have communicated about those positions early and often,” said Canale. “As we stated then, we want to maintain a degree of compatibility to support easier cross-browser development, while preserving important use cases from Mv2 extensions.

“Since then, we have also proposed a solution to address a major concern with Mv3, which Safari has also adopted. While Google has not accepted this proposal, they did acknowledge the need to address the gaps that exist in their implementation of Mv3. From our actions, it should be clear that while we are implementing some parts of Mv3, we departed from others that are detrimental to our users. Moreover, we constructively collaborate with other browser vendors and the community to shape the design of Mv3 towards one that fulfills the needs of browser vendors, extensions and users.”

It should be clear that while we are implementing some parts of Mv3, we departed from others that are detrimental to our users

Canale said that while all browsers are implementing some form of Mv2, it’s not a standard, and discussion about Google’s choices remain ongoing. She noted that an EFF post published in November offers some suggestions for how to improve Manifest v3 and that the first two suggestions correspond to changes that Mozilla already supports or itself proposed.

Google has taken some steps to acknowledge other viewpoints, most notably joining the W3C’s WebExtensions Community Group (WECG) in June, along with Apple, Microsoft and Mozilla. But Google’s rivals have long complained that the company, due to its size and market power, doesn’t have to respond to input.

In a September post about the problems posed by Manifest v3, AdGuard CTO and co-founder Andrey Meshkov observed about the group, “At the very least it provides a feeling of being listened to and heard, but such things rarely work fast. It’s unclear when we’ll see any real positive changes.”

The Mountain View

For its part, Google – preferring to be paraphrased rather quoted directly – told The Register that the W3C group was formed in June and so it’s premature to judge the impact of discussions. At the same time, the internet giant suggests the group has shined a light on various developer concerns and has led to efforts to look more closely at use cases that require DOM API access in service workers and persistent background processes.

The company maintains that it continues to incorporate developer feedback in the ongoing design of Manifest v3, citing as an example how the declarativeNetRequest API has been adjusted from a limit of 30,000 filtering rules per extension to a minimum of 30,000 rules plus access to a global pool that’s shared across all extensions.

Other examples of APIs modified based on feedback include letting devs decide whether the method scripting.executeScript will inject a script in the extension’s isolated world or in a page’s main world and the introduction of an in-memory storage API called storage.session to preserve data that would otherwise be lost when a service worker shuts down.

To counter the perception that Google has it in for ad blockers, the company pointed to a 2020 blog post containing an endorsement from Sofia Lindberg, tech lead for Eyeo, maker of Adblock Plus: “We’ve been very pleased with the close collaboration established between Google’s Chrome Extensions Team and our own engineering team to ensure that ad-blocking extensions will still be available after Manifest v3 takes effect.”

Eyeo’s Adblock Plus is not quite the same as the open-source uBlock Origin project. It’s made by an advertising company that brokers “acceptable ads.” ®

Source link

Back to top button