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

251–260 of 271 posts

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

#251

Post by Arnavion »

pmontra wrote: post #246
Semaphor wrote: post #238

Earlier quoted context omitted.

TL;DR: There is no proper UI, and it’s only usable if you either use the uM tables infrequently or feel like writing rules by hand all the time.

Agreed, what takes seconds now (click square or row, click to reload, repeat until it works well enough) would be going to take minutes, possibly large fractions of an hour. A two orders of magnitude change for the worse means that it's unusable. It's not life and death, where one adapts no matter what.

>click square or row, click to reload, repeat until it works well enough

Don't guess. uBO comes with a dashboard just like uM did that shows you exactly what's being blocked. It's usually very obvious what important script is being blocked whose domain you need to allow, what PUA symbols font is being blocked, etc.

>take minutes, possibly large fractions of an hour

Switching to the other window where you have the uBO list open and copy-pasting a line takes about as long as clicking the uM browser button, eyeballing the table and finding the right cell to click.

Your initial setup is going to take long. After that you'll a) get better at it, and b) you won't need to update it as often. I started doing this two years ago and these days I edit less than 2 lines per month on average. My list has rules for ~80 domains and is ~400 lines long, not counting whitespace and comments.

In any case, I'm not trying to convince you. I keep seeing people thinking that uBO can't do things that uM can, so I post that link to let them know that it can do those things except for cookies. Whether you want to use that info, or you think it's not worth it and you want to keep using uM, is something you decide for yourself.

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

#252

Post by nightpool »

concinds wrote: post #248
nightpool wrote: post #247

Earlier quoted context omitted.

Google's clearly signalled that they don't want Adblockers to use "read/write data on all websites" Where have they "clearly signaled this"? Gorhil even disproves this in his own comment: he links to an ad blocker in the Chrome webstore that uses MV3 and has been approved, even though it uses the "Read/write data on all websites" permission.

I got it from this comment: ( https://news.ycombinator.com/item?id=32755925); and Chromium's official blog that hints at that: https://blog.chromium.org/2020/12/manifest-v3-now-available-... > To give users greater visibility and control over how extensions use and share their data, we’re moving to an extensions model that makes more permissions optional and allows users to withhold sensitive permissions at install t…

Unsourced comments that cite unsourced comments... this is exactly how FUD spreads.

I agree that it's clear that Google wants to reduce the amount of extensions that users opt in to having access to their entire web browsing data. I don't think that's a psychological trick: I think it's very clear that most users don't understand that every single extension they install might have these permissions, and instead just click past the generic permissions dialogue that Google shows.

I don't think that that translates to "Google's clearly signalled that they don't want Adblockers to use "read/write data on all websites"". What Google has clearly signaled is that they want users to be able to opt in to using this permission for the extensions that are most important to them, and that they want extensions to gracefully degrade when those permissions are not available. For most users, that's going to be ad blockers: basic features work without full site access, and advanced features are available with more site access. That seems like a good thing to me, not a reason to rip those advanced features out all together.

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

#253

Post by thiht »

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

> The logical strategy is embrace extend extinguish ad blocking

The logical strategy is to extinguish. They never embraced or extended it.

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

#254

Post by rjh29 »

TimTheTinker wrote: post #104
rjh29 wrote: post #43

Earlier quoted context omitted.

> I see plenty of folks in here lamenting this release at all - in the hopes that the lack of it will push folks to Firefox. It won't. Those who care about this are already on Firefox Huh? I'm going to switch to Firefox the second uBlock Origin stops working on Chrome. Otherwise I'll continue to use Chrome because it's a better browser (for me). I don't think I'm some rare minority here.

> Huh? I'm going to switch to Firefox the second uBlock Origin stops working on Chrome. uBlock Origin already blocks a lot better on Firefox than on Chrome. https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...

In practical terms I haven't seen any ads on Chrome so the blocking experience seems good enough. If you care about privacy Firefox definitely seems better.

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

#255

Post by rjh29 »

Vinnl wrote: post #211
rjh29 wrote: post #109

Earlier quoted context omitted.

I dunno. The new version does not strongly affect end users (according to the devs) but there is a psychological barrier around switching from the full version to the minus version, which I think will cause me to switch to Firefox. Even if the new version works now, Google are clearly going to tighten the vice over the next few years.

Hmm, I guess it depends on what this will look like long-term, but I'd expect that regular uBO will be "upgraded" to this version when MV2 is deprecated in Chrome for good, possibly including the name change (if allowed by Google). Edit: ah, looking at gorhill's comments it looks like this is not intended to be the MV3 version of uBO, but just one that has minimal permissions. Then I guess uBO will migrate in its own…

Ultimately it'll come down to the experience - if uBlock stops blocking some percentage of ads (because it's impossible under the extension), or triggers ad-blocker-blocker type stuff, I would be very quickly be moving to Firefox!

Either way, very thankful to the developers and community for making our web browsing experience so much better.

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

#256

Post by nopcode »

solardev wrote: post #187
jchw wrote: post #156

Earlier quoted context omitted.

Not to burst your bubble but if you are leaving the Android ecosystem because of Chrome manifest v3 I definitely urge you to see what you're getting yourself into. Not only does Apple enforce that you use their browser engine, it also abuses this position to disable features that they keep enabled on desktop Safari where users have an actual browser engine choice. Also, Safari imposes limitations on extensions that a…

How does content blocking in iOS Safari (like with Adguard) work? Is it any better or worse than Chrome with manifest v3?

Apple offers a Content Blocking API which is leveraged by most apps and similar to mv3.

