Hacker News Reader

>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-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.

Also, the start-up time for the JVM made running applets very sluggish. Java quickly became a synonym for "slow".

Lack of 64-bit ints didn't help either...

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.

But web pages were not so sluggish, hence people chose them over using applets.

Web pages at the time could at most <blink>, its interactivity was extremely limited compared to what we have know. Meanwhile a java applet could include a full-blown IDE/CAD/what have you

Well, web pages could submit forms, which was the main thing. I remember working on apps where we went with web pages because applets were too slow, regardless of the features we gave up. Images were generated on the back end instead, for example.

Isn't the cold-start for the JVM still relatively slow, even in [current year]?

EDIT: seems like yes[1], at least where AWS Lambda is concerned.

[1] https://filia-aleks.medium.com/aws-lambda-battle-2021-perfor...

I have a couple Quarkus apps that I've run in Lambdas that start in about a second. This is without using GraalVM too! Good enough for what I was doing (taking a list of file names, finding them in an S3 bucket and zipping them into a single payload)

> 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

> 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.

> Heh, there were literally CPUs with some support for the JVM!

Jazelle, a dark history that ARM never wants to mention again

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.

Wht can't wasm have it own invoker, instead of relying on javascript?

> 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.

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.

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.

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.

It is not my intention to be contrarian, but honestly this might be the most incorrect comment I've ever read on hacker news, in several different ways. Sure, some of these might be subjective, but for example chromeOS is Linux with a shiny coat in top, how could it be any better than, well, Linux, let alone miles ahead?

ChromeOS uses the Linux kernel but unless you enable developer mode (which has multiple levels of scary warnings including on every boot and requires completely wiping the device to enable) everything runs in the Chrome web sandbox or the Android VM.

A ChromeOS user isn't apt-get installing binaries or copy/pasting bash one liners from Github. If you enable the Linux dev environment, that also runs in an isolated VM with a much more limited attack surface vs say an out of the box Ubuntu install. Both the Android VM and Linux VM can and routinely are blocked by MDM in school or work contexts.

You could lock down a Linux install with SELinux policies and various other restrictions but on ChromeOS it's the default mode that 99% of users are protected by (or limited by depending on your perspective).

Even when you enable “developer mode” which is essentially Debian in a VM the level of care that went into making sure that no matter what happens there you will never suffer a full system compromise is truly impressive.

To give you a sense of where they were half a decade ago you can already see that it’s as I described miles in front of anything that exists even today in this video: https://youtu.be/pRlh8LX4kQI

When we get to talking about when they went for a total ground up first principles approach with Fuchsia as a next generation operating system that is something else entirely on a different level again.

I genuinely didn’t have a hint of irony in my original comment. They are actually that much better when it comes to security.

> on mobile Android has historically lagged behind iOS although that gap is close to indistinguishable in 2024.

This is true, but unfortunately in the negative sense: both are as insecure as each other, i.e. pwned. [1]

[1] https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...

I think "routinely" is overstating it, billions people are running arbitrary JS on a daily basis and no meaningful number of them are being infected by malware.

Browser surface attracts the most intense security researcher scrutiny so they do find really wild chains of like 5 exploits that could possibly zero day, but it more reflects just how much scrutiny it has for hardening, realistically anything else will be more exploitable than that, eg your Chromecast playing arbitrarily video streams must he more exploitable than JS on a fully patched Chrome.

Both chrome and firefox lock down the javascript that site is running into their own box. By using a standalone process and whatever mechanism system provided. A pwned site alone isn't enough to cause damage. You also need to overcome other layer of defenses (unlike something like flash that can be owned from it's script engine alone)

It usually require multi 0 day to overcome all those defense and do anything useful. (And it is also the highest glory in defcon)

The browser is surely frequently attacked due to the high rewards. But it also get patched really fast. (As long as you are not using a browser from 10 years ago).

Flash/applets could have been isolated in a process too, right?

yes but no, because they needed access to the OS for various services, all of which would have had to be isolated from the user code. Sun and Adobe woiod never have done this. Chrome did it, Safari and Firefox followed. WASM runs in that environment. Flash/applets ran outside of that environment. they did that precisely to provide services the broswer didn't back then.

Chrome did put a sandbox around Flash, didn't they? I thought the bigger reasons it died out was that it didn't integrate with DOM and Apple hated it

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.

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.

Too be fair, they were slow to load if you didn’t have the browser extension and correct JRE installed.

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.

> 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.

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.

> 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...

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)

ActiveX and Macromedia Flash were also popular alternatives to Java applets. Until v8 and Nitro were available, browser-based JavaScript was not a credible option for many apps.

> 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.

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.

> 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...

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

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/574...