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

There's no point to client-side JavaScript: The baddies just write JavaScript that rewrites basic objects using Object.defineProperty so that document.visibilityState always says so (and so on), or that lie to the visibility sensor. Or they just make a whole fake web browser that runs on a Server. You are in an arms-race, and verification companies simply can't/don't do a very good job.

> Otherwise, obviously, the server could just maliciously record impressions/clicks.

I offer ads† to publishers server-side via XML or JSON, and they can stitch them into the page however they want, and I've been doing this for years.

My publishers often get paid by click, but some of the more valuable ads are paid on referral. Occasionally I see a CPM/CPD deal go through, but it's usually to a larger publisher that I can understand how they get their traffic. I won't help anyone do a CPM/CPD deal unless I understand their traffic.

You're right that it's much too easy to buy traffic from e.g. Google and spray it at my impression and click trackers, which is why I don't rely on them: Adblock and uBlock can remove the trackers all they want, but their users still get ads from my platform, and my publishers will still get paid.

†: Strictly speaking: I offer a platform for publishers, and often help my customers get introductions/recommendations/connections to advertisers who believe in data-driven online sponsorship.

> Embedding the ad into the video is more akin to a native ad, which is generally understood by the advertiser to not have measurable conversion

Server-side stitching can be done in realtime, bespoke, and with standard VAST tags. Not everyone is doing this, because dash/HLS are simpler and still "good enough".

> and to be strictly context (as opposed to user) targeted.

I've worked with several (big) brands who have done completers and demo-guaranteed video campaigns. There is absolutely user-targeting in video.

2 comments

> There's no point to client-side JavaScript: The baddies just write JavaScript that rewrites basic objects using Object.defineProperty so that document.visibilityState always says so (and so on), or that lie to the visibility sensor. Or they just make a whole fake web browser that runs on a Server. You are in an arms-race, and verification companies simply can't/don't do a very good job.

I agree it's an arms race, but why do you think it favors the attacker? Bot/spam detection is incredibly important, and the folks I've worked with in spam detection are really good at what they do.

(Disclosure: I work on ads at Google, though not in spam. Speaking only for myself.)

> There's no point to client-side JavaScript: The baddies just write JavaScript that rewrites basic objects using Object.defineProperty so that document.visibilityState always says so (and so on), or that lie to the visibility sensor. Or they just make a whole fake web browser that runs on a Server. You are in an arms-race, and verification companies simply can't/don't do a very good job.

You cannot overwrite javascript properties in frames from another domain, right? Am I missing something?

A fake webbrowser requires a lot of IP addresses. Wide-spread abuse seems hard to me, especially when combined with Google's hidden "I'm not a robot" thingy.

> You cannot overwrite javascript properties in frames from another domain, right? Am I missing something?

You don't need to.

The SSP or publisher can slip the naughty JavaScript directly into the ad tag.

> A fake webbrowser requires a lot of IP addresses.

You may be surprised to learn there's a market for buying IP addresses, and they're cheaper than the revenue a bad actor can gain from using them.

There's also a lot of toolbars that embed some limited tunnelling functionality that they can then resell.

There's also a market for hacked DSL routers that you can tunnel through.

You can't use ReCaptcha (or any captcha) for ads. Captchas work because they prevent access to content users want until they solve the captcha.

If you put ads behind a captcha? Well in all honesty you're just doing a service to the user by hiding the ads behind a captcha they're never going to solve (even if they are not robots) because it's not in their best interest to do so.

> You can't use ReCaptcha (or any captcha) for ads. Captchas work because they prevent access to content users want until they solve the captcha.

If you've used ReCaptcha in the past few years [1] you might have noticed it often doesn't ask you to solve a captcha. The parent is describing using a similar approach of detecting bots to identify ad impressions that shouldn't be counted (spam).

[1] https://security.googleblog.com/2014/12/are-you-robot-introd...

(Disclosure: I work at Google in ads, though not in spam.)

There is a hidden "I'm not a robot" "captcha". You might use that to help detect whether the impression/view/click was legit.

https://developers.google.com/recaptcha/docs/invisible

You can programmatically invoke the challenge from the ad's javascript.

If you follow that train of thought to its logical (if perverse) conclusion, we can soon expect ads as the subject matter of captcha.

Instead of selecting three pictures that have a given "thing" in them, we'll be picking the ones showing a given brand among otherwise generic signs.

I've seen some websites that do that, ie watch a short ad and then type in the brand name from the ad.
So life imitates art - again. Too bad the artist is a dystopian dadaist.