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

Cname cloaking, a disguise of third-party trackers

medium.com

Post reply on HN
Print view View original

61–70 of 202 posts

Re: Cname cloaking, a disguise of third-party trackers

#61

Post by stefan_ »

dgoldstein0 wrote: post #34
stefan_ wrote: post #9

Earlier quoted context omitted.

So website.com decided to sellout and now the cookies you send to website.com that betrayed your trust are also sent to it's chosen third-party tracker? That is a distinction without difference. The security implication is storing any data with website.com!

Yes, but www.website.com cookies won't be sent. But you'll have to crack open devtools to figure out which one each website is doing.

Yes, the cookies of the website that installed a third-party tracker to spy on you will be sent to the website and the tracker. They could always do that.

Re: Cname cloaking, a disguise of third-party trackers

#62

Post by TACIXAT »

I have done something similar as an experiment. I wanted mixpanel analytics on a site for element interaction. I proxied mixpanel through a URL endpoint (maybe it was a subdomain). I had it not load analytics if DNT was set. It was a fun hack but more work than it was worth for my low traffic site.

Re: Cname cloaking, a disguise of third-party trackers

#63

Post by tsimionescu »

going_to_800 wrote: post #58

I worked in ad space 7 years ago. Companies that provide content need to get paid for the content one way or another, either paying a fee or ads, nobody can argue with this. There needs to be an organization that imposes ad guidelines(like only specific formats, not being intrusive, etc) for both websites and ad companies. They should verify the ads/websites based on user reports and if they find something, to kick t…

There are other alternatives. Alternative monetization schemes, such as those offered by Patreon or Twitch or Kickstarter can be found.

Also, ads can be placed teh same way they were in newspapers - the ad company would submit ads to the content creator, who would manually chose which ads to include, and where.

Re: Cname cloaking, a disguise of third-party trackers

#64

Post by brian-armstrong »

zelly wrote: post #54

I knew something like this would come up. I always wondered why ad/tracking companies never proxied through the first-party domain (or in a more extreme case, the first-party server itself) to skirt adblock. Suppose you load example.com/article. Ad Agency serves ad/tracking assets from example.com/article/Zqj7MOm.js. When you reload, it serves from example.com/article/llc9h76.js. How do you block it? You can't. Getti…

As I understand it, ad companies and the people who sell their websites to ad companies have some base level of distrust of one another, which has kept them from integrating like this. Ad companies want to serve the code to be sure that no click fraud is occurring, and people who run websites don't want to completely hand over their domain. But it's easy to see them forging this alliance if ad delivery depended on it.

Re: Cname cloaking, a disguise of third-party trackers

#65

Post by zelly »

zelly wrote: post #54

I knew something like this would come up. I always wondered why ad/tracking companies never proxied through the first-party domain (or in a more extreme case, the first-party server itself) to skirt adblock. Suppose you load example.com/article. Ad Agency serves ad/tracking assets from example.com/article/Zqj7MOm.js. When you reload, it serves from example.com/article/llc9h76.js. How do you block it? You can't. Getti…

I can think of a couple mitigations against this future:

- Disable JavaScript

- Render SPAs off-site (or in some sandbox with a different network interface) and return the static HTML and CSS

Good enough to read news articles

Re: Cname cloaking, a disguise of third-party trackers

#66

Post by jefftk »

x0x0 wrote: post #57
jefftk wrote: post #55

Earlier quoted context omitted.

