cname-trackers VS ip-blindness

Note that CNAMEs is literally caused by GDPR, and the pathway every single ad or tracking company seems to go sooner or later.

For people not understanding how it works: you can set a CNAME entry on your tracker.domain.tld to bypass all Browser's third-party tracking preventions, and make it look like it's a normal subdomain of your website.

You need to make a CNAME tracker database manually by resolving the reverse entries for known IPs. Usually there is hundreds or thousands of CNAME entries pointing to the same IP address.

The AdGuard team also made a database for this, in case anyone needs it for UBOL [1]

[1] https://github.com/AdguardTeam/cname-trackers

So nextdns’s third party disguised trackers is actually really tiny of a list, like 30 domains. (Im trying to add more so it has the same amount of cname’s blocked as adguard). Anyways, the reason why the list is so tiny is because it uses wildcard logic so all subdomains get blocked. It already uses some of the cname companies that adguards cname-tracker list uses but not all. Hopefully my pull request can get merge eventually because then the setting will be a little bit more effective

I see fathom on Adguard CNAME tracker. Example:

> uBlock Origin already performs CNAME decloaking and blocks this approach, it’s pretty cool.

... which in return is a static list of domains which needs to be regularly updated, and therefore is not really failsafe. uBlock0 uses Adguard's scraped dataset [1] as a source to do this, as Chrome Extensions cannot make DNS requests without a DNS-via-HTTPS endpoint.

[1] https://github.com/AdguardTeam/cname-trackers

Not sure where I should report this, but I seem to have found a CNAME cloaking tracker which i don't find in either the original or disguised tracker lists here https://github.com/AdguardTeam/cname-trackers Is there a mechanism for reporting these? I saw someone posted a list on github, but no response there. Maybe this example is just ordinary tracking though?

Are you able to block trackers/ads using this new CNAME cloaking technique? https://github.com/AdguardTeam/cname-trackers

More here: https://github.com/bslassey/ip-blindness

Yes, but have in mind that in a future it may not be possible. Take a look to the Gnatcatcher proposal: https://github.com/bslassey/ip-blindness

> at the very least, the ad network will be able to see your IP and know that you like athletic shoes and visited www.wereallylikeshoes.com. If you visit some other domain first-ad-network.com owns with the same IP it within a small window of time, it can be pretty confident it's the same person and even store some client side data at that point. It feels like they can construct a reasonably good profile about their users by using that technique.

Yes, there are a lot of user identifying bits in an IP address. Chrome has two proposals: https://github.com/bslassey/ip-blindness I'm not sure what other browsers are thinking?

> That's considering the browser doesn't leak out any other potentially identifying information.

Which they definitely do. All the browsers are working on figuring out how to thwart fingerprinting, and it's really hard. I am glad, at least, that we were able to get Google Ads to publicly commit to not fingerprinting.

> when you click on the ad, they know one interest about you and, if you clicked in ads from other campaigns they run, they may reconstruct your profile well

Yes, when people click on ads in Turtledove the advertiser does learn something. This is a huge improvement to the status quo where advertisers learn things just by bidding, or an intermediate stage where advertisers learn things when they win an auction -- users don't click on ads very often, so the amount of information leaked this way is very low.

Exactly how much information the advertiser is able to learn on a click is still very much up in the air, so if you have views on this you might consider participating on the repo?

"Near-path NAT"[1] has been suggested as a mechanism that browsers can use to proxy requests through an intermediate server, similar to what you suggest.

[1] https://github.com/bslassey/ip-blindness/blob/master/near_pa...

> and you know my IP address

https://www.chromium.org/Home/chromium-privacy/privacy-sandb... links to https://github.com/bslassey/ip-blindness for how they intend to handle this.

(Disclosure: I work on ads at Google, speaking only for myself)

If you want to prevent fingerprinting, you need to look at where the identifying bits are coming from. (ex: https://coveryourtracks.eff.org/) The IP address provides enough bits to uniquely identify many users, and when combined with just a few more bits, to identify almost anyone.

TOR is one solution here, which you could potentially also describe as "adding forced MitM to every connection". The proposals in https://github.com/bslassey/ip-blindness/blob/master/near_pa... and https://github.com/bslassey/ip-blindness/blob/master/willful... have different tradeoffs than TOR, with the "TOR is painfully slow" problem being a big one.

If you have better ideas, though, I would be very interested in reading them!