Hacker News Reader

Comment by tabtab | Hacker News Reader

That would probably expose it to so many security concerns that it would face a similar fate as Java applets & Flash: causing more hacking/snooping than benefits for a typical browser user.

And I can't get a consistent answer on what problem WASM is trying to solve.

View on HN

The problem with Flash and Java was that they were not integrated with the browser's sandbox. WASM is integrated with the sandbox.

How would allowing DOM access be insecure? The DOM is designed to be completely controlled by the webpage. I don't see how adding an additional way for the webpage to do so adds any insecurity.

Indeed, as if sites today already can't snoop with JS instead of WASM.

Why offer TWO snoop vectors? And crypto miners would target WASM over JS, giving WASM a bad name.

Yet, one can still compile Heartbleed into a WASM module.

It adds more ways to sneak unwanted code into the page or do cross execution that shouldn't happen in first place, while staying inside the sandbox.

WASM neatly solves a pretty common problem of running code that can't be easily ported to JS inside the browser.

It also sort of solves a common problem of running untrusted code, both in browser or on server, because WASM VMs are much more isolated and restricted.

Just like plenty of other bytecode environments since 1961.

Javascript is a language like many since 1961, too, and not the best of them; it has the unique advantage of having been universally implemented and deployed already.

Same thing with WASM. JVM never achieved this level of penetration, and Flash allowed way too much access to ever be secured.

Great that we have WASM then,

https://leaningtech.com/cheerpj/

https://leaningtech.com/cheerpj-applet-runner/

https://leaningtech.com/cheerpx-for-flash/

And in regards to "security",

https://training.linuxfoundation.org/blog/webassembly-securi...

Obfuscation? Job security?

Reply on news.ycombinator.com