Consider Alt-Names as 1p (Feature Request)

Rudxain commented 7 months ago

Prerequisites

[X] I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
[X] This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
[X] This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
[X] I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
[X] The issue is not present after disabling uBO in the browser.
[X] I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

[X] uBO is the only extension.
[X] uBO uses default lists and settings.
[X] using a new, unmodified browser profile.

Description

The what

If the visited domain provides SSL/TLS certificate, then uBO would parse the "Subject Alternative Names" to get a set of domains that can be considered 1st-party in relation to the visited domain.

This would be an opt-in global setting, or a per-domain dyn-rule.

The why

This would make "Hard Mode" extremely convenient to use, as 3p content would be "truly 3p" instead of "any domain that's not a sub-domain of the current domain".
There would be minimal sacrifice of privacy+security, as not all 1st-party domains are SANs.
This would allow cleaner rule-sets, as the "boilerplate pollution" would be non-existent.
Future-proof rule-sets! New domains become SANs, and deprecated/unregistered domains may get removed from the set.

A specific URL where the issue occurs.

https://en.wikipedia.org

Steps to Reproduce

Enable "Advanced" mode
Enable "Hard Mode"
Visit any domain owned by Wikipedia, Google, GH, etc...

Expected behavior

G and YT domains and sub-domains should be mostly allowed (noop).
wikimedia.org should be allowed when visiting wikipedia.org
githubassets.com should be allowed for GH

Actual behavior

All non-identical domains are completely blocked by default

uBO version

1.55.0

Browser name and version

Firefox Mobile: 121

Operating System and version

Android 12.0

gwarser commented 7 months ago

I see no way to access this data from inside the browser.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/CertificateInfo

And I don't think people expect YT be first party to G.

gwarser commented 7 months ago

Google cert shows only:

DNS Name www.google.com

YT lists pretty much all Google domains.

gorhill commented 7 months ago

That information can be found in https://github.com/duckduckgo/tracker-radar, "Licensed under the CC BY-NC-SA 4.0". It's 155MB compressed. I did think about making use of this in a distant past.

And I don't think people expect YT be first party to G

Neither Google-owned doubleclick.net. Such information should be at most a visual hint, not acted upon automatically by uBO.

uBlock-user commented 7 months ago

This would make "Hard Mode" extremely convenient to use, as 3p content would be "truly 3p" instead of "any domain that's not a sub-domain of the current domain".

Hard-mode is not for convenience, only for those who have the patience to deal with breakage as it comes. The very premise here is wrong.

There would be minimal sacrifice of privacy+security, as not all 1st-party domains are SANs.

No, you're asking uBO to trust domains just because a company owns them.

Rudxain commented 7 months ago

Hard-mode is not for convenience, only for those who have the patience to deal with breakage as it comes.

Correct. "Hard Mode" would no longer be "hard" (if the user opts in), it would be "Medium" or "Easy". But the point of these modes isn't "patience" or "difficulty", it's about choosing what type of content to block. If an "average web user" wants higher security and/or privacy than what static-filters provide, they can block all 3p without sacrificing navigation efficiency (I mean the efficiency of the user browsing the web, not the browser software)

No, you're asking uBO to trust domains just because a company owns them.

What's the point of of blocking apis.google.com if googleapis.com is nooped? (or vice-versa?) Both are likely served by the same network of physicial machines. If anything, doing so increases fingerprinting entropy, it doesn't help at all with privacy.

I would suggest a per-domain dyn-rule, instead of a global setting. This way, we can enable SANs for Wikipedia, but not G

Rudxain commented 7 months ago

Google cert shows only:
DNS Name www.google.com
YT lists pretty much all Google domains.

Thanks for pointing it out! I've edited my post to use Wikipedia as example instead. I thought gstatic.com was a SAN

uBlock-user commented 7 months ago

What's the point of of blocking apis.google.com if googleapis.com is nooped?

Performance. The less number of domains you connect to, the faster the page loads

If anything, doing so increases fingerprinting entropy, it doesn't help at all with privacy.

You don't install uBlock for fingerprinting protection. Secondly, I don't want google to know list of resources I connected to, hence lesser data on me to them(only bare minimal that fulfills my requirement), so yes it does help with privacy.

You need to understand, dynamic filtering is not about trust. That's for you to decide, uBO is not going to do that for you.

Yuki2718 commented 7 months ago

While I oppose making this default-behavior, adding as an option might make sense. Should be availabe on filters too as this might mitigate FP like https://github.com/uBlockOrigin/uAssets/issues/20983 in some cases.

Rudxain commented 7 months ago

Performance.

I agree. But that's off-topic. We're talking about trust and privacy, not efficiency. The G-APIs thing was just an example.

Besides, what's wrong with trusting a cert that was already trusted by a browser? (I'm ignorant about this subject)

You don't install uBlock for fingerprinting protection. Secondly, I don't want google to know list of resources I connected to, hence lesser data on me to them(only bare minimal that fulfills my requirement), so yes it does help with privacy.

I agree. Correct. But not all users have the same privacy preferences. And not all users care that much about web minimalism (anti-bloat).

You need to understand, dynamic filtering is not about trust.

I wasn't even the one that introduced that topic! I'm fine using Hard-Mode as it is. I'm just suggesting this feature for other users (and partially myself). Dyn-rules could still be used to block domains nooped by SANs

Rudxain commented 7 months ago

I oppose making this default-behavior

I also do! I changed the title, and forgot to edit the issue-post accordingly. It always was an opt-in proposal, from the very beginning.

krystian3w commented 5 months ago

Maybe possible use shorter (alt name) $img instead $image and $js/$inline-js instead $script / $inline-script.

gorhill commented 4 months ago

I prefer to decline.

Rudxain commented 1 day ago

After noticing the CNAME problem, I've changed my mind! It's perfectly reasonable to reject this feature, because it could be exploited in similar ways.

So what if users had the freedom to pick which hosts are 1p and which aren't? Something like #3252 could help, but I'd propose something different. Should I open a new issue to explain what I mean?

gwarser commented 1 day ago

People don't see the dynamic rules list data, they see the popup UI. #3252 will only increase the work needed to write the rules.

garry-ut99 commented 1 day ago

It seems that's the same reason for which two previous requests were declined: https://github.com/uBlockOrigin/uBlock-issues/issues/439#issuecomment-466779216 and ( https://github.com/uBlockOrigin/uBlock-issues/issues/685#issuecomment-516372138 & https://github.com/uBlockOrigin/uBlock-issues/issues/685#issuecomment-516386971 ) (not that I'm complaining, I'm just providing related info).

uBlockOrigin / uBlock-issues