Most of these apps (now) also include a JavaScript extension to block the harder ads (eg youtube). This a recent development that apple seems to encourage.

Some apps also offer network-level adblocking by using a local VPN server, which allows for blocking in apps.

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

#257

Post by pmontra »

Arnavion wrote: post #251
pmontra wrote: post #246

Earlier quoted context omitted.

Agreed, what takes seconds now (click square or row, click to reload, repeat until it works well enough) would be going to take minutes, possibly large fractions of an hour. A two orders of magnitude change for the worse means that it's unusable. It's not life and death, where one adapts no matter what.

>click square or row, click to reload, repeat until it works well enough Don't guess. uBO comes with a dashboard just like uM did that shows you exactly what's being blocked. It's usually very obvious what important script is being blocked whose domain you need to allow, what PUA symbols font is being blocked, etc. >take minutes, possibly large fractions of an hour Switching to the other window where you have the uBO…

My point is that the uM UI is obvious and I never understood how the uBO overview works. This should be telling something about UX design (or the amount of time that people can put into these projects, after all they have a life like everybody else.)

Today I learned that the GUI is read only and I have to write rules by hand. I'm a fan of command line and textual configuration files, except the few cases where a complex configuration GUI is quicker to use. uM is a great example of such cases.

> Your initial setup is going to take long

So I'll postpone it to when uM won't work anymore :-)

But actually reading again the guide at https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-qu... it seems that it can be done with a mouse. It didn't work for me because of ctrl ctrl doesn't work (I'm resisting fingerprinting on Firefox) and filterAuthorMode was False.

I think I can create allow rules with a mouse now. Unfortunately it seems that they allow everything from that site. For granular control I'm back to writing rules.

By the way, it seems that the ++ and -- in the overview are a kind of histogram. The numbers as in uM are much more informative and they won't puzzle people like me. I thought they were targets for clicking or to allow / block the site. We're back to my initial assessment of the two UXes.

Anyway, both uBO and uM are really useful so I won't complain too much. I'll keep using uM as long as it works because it's easier to use. I'll switch to that functionality of uBo when there won't be other alternatives. I remember that I switched to uM from NoScript because of some changes there. I couldn't do anymore what I was used to do. I read years ago that maybe they fixed that, so I could check how it works but not now.

I was already using uBo for adblocking and content filtering.

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

#258

Post by gorhill »

nightpool wrote: post #121
stonogo wrote: post #64

Earlier quoted context omitted.

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 r…

> How is DNR "not flexible" enough here?

DNR does not allow uBO's _Block media elements larger than [x] KB_[1].

DNR does not allow to know which network request was blocked by what rule. To do so requires the `declarativeNetRequestFeedback` permission, which is available only on locally unpacked extensions, for debugging purpose. This prevents porting to MV3 uBO's overview panel[2], including the "advanced user" version to set firewall-like rules[3], and uBO's logger[4].

Furthermore, the filter-matching algorithm of DNR does not match the filter-matching algorithm of uBO regarding redirection. In uBO, redirect filters do not compete with block filters, they are looked-up after a network request has been blocked. With DNR, redirect rules competes with block rules, such that uBO's `redirect-rule=` filters can't be ported.

* * *

[1] https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-...

[2] https://github.com/gorhill/uBlock/wiki/Quick-guide:-popup-us...

[3] https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-qu...

[4] https://github.com/gorhill/uBlock/wiki/The-logger

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

#259

Post by michaelmrose »

thiht wrote: post #253
michaelmrose wrote: post #83

Earlier quoted context omitted.

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

> The logical strategy is embrace extend extinguish ad blocking The logical strategy is to extinguish. They never embraced or extended it.

Implementing what amounts to ad blocking in your browser which all extensions must necessarily be mere lists of what to block rather than complex programs that examine and modify data IS the embrace.

Extending it would involve either implementing acceptable ads functionality that was optional.

Extinguish is making it mandatory in order to be listed on the chrome web store and allowing the browser to transmit some certification that it doesn't have an extension installed that would modify data in transit to ensure "security" making it hard to use the modern web with a browser that didn't transmit such.

Locally installing extensions is only for development so that any such modification will effectively break such a seal and make it impossible for you to view $SOME_RANDOM_GOOGLE_ADS_USING_SITE which will complain your browser is insecure and refuse to work kind of like sites presently block adblockers but with browser support making it much harder to avoid.

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

#260

Post by Abishek_Muthian »

jchw wrote: post #250
Abishek_Muthian wrote: post #245

Earlier quoted context omitted.

> I finally got fed up and switched back to Android where I grabbed Fennec F-Droid, installed uBlock Origin and finally had a decent mobile browser. Just to note, There's a full-desktop Firefox available with mobile layout in PostmarketOS for Linux Phones. Here's the device I drive daily[1]. [1] https://wiki.postmarketos.org/wiki/Xiaomi_Poco_F1_(xiaomi-be...

postmarketOS is incredibly promising, but unfortunately the devices I've tried it on are still very unstable. Full-fat Firefox felt surprisingly usable on Pinephone under Phosh though. Even then: Fennec F-Droid is a compelling choice. It has a pretty good mobile experience.

SDM 845 devices, Especially OP6/6T and Xiaomi Poco F1 has changed the landscape for PostmarketOS(Still is not for everyone though).

Firefox/Fennec F-Droid is indeed great (Especially since UBO is supported), But unfortunately in Android almost every enthusiast project involves privilege escalation and in this case F-Droid auto update apps requires one too.

Post reply on HN