Ad blockers primarily look at domains, so blocking will continue to be possible at the request level. They aren't interpreting or parsing JS to begin with.
> - stronger DRM
If sites were going to ship Web Assembly-based DRM, they would already be shipping Web Assembly along with the Emterpreter. Remember that wasm has a polyfill already. I haven't seen that happening, so I see no reason to believe it'll happen in the future.
> - Bitcoin mining that regular user can't detect
A regular user certainly would notice the 100% CPU consumption. And anyway, bitcoin mining in a WebGL shader would be more profitable than anything wasm-based.
Moreover, though, surreptitious bitcoin mining on consumer PCs would be ludicrously unprofitable no matter what. Here a Stack Overflow answer from last year that calculates how much a site with 2M daily visitors would make if they could all somehow run the fastest C implementation [1]. It was less than 50 cents a day back then, and in the meantime the hash rate has grown by nearly an order of magnitude [2]. Good luck.
You are right, but replace Bitcoin with the latest Fadcoin and it might get lucrative again.
One cool idea that is also gaining traction is in-browser proof of work to prevent DDOS attacks. Basically you have to perform a lengthy computation to get past the (fast, ultra-high bandwidth) firewall. Doesn't slow down the individual user much, but makes an attack much more difficult. I could imagine people using malicious JS to get these proof-of-work tokens.
But yeah, computing power in the cloud has become fairly cheap, it's really hard to see how criminals could benefit from secretly serving WebAssembly to people.
I doubt a regular user would notice 100% CPU usage and even less certain that they would know what to do about it or what was causing it. Most OSes operate chrome just fine when another process is asking for 100% as well.
You must have been working with at least quite young people or something. My experience goes the other way. I've seen people who bought a new computer because their fans were running at max and the reason for that was that they were full with dust and dog hair.
Right, they might notice it, but why would they care? They don't know that they should care, it is just a computer being a computer and it probably spins up the fans for other tasks too. They would be right to not care unless told otherwise, sys ops isn't their job.
I think it would be smart to educate people as part of a regular security briefing for non technical staff though. But if it's something that high of concern to your company maybe an automated CPU usage monitor could alert the team to anomalies.
[1] I was running a test today when the program being tested ran into a very tight loop and the fan really kicked in. I was curious if it would finish and let it run for several minutes until all went quiet and the screen went dark. It had shutdown to prevent heat damage.
Regular users do notice things like that, they just can't articulate it. "I think my computers getting old" and "I think I have a virus" are common ways of trying to explain things like this.
I'm not sure where you're getting any of this from.
First, I don't see why you think WASM-based ads will be any less blockable than JS already is.
Stronger DRM on the web [is already a thing][1], but that has nothing to do with WASM.
Bitcoin mining on the web is already possible with JS and so far that hasn't been an issue. If it does start becoming a widespread problem though, browsers will start taking steps to combat it, like they [already have][2] for pages that needlessly consume CPU in the background.
That's actually a great idea for funding content creation online. If a site is open source, then it would even be possible to prove that only a reasonable share of the client's resources are being utilized. I'd take that funding model over the advertising-driven model that exists now.
WASM is aiming to be fast enough to actually be capable of running a rendering engine. No more DOM for adblockers to look at, the pages may finally become canvases.
Right, but you can already do that. Serve the whole page as a SVG, or JPEG, or PDF. You can already embed ads inline. Or just plain serve them from your own server, calling them article.jpg instead of http:://ads.adcompany.com/advertisement.jpg .
The reason people don't do this, is because ad companies want control. They want to know exactly how often the ads are served and they don't trust you to serve their ad all the time and to all customers. Also they want to rotate it quickly. Finally, they want to track people. So the solution is to use remote javascript. 99% of ads work this way, even mayor news sites don't sell their own ads anymore.
In this scheme, you'd probably still have ads served from a third party server. And even if they obfuscated the domain name, you could still probably identify their blob and block it.
So I'm not to worried about unblockable ads. But you're right, they will try, and I am worried about sites becoming unusable because they will emulate browsers using canvas, poorly.
If you run your own rendering engine you lose accessibility. If you add aria tags to stuff in order to make it accessible, adblockers will be able to read them as well.
I don't think advertisers care about accessibility. Not the same companies that want auto-starting video clips in your browser.
As for the site owners - unless it's someone large enough to care, I think the usual choice between "letting a few disabled persons access the site" and "getting a few more bucks from advertising" would be quite obvious. If that question would even arise.
Don't most ad blockers just rely on media queries on the DOM? I imagine there's a lot of ways to circumvent those techniques when you are rendering raw pixels with wasm.
Those pixels still have to go somewhere in the DOM, and clicks on those pixels still need to be handled. Plus, there's nothing wasm can render that you can't render with uglified JS already.
Put it this way: once you factored in the price of the bus fare to get to the public library to borrow a terminal to check your giant botnet's bitcoin earnings, your criminal enterprise would be operating at a loss.
CPU mining hasn't been viable since 2011 when bitcoin difficulty was below 1,000,000, and today it's near 600,000,000,000.
Turn your website into an interactive canvas, basically an HTML5 Canvas game that functions like a news site, I think it would be much more difficult to block ads in this scenario. One objection is that you can already do this and we don't see it, but a counterpoint is that its a hassle at the moment, and once tooling is advanced C# to WASM compiler or something along those lines, then we'll see frameworks and then it will be pretty simple and possibly compelling... If it gives publishers more control over the experience I don't see how they could pass it up.
Ad blockers primarily look at domains, so blocking will continue to be possible at the request level. They aren't interpreting or parsing JS to begin with.
> - stronger DRM
If sites were going to ship Web Assembly-based DRM, they would already be shipping Web Assembly along with the Emterpreter. Remember that wasm has a polyfill already. I haven't seen that happening, so I see no reason to believe it'll happen in the future.
> - Bitcoin mining that regular user can't detect
A regular user certainly would notice the 100% CPU consumption. And anyway, bitcoin mining in a WebGL shader would be more profitable than anything wasm-based.
Moreover, though, surreptitious bitcoin mining on consumer PCs would be ludicrously unprofitable no matter what. Here a Stack Overflow answer from last year that calculates how much a site with 2M daily visitors would make if they could all somehow run the fastest C implementation [1]. It was less than 50 cents a day back then, and in the meantime the hash rate has grown by nearly an order of magnitude [2]. Good luck.
[1]: https://bitcoin.stackexchange.com/a/42413
[2]: https://blockchain.info/charts/hash-rate?timespan=2years