4 ms·

Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implem

Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implementations were ridden with vulnerabilities and eventually browsers made them unusable. Other mentioned technologies didn't even promise that, I think. JavaScript did deliver its promise of unbreakable sandbox and nowadays browser runs JavaScript, downloaded from any domain without asking user whether he trusts it or not. WASM builds on JavaScript engine, delivering similar security guarantees. So there's no fundamental difference between WASM and JVM bytecode. There's only practical difference: WASM proved to be secure and JVM did not. So now Google Chrome is secure enough for billions of people to safely run evil WASM without compromising their phones, and you can copy this engine from Google Chrome to server and use this strong sandbox to run scripts from various users, which could share resources. An alternative is to use virtualization. So you can either compile your code to WASM blob and run it in the big WASM server, or you can compile your code to amd64 binary, put it along stripped Linux kernel and run this thing in the VM. There's no clear winner here, I think, for now, there are pros and cons for every approach.

silvestrov 2y ago
Most of all the problem with Java Applets was that they were very slow to load and required so many resources that the computer came to a halt. They also took much longer to develop than whatever you could cook up in plain html and javascript.
- kaba0 2y ago
  Funnily enough, wasm also has the problem of “slow to load”. In that vein, a higher level bytecode would probably result in smaller files to transport. And before someone adds, the JVM also supports loading stuff in a streaming way - one just has to write a streaming class loader, and then the app can start immediately and later on load additional classes.
  - deleted 2y ago
    [deleted]
- gnz11 2y ago
  Too be fair, they were slow to load if you didn’t have the browser extension and correct JRE installed.
DanielHB 2y ago
> WASM proved to be secure and JVM did not. It is interesting to ask why that is the case, from my point of view the reason is that the JVM standard library is just too damn large. While WASM goes on a lower-level approach of just not having one. To make WASM have the capabilities required the host (the agent running the WASM code) needs to provide them. For a lot of languages that means using WASI, moving most of the security concerns to the WASI implementation used. But if you really want to create a secure environment you can just... not implement all of WASI. So a lambda function host environment can, for example, just not implement any filesystem WASI calls because a lambda has no business implementing filesystem stuff. > An alternative is to use virtualization. So you can either compile your code to WASM blob and run it in the big WASM server, or you can compile your code to amd64 binary, put it along stripped Linux kernel and run this thing in the VM. I think the first approach gives a lot more room for the host to create optimizations, to the point we could see hardware with custom instructions to make WASM faster. Or custom WASM runtimes heavily tied to the hardware they run on to make better JIT code. I imagine a future where WASM is treated like LLVM IR
- kaba0 2y ago
  > I think the first approach gives a lot more room for the host to create optimizations, to the point we could see hardware with custom instructions to make WASM faster Heh, there were literally CPUs with some support for the JVM! But it turns out that “translating” between different forms is not that expensive (and can be done ahead of time and cached), given that CPUs already use a higher level abstraction of x86/arm to “communicate with us”, while they do something else in the form of microcode. So it didn’t really pay off, and I would wager it wouldn’t pay off with WASM either.
  - mshockwave 2y ago
    > Heh, there were literally CPUs with some support for the JVM! Jazelle, a dark history that ARM never wants to mention again
- cogman10 2y ago
  I'll just add one thing here, WASM's platform access is VERY small. There's almost no runtime associated with WASM and thus no guarantees to what WASM can access. When you throw WASM into the browser, it's access to the outside world is granted by the javascript container that invokes it. That's very different compared to how other browser extensions operated. The old browser extensions like the JVM or flash were literally the browser calling into a binary blob with full access to the whole platform. That is why the WASM model is secure vs the JVM model. WASM simply can't interact with the system unless it is explicitly given access to the system from the host calling it. It is even more strictly sandboxed than the Javascript engine which is executing it.
