3 ms·
The difference is that wasm is designed to be sandboxed, instead of the JVM which was designed to normalize disparate computing environments. In practice, this
by tadfisher 6y ago
The difference is that wasm is designed to be sandboxed, instead of the JVM which was designed to normalize disparate computing environments. In practice, this entails a lot of work to create runtimes to do anything interesting in wasm, but the behavior is secure by default (ignoring side-channel attacks, of course). Java applets run in a sandbox by default, of course, but the JRE itself has unmitigated access to the host system, so the security boundary isn't as well defined. Users can also be tricked to trust malicious applets, which is a built-in mechanism to escape the sandbox; browsers hopefully will not provide this feature for their wasm runtimes.
- WalterGR 6y ago> the JRE itself has unmitigated access to the host system As does the browser in which WebAssembly executes. > Users can also be tricked to trust malicious applets But the ability of applets to be trusted could have been eliminated entirely. To rewrite OP's question, then: "If we had entirely gotten rid of trusted applets, couldn't we already do this with Java, 20 years ago?" Of course, we didn't get rid of them, but that's still a valid question vs. inventing another technology.
- Closi 6y agoCan't we just do this in sandboxed regular assembly running inside a virtual machine?! /s
- asiachick 6y agowhich assembly?
- codeflo 6y agoInteresting thought experiment. However, you have to realize that Sun wasn’t a charity. At the time, platform vendors were were hoping to target intranet applications for the enterprise. Microsoft had a similar concept for trusted applications with IE’s “Active Scripting”, with very similar results in terms of (non)security.