Privacy News Google's 7-year slog to improve Chrome extensions still hasn't satisfied developers

[oldschool]

Content source

https://www.theregister.com/2025/02/07/google_chrome_extensions/

Makers of content blockers, privacy add-ons say promises weren't kept​

Thomas Claburn
Fri 7 Feb 2025 // 06:27 UTC

Google's overhaul of Chrome's extension architecture continues to pose problems for developers of ad blockers, content filters, and privacy tools.
This story starts in 2019 when Google detailed its plans to improve extensions’ security and privacy features with a project it called Manifest V3 (MV3) that changes the way extensions use various APIs. MV3 is currently being rolled out, and Google looks set to stop supporting extensions that use its predecessor MV2 this year. Back in 2019 Google insisted it was not trying to kill content blockers.
"In fact, this change is meant to give developers a way to create safer and more performant ad blockers," said Simeon Vincent, then developer advocate for Chrome Extensions.
That continues to be Google's position. "The Chrome team is committed to continuing to support content blocking extensions, and Manifest V3 was designed to preserve the functionality of these extensions," a Google spokesperson told The Register.


"In fact, we specifically designed a fast-tracking feature as a supported channel for content blockers looking to quickly roll out new rules.
The search and ad giant's privacy and security concerns are legitimate. Extensions written under the legacy Manifest V2 API have broad access to the browsing activities of users and have long been abused by miscreants to steal data and compromise systems. As noted by security researcher Wladimir Palant, some Chrome extensions are circumventing the ban on remote code execution.
MV3, however, appears not to be meeting Google’s stated goals.
AdGuard, a privacy service that makes an ad blocking extension for Chrome and related applications, recently complained that MV3 is making it hard to deliver its desired features.
In late January the company reported that Chrome's remote code execution policy under Manifest V3 (MV3), the revamped API for writing browser extensions, has forced it to remove its Quick Fixes filter and temporarily drop its Custom filter.

Making extensions under MV3 is harder and more confusing

The Quick Fixes filter is used to quickly resolve critical content filtering issues on popular websites without having to upgrade AdGuard’s extension. Custom filters lets users add third-party filters using a URL. Both are important to AdGuard because they allow rapid changes to content filters so the company’s wares can keep up with counter-measures designed to bypass filters.
AdGuard claims its extension was rejected five times by the Chrome Web Store review team for violating the remote code policy that aims to prevent extensions allowing remote execution of malicious code. The content-filtering outfit said its extension was rejected for using tags to inject rules, for downloading the Quick Fixes filter from a remote source, and later for using scriptlets and parameters, among other issues.
"In short, the policies initially seemed flexible enough to allow our solution, but in practice, we found it to be far more restrictive," a company spokesperson explained. "To be more precise, in the past, even during community meetings, we were led to believe by the Chrome team that the rules would not classify ad-blocker functionality as remote code. However, the reality has proved otherwise."

Working around MV3​

Raymond Hill, creator of uBlock Origin (uBO), arguably the most well-regarded open source content blocker, said he would not try to create a comparable version of the extension under MV3. Instead, he released uBlock Origin Lite (uBO Lite), with more modest capabilities and referred uBO users to Firefox.
Among those expressing concern about the limitations of MV3 over the past few years, AdGuard has been among the more optimistic that the technical barriers could be dealt with. Two years ago, the company went so far as to suggest customers would be unable to tell the difference between the now deprecated Manifest V2 (MV2) and MV3 versions of its extension.
The alleged performance advantages of MV3 over MV2 haven't been definitively established through any benchmark testing we're aware of. Such tests would be complicated because many factors influence how fast web pages load, including the quality of extension code, the elements on the web page, and the quality of the network connection.
However, testing conducted last year by web page testing outfit DebugBear suggests that using an ad blocker extension results in better page load performance than not using one. The study found that two ad-heavy news pages required 57 seconds of CPU processing time without an ad blocking extension, but as little as four seconds with "ad blocker adblox," which uBO developer Hill notes, "is a re-skinned version of [his own] uBO Lite," under MV3. The performance of MV2-based uBO appears to be more or less the same.

• Mixing Rust and C in Linux likened to cancer by kernel maintainer
• Coordinates of millions of smartphones feared stolen, sparking yet another lawsuit against data broker
• Google exec sees enterprise quantum app on closer horizon
• Supply chain attack hits Chrome extensions, could expose millions

Is Google listening to developers? Or want to?​

While Google's desire to improve the security, privacy, and performance of the Chrome extension platform is reasonable, its approach – which focuses on code and permissions more than human oversight – remains a work-in-progress that has left extension developers frustrated.
Alexei Miagkov, senior staff technology at the Electronic Frontier Foundation, who oversees the organization's Privacy Badger extension, told The Register, "Making extensions under MV3 is much harder than making extensions under MV2. That's just a fact. They made things harder to build and more confusing."
Miagkov said with Privacy Badger the problem has been the slowness with which Google addresses gaps in the MV3 platform. "It feels like MV3 is here and the web extensions team at Google is in no rush to fix the frayed ends, to fix what's missing or what's broken still."

