3 ms·

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, sal

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.

Drakim 12y ago
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?
- fpgaminer 12y ago
  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.
  - wampus 12y ago
    Since most ads are effectively blocked at the domain level, I doubt your scheme would provide much bang for the buck.
    - fpgaminer 12y ago
      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).
      - pbhjpbhj 12y ago
        How would the ad network verify metrics under such a regime?
        Kliment 12y ago
        That's their problem. If they have to spy on me to "verify metrics" they can go fuck themselves.
perlgeek 12y ago
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.
rb2k_ 12y ago
I guess the problem would be that this will make these requests basically uncachable in something like Varnish :)
DavideNL 12y ago
And in response, blockers could then create lists of hashes of ads (pictures) instead of URIs and block those ?
- fpgaminer 12y ago
  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.
Perdition 12y ago
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.
dzhiurgis 12y ago
TPB mirrors used to do something similar and I swear I had adBlock filter that efficiently blocked them.

Drakim 12y ago

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?

fpgaminer 12y ago
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.
- wampus 12y ago
  Since most ads are effectively blocked at the domain level, I doubt your scheme would provide much bang for the buck.
  - fpgaminer 12y ago
    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).
    - pbhjpbhj 12y ago
      How would the ad network verify metrics under such a regime?
      - Kliment 12y ago
        That's their problem. If they have to spy on me to "verify metrics" they can go fuck themselves.

perlgeek 12y ago

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.

rb2k_ 12y ago

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

DavideNL 12y ago

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

fpgaminer 12y ago
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.

Perdition 12y ago

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.

dzhiurgis 12y ago

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