Hacker News new | ask | show | jobs
by zelly 2404 days ago
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.

4 comments

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.
This may be tremendously ignorant but...

What is to stop ad tech companies creating a cryptographically secured reverse proxy device[1] that clients can install in their network between the web server and requests from the internet?

The ad tech company only has to trust that their device is secure and the company that sells their website doesn't have to give up control of their domain or anything else.

They would have to isolate the ad tech device from the rest of the network and only allow it to communicate to the web server inside the network and the ad tech server outside their network. If something goes wrong with the device then it is trivial for the web serving company to bypass it.

-------

As is mentioned in the grandparent comment, this allows anything to be done to the content being served from the website and not only domains cannot be trusted, individual URLS cannot either. Ad blockers will have to rely on examining the content directly even more than they already do. This would make it much less scalable for the ad blockers to deal with, they have to identify ad content individually, by their signatures or page structure in the best case, or examining arbitrary code behaviour in a worse case. Ad blockers may then have to deal with identifying ad content which changes as fast or faster than new ads appear, which is a lot worse than the relatively few(and relatively static) domains, URLS, bits of HTML and Javascript that are there now. Ad blockers may lose eventually due to incomputability, but who knows.

-------

[1] Using a TPM is one possibility

This would have to be a reverse proxy on the AdTech's infrastructure itself to make sure no rewriting is being done after-the-fact, as you can't trust your AdTech customer (the person that owns example.com) to not run a reverse proxy in front of that.
Thanks for making me realise the most obvious thing, that it doesn't stop click fraud if it is on the ADTech customers network as they can connect to the device and pretend to be any device on the internet.
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.
Most ad fraud is the referrer owner faking clicks on ads on their own site. To trust a click you need to trust that the ad was displayed to a legitimate user. That's the hard bit.

Ad companies could move to only paying when ads result in a sale, but that only works if there's a sale that can be tracked. If I click a BMW ad and then buy one in the showroom that's really hard to track.

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

> "Please enable JavaScript to view this content"
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.
no. the reason it hasn’t happened is because a) it’s very very hard (ie even harder) to detect click fraud. and b) you can’t track the user.