They're making it harder for users to pin extensions onto the toolbar

According to Google's documentation, "There are currently no open issues considered a critical platform gap," and various issues have been addressed through the addition of new API capabilities.
Miagkov described an unresolved problem that means Privacy Badger is unable to strip Google tracking redirects on Google sites. "We can't do it the correct way because when Google engineers design the [chrome.declarativeNetRequest API], they fail to think of this scenario," he said. "We can do a redirect to get rid of the tracking, but it ends up being a broken redirect for a lot of URLs. Basically, if the URL has any kind of query string parameters – the question mark and anything beyond that – we will break the link."
Miagkov said a Chrome developer relations engineer had helped identify a workaround, but it's not great.
Miagkov thinks these problems are of Google's own making – the company changed the rules and has been slow to write the new ones. "It was completely predictable because they moved the ability to fix things from extensions to themselves," he said. "And now they need to fix things and they're not doing it."

Burying extensions​

Complaints about Google ignoring the needs of developers, particularly with regard to the Chrome Web Store, where developers submit extensions for distribution, go back several years. But even as developers urge Google to flesh out its MV3 API to allow them to create effective content blocking and privacy extensions, the web giant is also pursuing user-facing controls that look likely to reduce use of extensions.
"So the gist is what Chrome is doing is they're further making it harder for users to pin extensions onto the toolbar," explained Miagkov, pointing to a recent Google blog post on the subject. "They're making the pin even harder to reach. But what they're making easier to access is site permissions. So now users will have supposedly, theoretically, quicker access to the menu that will let them disable Privacy Badger on a specific site, or to allow Privacy Badger to only run on a specific site."
Miagkov said that doesn't make any sense and he can't fathom who has asked for this.
"To me, it's obvious that users, when they install an extension, want that extension to just work," he said. "And they don't want to have to deal with menus or preferences. They just want the thing they installed to work."
Miagkov added that extension users "want to be able to trust that the extension they installed from Chrome Web Store is safe, that's not gonna jack all their data, right? And the reality is Chrome Web Store is not safe. But Google is investing in exposing these site controls that, once they come out, they will claim as a win for user control and privacy." ®

 

[oldschool]

"[Privacy Badger] can do a redirect to get rid of the tracking, but it ends up being a broken redirect for a lot of URLs. Basically, if the URL has any kind of query string parameters – the question mark and anything beyond that – we will break the link." Miagkov said a Chrome developer relations engineer had helped identify a workaround, but it's not great.
Miagkov thinks these problems are of Google's own making – the company changed the rules and has been slow to write the new ones. "It was completely predictable because they moved the ability to fix things from extensions to themselves," he said. "And now they need to fix things and they're not doing it."

The above is just one example. The crux of the problem is Chrome's willingness (or not) to fix a browser bug (as above) since it, and not the extension, is responsible for carrying out the extensions request. And apparently, Google claims no open issues.
Known issues when migrating to Manifest V3 | Chrome Extensions | Chrome for Developers

Ultimately, all browsers are going to be f***ed as MV3 begins to dominate across the ecosystem. Don't say you weren't warned.

 

[Vitali Ortzi]

The above is just one example. The crux of the problem is Chrome's willingness (or not) to fix a browser bug (as above) since it, and not the extension, is responsible for carrying out the extensions request. And apparently, Google claims no open issues.
Known issues when migrating to Manifest V3 | Chrome Extensions | Chrome for Developers

Ultimately, all browsers are going to be f***ed as MV3 begins to dominate across the ecosystem. Don't say you weren't warned.

At least brave has a built in ad blocker
Anyway except the purposely anti ad blocker move everything else especially performance and security is better with mv3 and after mv3 I can now have multi security extensions with good performance



About "Is Google listening to developers? "
Well first to their own interests (tracking, ads etc ) but after that they actually do care but they are just not the priority



Basically brave is a great alternative to chrome and I think once you have the built in ad blocker there wouldn't really be a need to other mv2 extensions and you will have all the benefits of mv3 unlike Firefox and a better engine too on every metric especially security then Firefox

 

[oldschool]

performance and security is better with mv3

How exactly? Even @gorhill states that security is not better due to Google's implementation of MV3. And of course, without a secure Chrome Web Store, no extension is really secure.

The first link provides a great look at some of the security pitfalls.
Analysis of an advanced malicious Chrome extension
Chrome Web Store is a mess
More malicious extensions in Chrome Web Store
Another cluster of potentially malicious Chrome extensions
The Karma connection in Chrome Web Store
Malicious extensions in the Chrome Web Store

 

