Live data from Hacker News

Cname / DNS based third party tracking

arxiv.org

11–20 of 49 posts

Re: Cname / DNS based third party tracking

#11

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…

At what point does an opt-in approach make more sense than opt-out?

Re: Cname / DNS based third party tracking

#12

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…

> is foolish to rely on DNS to discern between first-party and third-party

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

#13

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…

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

#14

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…

At what point does an opt-in approach make more sense than opt-out?

Cookie banners were invented for this purpose but as we can see this is not the best solution. How would anyway anyone opt-in to any kind of tracking after all the privacy issues in the last years? But some kind of standard would be really important for sure. I'm working on the implementation of tracking solutions with the respect of user consent and privacy but even simple website analytics gets really complicated because there are no industry standards currently, every 3rd party handles user consent differently. And we did not even got to the point of gathering the user consent..

Re: Cname / DNS based third party tracking

#15
post #8

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…

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.

Unfortunately, both Chrome and Safari seem dead set on killing any ability for extensions to block based on heuristics.

Re: Cname / DNS based third party tracking

#16

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…

> Another variant of this is, some DNS nameservers (like Cloudflare) flatten CNAME records (aka transparently ALIAS endpoints)

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

#17

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…

I just use an HTTP client that does not automatically load resources nor run Javascript. Using such a client, the user, by voluntarily typing the name of a website or following a URL, decides what to retrieve (a page, e.g., index.html), not the web developer. If the website developer is allowed to decide what the user involuntarily retrieves, then it stands to reason a website seeking revenue through online advertising will make sure the user involutarily retrieves ads, or cookies from a tracker. For example, by letting the ad server or tracker use a subdomain of the website as a "cloak".

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

#18

Earlier 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.

What would be wrong with blocking the entire /32 if you know the owner of it is using it in such a way?

Re: Cname / DNS based third party tracking

#19

Earlier 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.

Yeah, but they'd all be in the same /32, which is trivial to block. You'd have to intersperse "legitimate" users through your space to thwart that.

Re: Cname / DNS based third party tracking

#20

I 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…

Ya, blocking requests is a bandaid for preventing tracking.

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.

Post reply on HN