µBlock, a lean and fast blocker

Why is this a "disadvantage"?

That connection was never blocked before because you were not seeing it, let alone being able to block it. Now you can see it, and as a result you can either keep blocking it or allow it on mozilla.org.

How is "seeing the connection to cloudflare and being able to set rules for it" a disadvantage over "not seeing the connection to cloudflare"?

 

because - when cloudflare is not allowed (green) i cannot download from archive.mozilla.org using right mouse "save as" in firefox. it throws an error.

i already knew that mozilla is hosting on cloudflare. same for soundcloud. i have to allow cloudflare as the final host. this is all about spiegel.de with podcasts hosted in soundcloud. cname reversing do not have benefit here so i disabled it for unknown period.

 

Tho I don't see Cloudflare on archive.mozilla (maybe it's geo-dependent), before the change or if you disabled the uncloaking, connection to Cloudflare anyway occured whatever setting you used, because uBO could't recognize it as Cloudflare but wrongly recognized it as Mozilla. Now you can block connection to Cloudflare which based on your claim blocked download. Only thing you have to do is to noop that cloudflare domain ONLY ON archive.mozilla.org (local scope) but not globally. This way NOTHING has changed before and after the new option, except now you can block disguised Cloudflare domains on all other sites.

As to spiegel.de, on my end nothing about soundcloud need to be nooped to listen podcasts. If anything, edgekey.net may need to be nooped only on main page but not the podcast page. It can also be geo-dependent tho. The URL tested is:
https://www.spiegel.de/thema/podcasts_vom_spiegel/

 

It seems

Code:

* edgekey.net.globalredir.akadns.net * noop

is another staff widely used on English sites and need to be nooped.
I also added

Code:

* sites.hubspot.net * noop

(you can see all these on my Github repo by clicking "History" and then commit number)
but so far not sure if it's widely used on English sites - other domains I added are probably regional so I don't share (unless someone here needs Japanese rules).

 

sorry, but you missed it. and no, it is your romance with edgekey, and no, spiegel dont load from akadns here.
cloudfront will be blocked here by default, i had no issues before cname was introduced.

 

Huh? First of all, my second post is NOT toward you, it's for public benefit (continued from #4349). akadns is not at all related to spiegel, IDK how you thought that was somehow related to you or your post.

And about your problem, it's really only your problem, or rather the problem in your imagination. Before the change, uBO didn't block that connection because it wrongly "thought" it was to mozilla.org and not to cloudflare.net. Your blocking rule for cloudflare had no effect at all on this site. Or if you think any connection to cloudflare had been blocked just because you had the blocking rule, that's completely wrong! uBO could block only connection recognized to go to cloudflare, not the disguised connection as going to mozilla.org. The connection to cloudflare appeared in blue char because now uBO is able to uncloak this disguised connection, it's purely advantage and by no means disadvantage, but IF you don't listen to gorhil's comment and don't try to understand what this means, nobody would be able to persuade you.

Also note this is not uncommon that some sites are delivered through CDN only when you accessed the site from certain place and not when from other place, there are other examples of this.

 

you answered me

edgekey is not my interest here, neither nor (as it never showed up)

I already wrote that i know that mozilla uses cloudfront, but now with cname i need explicit to allow cloudfrond this way. the rest of used rules is visible for you as the matrix shows it. this is reproducable in any firefox with any profile (>= v73)
this wont happen without cname reversing.

maybe, i wont deny.

for spiegel, to reproduce - this is a kind of timelime how to resolve a working page but not having show the anti-adblock message (1st image)

for podcast only 1.24.4

Code:

www.spiegel.de adobedtm.com * allow
www.spiegel.de spiegel.de * noop

podcast in 1.25

Code:

www.spiegel.de adobedtm.com * allow
www.spiegel.de cloudfront.net * allow
www.spiegel.de footprint.net * allow
www.spiegel.de spiegel.de * noop

for any kind of video and podcast in 1.24.4

Code:

www.spiegel.de adobedtm.com * allow
www.spiegel.de emsservice.de * allow
www.spiegel.de mxcdn.net * allow
www.spiegel.de s3.amazonaws.com * allow
www.spiegel.de smartclip.net * allow
www.spiegel.de spiegel.de * noop

video/podcast in 1.25

Code:

