Chrome ad-blocker crackdown preview due late July. Here's a half-dozen reasons why add-on devs are still upset

Canary channel will let programmers experience tough new limits on extensions

Analysis An early version of Manifest v3 – Google's controversial revision of Chrome's extensions system that will affect ad and content blockers – should appear in about a month.

Add-on developers remain concerned the internet advertising giant will remove too much utility from their extensions in the name of performance, privacy, and security.

"Manifest V3 is not yet ready for experimentation and feedback," said developer advocate Simeon Vincent in a Google Groups discussion thread on Thursday. "The extensions team is currently working towards releasing a Developer Preview in the Canary channel at the end of July or beginning of August. We'll be sharing additional details when that lands."

He added that determined devs can try a half-baked version by manually building the master branch of the Chromium source code repository. But doing so means foregoing guidance or support, and puzzling through the source line by line to figure out what's going on.

Vincent was responding to a series of concerns raised by developers following Google's mini PR blitz last week. He attempted to allay fears that the API revisions planned for the Chrome extensions platform since last October will cripple or degrade content blockers, privacy extensions, and other browser add-on tools.

The controversy centers around the planned removal of the blocking (synchronous) version of the webRequest API, which can intercept, alter or nix incoming network traffic before it gets displayed by the browser – a crucial intervention for content blocking and privacy applications. Ad blockers, for example, use it to detect and halt any requests to display unwanted ads or tracker scripts.

However, Googlers toiling away on Manifest v3, an ongoing work-in-progress project, are also contemplating many other changes that affect the power and scope of Chrome extensions.

For example, the planned replacement for webRequest, declarativeNetRequest, allows a set number of pattern matching rules for detecting and taking action on request traffic. Extensions are expected to use the new interface to provide rules that Chrome uses to identify and act on traffic, rather than trusting each add-on to do the interception and blocking.

Currently, the preset rule limit is 30,000 static rules and 5,000 dynamic rules, dynamic rules being far more useful for content blocking.

Last week, Vincent said, "we are currently planning to change the rule limit from maximum of 30k rules per extension to a global maximum of 150k rules." But as he confirmed in his post on Thursday, "Chrome will have a global maximum of 150k rules shared among all extensions."

That may sound like a lot, but as HTTPS Everywhere developer William Budington observed, HTTPS Everywhere is aware of more than 157K target sites. Under Google's shared model, using one extension with a lot of rules would preclude using other rule-heavy extensions.

Vincent attempted to reassure Budington by noting that the limit is probably not final. "We are still analyzing what the real-world performance cost is at different rule set sizes," he said, without addressing the fact that dynamic rules are far more useful that fixed ones.

Performance is not a problem

Of the three rationales Google engineers have cited for the change, performance has been the least convincing. Vincent has argued that the overall performance impact of Chrome extensions "can be very large, even for an extension written as performantly as possible where the JavaScript execution time is negligible."

Google Chrome security engineer Chris Palmer echoed that claim in the discussion thread, insisting: "The performance concern is real." He pointed to the resource cost of storing a large number of rules in a persistent browser or network service process, and to the delays imposed by waiting for synchronous calls to resolve.

While it's certainly conceivable that a poorly coded extension could tie things up, leading to a poor user experience, extension developers remain skeptical that such delays are unavoidable.

The release of an open-source tool called Exthouse for measuring extension-induced slowdowns this week has only added to that skepticism. Though Exthouse indicates that Adblock Plus has a performance impact, it also shows uBlock Origin adds exactly no delay in two interactivity metrics, Time to Interactive and First Input Delay. This underscores claims by developers of content blockers that their extensions actually improve performance by eliminating ad tracking code on webpages.

Vincent acknowledged that Google's official blog posts on Manifest v3 had skimped on the performance issues and said he hoped to provide more details about this soon. The issue isn't so much the execution time of blocking (synchronous) webRequest callbacks, he said. Rather it's the overall cost of processing a request in Chrome.

