Manifest V3, webRequest, and ad blockers

Stardust

@Catweazle interesting, that uBlock Origin is actually older than Vivaldi.

uBlock Origin Initial release date: June 23, 2014

Vivaldi Initial release date: January 27, 2015

iqaluit

@barbudo2005 I installed AdGuard, found good lifetime deal and I am comfortable with it. It is as powerful as uBlock as a content and ad blocker. But I don't use the extension, I installed in windows and works seamlessly. I recommend.

Catweazle

@Stardust, yes, nothing against uBO, but it's not the center of the Mv3 problem, it's the web hegemony of Google, which can be changed with using another browser because of uBO.
Mv3 will be generally the new standart for ALL browsers easier or later, because the devs won't work on 2 different extension for Mv2 and Mv3 indefinitely. Mv2 will disappear, same as Mv1 with Chrome 18 in the past also for all others. Law of the market, made by a monopoly. Changing to Firefox/Mozilla only reforce the Google domain, becaus, despite the engine depends way more on Google than Vivaldi.

alt text

Stardust

@Catweazle said in Manifest V3, webRequest, and ad blockers:

Mv3 will be generally the new standart for ALL browsers easier or later, because the devs won't work on 2 different extension for Mv2 and Mv3 indefinitely. Mv2 will disappear, same as Mv1 with Chrome 18 in the past also for all others.

We will see when/if it will disappear. Currently there is no plan to abandon MV2 by Mozilla and uBO MV2 is going to be maintained for Firefox.

@Catweazle said in Manifest V3, webRequest, and ad blockers:

Changing to Firefox/Mozilla only reforce the Google domain, becaus, despite the engine depends way more on Google than Vivaldi.

Having non-chromium engine is a good thing. We don't know when and how Google will try to poison Firefox engine, but good thing there are few other engines in development at the moment.

uBO MV2 forever!

Catweazle

@Stardust, there even Google devs working on FF. Enough poison? Well, FF (or better some forks) is still the best alternative respect other browsers, but it's risky to overestimate it.

Stardust

@Catweazle said in Manifest V3, webRequest, and ad blockers:

there even Google devs working on FF. Enough poison?

Who exactly?

Well, FF (or better some forks) is still the best alternative respect other browsers, but it's risky to overestimate it.

Fight is never easy!

Catweazle

@Stardust, https://blog.mozilla.org/en/mozilla/mozilla-brings-microsoft-google-w3c-samsung-together-create-cross-browser-documentation-mdn/

Stardust

@Catweazle said in Manifest V3, webRequest, and ad blockers:

@Stardust, https://blog.mozilla.org/en/mozilla/mozilla-brings-microsoft-google-w3c-samsung-together-create-cross-browser-documentation-mdn/

that blog post is very old, from 2017, so probably those people (Board Members) are even no longer working there. Also it sounds a bit different than your phrase "there even Google devs working on FF"

Catweazle

@Stardust, MDN is still active, also it's collaborators from all big companies. But if you trust these alliance of Mozilla, it's OK, but I understand with working for a better and free internet someting different.

Stardust

@Catweazle said in Manifest V3, webRequest, and ad blockers:

@Stardust, MDN is still active, also it's collaborators from all big companies. But if you trust these alliance of Mozilla, it's OK, but I understand with working for a better and free internet someting different.

Mozilla lost my remaining trust after they quietly added PPI ads tracking in Firefox
I only trust uBO now!

shojivrstrinova8

so when this will be applied on vivaldi?

DoctorG

@shojivrstrinova8 We do not give a timeline for changes and new features.

shojivrstrinova8

@DoctorG alright hope it wont affect vivaldi so much

DoctorG

@shojivrstrinova8 IT will affect some older extensions, not Vivaldi itself.

barbudo2005

AdGuard Browser Extension 5.0.178
Release date: December 24, 2024

Small but important hotfix.

Changelog:

Changed

Remade JS rules injections in MV3:

Use chrome.scripting API for injecting functions for script rules from the pre-built filters.
Use script tag injection only for script rules manually added by users — rules from User rules and Custom filters.

Does anyone know the difference between the two methods?

iqaluit

@barbudo2005 I use adguard. First one is what comes with AdGuard presinstalled. Second is the one which you can tweak, create exceptions and create own filters

barbudo2005

@iqaluit

I was referring to the injection methods.

iqaluit

@barbudo2005 Sorry. I don't have an answer

Bingbot

Since Vivaldi is based on Chrome and google wants to remove adblock support by removing certain APIs. What will this mean for Vivaldi and adblock support?

Will i use support for ublock origin in future versions and maybe other extensions?

Regards,
Bingbot

PS. i hope this hasnt answer already ...

barbudo2005

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

From theregister.com

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.

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."

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