kaba0 2y ago
I would add that most of it was politics. The JVM is not fundamentally insecure the same say as neither is any Turing-complete abstraction like an x86 emulator or so. It’s always the attached APIs that open up new attack surfaces. Since the JVM at the time was used to bring absolutely unimaginable features to the otherwise anemic web, it had to be unsafe to be useful. Since then, the web improved a huge amount, like a complete online FPS game can literally be programmed in just JS almost a decade ago. If a new VM can just interact with this newfound JS ecosystem and rely on these to be the boundaries it can of couse be made much safer. But it’s not inherently due to this other VM.
perching_aix 2y ago
> JavaScript did deliver its promise of unbreakable sandbox Aren't its VM implementations routinely exploited? Ranging from "mere" security feature exploits, such as popunders, all the way to full on proper VM escapes? Like even in current day, JS is ran interpreted on a number of platforms, because JIT compiling is not trustworthy enough. And I'm pretty sure the interpreters are no immune either.
- mdhb 2y ago
  There were a bunch of things missing from OPs description around the security considerations of Wasm but it has a lot of other stuff on top of what the browser provides when it’s executing JavaScript. The primary one is its idea of a “capability model” where it basically can’t do any kinds of risky actions (I.e touch the outside world via the network or the file system for example) unless you give it explicit permissions to do so. Beyond that it has things like memory isolation etc so even an exploit in one module can’t impact another and each module has its own operating environment and permission scope associated with it.
  - emporas 2y ago
    I was surprised when google has agreed to implement the capabilities model for Chrome. I would guess that asking the user for permission to access the microphone would not sit well with google. In smartphones they own the OS so they can ignore wasm's security model as much as they like.
    - mdhb 2y ago
      I feel there’s a bit of a disconnect here between Google’s Ads division who are looking to basically do the bare minimum to avoid getting repeatedly spanked primarily by the EU but also now with talk of a breakup in the US and most other parts of Google who I say this entirely unironically are by far the best of all major options with regards to security in both the browser and their public cloud offerings. I’d even extend that possibly to operating systems as well. ChromeOS is miles in front of anything else out there currently but on mobile Android has historically lagged behind iOS although that gap is close to indistinguishable in 2024.
foobarian 2y ago
> There's only practical difference: WASM proved to be secure and JVM did not. The practical reasons have more to do with how the JVM was embedded in browsers than the actual technology itself (though Flash was worse in this regard). They were linked at binary level and had same privileges as the containing process. With the JS VM the browser has a lot more control over I/O since the integration evolved this way from the start.
jasode 2y ago
>So there's no fundamental difference between WASM and JVM bytecode. There's only practical difference: WASM proved to be secure and JVM did not. There's more to it than just the sandbox security model. The JVM bytecode doesn't have pointers which has significant performance ramifications for any language with native pointers. This limitation was one of the reasons why the JVM was never a serious compilation target platform for low-level languages like C/C++. E.g. Adobe compiled their Photoshop C++ code to WASM but not to the JVM to run in a Java JRE nor the Java web applet. Sure, one can twist a Java byte array to act as a flat address space and then "emulate" pointers to C/C++ but this extra layer of indirection which reduces performance wasn't something software companies with C/C++ codebases were interested in. Even though the JVM was advertised as "WORA Write-Once-Run-Anywhere", commercial software companies never deployed their C/C++ apps to the JVM. In contrast, the motivation for asm.js (predecessor to WASM) was to act as a reasonable and realistic compilation target for C/C++. (https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-nightly/#:~:text=start%20compiling%20C/C%2B%2B%20code https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-n....) So the WASM-vs-JVM story can't be simplified to "just security" or "just politics". There were actual different technical choices made in the WASM bytecode architecture to enable lower-level languages like C/C++. That's not to say the Sun Java team's technical choices for the JVM bytecode were "wrong"; they just used different assumptions for a different world.
- adamc 2y ago
  Also, the start-up time for the JVM made running applets very sluggish. Java quickly became a synonym for "slow".
  - tromp 2y ago
    Lack of 64-bit ints didn't help either...
  - kaba0 2y ago
    You can’t just compare across decades of software and hardware development. Even downloading native binaries would have been sluggish, as the download would have been slow with those download speeds.
BobbyTables2 2y ago
JavaScript is all fun and games until a type confusion bug in V8 allows arbitrary code execution from a simple piece of JavaScript code…
- abound 2y ago
  Sure, and if you find one of those, you can trade it in for $25k or more [1] [1] https://bughunters.google.com/about/rules/chrome-friends/5745167867576320/chrome-vulnerability-reward-program-rules https://bughunters.google.com/about/rules/chrome-friends/574...
