5 ms·

You're right, and not just the DOM: https://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html https://docs.oracle.com/j

by panic 5y ago

You're right, and not just the DOM: https://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html https://docs.oracle.com/javase/tutorial/deployment/applet/in... Maybe the real reason has to do with security, then? That was the justification for removing Java support from browsers, leaving the door open for WASM to take its place.

pjmlp 5y ago
Politics, https://en.m.wikipedia.org/wiki/Google_Native_Client https://en.m.wikipedia.org/wiki/Google_Native_Client https://adobe-flash.github.io/crossbridge/ https://adobe-flash.github.io/crossbridge/ https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat...
- josephg 5y ago
  There's also technical reasons galore: - NaCL (as I understand it) essentially enshrined a particular version of llvm bytecode as its data format. This made it overcomplicated, and made it very difficult (technically and politically) for other browsers to implement any of it. It was difficult to compile to, and only supported chrome (which was at the time much less dominant than it is now). But webassembly is like NaCL 3.0 anyway. (2.0 was asmjs). Webassembly is NaCL's successor, not its rival. - Flash was always a firehose of security vulnerabilities, and using it tied the future of the web to an (essentially) proprietary format put out by a single company. Flash never worked well on mobile - when it worked at all it turned your phone into a pocket heater. It didn't help that so many banner ads were distributed via flash. And given how badly flash integrated with the browser's scheduler that meant a background tab turned your computer into a space heater. Ultimately flash was killed by adobe's failure to ship a good enough product. - Java in the browser had nearly as many security issues as flash did. And it took seconds for the jvm to start up. When it worked at all that is - java applets relied on the user to have a reasonably up-to-date version of the JVM installed (and appropriate browser extensions). Even as a developer it was a pain to get java applets working. And for what benefit? So we could have ugly non-native controls? It could have worked if browser vendors all shipped a properly sandboxed lightweight JVM like they started to do with flash. But nobody used applets anyway because they barely worked on anyone's computers. Webassembly has taken all of the lessons from this to heart and taken 2 really important steps that no competing system has achieved: 1. Webassembly only runs in a completely sandboxed, bounds checked memory container with a tiny surface area. As a result it is orders of magnitude more secure than flash or java. 2. Webassembly got buy-in from browser vendors. Because the browsers are in charge of their respective wasm virtual machines, they're extremely well integrated with the rest of the browser. Wasm has solid JS APIs, it works everywhere including mobile, it starts up instantly (unlike java), and its tied to browsers' update mechanisms. Yeah, politics were involved. But the outcome is much better than we would have achieved with flash or java. And I'm very grateful for the outcome. I don't want to need proprietary junk from Adobe and Oracle to make the web work.
  - PaulDavisThe1st 5y ago
    > 1. Webassembly only runs in a completely sandboxed, bounds checked memory container with a tiny surface area. Which is mostly sort of great in a browser context. But WASI appears to be pushing WASM for use outside the browser context, and for this to really make sense, the restruction in your #1 would need to be severely relaxed and/or substantial and large modules added to facilitate interaction with the underlying host system. Of course some of this happened at the browser level already: web audio, web usb as the two main examples. But as that keeps happening, the "tiny surface area" feature also gets a little harder to claim.
    - josephg 5y ago
      I know this may be controversial, but I think injecting a carefully thought out sandboxing layer between application code and the rest of my system is something desktop operating systems been needing for a long time anyway. Its crazy how vulnerable modern operating systems are in the face of malicious code. Literally any of the hundreds of programs running on my computer could steal credentials out of my browser, or read any of my files and send them out over the internet. Or, worse - encrypt all my stuff and ransom it back to me. Why can my text editor read my browser's complete history and credential store? Why does crappy program from Corsair which maps the buttons on my mouse have access to the internet? Why does my operating system allow wacom's driver bundle to silently read, send and ultimately sell lists of what programs I'm running on my computer? So yeah, I agree that the need for WASI is a bit unfortunate. And it'll be a lot of work to get everything working with wasi. And WASI programs will eventually, necessarily pierce WASM's beautiful hermetic shell. But I'm a big supporter of whatever roads lead us to having more control over what access to the rest of the system my applications have. In the long run I can see WASI being part of a much more secure desktop computing environment. We need that - the current situation is ridiculous.
      - pjmlp 5y ago
        Here is a fun exercise, compile a full C application with a dependency in a Heartbleed tainted version of OpenSSL into WebAssembly and then expose it to the Internet, and watch it burn exactly the same way despite whatever magic properties the sandbox offers. Notice the full application part. The castle walls don't matter if one can make the people inside start a fire on their own.

