I develop a FOSS adblocking DNS stub resolver and client. And I believe, DNS-based content-blocking will become drastically ineffective as it gets more popular. Besides CNAMEs breaking all sorts of assumptions a client software makes (and hence also causing security headaches in the process as outlined in the paper), there are a couple other DNS cloaking techniques that the paper doesn't discuss: 1. ALIAS records (no…
Cname / DNS based third party tracking
11–20 of 49 posts
Re: Cname / DNS based third party tracking
#12I develop a FOSS adblocking DNS stub resolver and client. And I believe, DNS-based content-blocking will become drastically ineffective as it gets more popular. Besides CNAMEs breaking all sorts of assumptions a client software makes (and hence also causing security headaches in the process as outlined in the paper), there are a couple other DNS cloaking techniques that the paper doesn't discuss: 1. ALIAS records (no…
Correct, because first-party / third-party is not a technical difference, but a social/commercial one. The app.example.com may run in a different cloud and be part of the same first-party service.
Re: Cname / DNS based third party tracking
#13I develop a FOSS adblocking DNS stub resolver and client. And I believe, DNS-based content-blocking will become drastically ineffective as it gets more popular. Besides CNAMEs breaking all sorts of assumptions a client software makes (and hence also causing security headaches in the process as outlined in the paper), there are a couple other DNS cloaking techniques that the paper doesn't discuss: 1. ALIAS records (no…
IPV6 also greatly complicates IP-based blocking. There are so many IPV6 addresses that it'd be relatively cheap for an ad tracker to develop a system that uses a new one every day.
Re: Cname / DNS based third party tracking
#14I develop a FOSS adblocking DNS stub resolver and client. And I believe, DNS-based content-blocking will become drastically ineffective as it gets more popular. Besides CNAMEs breaking all sorts of assumptions a client software makes (and hence also causing security headaches in the process as outlined in the paper), there are a couple other DNS cloaking techniques that the paper doesn't discuss: 1. ALIAS records (no…
At what point does an opt-in approach make more sense than opt-out?
Re: Cname / DNS based third party tracking
#15I develop a FOSS adblocking DNS stub resolver and client. And I believe, DNS-based content-blocking will become drastically ineffective as it gets more popular. Besides CNAMEs breaking all sorts of assumptions a client software makes (and hence also causing security headaches in the process as outlined in the paper), there are a couple other DNS cloaking techniques that the paper doesn't discuss: 1. ALIAS records (no…
I don't see a way out of this without the ability to selectively block or fake browser APIs and detect tracking with heuristics, just like old antivirus and spyware blocking software.
Re: Cname / DNS based third party tracking
#16I develop a FOSS adblocking DNS stub resolver and client. And I believe, DNS-based content-blocking will become drastically ineffective as it gets more popular. Besides CNAMEs breaking all sorts of assumptions a client software makes (and hence also causing security headaches in the process as outlined in the paper), there are a couple other DNS cloaking techniques that the paper doesn't discuss: 1. ALIAS records (no…
AFAIK, cloudflare only flattens CNAMEs at the root level, and that’s because CNAMEs at the root are not a standard. They have to convert it to an A record to be standards compliant.
Re: Cname / DNS based third party tracking
#17I develop a FOSS adblocking DNS stub resolver and client. And I believe, DNS-based content-blocking will become drastically ineffective as it gets more popular. Besides CNAMEs breaking all sorts of assumptions a client software makes (and hence also causing security headaches in the process as outlined in the paper), there are a couple other DNS cloaking techniques that the paper doesn't discuss: 1. ALIAS records (no…
The fact that the technique relies on a CNAME or some other DNS indirection seems to suggest that the ad server or tracker will have a different IP from the website. That may be another weak point in any effort to conceal the fact that some resources referenced in the page or Javascript files are only necessary for advertising purposes. If both content and ad cruft were being served from a single IP, then that might pose more of a challenge in deciphering what to retreieve. I have yet to see that and doubt I ever will.
I am a believer that ultimately whitelisting is more effective than blacklisting. Request what you want, leave the rest. As opposed to letting a browser request everything according to a web developer's wishes, and then you try to block stuff. With extensions, third party assistance, etc.
Re: Cname / DNS based third party tracking
#18Earlier quoted context omitted.
IPV6 also greatly complicates IP-based blocking. There are so many IPV6 addresses that it'd be relatively cheap for an ad tracker to develop a system that uses a new one every day.
If you get allocated a /32, you have 95 bits of addresses to play with. You could use a different IP every millisecond and not have problems.
Re: Cname / DNS based third party tracking
#19Earlier quoted context omitted.
IPV6 also greatly complicates IP-based blocking. There are so many IPV6 addresses that it'd be relatively cheap for an ad tracker to develop a system that uses a new one every day.
If you get allocated a /32, you have 95 bits of addresses to play with. You could use a different IP every millisecond and not have problems.
Re: Cname / DNS based third party tracking
#20I guess you could build a tool that blocks cnames that point to other domains. But then they could switch to A records, which I guess could be blocked with lists of the IPs of tracking parties. Or just by blocking all hosts besides the one being requested (which I personally prefer in all web design). Then again they could always just put a redirect/rewrite in their web server to a any third party they want, but atle…
The only way to stop this permanently is to address the root cause. As far as I can tell that would be through permissioned browser api access. The UX might become a bit unwieldy though Google’s idea of limiting the number of bits of identifying info revealed might be a way around that.
But then there is the issue of sites blocking access when more bits of identity are not given. This would lead to another cat and mouse game of tricking sites into thinking they are getting globally useful identity bits and the sites trying to counter this. This might be an easier game to play for the users where they randomly generate and isolate this data per domain or container but I’m not sure.