3 ms·

So what is everybody who uses an ad-blocker planning to do when browsers start to support WebAssembly? When it becomes easy to compile C libraries like freetype

by pdkl95 11y ago

So what is everybody who uses an ad-blocker planning to do when browsers start to support WebAssembly? When it becomes easy to compile C libraries like freetype - or a proprietary replacement, designed for obfuscation - I expect any website paranoid about "controlling the user experience' will simply use the browser for the <canvas> tag. 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. This is the problem with having a Turing complete language as a dependency for rendering documents; the only reason it hasn't become a big problem yet is that the technologies involved are fairly new and can be awkward to use for some use cases. With a framebuffer and a way to generically use any language, those speed bumps no longer apply.

tux1968 11y ago
For sure it is an arms race, and ultimately many web sites will make their content and ads indivisible. But maybe by the time that they do, enough people will have a taste for ad-free browsing that there will be a competitive advantage to avoid the worst offenses.
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 ago
  or 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 ago
  You'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...
tux3 11y ago
If advertisers went that far to obfuscate, they might stop ad blockers from reclaiming the space, but they still won't be able to actually display anything. You can't win the obfuscation game. At the end of the day ads run in the browser, and eventually they'll have to ask the browser to pretty please connect to "ad.doubleclick.net" and fetch something from there, be it a convoluted rendering script, an autoplaying flash video, or an animated gif.
- Matheus28 11y ago
  Or the server at example.com may simply embed it in the resulting file that it'll send you.
smosher_ 11y ago
Blocking at the request level is where it's at: you don't download the content, you don't execute the scripts, you don't interact with the DOM. You block requests to third party servers or resources based on lists or other policies. This saves you load time, execution time, and it keeps you from being tracked by targeted ad systems. If people start bypassing the DOM with canvas we will have a bigger problem than cosmetic filters failing: we will no longer be served the same kind of document. Or we will, but the content will be in an opaque region of it. If that happens the web is dead. People tried this before with flash and that smoldered for a while in the 90s but didn't last, so I'm not feeling all doom-and-gloom about it. Aside: Standardized document formats are important. If rendering to canvas takes on as the defacto standard, it would cripple the web technologically.
- pdkl95 11y ago
  Request level blocking isn't going to work when advertisers finally figure out that embedding into the actual document (like a data: URL today) is much harder to block. As the entire point of WebAssembly is to make a small download that is efficient in parse-time and size, it will be practical to embed images (less overhead than a base64'd data: URL). As for bypassing the DOM, it's a question of when they do that, not if; for evidence, a lot of people tried that with flash already, and lots more try things like trying to block UserAgent context menu. Yes, these were ineffective, but they were (and still are) used by a lot of businesses. Yes, I think we have a huge problem, because hoping that nobody decides to abuse technology for personal gain doesn't work. With new technologies like WebAssembly, we shouldn't be caring about technical benefits, but instead asking how the technology will be abused. If we give everybody tools to serve a non-document, then we shouldn't be surprised when non-documents are used. The only way to prevent this is to restrict the UserAgent to standards that can only be implemented as an open format, which is what HTML/CSS tried to do. If you're not feeling the doom-and-gloom, you might want to watch PHK's "Operation Orchestra" talk, and consider that there are a lot of businesses that would love to serve up something closer to cable TV than the current environment where the user can control the rendering.