[Captain Holly]

I appreciate the info and advice here in this thread. I am keeping an eye on it. Today I changed my default browser back to Firefox. I am also using the original Ublock Origin from the Firefox extension group, along with Malwarebytes Browser Guard and Malwarebytes Premium. I really do hope Firefox will stand its ground, stay true to their roots and not cave in to any extension pressure from Google. Edge and Firefox are the only browsers on my laptop now. I plan to keep it that way and only use Edge if I ever run across a site that will not work in Firefox. I do have Ublock Origin in Edge too, but who knows how much longer it will be available in the MS extension store.

C.H.

 

[Vitali Ortzi]

How exactly? Even @gorhill states that security is not better due to Google's implementation of MV3. And of course, without a secure Chrome Web Store, no extension is really secure.

The first link provides a great look at some of the security pitfalls.
Analysis of an advanced malicious Chrome extension
Chrome Web Store is a mess
More malicious extensions in Chrome Web Store
Another cluster of potentially malicious Chrome extensions
The Karma connection in Chrome Web Store
Malicious extensions in the Chrome Web Store

All these cases is a dev specifically uploading a malicious extension
specifically all well vetted extensions are more secure then ever thanks to mv3 changes but yes it doesn't stop people from uploading malicious extensions
You can read more here about mv3

Extensions / Manifest V3 | Chrome for Developers

developer.chrome.com

Attacking browser extensions

Learn about browser extension security and secure your extensions with the help of CodeQL.

github.blog

 

[oldschool]

@Vitali Ortzi If only 'vetted' extensions are secure, than where's the MV3 advantage over a vetted MV2?
Google’s Plans for Chrome Extensions Won’t Really Help Security
For instance, part of the supposed advantage is a prohibition on remotely hosted code. Except there is this flaw in their change, from Malicious extensions circumvent Google’s remote code ban

As noted last week I consider it highly problematic that Google for a long time allowed extensions to run code they downloaded from some web server, an approach that Mozilla prohibited long before Google even introduced extensions to their browser. For years this has been an easy way for malicious extensions to hide their functionality. When Google finally changed their mind, it wasn’t in form of a policy but rather a technical change introduced with Manifest V3.

As with most things about Manifest V3, these changes are meant for well-behaving extensions where they in fact improve security. As readers of this blog probably know, those who want to find loopholes will find them: I’ve already written about the Honey extension bundling its own JavaScript interpreter and malicious extensions essentially creating their own programming language. This article looks into more approaches I found used by malicious extensions in Chrome Web Store. And maybe Google will decide to prohibit remote code as a policy after all.

There are other examples, such as abuse of declarativeNetRequest API, Content Security Policy, etc.
Google Chrome extensions remain a security risk as Manifest V3 fails to prevent data theft and malware exploitation
And other considerations like here Manifest V2 to V3: Challenges and Security Considerations. - Least Authority

You still haven't explained how MV3 is inherently more secure than MV2.

 

[Vitali Ortzi]

@Vitali Ortzi If only 'vetted' extensions are secure, than where's the MV3 advantage over a vetted MV2?
Google’s Plans for Chrome Extensions Won’t Really Help Security
For instance, part of the supposed advantage is a prohibition on remotely hosted code. Except there is this flaw in their change, from Malicious extensions circumvent Google’s remote code ban

There are other examples, such as abuse of declarativeNetRequest API, Content Security Policy, etc.
Google Chrome extensions remain a security risk as Manifest V3 fails to prevent data theft and malware exploitation
And other considerations like here Manifest V2 to V3: Challenges and Security Considerations. - Least Authority

You still haven't explained how MV3 is inherently more secure than MV2.

There is a lot of reduction in Attack surface but yes there is definitely a long way to go and worst of all a malicious actor can still publish malicious extension as google own vetting isn't great and the abuses above are malicious intent and mv3 doesn't deal with malicious intent rather tries to reduce attack surface from outside actors by having far lower attack surface
So the benefits are mainly against a malicious external actor like a malicious site


1. Background pages replaced with service workers
2.google now Enforces script-src 'self' and doesn't allow unsafe-inline and unsafe-eval
3 more aggressive permissions over Firefox if I remember correctly
4. Web request API is banned and you can only use declarativeNetRequest
5. UUID randomization
And a few others u can look for in the docs

 

[oldschool]

And a few others u can look for in the docs

Yes, I've looked at the docs and these are still vulnerable, as documented in above post.

 

[Vitali Ortzi]

Yes, I've looked at the docs and these are still vulnerable, as documented in above post

Not perfect but there is definitely an improvement and it would be insanely difficult for an external attacker to abuse an extension after the changes as devs use apis now with less attack surface plus UUID randomization and if you could find a way to attack the browser extension via a malicious web page you could get a bounty as they are working on making it as difficult as possible and mv3 is a good leap in security