Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: TrackingTheTrackers – Is a website disguising its 3rd-party trackers?

trackingthetrackers.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Show HN: TrackingTheTrackers – Is a website disguising its 3rd-party trackers?

#31

Post by garren »

icebraining wrote: post #28
3xblah wrote: post #23

Earlier quoted context omitted.

"So, in practical terms, what's the difference between this CNAME trick and building the same thing in-house to run your own analytics?" In practical terms, based on what we have seen up to now, few websites will run their own analytics. Thus, focusing on the third party services is effective against most tracking. The "CNAME trick" might be viewed as a good thing because it is putting evolutionary pressure on users…

> it is putting evolutionary pressure on users to utilise DNS to "block" ads instead of using popular graphical web browsers to do the work How so? Browser and browser addons are perfectly capable of blocking these subdomains.

It's not that browser add-ons aren't capable of blocking them, it's that a) browser extensions generally don't have access to dns resolution, b) even if they did, cname tracker resolution would increase overall latency due to multiple requests to identify trackers /outside/ of normal resolution, c) it's trivial for a host to create a new cname for a tracker, so automating this makes a lot of sense from their perspective in order to avoid blocklists.

Extensions now have to identify which cnames are a front for which trackers, block the new tracker, and somehow manage to stay below the max rules-per-extension that the browser allows (30k for Chrome[0]). See original nextdns.io post for details [1].

[0] https://www.xda-developers.com/google-chrome-manifest-v3-ad-...

[1] https://medium.com/nextdns/cname-cloaking-the-dangerous-disg... ( https://outline.com/Y6PKr3 )

Re: Show HN: TrackingTheTrackers – Is a website disguising its 3rd-party trackers?

#32

Post by bscphil »

garren wrote: post #31
icebraining wrote: post #28

Earlier quoted context omitted.

> it is putting evolutionary pressure on users to utilise DNS to "block" ads instead of using popular graphical web browsers to do the work How so? Browser and browser addons are perfectly capable of blocking these subdomains.

It's not that browser add-ons aren't capable of blocking them, it's that a) browser extensions generally don't have access to dns resolution, b) even if they did, cname tracker resolution would increase overall latency due to multiple requests to identify trackers /outside/ of normal resolution, c) it's trivial for a host to create a new cname for a tracker, so automating this makes a lot of sense from their perspect…

> it's trivial for a host to create a new cname for a tracker, so automating this makes a lot of sense from their perspective in order to avoid blocklists.

This is the part I'm skeptical of. If your site is HTTPS, and a user forbids mixed content, all your ads have to be served over HTTPS. That means whenever you create a new CNAME, the ad server (not run by you) has to generate a new certificate, or else you have to give them a cert for *.yourdomain.com. Both are pretty big asks. Even if the ad server can automatically generate new certs, they're going to show up in a transparency log and can be automatically added to blocklists based on that.

So I'm not sure it's going to make much of a difference which blocking method people use. All the Easylist (or whoever) folks have to do is add new subdomains to their blocklist - the exact same thing an ad blocking DNS provider is doing.

Edit: the process for obtaining a certificate from Adobe for a new tracking CNAME looks absolutely excruciating, which is good evidence for my point. https://docs.adobe.com/content/help/en/core-services/interfa...

Re: Show HN: TrackingTheTrackers – Is a website disguising its 3rd-party trackers?

#34

Post by egdod »

teamjimmyy wrote: post #15

We now have trackers acting like first-party properties, but where do you draw the line between first-party and third-party? What I mean is, if I build my own in-house analytics app that does a lot of what Adobe's product does, should that be blocked too? I specifically mean for site analytics, like Experience Cloud or GA, not serving ads. Ad block is different IMO. If this is hosted on a first party subdomain you're…

All analytics should be blocked.

Re: Show HN: TrackingTheTrackers – Is a website disguising its 3rd-party trackers?

#35

Post by x0x0 »

munchbunny wrote: post #16
teamjimmyy wrote: post #15

We now have trackers acting like first-party properties, but where do you draw the line between first-party and third-party? What I mean is, if I build my own in-house analytics app that does a lot of what Adobe's product does, should that be blocked too? I specifically mean for site analytics, like Experience Cloud or GA, not serving ads. Ad block is different IMO. If this is hosted on a first party subdomain you're…

It depends on why you care about the distinction. If you're talking from a purely privacy perspective, the important questions are (1) are you taking analytics? (2) what are you doing with them? (3) is that in line with users' expectations? Third party, or third party disguised as first party, is only problematic because of an implied "there's very little keeping the third party from using your data for things that a…

> violate the general assumption that first party data stays first party

How? Because they can't do that with cookies.

I think the most prominent objection to 3rd party cookies is they allow systematic tracking. This seems like they just help eg apple or whomever understand what you're doing on that same site.

Re: Show HN: TrackingTheTrackers – Is a website disguising its 3rd-party trackers?

#36

Post by 3xblah »