userbinator 11y ago
So what is everybody who uses an ad-blocker planning to do when browsers start to support WebAssembly? Use the Back button more often. Seriously, if I come across some site in a search result that requires running a Turing-complete language to get some textual content I'm looking for, unless it's the only site with that content (and in most cases it isn't) I'm just going to move on to the next one. If the content is really unique, Google's text-only cache seems to work well. Incidentally this is not just a problem for users but for search engines' crawlers too - I believe Google's bot does execute some JS, but if it takes too much resources to render any content it gives up or demotes the site's rankings.
- pdkl95 11y ago
  I actually do this as well. Blank <body> tags from Angular et al get the same treatment, too. If some site doesn't want to send an an actual readable document, then there's no reason to waste any time reading it. Unfortunately, I fear this is not a long-term solution as it lacks critical mass to effect any meaningful change. Too many sites already try various technical workarounds for ads and tracking purposes.
  - tomjen3 11y ago
    Angular is for data in an interactive app. I really don't see how you can make an interactive app without Javascript (you could do as HN do and make it reload a new page all the time).
    - pdkl95 11y ago
      It doesn't matter what it's "for" - I've seen quite a few sites where it's being used to render static content. Well, at least what should be static content (i.e. articles/blog-posts, basic index or portal hompages). example: http://www.intel.com http://www.intel.com I don't intend to single out Angular. I'm talking about any framework that renders empty pages. For example, http://www.meteor.com/ http://www.meteor.com/ renders an empty body tag, and I doubt their homepage requires interactivity. (I'm not talking about anybody that uses a framework but still renders an actual document)
tomjen3 11y ago
Impersonate google bot? They will have to serve text to google. Assume any site that uses WebAssembly is trying to pull some shit and dissallow it by default? That probably means turning of Javascript by default, but so be it. Or just not go there?
monort 11y ago
Ad blocking software would be blocking canvas by default.

by pdkl95 11y ago

tux1968 11y ago

For sure it is an arms race, and ultimately many web sites will make their content and ads indivisible. But maybe by the time that they do, enough people will have a taste for ad-free browsing that there will be a competitive advantage to avoid the worst offenses.

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 ago
or 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 ago
You'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...

tux3 11y ago

If advertisers went that far to obfuscate, they might stop ad blockers from reclaiming the space, but they still won't be able to actually display anything. You can't win the obfuscation game. At the end of the day ads run in the browser, and eventually they'll have to ask the browser to pretty please connect to "ad.doubleclick.net" and fetch something from there, be it a convoluted rendering script, an autoplaying flash video, or an animated gif.

Matheus28 11y ago
Or the server at example.com may simply embed it in the resulting file that it'll send you.

smosher_ 11y ago

Blocking at the request level is where it's at: you don't download the content, you don't execute the scripts, you don't interact with the DOM. You block requests to third party servers or resources based on lists or other policies. This saves you load time, execution time, and it keeps you from being tracked by targeted ad systems. If people start bypassing the DOM with canvas we will have a bigger problem than cosmetic filters failing: we will no longer be served the same kind of document. Or we will, but the content will be in an opaque region of it. If that happens the web is dead. People tried this before with flash and that smoldered for a while in the 90s but didn't last, so I'm not feeling all doom-and-gloom about it. Aside: Standardized document formats are important. If rendering to canvas takes on as the defacto standard, it would cripple the web technologically.

pdkl95 11y ago
Request level blocking isn't going to work when advertisers finally figure out that embedding into the actual document (like a data: URL today) is much harder to block. As the entire point of WebAssembly is to make a small download that is efficient in parse-time and size, it will be practical to embed images (less overhead than a base64'd data: URL). As for bypassing the DOM, it's a question of when they do that, not if; for evidence, a lot of people tried that with flash already, and lots more try things like trying to block UserAgent context menu. Yes, these were ineffective, but they were (and still are) used by a lot of businesses. Yes, I think we have a huge problem, because hoping that nobody decides to abuse technology for personal gain doesn't work. With new technologies like WebAssembly, we shouldn't be caring about technical benefits, but instead asking how the technology will be abused. If we give everybody tools to serve a non-document, then we shouldn't be surprised when non-documents are used. The only way to prevent this is to restrict the UserAgent to standards that can only be implemented as an open format, which is what HTML/CSS tried to do. If you're not feeling the doom-and-gloom, you might want to watch PHK's "Operation Orchestra" talk, and consider that there are a lot of businesses that would love to serve up something closer to cable TV than the current environment where the user can control the rendering.

userbinator 11y ago

So what is everybody who uses an ad-blocker planning to do when browsers start to support WebAssembly? Use the Back button more often. Seriously, if I come across some site in a search result that requires running a Turing-complete language to get some textual content I'm looking for, unless it's the only site with that content (and in most cases it isn't) I'm just going to move on to the next one. If the content is really unique, Google's text-only cache seems to work well. Incidentally this is not just a problem for users but for search engines' crawlers too - I believe Google's bot does execute some JS, but if it takes too much resources to render any content it gives up or demotes the site's rankings.

pdkl95 11y ago
I actually do this as well. Blank <body> tags from Angular et al get the same treatment, too. If some site doesn't want to send an an actual readable document, then there's no reason to waste any time reading it. Unfortunately, I fear this is not a long-term solution as it lacks critical mass to effect any meaningful change. Too many sites already try various technical workarounds for ads and tracking purposes.
- tomjen3 11y ago
  Angular is for data in an interactive app. I really don't see how you can make an interactive app without Javascript (you could do as HN do and make it reload a new page all the time).
  - pdkl95 11y ago
    It doesn't matter what it's "for" - I've seen quite a few sites where it's being used to render static content. Well, at least what should be static content (i.e. articles/blog-posts, basic index or portal hompages). example: http://www.intel.com http://www.intel.com I don't intend to single out Angular. I'm talking about any framework that renders empty pages. For example, http://www.meteor.com/ http://www.meteor.com/ renders an empty body tag, and I doubt their homepage requires interactivity. (I'm not talking about anybody that uses a framework but still renders an actual document)

tomjen3 11y ago

Impersonate google bot? They will have to serve text to google. Assume any site that uses WebAssembly is trying to pull some shit and dissallow it by default? That probably means turning of Javascript by default, but so be it. Or just not go there?

monort 11y ago

Ad blocking software would be blocking canvas by default.