www.spiegel.de adobedtm.com * allow
www.spiegel.de cloudfront.net * allow
www.spiegel.de footprint.net * allow
www.spiegel.de mxcdn.net * allow
www.spiegel.de ndcaidemh.com * allow
www.spiegel.de s3.amazonaws.com * allow
www.spiegel.de smartclip.net * allow
www.spiegel.de spiegel.de * allow
www.spiegel.de www.spiegel.de * noop

and this includes ad-videos while i dont have in 1.24.4 (ndcaidemh.com)

presets for both (ofc also for other pages with soundcloud)

Code:

* jwpcdn.com * allow
* jwplayer.com * allow
* jwpltx.com * allow
* jwpsrv.com * allow
* sndcdn.com * noop
* soundcloud.com * noop

as you can see there is a big difference w/ or w/o cname.

anyhow even with cnameuncloak=false its not the same - i get ad-videos.

 

From what I see above, I will just to reiterate good practices for those who uses advanced dynamic filtering:

Do NOT use "allow" rules unless you understand EXACTLY what they do. I personally have ZERO "allow" rules in my ruleset after years of using uBO. A reminder that using an "allow" rule on a 1st-party domain WILL disable scriptlet and HTML filtering -- which may lead to anti-blocker mechanism no longer being defused.

Blocking 3rd parties by default WILL break web sites, uncloaked CNAME or not, and either way the recourse is to investigate what needs to be noop'ed.

The only thing CNAME uncloaking does is to make visible what was previously not visible. What was not visible was so entirely because of a server-side decision to hide stuff, and whoever uses dynamic filtering surely would not want server-side decision to dictate where their browser is allowed to connect without their knowledge -- that is the entire point of dynamic filtering. If you do not like the uncloaking of canonical names, dynamic filtering is probably not for you.

You chose to use dynamic filtering because it gives you greater control over filter lists and over the servers' dictates, and thus you implicitly fully accept that sites might be broken as a result, and accept to adjust your ruleset to fix broken web sites.

 

@Brummelchen You're reporting completely normal and expected behavior as a problem. And as gorhill said, you don't need - rather should not use Allow rule on uBO dynamic filtering except for a temporal solution (e.g. false positive hunting). You may think by using uMatrix and uBO dynamic filtering you're better protected from ads and trackers, but the chance is you're less protected by average adblock user by misuse of Allow rule.

