Hacker News new | ask | show | jobs
by zeta0134 2658 days ago
> Before anyone thinks this is a Eureka anti-ad-blocking technology: Clearly you still need client-side javascript, distributed by the mediator, to ensure that the impression is actually delivered and the click is actually registered.

I don't suppose I understand why clientside JavaScript is needed here. The serverside code could simply generate a unique hash for every visitor, and include that in the campaign link. Then, server-side code on the receiving end can read this hash, record a unique hit, and monitor the user on the campaign landing page to see if a lead is generated.

This seems obvious to me, but I don't actually work in advertising. Where is the break in this system? What am I missing that allows this to be exploited, in a way that only clientside JavaScript can fix?

EDIT: In context, I've realized that my proposed solution might work for clicks, but would do nothing for tracking impressions. Hrm. I'm not really sure if that problem is solvable. Then again, I'm also not a fan of impression based ad tracking (it feels creepy) so maybe I don't mind if it remains broken.

3 comments

A couple leads to answer you :

- Video advertising is not happy with only impressions and clicks metrics. In general, advertiser will want to know if their video played while in view from a human (or at least in view on a screen), and for how long it has played (or at the very least a rough estimate, like say how much midpoints).

- The concept of "impression" itself is often not very well defined, but counting it at "the server served a request with the video payload" is really a too optimistic view of things which leaves big holes exploitable by fraudsters. Having client side javascript playing at least requires additional software running, aka additional costs (if minimal) for fraudster.

- You can't really "just" monitor the user on the campaign landing page, since it's different sites involved, it involves different cookies, and actually reconciliating them is doable, but it'd require some work that the advertiser may not be willing or able to do.

If all script appears to come from the website (advertiser scripts routed via the website with random filenames), it'll probably be pretty hard to filter that kind of behavior without breaking other websites.
Sure ! You still need client side javascript though
Threat models:

* The ad server outright telling lies to get paid for nothing.

* The ad server not being trusted to validate that views are legitimate.

Client-side JavaScript can probe the DOM and execution environment for abnormalities indicative of automation.

yes but as was said earlier client-side JavaScript can also be blocked. Everything has downsides.

And it was posited that client-side was needed, the reply was they couldn't see why it was 'needed', which I agree with, I can see why it might be wished for, but you do not need it to record clicks. You do need it for other things, or to improve understanding of the clicks.

Basically any solution is going to be composed of many pieces, all of those pieces susceptible to attack in different ways.

if client side javascript is blocked, then just don't pay for that impression
But why can't a malicious server also serve up some JS that modifies the behaviour of the JS served by the ad network?
You don't need a malicious server.

You can use Google to do this and you'll get a google/branded domain name for your object-hijacking javascript. The number of times I've seen something like document.visibilityState='visible' in peoples ads (or ad wrappers) is astounding.

Isn't document.visibilityState a read-only property?

https://developer.mozilla.org/en-US/docs/Web/API/Document/vi...

No.

It is not.

    Object.defineProperty(document, 'visibilityState', { value: "visible", writable: false })
demonstrates trivially that the documentation is clearly wrong.

Maybe it says it's "read-only" because Google wants bad guys to do this sort of thing, since it makes advertisers buy more ads from them.

Or maybe it's an honest mistake that neither Mozilla, nor Google (nor Microsoft or anyone else it seems) has any idea what "read-only" means.

they try to do that sometimes, but it's rather harder to claim innocence for that than other methods
The server could track it based on the fact it delivered the content to the end user with the same unique hash present, no?
You mean like a tracking pixel? The issue here is that all requests to the ad domain can be blocked by the ad blocker.