Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3

github.com

Post reply on HN
Print view View original

121–130 of 271 posts

Re: “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3

#121

Post by nightpool »

stonogo wrote: post #64
nightpool wrote: post #21

Just so I understand correctly: This version removes *all* of the features that read or modify a user's data, so as to abide by the ""stated intent"" of MV3, rather than taking full advantage of all of the actual MV3 APIs? For example, this commit removes the "scriplet injection" and cosmetic filtering features, which AFAIK work perfectly fine on MV3? if broad "read/modify data" permission is to be used, than there i…

You are conflating a "present/absent" question of this permission with Google's stated intent. The key modifier here is broad "read/modify data" permission. If an extension attempts to assert that permission across a user's entire traffic, the extension will not be permitted in the store. Google's been very clear on this and it's already caused problems for other extensions. Furthmore the webRequest API has been nerf…

> If an extension attempts to assert that permission across a user's entire traffic, the extension will not be permitted in the store. Google's been very clear on this and it's already caused problems for other extensions.

Do you have a source for this? Have other ad blocking extensions been removed from the store? I find it very hard to believe that Google would block uBlock over something so clearly and obviously required for its functioning when they've said over and over again that making sure ad blocking extensions continue to work is a high priority for them.

> The replacement declarativeNetRequest API is not flexible enough to serve uBlock Origin's needs.

Well, the stats from the commit in question clearly disagree with you—of 22,245 rules, only 145 use unsupported regexes. How is DNR "not flexible" enough here?

Re: “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3

#122

Post by Dalewyn »

redox99 wrote: post #108
Tenoke wrote: post #100

Earlier quoted context omitted.

If uBlock doesn't provide a compatible extension or if their extension is worse than possible I'd likely just switch to the best alternative which will pop-up. I imagine most users will do the same.

Why are you willing to accept an inferior adblocker, instead of switching to another browser that maintains support for fully featured adblockers?

Because Firefox is shit to use.

Adblocking means little if the actual browser is terrible to use. Between proper adblocking and a shitty browser, or a shitty adblocker and a shitty-but-still-usable browser I will take the latter because ultimately I have shit that needs to get done.

Practicality cares not for ideology.

Re: “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3

#123

Post by jorvi »

uneekname wrote: post #75
blibble wrote: post #49

Earlier quoted context omitted.

I was fully in the Google world prior to gorhill's posts on manifest v3 as a direct result the only thing I have left is a pixel phone, which will be going with the new iPhone (and in the meantime my entire family has been 'helpfully' migrated too) I may be up the extreme end of the distribution, but this sort of grassroots push is what dethroned IE, and the resultant loss of control of the web eliminated Microsoft's…

IMO Firefox on an Android is better than anything you can get on iOS. It fully supports uBlock Origin! I also use a Pixel phone, though I use LineageOS so I feel less tied to Google

To be clear: it is a willful choice by Mozilla to fully protect Android users but to leave iOS users in the turmoil of a constant stream of invasive and malicious ads. I specifically took my parents off of Firefox for this express reason. Brave has a built-in adblocker, as do many other iOS browsers.

And it is not like Mozilla isn’t aware, I believe there are 2-3 open issues on Bugzilla, years old, that have just been left to wither.

Re: “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3

#124

Post by nightpool »

ohgodplsno wrote: post #73
nightpool wrote: post #21

Just so I understand correctly: This version removes *all* of the features that read or modify a user's data, so as to abide by the ""stated intent"" of MV3, rather than taking full advantage of all of the actual MV3 APIs? For example, this commit removes the "scriplet injection" and cosmetic filtering features, which AFAIK work perfectly fine on MV3? if broad "read/modify data" permission is to be used, than there i…

> this commit removes the "scriplet injection" Considering this is stated in ManifestV3's announcement and that no APIs have been made for it: > Beginning in Manifest V3, we will disallow extensions from using remotely-hosted code. This will require that all code executed by the extension be present in the extension’s package uploaded to the webstore. Server communication (potentially changing extension behavior) wil…

> Considering this is stated in ManifestV3's announcement and that no APIs have been made for it