I tried to explain that to him but had no effect. It seems he has difficulty in Englsih (tho I'm also not so good, admittedly) so I hope anyone who speaks German to explain him all those things.

 

This is simply not true. I have no allow rule for spiegel.de or any 3rd-party domain (on the contrary, I have some block rules for, e.g., mxcdn.com, emsservice.de, adobedtm.com etc.) and I can watch videos.

 

So this wasn't possible in the past? Also a bummer that it doesn't work on Chromium based browsers, perhaps they can add this API.

 

No, not possible. However, in my observation many of CNAME trackers have already been covered by generic rules in EasyPrivacy. For Chromium the easiest solution will be Geoffrey's list. Switching your DNS to AdGuard DNS or Next DNS may be another easy solution; AG DNS occasionally causes false positives but they're quick to resolve once reported. No experience on Next DNS. Those who uses DNScrypt-proxy or runs their own Stub resolver can also block those tracker.

 

On the previous subject of spiegel.de, I just had to create noop rules for:

Code:

www.spiegel.de d36lkcxq7qra7v.cloudfront.net * noop
www.spiegel.de footprint.net * noop
www.spiegel.de ioam.de * noop

in order to play podcasts. No allow rules required.

 

it do not really matter here if "noop" as first try dont work while "allow" will work then it is used. end of discussion for me about this setting. i am not that idiot as you want people to know, in special for you Yuki.

find one who will translate the whole wiki!

"ioam" is blocked here in general, even ublock is not able to lose restriction
its a kind of optimizely, t4ft, krxd, yieldlab and more.

well, this ofc happens here based on the visible settings above. at least it works and spiegel is ad-free.

 

Guys, i updated ublock to 1.25 but it doesn't load youtube. i use ublock in simple mode.

 

What are you using for Filter lists?

In support of what you're saying, I have also sometimes had to "Allow" a hostname(s) to unbreak a site, although I'm sure no one thinks of your abilities in a derogatory way either In most case I just need to noop a hostname(s).

BTW, I'm curious as to how others of you unbreak sites when using uBlockO in "Medium" mode. my approach, fwiw, is as follows:

1. first put the 3rd-party scripts site specific cell from "Block" to "Noop", then refresh uBlockO to refresh site. This typically unbreaks the site, revealing required and now unblocked hostnames that weren't visible before.
2. Attempt to figure out which of the now revealed hostnames need to be nooped, then noop them in the site-specific cells.
3. Put the 3rd-party scripts cell back to "Block" then refresh to see if this fixes the site.
4. If it does, lock the settings. If not, wash rinse and repeat

 

It is not related to filter list. it happened after update. I update ublock manually.

 

@Brummelchen "Allow" will never be found in any of truly advanced user's rule set, so none of us, gorhill, summerheat, and I use even single Allow. The fact noop didn't work simply means you subscribe problematic filter or you have a problematic rule in My filters, which we can help as we know how to address it, but you didn't show your filter set and even refused any help now. Frankly, often I feel your writing is hard to get meaning as I'm more accustomed to 'formal' English - ofc it's international forum and there are other members as poor at English as you. I hope you at least understood that cloudflare thing is no problem. It appeared just because uBO plugged a hole which existed in previous versions and allowed Mozilla to bypass your blocking rules.

@wat0114 I don't have a single schematic way for this, it all depends on the site - often I start from nooping likely-culprit, sometimes temporary disable medium mode, then viewing the logger I may find the culprit, or it may require me to temporary Allow likely cells to narrow down the culprit in domain level and go back to the logger (filtered by the domain) to find the real culprit.

 

@pandorax YT works fine here, Fx 73.0.1 (64 bit) w/ uBO 1.25.0 medium mode w/ some additional filter sets.

 

Thanks for sharing your approach, Yuki. Somethimes, however, the likely culprit isn't revealed until the 3rd-party script site-specific cell is nooped, which is why I usually just noop the 3rd-party script site-specific cell right away.

As for "Allow" rules, I had small handful of them which I have changed to "noop", so therefore I will try again, but I can tell you from experience "noop" has not always worked to unbreak a site. As you know, there's a lot going on with a number of sites, where when you noop one or more hostame(s), it can result in the spawning of several more hostnames, and for whatever reason, a noop of the required hostname may not work on first attempt, and so only an Allow of the hostanme will unbreak the site. Sorry for the convoluted explanation, but it's about the best way i can explain it.

 

@wat0114 No problem bro, I see what you wanna say. That's basically rare, the last time I remember for that was probably some Russian site. If (combination of) noop(s) or disabling medium mode didn't work, it's time to test Allow. It may be a bit tedious to find out the minimal combination of noop(s) and Allow(s) for the site to work, but you'll finally find it (and more experience you have, the less consumed time will be). Sometimes it may be helpful to first generously Allow many and then reduce the number of Allow as long as the site works (don't forget clearing cache etc. every time and reload). Once found, open the logger (whoops - you should have opened the logger before all this, sorry!) and filter it w/ the allowed domain, then remove your Allow rule - now you see what rule of what filter blocked the connection causing the trouble (it's shown in red row). Click on the 3rd column of the rule ("--"), and you can directly create exception rule for it - (you may need to adjust scope for the rule).

As to likely culprit - often it is shown in yellow, or has likely names (e.g. example.net when you're on the example.com, or assets.somecdn.com etc. If you're watching video the name is often related to its video-serving server. There are many more individual tips I can't talk everything here, say, c.amazon-adsystem.com is often related to a media not working etc.).

 

Yeah, another method how to narrow down the possible culprits is to create block rules in the global column for the ubiquitous adservers/trackers like doubleclick.net, adnxs.com, asadcdn.com, google-analytics.com (the latter taken care by the respective surrogate anyhow) etc. over time. So when searching for the culprit causing a site break, those 3rd-party sites are already left out which makes it a bit easier.

 

Right, because often noop has no effect at all because ofc it enforces static filtering, which is/was probably the cause of these few and rare sites to break; somehow I think they set it up so that certain content in the site would break unless the adverts were allowed. I had maybe only 8 that were allowed since using uBlockO for years.

That's a good idea summerheat, thanks for sharing! Definitely those and many others can be blocked globally on a permanent basis with no consequences at all

 

thanks. i read your settings for spiegel but i think i wont be able to reproduce it here due my settings, i would need your whole ublock settings - and you need mine.

 

My entire settings is more than I'd care to share, but I can show you screenshots of what's allowed and blocked on spiegel, as well as my Filters lists used. I use no Multipurpose filter btw.