"With the blocking version of webRequest, Chrome has to serialize a lot of data (the request itself and request metadata, etc.) and send it to each extension," he said. "This results in significant costs from type conversions, copies, interprocess communication, (de)serialization, etc. for each listening extension (which are usually in separate processes)."

At the same time, Vincent acknowledged performance was not the primary motivation for Manifest v3. Rather, Google's main concern is "to improve the privacy and security of request modification and to reduce the attack surface for malicious extensions." To be blunt, Googlers really aren't comfortable with the idea of gone-rogue extensions manipulating and eavesdropping on users' network traffic.

A scary monster

Why are fervid Googlers making ad-blocker-breaking changes to Chrome? Because they created a monster – and are fighting to secure it


And so, with regard to improving privacy, what Google is doing appears to be more along the lines of improving privacy options. The privacy issues raised by webRequest won't go away because while developers won't be able to intercept requests without the blocking method, they will still be able to request permission to observe network requests. The main privacy gain, as Palmer describes it, is that developers will be able to "write an extension using Declarative Net Request to block content without necessarily getting the power to passively monitor requests and page content."

The extension might implement additional APIs that require host permissions, he explains, but the process of granting those will require more explicit permission from users.

And finally...

That leaves security. And as we've reported, there's a real issue with Chrome extension security, though one that might be addressed in ways other than broad API changes, such as tighter developer vetting, hiring extension security inspectors, stricter Chrome Web Store policy enforcement, or security audits.

"In rethinking how we approach the extensions platform, one of the goals we're trying to achieve is to enable extensions to do what they do today, but in ways that don't compromise the user's privacy," explains Vincent. "Broadly speaking, the declarativeNetRequest (DNR) API fits into this mold by giving extensions a way to modify requests without exposing the request object to the extension or (as much as possible) without requiring the extension to have host permissions to modify requests."

Vincent claims that, in theory, a content blocker implemented with Manifest v3 could match the results of its Manifest v2 counterpart, but without any risk of data theft.

Yet in the very next line of his post, he acknowledges that webRequest in its current form is indispensable. Why keep the blocking version of webRequest around for enterprise users if it's so dangerous?

"First, because it gives extensions an important capabilities that can't be replicated with a more secure API," says Vincent. "Second, the risks around webRequest can be mitigated by increasing the friction of getting (and keeping) host permissions."

He goes on to acknowledge declarativeNetRequest cannot do everything webRequest can. "From the Chrome team's perspective this change and others combine to close off an entire class of exploits," he said. "[Declarative Net Request] isn't a perfect tradeoff, but we strongly believe the privacy guarantees it brings outweigh the loss of capabilities. That said, we want to enable content blockers and request modifying extensions as much as we can without exposing too much data or empowering malicious actors."

In short, web ad and content blockers, and other Chrome extensions, will be made less capable – for your protection. ®

