Comment by ddevault | Hacker News Reader

Comment by ddevault | Hacker News Reader

I'm typically sharply critical of the web, but I think this comparison is kind of silly. The biggest problem with Java Applets and Flash is the security issues, which were largely caused by giving web pages access to a second, less secure sandbox. WASM stays in the same sandbox as the rest of the web. Flash also had the problem of being proprietary and non-standardized with only one implementation, something WASM does not suffer from.

For those worried about the "all WASM" pages looking like the old "all Flash" pages of yore, consider that Flash and Java applets had their own UI stack and WASM does not. The closest WASM has to that is OpenGL, but you've been able to make all-OpenGL apps with pure JavaScript for some time and it hasn't taken over the web with terrible sites yet. WASM code can interact with the DOM. I guess we could worry about native C/C++ GUI toolkits being ported to WASM, but the web community gets what you deserve for making Electron a thing.

I don't like JavaScript in general but I don't see how WASM is any worse, and if anything it's quite a bit better.

Flash player had a open access spec and there was more than just the Adobe Flash Player as implementations.

Pretty much every AAA video game of a certain period would have been using scaleforms Flashplayer for their user interface.

Doom 3 BFG comes to my mind.

Why on earth is this being down voted?

> Flash player had a open access spec and there was more than just the Adobe Flash Player as implementations.

No, the compiler maybe, Action Script maybe, but not the player. The player is entirely closed source and there is no open spec for the player. Or you need to show it to me.

> there was more than just the Adobe Flash Player as implementations.

Only Adobe's implementation could run all swf files. Scaleform was not an alternative flash player. Any attempt at creating an alternative and feature complete flash player failed.

Flash the tech is not open, at all.

The player is closed source but the SWF spec is open.

https://www.adobe.com/devnet/swf.html

WASM has all the security problems of flash, and then it multiplies them, by making WASM content linkable.

So someone makes a game, and they use this very useful WASM library over here. Only that library exploits spectre or meltdown to steal data. Or maybe it just silently hoses your machine by targeting the new WebGL shaders? Or any myriad number of other things.

Exploiting browser bugs is still just exploiting browser bugs and this is already a problem for JavaScript, WASM doesn't make it worse. Flash introduces a second, black box sandbox implemented by morons.

I don't think you're understanding.

Let me be explicit. There are changes in WASM specifically made that render spectre and meldown mitigations useless. (ie-Browser makers put in spectre and meltdown mitigations, and changes in WASM allow WASM content to get around those mitigations.) Developers cheer the changes, because they make WASM more useful, and to be fair, browser mitigations of spectre and meltdown type bugs make WASM far less performant. But changes which render those mitigations useless are dangerous no matter what your opinion is on how useful WASM should be.

Edit: Should probably mention that the upcoming changes include threading and shared memory. Implemented in a way that enables CPU side channel attacks. (Probably because there is no other way to get threading and shared memory without everything slowing to a crawl, but still.)

Maybe I don't understand Spectre and Meltdown, then. I wasn't aware it was the browser's business to patch that, I thought it was kernel and microcode patches?

Kernel and microcode patches allow the OS to control for meltdown a bit better.

The problem with Spectre is that it is a bit different. Array bounds class might be able to be patched in the long run, but even from the beginning, people have suspected that the other classes of spectre would be more slippery. And true to form, new spectre type variants continue to be discovered and disclosed by Intel even to this day. (SpectreRSB for instance.)

In short, it's not a simple patch that will fix all these strains of bugs out there. In light of that fact, browser makers have implemented mitigations at the application level which are a bit more heavy handed. But, as you can imagine, this is going to impact all content inside the browser. Which brings us to the WASM content, and the threading and shared memory changes. And you know the rest of the story from there.

> (ie-Browser makers put in spectre and meltdown mitigations, and changes in WASM allow WASM content to get around those mitigations.)

Could you be more specific? I implemented Chrome's Spectre mitigations for WASM and I'm not sure what you are referring to.

> Should probably mention that the upcoming changes include threading and shared memory.

These only give you a high-resolution timer mechanism--which you have to build yourself and is possible in JS with SharedArrayBuffer before. So WASM is no worse in this respect.

It's probably a good thing that a standard isn't designed around Vulnerability of the Day, no?

Some time in the (near?) future those vulnerabilities will just be a footnote in some history book and having to support mitigations forever (due to backwards compatibility) probably isn't the best thing to encode into a standard.

I'm sure some intrepid security researcher will find some new Vulnerability of the Day which can also be exploited through wasm and then they will need to add mitigation to the standard yet again ad nauseam until it becomes some giant bloated unusable mess for which we'll need yet another standard.

Reply on news.ycombinator.com