by panic 5y ago

pjmlp 5y ago

Politics, https://en.m.wikipedia.org/wiki/Google_Native_Client https://en.m.wikipedia.org/wiki/Google_Native_Client https://adobe-flash.github.io/crossbridge/ https://adobe-flash.github.io/crossbridge/ https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat...

josephg 5y ago
There's also technical reasons galore: - NaCL (as I understand it) essentially enshrined a particular version of llvm bytecode as its data format. This made it overcomplicated, and made it very difficult (technically and politically) for other browsers to implement any of it. It was difficult to compile to, and only supported chrome (which was at the time much less dominant than it is now). But webassembly is like NaCL 3.0 anyway. (2.0 was asmjs). Webassembly is NaCL's successor, not its rival. - Flash was always a firehose of security vulnerabilities, and using it tied the future of the web to an (essentially) proprietary format put out by a single company. Flash never worked well on mobile - when it worked at all it turned your phone into a pocket heater. It didn't help that so many banner ads were distributed via flash. And given how badly flash integrated with the browser's scheduler that meant a background tab turned your computer into a space heater. Ultimately flash was killed by adobe's failure to ship a good enough product. - Java in the browser had nearly as many security issues as flash did. And it took seconds for the jvm to start up. When it worked at all that is - java applets relied on the user to have a reasonably up-to-date version of the JVM installed (and appropriate browser extensions). Even as a developer it was a pain to get java applets working. And for what benefit? So we could have ugly non-native controls? It could have worked if browser vendors all shipped a properly sandboxed lightweight JVM like they started to do with flash. But nobody used applets anyway because they barely worked on anyone's computers. Webassembly has taken all of the lessons from this to heart and taken 2 really important steps that no competing system has achieved: 1. Webassembly only runs in a completely sandboxed, bounds checked memory container with a tiny surface area. As a result it is orders of magnitude more secure than flash or java. 2. Webassembly got buy-in from browser vendors. Because the browsers are in charge of their respective wasm virtual machines, they're extremely well integrated with the rest of the browser. Wasm has solid JS APIs, it works everywhere including mobile, it starts up instantly (unlike java), and its tied to browsers' update mechanisms. Yeah, politics were involved. But the outcome is much better than we would have achieved with flash or java. And I'm very grateful for the outcome. I don't want to need proprietary junk from Adobe and Oracle to make the web work.
- PaulDavisThe1st 5y ago
  > 1. Webassembly only runs in a completely sandboxed, bounds checked memory container with a tiny surface area. Which is mostly sort of great in a browser context. But WASI appears to be pushing WASM for use outside the browser context, and for this to really make sense, the restruction in your #1 would need to be severely relaxed and/or substantial and large modules added to facilitate interaction with the underlying host system. Of course some of this happened at the browser level already: web audio, web usb as the two main examples. But as that keeps happening, the "tiny surface area" feature also gets a little harder to claim.
  - josephg 5y ago
    I know this may be controversial, but I think injecting a carefully thought out sandboxing layer between application code and the rest of my system is something desktop operating systems been needing for a long time anyway. Its crazy how vulnerable modern operating systems are in the face of malicious code. Literally any of the hundreds of programs running on my computer could steal credentials out of my browser, or read any of my files and send them out over the internet. Or, worse - encrypt all my stuff and ransom it back to me. Why can my text editor read my browser's complete history and credential store? Why does crappy program from Corsair which maps the buttons on my mouse have access to the internet? Why does my operating system allow wacom's driver bundle to silently read, send and ultimately sell lists of what programs I'm running on my computer? So yeah, I agree that the need for WASI is a bit unfortunate. And it'll be a lot of work to get everything working with wasi. And WASI programs will eventually, necessarily pierce WASM's beautiful hermetic shell. But I'm a big supporter of whatever roads lead us to having more control over what access to the rest of the system my applications have. In the long run I can see WASI being part of a much more secure desktop computing environment. We need that - the current situation is ridiculous.
    - pjmlp 5y ago
      Here is a fun exercise, compile a full C application with a dependency in a Heartbleed tainted version of OpenSSL into WebAssembly and then expose it to the Internet, and watch it burn exactly the same way despite whatever magic properties the sandbox offers. Notice the full application part. The castle walls don't matter if one can make the people inside start a fire on their own.