bscphil wrote: post #32
garren wrote: post #31

Earlier quoted context omitted.

It's not that browser add-ons aren't capable of blocking them, it's that a) browser extensions generally don't have access to dns resolution, b) even if they did, cname tracker resolution would increase overall latency due to multiple requests to identify trackers /outside/ of normal resolution, c) it's trivial for a host to create a new cname for a tracker, so automating this makes a lot of sense from their perspect…

> it's trivial for a host to create a new cname for a tracker, so automating this makes a lot of sense from their perspective in order to avoid blocklists. This is the part I'm skeptical of. If your site is HTTPS, and a user forbids mixed content, all your ads have to be served over HTTPS. That means whenever you create a new CNAME, the ad server (not run by you) has to generate a new certificate, or else you have to…

"... the exact same thing an ad blocking DNS provider is doing."

Just to be clear, I was not advocating using third party DNS.

Using djbdns I can just "block" all non-www subdomains for a domain with a single line in a zone file (if using tinydns) or a single byte file in a directory (if using dnscache) and then add entries in the zone file for any specific subdomains I want to "allow".

It is only an opinion, but I think the ability to wildcard all subdomains makes DNS-based methods of blocking trackers easier to manage and allows it to scale better than having to list every tracker subdomain in a blocklist.

Re: Show HN: TrackingTheTrackers – Is a website disguising its 3rd-party trackers?

#37

Post by zonidjan »

x0x0 wrote: post #35
munchbunny wrote: post #16

Earlier quoted context omitted.

It depends on why you care about the distinction. If you're talking from a purely privacy perspective, the important questions are (1) are you taking analytics? (2) what are you doing with them? (3) is that in line with users' expectations? Third party, or third party disguised as first party, is only problematic because of an implied "there's very little keeping the third party from using your data for things that a…

> violate the general assumption that first party data stays first party How? Because they can't do that with cookies. I think the most prominent objection to 3rd party cookies is they allow systematic tracking. This seems like they just help eg apple or whomever understand what you're doing on that same site.

There are plenty of other ways to fingerprint a user. https://amiunique.org/

Re: Show HN: TrackingTheTrackers – Is a website disguising its 3rd-party trackers?

#38

Post by xwvvvvwx »

drdaeman wrote: post #29
xwvvvvwx wrote: post #19

Earlier quoted context omitted.

disable javascript.

JavaScript, cookies and browser cache.

You can also use temporary containers [1] to present a clean and isolated cache & cookie store for every new website visit. This is both less fingerprintable and more usable than disabling cache and cookies.

It is also worth noting that caches other than the browser cache can also be abused to track users: http://dnscookie.com/

[1]: https://medium.com/@stoically/enhance-your-privacy-in-firefo...

Re: Show HN: TrackingTheTrackers – Is a website disguising its 3rd-party trackers?

#39

Post by bscphil »

3xblah wrote: post #36
bscphil wrote: post #32

Earlier quoted context omitted.

> it's trivial for a host to create a new cname for a tracker, so automating this makes a lot of sense from their perspective in order to avoid blocklists. This is the part I'm skeptical of. If your site is HTTPS, and a user forbids mixed content, all your ads have to be served over HTTPS. That means whenever you create a new CNAME, the ad server (not run by you) has to generate a new certificate, or else you have to…

"... the exact same thing an ad blocking DNS provider is doing." Just to be clear, I was not advocating using third party DNS. Using djbdns I can just "block" all non-www subdomains for a domain with a single line in a zone file (if using tinydns) or a single byte file in a directory (if using dnscache) and then add entries in the zone file for any specific subdomains I want to "allow". It is only an opinion, but I t…

> Just to be clear, I was not advocating using third party DNS.

Well, you weren't, but the OP is a Show HN by a company offering such a service.

> It is only an opinion, but I think the ability to wildcard all subdomains makes DNS-based methods of blocking trackers easier to manage

I dunno, I think for most people uBlock rules are going to be easier to handle then setting up their own DNS server. Sure, I have my own resolver too (Unbound), but since you need an ad blocker on top of that anyway, I just keep my rules in uBlock. The following is all you need to block all subdomains but allow the bare domain:

  ||example.org^
  @@*/example.org/*
Or to allow www:

  @@www.example.org^

Re: Show HN: TrackingTheTrackers – Is a website disguising its 3rd-party trackers?

#40

Post by x0x0 »

zonidjan wrote: post #37
x0x0 wrote: post #35

Earlier quoted context omitted.

> violate the general assumption that first party data stays first party How? Because they can't do that with cookies. I think the most prominent objection to 3rd party cookies is they allow systematic tracking. This seems like they just help eg apple or whomever understand what you're doing on that same site.

There are plenty of other ways to fingerprint a user. https://amiunique.org/

That really doesn't answer the question. Munchberry claims these analytics tools have cross domain tracking and I'm asking how, precisely. In part because of professional interest, and in part because I don't actually think it's true.
Post reply on HN