hagezi / dns-blocklists

DNS-Blocklists: For a better internet - keep the internet clean!
GNU General Public License v3.0
6.14k stars 207 forks source link

Samsung internet default home page blocked #3807

Open user716253 opened 5 days ago

user716253 commented 5 days ago

Which AdBlocker/DNS cloud service do you use?

ControlD

Other

No response

ControlD users

NextDNS users

With which block list(s) does the problem occur?

Multi PRO++

Which domain(s) should be unblocked?

quickaccess.internet.apps.samsung.com

Why should the domain(s) be unblocked?

This is the default home page of samsung internet

Privacy

hagezi commented 4 days ago

The domain is not blocked, it is only blocked:

config-api.internet.apps.samsung.com
sia.internet.apps.samsung.com
www.internet.apps.samsung.com

ControlD seems to have a life of its own and truncates the www when parsing the lists and as a result internet.apps.samsung.com is completely blocked, not just www.internet.apps.samsung.com. This is only the case in ControlD and should not be the case.

A bug @yegors.

github-actions[bot] commented 4 days ago

Thank you for your support. The domain(s) has/have been added to the allowlist and will be removed with the next release.

hagezi commented 4 days ago

@user716253 I will remove www.internet.apps.samsung.com until the bug in ControlD is fixed.

yegors commented 4 days ago

Hi,

We indeed strip out "www." from the domains and normalize the list as there are frequently 2 entries for many domains, ie:

www.domain.com domain.com

This saves quite a bit of memory, since all the lists we enforce have to exist in RAM on every DNS server. This is usually OK, but in scenarios like this, I see how it creates a problem. What's actually bad about "www.internet.apps.samsung.com", it appears to host a bunch of legal docs / ToS / privacy notices.

Are there any other examples? We could make exceptions for certain filters not to strip out www when they're downloaded + parsed into a format we use.

hagezi commented 4 days ago

Hi @yegors, I understand, but in my view this only makes sense for:

It makes no sense for sources that are already compressed and therefore do not contain any unnecessary subdomains. A general truncation of www also for subdomains distorts the list. In most cases this will not be negative, but there are cases like this and the list no longer corresponds to the original.

yegors commented 3 days ago

Fair enough, we'll make an exception for the 3rd party filter parser. Will reply here when this is done.