[ryan-c]

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.

[bryanrasmussen]

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.

[ryan-c]

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?

[geocar]

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.

[Freak_NL]

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

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

[geocar]

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.

[ryan-c]

they try to do that sometimes, but it's rather harder to claim innocence for that than other methods