4 ms·
I asked a number of times on HN why wasm was good when java applets, exactly the same thing, were bad. There was a vague feeling that java applets were insecure
by thaumasiotes 1y ago
I asked a number of times on HN why wasm was good when java applets, exactly the same thing, were bad. There was a vague feeling that java applets were insecure and that this would somehow not be an issue for wasm.
It's not just applets; we also had Flash, which was a huge success until it was suddenly killed.
As far as I can tell, the difference between java applets and Flash is that you, the user, have to install java onto your system to use applets, whereas to use Flash you have to install Flash into your browser. I guess that might explain why one became more popular than the other.
- diffuse_l 1y agoFlash was a security nightmare, with multiple vulnerabilities discovered regularly. It was eventually killed because Apple decided it won't support it on the iPhone.
- shagmin 1y agoAnd conveniently around the same time javascript was rapidly evolving.
- thaumasiotes 1y agoYour implication is that the idea that java applets were insecure had nothing to do with their adoption or lack thereof.
- detaro 1y agoI don't think "exactly the same thing" is accurate. And WASM has put more effort into sandboxing, both in the design (very limited interfaces outside the sandbox) and implementations (partially because we've just gotten a lot better at that as an industry).
- croes 1y agoBut now you can do more in the browser than back then with Java applets. Crypto miners weren’t a thing for Java applets
- adastra22 1y agoThey are vastly different. The WASM is much more low level, and supports a wider range of program types, including low level embedded stuff.
- brazzy 1y ago> There was a vague feeling that java applets were insecure and that this would somehow not be an issue for wasm. Nothing "vague" or "somehow" about that. Applets were insecure, because A) they were based on the Netscape browser plugin API, which had a huge attack surface, and B) they ran in a normal JVM with a standard API that offeres full system access, restricted by a complex sandbox mechanism which again had a huge attack surface. This IS, in fact, not an issue for wasm, since A) as TFA describes it has by default no access at all to the JavaScript browser API and has to be granted that access explicitly for each function, and B) the JavaScript browser API has extremely restricted access to OS functionality to begin with. There simply is no API at all to access arbitrary files, for example.
- immibis 1y agoThere wasn't a vague feeling. Both kept getting exploited. My favorite is Trusted Method Chaining, which is hard to find a reference on now, but showed the whole Java security model was fundamentally flawed. These days that security model has simply been removed: all code in the VM is assumed to run in the privilege level of the VM. WASM sandboxes the entire VM, a safer model. Java ran trusted and untrusted code in the same VM. Flash, while using the whole-VM confinement model, simply had too many "boring" exploits, like buffer overflows and so on, and was too much of a risk to keep using. While technically nothing prevented Flash from being safe, it was copyright Adobe and Adobe didn't make it safe, and no one else was allowed to.
- euroderf 1y agoOff-topic but... whatever happened to Real Player? Installing that was always a nightmare.
- whywhywhywhy 1y agoWASM doesn’t feel like an “applet” and can be either seamlessly integrated or take over the space. Applets felt horrible, maybe if they appeared today it would be different but back then the machines were not powerful enough and the system not integrated enough to make it feel smooth.