Reverse proxying is a little harder, but not much. In NGINX, for example: location /adtech/ { proxy_pass https://adtech.example/; } What additional trust are you thinking about? HttpOnly cookies are already sent when you use the subdomain approach.

js running on your domain can read eg login cookies at least if you cname definitelynotads.yourdomain.com to js.ads.com, the javascript running on definitelynotads... can't read host-only login cookies on yourdomain.com.

Sites generally set Domain= on their cookies, and so include subdomains. For example, if you click "sign in" on apple.com it brings you to secure2.store.apple.com and after entering your password it sets a cookie with "Path=/; Domain=apple.com; Secure; HttpOnly".

You're right that this does reduce security on some sites: if domain.example doesn't set Domain= on their cookies then ads.domain.example (CNAMED to js.ads.example) won't see the cookies but domain.example/ads would. This is pretty rare, though, because sites you log into generally do need their cookies to work across subdomains.

Except this problem is easier to handle with reverse proxies than with subdomains: with subdomains the cookies are sent whether you want to or not, while with a reverse proxy the site owner can configure it to strip cookies.

Re: Cname cloaking, a disguise of third-party trackers

#67

Post by zelly »

brian-armstrong wrote: post #64
zelly wrote: post #54

I knew something like this would come up. I always wondered why ad/tracking companies never proxied through the first-party domain (or in a more extreme case, the first-party server itself) to skirt adblock. Suppose you load example.com/article. Ad Agency serves ad/tracking assets from example.com/article/Zqj7MOm.js. When you reload, it serves from example.com/article/llc9h76.js. How do you block it? You can't. Getti…

As I understand it, ad companies and the people who sell their websites to ad companies have some base level of distrust of one another, which has kept them from integrating like this. Ad companies want to serve the code to be sure that no click fraud is occurring, and people who run websites don't want to completely hand over their domain. But it's easy to see them forging this alliance if ad delivery depended on it…

What if they didn't need to trust the website operators because they only pay them if users click? When the user clicks, it goes through the ad company's domain with the Referrer who would be paid for it.

Re: Cname cloaking, a disguise of third-party trackers

#68

Post by devhwrng »

cheald wrote: post #12

Use a Pihole + your adblocker of choice - defense in depth. It's easy to set up, brainless to keep updated, and helps to protect all devices on your network, not just the things that can run uBlock. I've got mine running in a Docker container, which upstreams to a stubby container, which gets DNS-over-TLS, so I get adblocking and DNS query encryption out to Cloudflare for the whole network, and it's really not all th…

I do this personally and it's great. I've even set this up for extended family. But any real solutions to the problem will not be technological, they will have to be legislative...

Given that no reasonable legislation will likely pass against adtech, I'll be stuck buying rpis as gifts again for the next several years.

Re: Cname cloaking, a disguise of third-party trackers

#69

Post by ignoramous »

going_to_800 wrote: post #58

I worked in ad space 7 years ago. Companies that provide content need to get paid for the content one way or another, either paying a fee or ads, nobody can argue with this. There needs to be an organization that imposes ad guidelines(like only specific formats, not being intrusive, etc) for both websites and ad companies. They should verify the ads/websites based on user reports and if they find something, to kick t…

https://eyeo.com, home to the world's most installed ad-blocker, AdBlock+, has an acceptable ads policy already in place; whilst Google is trying to tackle the data-collection problem via the controversial privacy-sandbox proposal [0]. Safari [1] and Firefox [2] seem to have the right idea abt it all, whilst Brave is trying a radically new approach [3].

As for the online services needing ads to keep lights on:

1. The pervasive dragnet that the online ad-industry has birthed is a massive reason behind content-blocking.

2. Ads are freq used to spread source of malware, scareware, spyware, ransomware, fake-news among other totally unreasonable things.

3. The end-users should be free to chose what they want to view and what they don't. The service providers are free to refuse service.

4. The tracking that goes on is so covert that it seems to me that it is borderline unethical [4].

5. The online ads business is a scam [5]?

---

[0] https://news.ycombinator.com/item?id=20767891

[1] https://news.ycombinator.com/item?id=20700914

[2] https://news.ycombinator.com/item?id=21497488

[3] https://news.ycombinator.com/item?id=21525592

[4] https://news.ycombinator.com/item?id=20336762

[5] https://news.ycombinator.com/item?id=13992576

Re: Cname cloaking, a disguise of third-party trackers

#70

Post by Spivak »

koolba wrote: post #27
perspective1 wrote: post #26

Earlier quoted context omitted.

Just use iptables on your firewall/router to reroute all traffic on port 53 to your DNS server.

I can assure you that the general population has no idea what half the nouns in that sentence mean, let alone how to do any of that.

I mean the game of controlling 3rd-party devices that we don’t really own via side channels is always gonna be a cat-and-mouse of ever more elaborate hacks.

The next game will probably be mitming these devices by flashing a new CA store.

There is no general solution to running an openly adversarial app/device in your network.

Post reply on HN