31–40 of 75 posts
For everyone saying this ruins impression tracking, couldn't an ad-network just act as a "CDN" (e.g. client Not that any server owner should do this (giving over control of your website ultimately to the ad-network? fuck that), but as ad-tech becomes more desperate, shouldn't these types of MITM setups get pushed more?
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. Otherwise, obviously, the server could just maliciously record impressions/clicks. Then, logically, if uBlock Origin doesn't remove the ad, but does successfully remove the mediator's scr…
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.
Earlier quoted context omitted.
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.
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 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.
Earlier quoted context omitted.
> 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.…
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.
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.
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. Otherwise, obviously, the server could just maliciously record impressions/clicks. Then, logically, if uBlock Origin doesn't remove the ad, but does successfully remove the mediator's scr…
> 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…
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.
Earlier quoted context omitted.
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.
https://developer.mozilla.org/en-US/docs/Web/API/Document/vi...
Earlier quoted context omitted.
> 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…
> 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 javascr…
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.
I get the distinct impression, in the war of ads vs. consumer, that some people will not be satisfied until they've submarined advertising all the way down to sponsored content and we have to go way out of our way to notice that the Try Guys are always drinking Coca-Cola or something.
There will always be those fringe people who insist on content being valueless even though they consume hours of it. The greater problem is that the ad industry is too unregulated and greedy which has led to a tragedy of the commons with malware and poor UX everywhere, leading to adblockers installed by many who otherwise wouldn't mind.
If you want to make sure you get paid for your content, put it behind a paywall. Yes, the number of users will drop, but you can't have your cake and eat it, too.
Otherwise, ask nicely for donations or Patreon support or do old-fashioned sponsored content, obviously with full disclaimers that the content is sponsored, so people can decide whether they want to watch it or not.
Specifically talking about video ads, look at what Glenn Fricker from Spectre Media Group does on his Youtube channel. He often gets demonitized because he tends to swear a lot. So he asks people to "spend a buck, give a fuck" on Patreon, and he does short sponsor midway interludes in his videos. It's always a short clip of himself talking about the product or service in question, and it's always something he uses himself, he won't advertise something he can't vouch for. So you don't get the jarring cuts to some random ad agency's standard BS video that runs on thousands of un-related videos.
That's how to do it. Part of and related to the channel's content, but also clearly demarcated and made fully clear that it is sponsorship/advertising. And most importantly: No tracking!
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. Otherwise, obviously, the server could just maliciously record impressions/clicks. Then, logically, if uBlock Origin doesn't remove the ad, but does successfully remove the mediator's scr…
Maybe even programmatically allowing the upload of images or videos? (Maybe even ADsafe [0] scripts?)