norswap 2y ago
> WASM proved to be secure and JVM did not. This is an oversimplification — there's nothing about the JVM bytecode architecture making it insecure. In fact, it is quite simpler as an architecture than WASM. Applets were just too early (you have to remember what the state of tech looked like back then), and the implementation was of poor quality to boot (owing in part to some technical limitations — but not only). But worst of all, it just felt jank. It wasn't really part of the page, just a little box in it, that had no connection to HTML, the address bar & page history, or really anything else. The Javascript model rightfully proved superior, but there was no way Sun could have achieved it short of building their own browser with native JVM integration. Today that looks easy, just fork Chromium. But back then the landscape was Internet Explorer 6 vs the very marginal Mozilla (and later Mozilla Firefox) and proprietary Opera that occasionally proved incompatible with major websites.
- skybrian 2y ago
  Yes it’s true that there’s more to the story, but also, Java really is more complicated and harder to secure than WASM. You need to look at the entire attack surface and not just the bytecode. For example, Java was the first mainstream language with built-in threading and that resulted in a pile of concurrency bugs. Porting Java to a new platform was not easy because it often required fixing threading bugs in the OS. By contrast, JavaScript and WASM (in the first version) are single-threaded. For JavaScript it was because it was written in a week, but for WASM, they knew from experience to put off threading to keep things simple. Java also has a class loader, a security manager that few people understand and sensitive native methods that relied on stack-walking to make sure they weren’t called in the wrong place. The API at the security boundary was not well-designed. A lot of this is from being first at a lot of things and being wildly ambitious without sufficent review, and then having questionable decisions locked in by backward compatibility concerns.
- eduction 2y ago
  > back then the landscape was Internet Explorer 6 vs the very marginal Mozilla Your timeline is off by about five years. Java support shipped with Netscape Navigator 2 in 1995, and 95/96/97 is when Java hype and applet experimentation peaked. Netscape dominated this era. IE6 wouldn’t come out until 2001 and IE share generally wouldn’t cross 50% until 2000 https://en.m.wikipedia.org/wiki/File:Internet-explorer-usage-data.svg https://en.m.wikipedia.org/wiki/File:Internet-explorer-usage... By the time Mozilla spun up with open sourced Netscape code, Java in the browser was very much dead. You nailed the other stuff though. (Kind of an academic point but I’m curious if Java browser/page integration was much worse than JavaScript in those days. Back then JS wasn’t very capable itself and Netscape was clearly willing to work to promote Java, to the point of mutilating and renaming the language that became JavaScript. I’m not sure back then there was even the term or concept of DOM, and certainly no AJAX. It may be a case of JavaScript just evolving a lot more because applets were so jank as to be DOA)
EasyMark 2y ago
What would you say is the performance difference between say running a qt app as native compiled vs running it in WASM? I’ve always been curious but never tried. I know it would vary based on the application but I’m guessing something that is maybe calculating some Monte Carlo model and then displaying the result or something else along those lines that actually will max out the CPU at times rather than be waiting on human interaction 99%of the time.
Dwedit 2y ago
> JavaScript did deliver its promise of unbreakable sandbox I'm sure there's a big long list of WebKit exploits somewhere that will contradict that sentence...

silvestrov 2y ago

Most of all the problem with Java Applets was that they were very slow to load and required so many resources that the computer came to a halt. They also took much longer to develop than whatever you could cook up in plain html and javascript.

kaba0 2y ago
Funnily enough, wasm also has the problem of “slow to load”. In that vein, a higher level bytecode would probably result in smaller files to transport. And before someone adds, the JVM also supports loading stuff in a streaming way - one just has to write a streaming class loader, and then the app can start immediately and later on load additional classes.
- deleted 2y ago
  [deleted]
gnz11 2y ago
Too be fair, they were slow to load if you didn’t have the browser extension and correct JRE installed.

DanielHB 2y ago

> WASM proved to be secure and JVM did not. It is interesting to ask why that is the case, from my point of view the reason is that the JVM standard library is just too damn large. While WASM goes on a lower-level approach of just not having one. To make WASM have the capabilities required the host (the agent running the WASM code) needs to provide them. For a lot of languages that means using WASI, moving most of the security concerns to the WASI implementation used. But if you really want to create a secure environment you can just... not implement all of WASI. So a lambda function host environment can, for example, just not implement any filesystem WASI calls because a lambda has no business implementing filesystem stuff. > An alternative is to use virtualization. So you can either compile your code to WASM blob and run it in the big WASM server, or you can compile your code to amd64 binary, put it along stripped Linux kernel and run this thing in the VM. I think the first approach gives a lot more room for the host to create optimizations, to the point we could see hardware with custom instructions to make WASM faster. Or custom WASM runtimes heavily tied to the hardware they run on to make better JIT code. I imagine a future where WASM is treated like LLVM IR

