3 ms·
>Blocking elements with CSS (or whatever) will no longer be possible, and the Halting Problem says you're going to have a hard time trying to do similar blockin
by jasode 11y ago
>Blocking elements with CSS (or whatever) will no longer be possible, and the Halting Problem says you're going to have a hard time trying to do similar blocking of the WebAssembly bytecode. You might be able to block a few image URLs for a while, but the ad industry will quickly migrate to any technique that has has a real effect of bypassing ad-blockers.
I don't think the opaque nature of WebAssembly will defeat ad blockers because advertisers depend on the distributed infrastructure of the internet and that aspect stays the same whether browsers execute plain-text Javascript, or obfuscated minified Javascript, or obfuscated WebAssembly. Many (most?) obnoxious ads depend on ad networks to constantly generate realtime contextual ads for a particular web surfer. They also require the ad network for behavior tracking and monetizing. Therefore, fetching these external resources (urls) to "build the ad" will always be transparent to browsers engines and if they continue to provide "hooks" for ad blockers to detect these GETs, the filters will continue to be effective.
Another way to put it... there are 3 separate entities collaborating to deliver realtime ads: (1) content provider (2) the ad distrib network (3) the advertisers ... and following Conway's Law[1], the code snippets executed and fetched by the browser engine will mimic those business boundaries. That structure can always be detected by ad blockers.
On the other hand, if the ad is deeply "embedded" inside of content such as Fox Studios embedding a Pepsi ad for a XMen movie such that it's a contiguous chunk of WebAssembly, or continuous stream of "frames" for <canvas>, then yes, it will be harder to detect such "native advertising"[2]. In my mind, this scenario is closer to the "halting problem". This type of advertising doesn't appear to be the majority because the content providers don't like to burn their servers' CPU and network bandwidth "pre-assembling" the embedded ad before delivery. They'd rather take advantage of ad networks to make the cpu+network on users' desktops/iPhones assemble the ads on-the-fly.
[1]https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
[2]https://en.wikipedia.org/wiki/Native_advertising https://en.wikipedia.org/wiki/Native_advertising
- userbinator 11y agoor continuous stream of "frames" for <canvas>, then yes, it will be harder to detect VCRs back in the 90s had this feature, as TV ads couldn't be anything other than embedded directly into the content, and they weren't anything as powerful as the desktop PCs of the time (which were still only around 1% of the speed and memory of one today), so I think it's quite feasible to do such a thing if this happens in the future. Further reading (this was possible 20 years ago!): http://articles.chicagotribune.com/1995-10-13/entertainment/9510130013_1_commercial-advance-starsight-program-material http://articles.chicagotribune.com/1995-10-13/entertainment/... http://articles.philly.com/1995-07-18/news/25677718_1_commercials-new-vcrs-tape http://articles.philly.com/1995-07-18/news/25677718_1_commer... http://www.hometheaterforum.com/topic/42956-vcrs-and-commercial-skip-do-they-work/ http://www.hometheaterforum.com/topic/42956-vcrs-and-commerc... https://en.wikipedia.org/wiki/Commercial_skipping https://en.wikipedia.org/wiki/Commercial_skipping
- pdkl95 11y agoYou're describing how ads work today. I'm speculating about the future, where we can assume ad networks have responded to the current trend of ad blockers. Those networks will go away, a least as seen from the UserAgent, the moment advertisers figure out how to stuff it all behind a proxy. This will happen regardless of future technologies simply to make URL blocking harder. Conway's law is free to dictate the structure behind the proxy. As for the halting problem, while it might be possible to detect some ads (it would obviously be an arms race), it will be hard to detect when the ads are sent in the same "binary" as the page content. This can be automated trivially, in a similar manner to how Javascript and CSS are assembled from multiple source files today.
- 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