Hacker News Reader

Comment by fpgaminer | Hacker News Reader

It seems like, if one were an evil web developer, one could thwart blockers like these with a few nasty tricks. Server-side: on each request of a resource, salt all linked resource URIs and encrypt (after the host name) before sending the final document to the client. The resources can still be fetched, because the server can decrypt any requests, but the client has no way of knowing whether a particular resource is an ad or not. That thwarts URI based filtering. To thwart DOM filtering, randomize element classes and ids.

Though impractical, I thought it was an evil/funny idea.

View on HN

Messing with the URIs isn't going to work because most ads are from ad networks and their domains can be blocked. And no ad network is going to trust some system where they need to rely on the client server to not lie about ad impressions.

Adblock mostly misses self-hosted ads anyway.

If the resource names are still "static" your resources can still be blocked. But if they are altered slightly every time, you may also thwart caching, right?

Right, which is why I added the bit about salting the URIs before encryption. The salt could be per request, per session, or rotated after some period of time (say once per day). If only rotated once per day, it would still thwart ad blocking, but have less of an impact on caching. It would turn into an economic question of whether the extra ad impressions are worth the extra bandwidth.

Since most ads are effectively blocked at the domain level, I doubt your scheme would provide much bang for the buck.

The idea is that the ads would be served from the original host. Combined with encrypted URIs and the ad resources become indistinguishable from content resources. Thus thwarting blocking. As others have pointed out, yes this evil trick is incompatible with existing ad networks (which use their own domains). But it wasn't my intention to put forward a viable idea. Just an interesting one (namely, ciphering URIs to prevent blocking).

How would the ad network verify metrics under such a regime?

That's their problem. If they have to spy on me to "verify metrics" they can go fuck themselves.

Ad programs such as Google AdSense forbid modification of the ad code through their ToS. So sre, you could encrypt (and javascript-side decrypt) your ads, but Google would (or might) through you out.

I guess the problem would be that this will make these requests basically uncachable in something like Varnish :)

And in response, blockers could then create lists of hashes of ads (pictures) instead of URIs and block those ?

That would burn bandwidth and loading time, since the only way to check the hash is to download the content. Part of the point of ad blockers is to stop the request for the ad as early as possible.

Regardless, it's easy enough to salt the ads for each request, thwarting hash checks.

TPB mirrors used to do something similar and I swear I had adBlock filter that efficiently blocked them.

Reply on news.ycombinator.com