kaba0 2y ago
> I think the first approach gives a lot more room for the host to create optimizations, to the point we could see hardware with custom instructions to make WASM faster Heh, there were literally CPUs with some support for the JVM! But it turns out that “translating” between different forms is not that expensive (and can be done ahead of time and cached), given that CPUs already use a higher level abstraction of x86/arm to “communicate with us”, while they do something else in the form of microcode. So it didn’t really pay off, and I would wager it wouldn’t pay off with WASM either.
- mshockwave 2y ago
  > Heh, there were literally CPUs with some support for the JVM! Jazelle, a dark history that ARM never wants to mention again
cogman10 2y ago
I'll just add one thing here, WASM's platform access is VERY small. There's almost no runtime associated with WASM and thus no guarantees to what WASM can access. When you throw WASM into the browser, it's access to the outside world is granted by the javascript container that invokes it. That's very different compared to how other browser extensions operated. The old browser extensions like the JVM or flash were literally the browser calling into a binary blob with full access to the whole platform. That is why the WASM model is secure vs the JVM model. WASM simply can't interact with the system unless it is explicitly given access to the system from the host calling it. It is even more strictly sandboxed than the Javascript engine which is executing it.

kaba0 2y ago

I would add that most of it was politics. The JVM is not fundamentally insecure the same say as neither is any Turing-complete abstraction like an x86 emulator or so. It’s always the attached APIs that open up new attack surfaces. Since the JVM at the time was used to bring absolutely unimaginable features to the otherwise anemic web, it had to be unsafe to be useful. Since then, the web improved a huge amount, like a complete online FPS game can literally be programmed in just JS almost a decade ago. If a new VM can just interact with this newfound JS ecosystem and rely on these to be the boundaries it can of couse be made much safer. But it’s not inherently due to this other VM.

perching_aix 2y ago

> JavaScript did deliver its promise of unbreakable sandbox Aren't its VM implementations routinely exploited? Ranging from "mere" security feature exploits, such as popunders, all the way to full on proper VM escapes? Like even in current day, JS is ran interpreted on a number of platforms, because JIT compiling is not trustworthy enough. And I'm pretty sure the interpreters are no immune either.

mdhb 2y ago
There were a bunch of things missing from OPs description around the security considerations of Wasm but it has a lot of other stuff on top of what the browser provides when it’s executing JavaScript. The primary one is its idea of a “capability model” where it basically can’t do any kinds of risky actions (I.e touch the outside world via the network or the file system for example) unless you give it explicit permissions to do so. Beyond that it has things like memory isolation etc so even an exploit in one module can’t impact another and each module has its own operating environment and permission scope associated with it.
- emporas 2y ago
  I was surprised when google has agreed to implement the capabilities model for Chrome. I would guess that asking the user for permission to access the microphone would not sit well with google. In smartphones they own the OS so they can ignore wasm's security model as much as they like.
  - mdhb 2y ago
    I feel there’s a bit of a disconnect here between Google’s Ads division who are looking to basically do the bare minimum to avoid getting repeatedly spanked primarily by the EU but also now with talk of a breakup in the US and most other parts of Google who I say this entirely unironically are by far the best of all major options with regards to security in both the browser and their public cloud offerings. I’d even extend that possibly to operating systems as well. ChromeOS is miles in front of anything else out there currently but on mobile Android has historically lagged behind iOS although that gap is close to indistinguishable in 2024.

foobarian 2y ago

> There's only practical difference: WASM proved to be secure and JVM did not. The practical reasons have more to do with how the JVM was embedded in browsers than the actual technology itself (though Flash was worse in this regard). They were linked at binary level and had same privileges as the containing process. With the JS VM the browser has a lot more control over I/O since the integration evolved this way from the start.

jasode 2y ago

>So there's no fundamental difference between WASM and JVM bytecode. There's only practical difference: WASM proved to be secure and JVM did not. There's more to it than just the sandbox security model. The JVM bytecode doesn't have pointers which has significant performance ramifications for any language with native pointers. This limitation was one of the reasons why the JVM was never a serious compilation target platform for low-level languages like C/C++. E.g. Adobe compiled their Photoshop C++ code to WASM but not to the JVM to run in a Java JRE nor the Java web applet. Sure, one can twist a Java byte array to act as a flat address space and then "emulate" pointers to C/C++ but this extra layer of indirection which reduces performance wasn't something software companies with C/C++ codebases were interested in. Even though the JVM was advertised as "WORA Write-Once-Run-Anywhere", commercial software companies never deployed their C/C++ apps to the JVM. In contrast, the motivation for asm.js (predecessor to WASM) was to act as a reasonable and realistic compilation target for C/C++. (https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-nightly/#:~:text=start%20compiling%20C/C%2B%2B%20code https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-n....) So the WASM-vs-JVM story can't be simplified to "just security" or "just politics". There were actual different technical choices made in the WASM bytecode architecture to enable lower-level languages like C/C++. That's not to say the Sun Java team's technical choices for the JVM bytecode were "wrong"; they just used different assumptions for a different world.