I'll admit—when I first made this comment, I assumed (based on the initial manifest v3 draft) that this change only affected privileged context execution, and did not affect execution in the "main world", outside of privileged extension contexts. That said, APIs HAVE been made for it, and it would still be possible to do this using the dynamic addContentScript feature, even though I'd imagine it's a very low priority change to implement for the uBlock team (how many rules even use scriptlets?). But this is only a very small part of the features that Gorhill removed from the extension

> Cosmetic filtering can only happen by making a service worker, that will turn on five seconds after the page has loaded.

What? Content scripts still exist. Scriptlets may be harder to implement, but there's absolutely no reason cosmetic filtering should be.

> No, but Google will heavily restrict any extension using this permission, and make the requirements to be published on their extension store so draconian that an ad blocking extension (which directly threatens their business model) has no chance of ever being accepted.

Source? Have they said that they're going to do this to uBlock origin? They've said time and time again that making sure ad blocking extensions continue to work is one of their highest priority goals with MV3.

Also, the DNR changes absolutely do not make a meaningful impact on Google's business model—Google's ads are very, very easy to block, and you could do it with a one-line chrome extension. The vast majority of complexity in ad blockers is required for other ads that live outside of Google's ecosystem. If you really believed that Google was making their MV3 changes based on their business goals for their ads team (a pretty ludicrous idea when you think about how big Google is and how far separated the ads department and extensions teams are), then the inescapable conclusion is that Google should be supporting ad blockers themselves, to hurt the smaller companies that threaten their monopoly by trying to work around ad blockers.

Re: “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3

#125

Post by horsawlarway »

tyingq wrote: post #115
horsawlarway wrote: post #99

Earlier quoted context omitted.

