No domain name label for cloudfront.net in popupmenu

[ghost]

I've noticed that (at least) for cloudfront.net, only its hosts are listed but not the domain itself as it is made available when the user wishes to perform a rule domain-wide.

Screenshot as an example for 3 calls to cloudfront.net hosts : http://hpics.li/0bfe9cf

As we can see, there are 3 cloudfront.net hosts listed, but not cloudfront.net as a domain
Now, if I set a rule for the first host, then if I change the rule manually in uBlock's My Rules,
from zenmate.com d1dz47xko52i1p.cloudfront.net * noop to zenmate.com cloudfront.net * noop
all three above are handled.

Is cloudfront.net an exception, is it not listed as a domain because the domain itself has no sense, does not exist? Naive hypothesis, only trying to understand.

Thanks

[gorhill]

Dup of #740.

[lucideer]

I can see the argument in #740 - equating githubusercontent.com to co.uk - but I'm not sure I see how this quite applies in the same way to Cloudfront, or at least not as strongly.

Moreover - in terms of pragmatic usability - sites pulling in content from *.githubusercontent.com pull in their own individual content from PREDICTABLESTRING.githubusercontent.com, whereas with cloudfront the prefixes aren't predictable.

[gorhill]

We can't demand the code to have an opinion about what should not be considered a root domain or not after all.

Following PSL to the letter is the sane approach. I can't imagine the alternative of having hard-coded exceptions PSL: messy code, not everybody agreeing on the exceptions, decreased performance. PSL dictates = straightforward, no mess. Not worth to make an issue out of having to create a few more rules for some very specific cases.

[lucideer]

I understand where you're coming from - putting in two separated PSL-based lists would definitely introduce far too much maintenance overhead.

However, on a practical level, any users availing of Dynamic filtering will encounter completely broken sites that they absolutely cannot fix using the popdown. As one of those users - I personally wouldn't actually mind seeing an option to allow all resources from "co.uk" (which I would simply never click in practice). Not sure if this is something you'd consider...

[gorhill]

Not sure if this is something you'd consider

I did, during early development of HTTPSB. These TLDs add more noise than anything else in the UI. Aside the rare misunderstanding that d1dz47xko52i1p.cloudfront.net is actually a root domain, a misunderstanding easily dispelled, no complaints.

[eproxus]

One thing I often do is to add all the domains which, for example for GitHub, generates the following rule:

github.com avatars1.githubusercontent.com * allow
github.com avatars2.githubusercontent.com * allow
github.com avatars3.githubusercontent.com * allow

The tediousness comes from visiting another page on GitHub, which is then slightly broken because there was a new domain used, e.g. avatars4.githubusercontent.com).

Then I go into the rules tab and distill it, like so:

github.com githubusercontent.com * allow

For the site GitHub, I'm completely fine with allowing all requests from github.com to githubusercontent.com. It solves all my problems using that side. Basically the same applies to the Cloudfront problem.

Surely, there must be a better way to enable this in the UI? For example, expanding domains could show all domains in the path in a pyramid:

example.com
secure.example.com
resources.secure.example.com
images.resources.secure.example.com

That way, I could choose to allow all requests from a page to only secure.example.com without having to deal with all the sub domains independently.

[gorhill]

expanding domains could show all domains in the path in a pyramid

Click the all cell to expand/collapse.

[eproxus]

Not for githubusercontent.com or cloudfront.net (which is by far the most common use case). Am I missing something from #740? I understand that these domains are somehow considered "suffices" by some entity somewhere, but for me as a user it doesn't help at all. The other way around, it generates more work for me.

[gorhill]

it generates more work for me

Ask the maintainers of the PSL to do extra work to create the exceptions you think should be made to save you work.

Notice that there are cloudfront.net-based domains in the malware lists.

[eproxus]

I would assume blocklists would prevail over rules?

Don't get me wrong, I understand the implementation reasoning and the PSL rules / intentions. I just think this is an edge case which makes it worse for the users where the reasoning is mostly technical.