3 ms·

>I'm speculating about the future, where we can assume ad networks have responded to the current trend of ad blockers. Yes, and you have also said in another c

by jasode 11y ago

>I'm speculating about the future, where we can assume ad networks have responded to the current trend of ad blockers. Yes, and you have also said in another comment: >when advertisers finally figure out that embedding into the actual document (like a data: URL today) is much harder to block. Ad networks and advertisers have already been well aware of this for years.[1] However, they value personalized ad generation more than embedded ads. The content owners and ad networks value the realtime bidding of ad slots. The advertisers value delivering targeted ads to the most relevant eyeballs. The part I think you're underestimating is the inherent value proposition of realtime ads that must be generated dynamically. The economics really favor the construction of those ads on the users' browsers instead of the server. The inherent boundaries in that make it easy for ad blockers to work effectively. To merge all 3 entities' interests behind a monolithic "proxy" requires different economics because they now have pay for cpu & network bandwidth upfront to construct millions of ads. Now "Joe's Music Blog" has to send his blog post to the proxy for ad merging. That's a friction that's totally different from Joe just copy&pasting some ad javascript into his Wordpress template. Your first post was about WebAssembly and that's a separate issue from ad proxies creating seamless ads. [1]https://www.reddit.com/r/explainlikeimfive/comments/35rfhe/eli5_how_do_websites_put_up_special_hello_adblock/ https://www.reddit.com/r/explainlikeimfive/comments/35rfhe/e...

pdkl95 11y ago
It's not a separate issue at all: the entire point is that making all request come from the same source - which can happen in more opaque way with obfuscated WebAssembly. "Joe's Music Blog" would just hit the "insert ad" button on a future website authoring tool, and the automation can build everything. Remember, I'm just speculating and suggesting caution. Nothing would make me happier than to be completely wrong about technologies like WebAssembly. I just think that it's a bad idea to underestimate the ingenuity of people that see dollar signs when they look at a new tool. If it I'm wrong and ad-blockers continue to work in a WebAssembly world, then there's no problem.
- jasode 11y ago
  >the entire point is that making all request come from the same source - which can happen in more opaque way with obfuscated WebAssembly. No matter how convoluted the WebAssembly bytecode, the browser engine still has to execute it and therefore it will ultimately know to go fetch "something" from AdsClearinghouseProxy.Com. If the browser engine knows that fact, the ad blockers know that fact as well. In that aspect, it doesn't matter whether the string "AdsClearinghouseProxy.Com" is obvious in plain-text Javascript or hidden in WebAssembly bytecode. >technologies like WebAssembly. I just think that it's a bad idea to underestimate the ingenuity of people that see dollar signs when they look at a new tool. It's not a technology problem and WebAssembly won't help the advertisers as much as you think. Check out the questions asked in that reddit thread. The advertisers already have the technical tools and know-how to do something about "empty ad boxes" when ad block is active. Nevertheless, they don't pursue the solutions. The issue is that they want to have their cake and eat it too. WebAssembly will not remove the immense friction of coordinating all entities to deliver merged ads that are undetectable by ad blockers.

by jasode 11y ago

pdkl95 11y ago

It's not a separate issue at all: the entire point is that making all request come from the same source - which can happen in more opaque way with obfuscated WebAssembly. "Joe's Music Blog" would just hit the "insert ad" button on a future website authoring tool, and the automation can build everything. Remember, I'm just speculating and suggesting caution. Nothing would make me happier than to be completely wrong about technologies like WebAssembly. I just think that it's a bad idea to underestimate the ingenuity of people that see dollar signs when they look at a new tool. If it I'm wrong and ad-blockers continue to work in a WebAssembly world, then there's no problem.

jasode 11y ago
>the entire point is that making all request come from the same source - which can happen in more opaque way with obfuscated WebAssembly. No matter how convoluted the WebAssembly bytecode, the browser engine still has to execute it and therefore it will ultimately know to go fetch "something" from AdsClearinghouseProxy.Com. If the browser engine knows that fact, the ad blockers know that fact as well. In that aspect, it doesn't matter whether the string "AdsClearinghouseProxy.Com" is obvious in plain-text Javascript or hidden in WebAssembly bytecode. >technologies like WebAssembly. I just think that it's a bad idea to underestimate the ingenuity of people that see dollar signs when they look at a new tool. It's not a technology problem and WebAssembly won't help the advertisers as much as you think. Check out the questions asked in that reddit thread. The advertisers already have the technical tools and know-how to do something about "empty ad boxes" when ad block is active. Nevertheless, they don't pursue the solutions. The issue is that they want to have their cake and eat it too. WebAssembly will not remove the immense friction of coordinating all entities to deliver merged ads that are undetectable by ad blockers.