> if they were suddenly deprived of good adblocking on Chrome. Ok - but that won't happen (at least not yet, given the m3 api available, who knows what google will do long term). The majority of users won't genuinely notice any difference between an adblocker running on m3 vs m2, and plenty of companies are going to make them. My point is that despite the push back from the UBO dev (and I sort of agree - this does li…

"The majority of users won't genuinely notice any difference between an adblocker running on m3 vs m2" I think that'll be true for a short time. But once the advertisers figure out that ad blockers have been crippled on the most popular browser... They'll figure out how to take advantage of that. Once Chrome takes away the ability to do live heuristics, and leaves you with just a static-ish blacklist, it's pretty eas…

But you can already work around adblockers by just serving ads directly from your own servers.

Frankly - you can also move to a service that implements adblocking at a different layer (I've seen an explosion of dns based adblockers as a service, likely inspired by the likes of pi-hole). Those services are using roughly the same feature set that's still available in m3.

The big dealbreaker (imo) was the inability to configure rules at runtime, and the requirement that they be declared in the manifest - and that never actually happened (you can dynamically configure them with https://developer.chrome.com/docs/extensions/reference/decla...)

Re: “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3

#126

Post by nightpool »

sgc wrote: post #68
nightpool wrote: post #21

Just so I understand correctly: This version removes *all* of the features that read or modify a user's data, so as to abide by the ""stated intent"" of MV3, rather than taking full advantage of all of the actual MV3 APIs? For example, this commit removes the "scriplet injection" and cosmetic filtering features, which AFAIK work perfectly fine on MV3? if broad "read/modify data" permission is to be used, than there i…

Maybe I am missing something here. But google is a well-known pull-the-rug-from-under-you type company, with a long proven track record of doing just that. Don't use undocumented, not officially supported anything from them. ever. Don't use apis that go against their stated goals. They WILL remove them. Unless MV3 has officially committed to a changed changed scope to allow this, it is irrelevant if it incidentally w…

I'm talking about features that the Chrome team has explicitly said time and time again will continue to work, like content scripts and user styles (cosmetic filters), and which MV3 never threatened in the first place. It would be ludicrous to consider these "undocumented". It's hard for me to see any other reason for gorhill to remove these features from the MV3 version of the extension except out of some perverse inclination to twist around the meaning of the Chrome team's words to support the conclusion that he obviously wants to find (that Chrome is trying to kill ad-blockers)—when in fact the *stated goals* of the extension team have always been the exact opposite (to provide APIs and extension points that allow ad blockers to continue to work)

Re: “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3

#127

Post by nightpool »

michaelmrose wrote: post #83
nightpool wrote: post #21

Just so I understand correctly: This version removes *all* of the features that read or modify a user's data, so as to abide by the ""stated intent"" of MV3, rather than taking full advantage of all of the actual MV3 APIs? For example, this commit removes the "scriplet injection" and cosmetic filtering features, which AFAIK work perfectly fine on MV3? if broad "read/modify data" permission is to be used, than there i…

Google is an ad company. The logical strategy is embrace extend extinguish ad blocking. If your extension is getting attacked and stripped of functionality minimal investment in keeping it working likely to continue to work the longest is logical

Many people have responded to this argument across many different threads, but just to reiterate: this is just the exact opposite of true. Google's ads are very, very easy to block, and you could do it with a one-line chrome extension. The vast majority of complexity in ad blockers is required for other ads that live outside of Google's ecosystem. If you really believed that Google was making their MV3 changes based on their business goals for their ads team (a pretty ludicrous idea when you think about how big Google is and how far separated the ads department and extensions teams are), then the inescapable conclusion is that Google should be supporting ad blockers themselves, to hurt the smaller companies that threaten their monopoly by trying to work around ad blockers.

Re: “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3

#128

Post by jdmichal »

jorvi wrote: post #123
uneekname wrote: post #75

Earlier quoted context omitted.

IMO Firefox on an Android is better than anything you can get on iOS. It fully supports uBlock Origin! I also use a Pixel phone, though I use LineageOS so I feel less tied to Google

To be clear: it is a willful choice by Mozilla to fully protect Android users but to leave iOS users in the turmoil of a constant stream of invasive and malicious ads. I specifically took my parents off of Firefox for this express reason. Brave has a built-in adblocker, as do many other iOS browsers. And it is not like Mozilla isn’t aware, I believe there are 2-3 open issues on Bugzilla, years old, that have just bee…

Isn't there some rule that any browser on iOS must use the native Safari engine? So if iOS Safari doesn't support something, there's no way for Firefox to add that support. It's basically just a skin.

Re: “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3

#129

Post by jorvi »

jdmichal wrote: post #128
jorvi wrote: post #123

Earlier quoted context omitted.

To be clear: it is a willful choice by Mozilla to fully protect Android users but to leave iOS users in the turmoil of a constant stream of invasive and malicious ads. I specifically took my parents off of Firefox for this express reason. Brave has a built-in adblocker, as do many other iOS browsers. And it is not like Mozilla isn’t aware, I believe there are 2-3 open issues on Bugzilla, years old, that have just bee…

Isn't there some rule that any browser on iOS must use the native Safari engine? So if iOS Safari doesn't support something, there's no way for Firefox to add that support. It's basically just a skin.

Yes, but like I said, many other 3rd-party browsers have perfectly fine built-in adblockers.

Hell, you can install Firefox Focus (which is a ‘private mode only’ browser) and that does have built-in adblocking. More perversely, you can use it as a content blocker for Safari.

(No, other browsers using Safari’s engine do not inherit the content blocking)

I repeat: Mozilla is willfully choosing not to protect iOS Firefox users from ads. Plain and simple.

Re: “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3

#130

Post by tyingq »

horsawlarway wrote: post #125
tyingq wrote: post #115

Earlier quoted context omitted.

"The majority of users won't genuinely notice any difference between an adblocker running on m3 vs m2" I think that'll be true for a short time. But once the advertisers figure out that ad blockers have been crippled on the most popular browser... They'll figure out how to take advantage of that. Once Chrome takes away the ability to do live heuristics, and leaves you with just a static-ish blacklist, it's pretty eas…

But you can already work around adblockers by just serving ads directly from your own servers. Frankly - you can also move to a service that implements adblocking at a different layer (I've seen an explosion of dns based adblockers as a service, likely inspired by the likes of pi-hole). Those services are using roughly the same feature set that's still available in m3. The big dealbreaker (imo) was the inability to c…

>But you can already work around adblockers by just serving ads directly from your own servers

The available heuristics in UBO can block those with many different techniques today, especially for a short list of very popular sites. I assume many of them stop working with MV3.

I'm aware of the DNS based adblockers, what I'm saying is that the advertisers might take action on all of them once the best option is hobbled. Then it's worth doing something that will break almost all the adblockers. One effort that puts everything to rest.

Post reply on HN