Cname cloaking, a disguise of third-party trackers • Hacker News Board

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

#51

Post by dylz » Sat, Nov 23, 2019, 9:23 PM UTC

bsysop wrote: post #46

jefftk wrote: post #42

The easiest way for site-owners to delegate control has been to include third-party javascript. With new browser restrictions, we're starting to see companies switching to loading JS via CNAMEd subdomains, because that's nearly as easy. The next step is probably reverse proxies, though, where the third-party JS comes from the same server that gives you the rest of the site's JS. (Disclosure: I work in ads; speaking o…

Do you think ad companies will really trust reverse-proxied ad traffic? Seems like a tremendous opportunity for fraud. Right now with user agents hitting ad servers directly, there's much less opportunity for content publishers to fake impressions and clicks.

They already do - Instart Logic is one of the reverse proxies dedicated to serving ads first-party.

For tracking and invasive device tracking (WebGL, plugin enumeration, Canvas, audiocontext, WebRTC, WebSocket-based portscanning of your LAN CIDR acquired from WebRTC, ...) there's Shape and Distil that both do inline reverse proxying.

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

#52

Post by bufferout » Sat, Nov 23, 2019, 9:24 PM UTC

stefan_ wrote: post #2

So block content, as always? That's not possible for NextDNS, which I guess is their concern, but then DNS blocking was always going to be a very very blunt instrument.

"NextDNS is proud to announce that all your blocklists are now applied to each intermediate CNAMEs in addition to the queried domain name.": https://medium.com/nextdns/nextdns-added-cname-uncloaking-su...

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

#53

Post by ignoramous » Sat, Nov 23, 2019, 9:30 PM UTC

bsysop wrote: post #46

jefftk wrote: post #42

The easiest way for site-owners to delegate control has been to include third-party javascript. With new browser restrictions, we're starting to see companies switching to loading JS via CNAMEd subdomains, because that's nearly as easy. The next step is probably reverse proxies, though, where the third-party JS comes from the same server that gives you the rest of the site's JS. (Disclosure: I work in ads; speaking o…

Do you think ad companies will really trust reverse-proxied ad traffic? Seems like a tremendous opportunity for fraud. Right now with user agents hitting ad servers directly, there's much less opportunity for content publishers to fake impressions and clicks.

Instead of websites deploying reverse-proxies to tunnel ads through, Google has entire websites tunnel through their edge via AMP. Wouldn't surprise me if BigTech gets together and introduces standards that open up more avenues for CDNs to take away even more control and monetize the traffic they serve, on their terms.

Google has pretty much checkmated content-blockers in that they control the servers, the OS, and the clients used by an overwhelming majority internet users and service providers, alike.

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

#54

Post by zelly » Sat, Nov 23, 2019, 9:43 PM UTC

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. Getting this to work in a pluggable fashion is an implementation detail (maybe some on-the-fly statistical generation of URLs + passing nonces to and from Ad Agency as a mitigation for spoofing by example.com). Another way to implement it is a custom URL router that dynamically reverse proxies to Ad Agency on the generated ad trojan horse URL. The only reason this hasn't happened yet is because still very few people use adblock, esp. on mobile.

P.S. please don't do this.

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

#55

Post by jefftk » Sat, Nov 23, 2019, 9:47 PM UTC

poitrus wrote: post #50

jefftk wrote: post #42

The easiest way for site-owners to delegate control has been to include third-party javascript. With new browser restrictions, we're starting to see companies switching to loading JS via CNAMEd subdomains, because that's nearly as easy. The next step is probably reverse proxies, though, where the third-party JS comes from the same server that gives you the rest of the site's JS. (Disclosure: I work in ads; speaking o…

They might yes, but it is orders of magnitude harder to setup and maintain than this, and as a website owner, you have to put even more trust in your ad serving solution than today.

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.

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

#56

Post by hunter2_ » Sat, Nov 23, 2019, 9:49 PM UTC

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've been wondering the exact same thing for a long time. However, browser extensions could probably still use good enough heuristics. It's the pihole category of solutions that would be defeated.

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

#57

Post by x0x0 » Sat, Nov 23, 2019, 9:53 PM UTC

jefftk wrote: post #55

poitrus wrote: post #50

Earlier quoted context omitted.

They might yes, but it is orders of magnitude harder to setup and maintain than this, and as a website owner, you have to put even more trust in your ad serving solution than today.

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.

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

#58

Post by going_to_800 » Sat, Nov 23, 2019, 9:53 PM UTC

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 the company out.

All companies that follow those guidelines should be whitelisted by ad blockers, probably something implemented at browser level.

Otherwise is just a useless chase.

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

#59

Post by ignoramous » Sat, Nov 23, 2019, 9:56 PM UTC

poitrus wrote: post #49

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…

Check this article, pi-hole can’t block this yet: https://medium.com/nextdns/nextdns-added-cname-uncloaking-su...

I personally setup nextdns for 30+ people. It is that simple and useful. Thanks.

I've a couple of questions, though:

1. Do you run one unbound instance per configuration, or share among multiple configurations per user or...? The reason I ask is, sometimes the latencies are too high, 2000ms+. Should I be creating less configurations per account?

2. How could nextdns combat ad-networks resorting to DoH: https://1.1.1.1.com/dns-query?name=example.com&type=AAAA

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

#60

Post by zelly » Sat, Nov 23, 2019, 9:56 PM UTC

bsysop wrote: post #46

jefftk wrote: post #42

The easiest way for site-owners to delegate control has been to include third-party javascript. With new browser restrictions, we're starting to see companies switching to loading JS via CNAMEd subdomains, because that's nearly as easy. The next step is probably reverse proxies, though, where the third-party JS comes from the same server that gives you the rest of the site's JS. (Disclosure: I work in ads; speaking o…

Do you think ad companies will really trust reverse-proxied ad traffic? Seems like a tremendous opportunity for fraud. Right now with user agents hitting ad servers directly, there's much less opportunity for content publishers to fake impressions and clicks.

When user agent clicks the ad, that's how the ad companies know it's real.