adamc 2y ago
Also, the start-up time for the JVM made running applets very sluggish. Java quickly became a synonym for "slow".
- tromp 2y ago
  Lack of 64-bit ints didn't help either...
- kaba0 2y ago
  You can’t just compare across decades of software and hardware development. Even downloading native binaries would have been sluggish, as the download would have been slow with those download speeds.

BobbyTables2 2y ago

JavaScript is all fun and games until a type confusion bug in V8 allows arbitrary code execution from a simple piece of JavaScript code…

abound 2y ago
Sure, and if you find one of those, you can trade it in for $25k or more [1] [1] https://bughunters.google.com/about/rules/chrome-friends/5745167867576320/chrome-vulnerability-reward-program-rules https://bughunters.google.com/about/rules/chrome-friends/574...

norswap 2y ago

> WASM proved to be secure and JVM did not. This is an oversimplification — there's nothing about the JVM bytecode architecture making it insecure. In fact, it is quite simpler as an architecture than WASM. Applets were just too early (you have to remember what the state of tech looked like back then), and the implementation was of poor quality to boot (owing in part to some technical limitations — but not only). But worst of all, it just felt jank. It wasn't really part of the page, just a little box in it, that had no connection to HTML, the address bar & page history, or really anything else. The Javascript model rightfully proved superior, but there was no way Sun could have achieved it short of building their own browser with native JVM integration. Today that looks easy, just fork Chromium. But back then the landscape was Internet Explorer 6 vs the very marginal Mozilla (and later Mozilla Firefox) and proprietary Opera that occasionally proved incompatible with major websites.

skybrian 2y ago
Yes it’s true that there’s more to the story, but also, Java really is more complicated and harder to secure than WASM. You need to look at the entire attack surface and not just the bytecode. For example, Java was the first mainstream language with built-in threading and that resulted in a pile of concurrency bugs. Porting Java to a new platform was not easy because it often required fixing threading bugs in the OS. By contrast, JavaScript and WASM (in the first version) are single-threaded. For JavaScript it was because it was written in a week, but for WASM, they knew from experience to put off threading to keep things simple. Java also has a class loader, a security manager that few people understand and sensitive native methods that relied on stack-walking to make sure they weren’t called in the wrong place. The API at the security boundary was not well-designed. A lot of this is from being first at a lot of things and being wildly ambitious without sufficent review, and then having questionable decisions locked in by backward compatibility concerns.
eduction 2y ago
> back then the landscape was Internet Explorer 6 vs the very marginal Mozilla Your timeline is off by about five years. Java support shipped with Netscape Navigator 2 in 1995, and 95/96/97 is when Java hype and applet experimentation peaked. Netscape dominated this era. IE6 wouldn’t come out until 2001 and IE share generally wouldn’t cross 50% until 2000 https://en.m.wikipedia.org/wiki/File:Internet-explorer-usage-data.svg https://en.m.wikipedia.org/wiki/File:Internet-explorer-usage... By the time Mozilla spun up with open sourced Netscape code, Java in the browser was very much dead. You nailed the other stuff though. (Kind of an academic point but I’m curious if Java browser/page integration was much worse than JavaScript in those days. Back then JS wasn’t very capable itself and Netscape was clearly willing to work to promote Java, to the point of mutilating and renaming the language that became JavaScript. I’m not sure back then there was even the term or concept of DOM, and certainly no AJAX. It may be a case of JavaScript just evolving a lot more because applets were so jank as to be DOA)

EasyMark 2y ago

What would you say is the performance difference between say running a qt app as native compiled vs running it in WASM? I’ve always been curious but never tried. I know it would vary based on the application but I’m guessing something that is maybe calculating some Monte Carlo model and then displaying the result or something else along those lines that actually will max out the CPU at times rather than be waiting on human interaction 99%of the time.

Dwedit 2y ago

> JavaScript did deliver its promise of unbreakable sandbox I'm sure there's a big long list of WebKit exploits somewhere that will contradict that sentence...