Other stories you might like

  • Florida's content-moderation law kept on ice, likely unconstitutional, court says
    So cool you're into free speech because that includes taking down misinformation

    While the US Supreme Court considers an emergency petition to reinstate a preliminary injunction against Texas' social media law HB 20, the US Eleventh Circuit Court of Appeals on Monday partially upheld a similar injunction against Florida's social media law, SB 7072.

    Both Florida and Texas last year passed laws that impose content moderation restrictions, editorial disclosure obligations, and user-data access requirements on large online social networks. The Republican governors of both states justified the laws by claiming that social media sites have been trying to censor conservative voices, an allegation that has not been supported by evidence.

    Multiple studies addressing this issue say right-wing folk aren't being censored. They have found that social media sites try to take down or block misinformation, which researchers say is more common from right-leaning sources.

    Continue reading
  • US-APAC trade deal leaves out Taiwan, military defense not ruled out
    All fun and games until the chip factories are in the crosshairs

    US President Joe Biden has heralded an Indo-Pacific trade deal signed by several nations that do not include Taiwan. At the same time, Biden warned China that America would help defend Taiwan from attack; it is home to a critical slice of the global chip industry, after all. 

    The agreement, known as the Indo-Pacific Economic Framework (IPEF), is still in its infancy, with today's announcement enabling the United States and the other 12 participating countries to begin negotiating "rules of the road that ensure [US businesses] can compete in the Indo-Pacific," the White House said. 

    Along with America, other IPEF signatories are Australia, Brunei, India, Indonesia, Japan, South Korea, Malaysia, New Zealand, the Philippines, Singapore, Thailand and Vietnam. Combined, the White House said, the 13 countries participating in the IPEF make up 40 percent of the global economy. 

    Continue reading
  • 381,000-plus Kubernetes API servers 'exposed to internet'
    Firewall isn't a made-up word from the Hackers movie, people

    A large number of servers running the Kubernetes API have been left exposed to the internet, which is not great: they're potentially vulnerable to abuse.

    Nonprofit security organization The Shadowserver Foundation recently scanned 454,729 systems hosting the popular open-source platform for managing and orchestrating containers, finding that more than 381,645 – or about 84 percent – are accessible via the internet to varying degrees thus providing a cracked door into a corporate network.

    "While this does not mean that these instances are fully open or vulnerable to an attack, it is likely that this level of access was not intended and these instances are an unnecessarily exposed attack surface," Shadowserver's team stressed in a write-up. "They also allow for information leakage on version and build."

    Continue reading
  • A peek into Gigabyte's GPU Arm for AI, HPC shops
    High-performance platform choices are going beyond the ubiquitous x86 standard

    Arm-based servers continue to gain momentum with Gigabyte Technology introducing a system based on Ampere's Altra processors paired with Nvidia A100 GPUs, aimed at demanding workloads such as AI training and high-performance compute (HPC) applications.

    The G492-PD0 runs either an Ampere Altra or Altra Max processor, the latter delivering 128 64-bit cores that are compatible with the Armv8.2 architecture.

    It supports 16 DDR4 DIMM slots, which would be enough space for up to 4TB of memory if all slots were filled with 256GB memory modules. The chassis also has space for no fewer than eight Nvidia A100 GPUs, which would make for a costly but very powerful system for those workloads that benefit from GPU acceleration.

    Continue reading
  • GitLab version 15 goes big on visibility and observability
    GitOps fans can take a spin on the free tier for pull-based deployment

    One-stop DevOps shop GitLab has announced version 15 of its platform, hot on the heels of pull-based GitOps turning up on the platform's free tier.

    Version 15.0 marks the arrival of GitLab's next major iteration and attention this time around has turned to visibility and observability – hardly surprising considering the acquisition of OpsTrace as 2021 drew to a close, as well as workflow automation, security and compliance.

    GitLab puts out monthly releases –  hitting 15.1 on June 22 –  and we spoke to the company's senior director of Product, Kenny Johnston, at the recent Kubecon EU event, about what will be added to version 15 as time goes by. During a chat with the company's senior director of Product, Kenny Johnston, at the recent Kubecon EU event, The Register was told that this was more where dollars were being invested into the product.

    Continue reading
  • To multicloud, or not: Former PayPal head of engineering weighs in
    Not everyone needs it, but those who do need to consider 3 things, says Asim Razzaq

    The push is on to get every enterprise thinking they're missing out on the next big thing if they don't adopt a multicloud strategy.

    That shove in the multicloud direction appears to be working. More than 75 percent of businesses are now using multiple cloud providers, according to Gartner. That includes some big companies, like Boeing, which recently chose to spread its bets across AWS, Google Cloud and Azure as it continues to eliminate old legacy systems. 

    There are plenty of reasons to choose to go with multiple cloud providers, but Asim Razzaq, CEO and founder at cloud cost management company Yotascale, told The Register that choosing whether or not to invest in a multicloud architecture all comes down to three things: How many different compute needs a business has, budget, and the need for redundancy. 

    Continue reading

Biting the hand that feeds IT © 1998–2022