Hacker News Reader

Comment by projektfu | Hacker News Reader

What can wasm accomplish in that way that Java couldn't? I'm really confused about the hoopla.

You can compile C, C++ and a bunch of other languages to Wasm, while you can't do that with Java as a target. A lot of existing C code compiles unchanged. And Wasm also actually runs in all browsers nowadays without the user noticing a difference (eg. iOS Safari too).

What we should be comparing it is to activeX and flash will it have the security that those two technologies didn't?

WASM uses the browser sandbox, from what I understand it re-uses the same facilities that browsers use for JIT

WASM's sandboxing as implemented in practice is different from JITs. It works by allocating a 4GB region of virtual memory and treating the base address as NULL. Pointers in WASM are 32 bit so they are unable to point outside the region.

The big win is the runtime doesn't need to check pointers for validity. However there are some downsides relative to native code:

1. Can't address more than 4GB of memory

2. Can't be efficiently implemented on 32 bit systems

3. Can't share memory between WASM modules

4. NULL dereferences don't trap (I think)

I would not be surprised if future CPUs had hardware support for this stuff, e.g. load/stores with a mask to confine the pointers.

Just like Solaris SPARC has been doing like for 10 years.

Neat. I thought Web pages were limited to 2 GB memory. I guess tines have changed.

The other way it ensures isolation is by separating code and data. All executable code lives in a separate address space that is not accessible from within wasm. Call stack is also a separate area, making it impossible to muck around or even look at the return pointer. Function pointers are opaque - they can live in global or local variables and in table entries (which are also completely separate from memory), but not in memory; when one needs such a pointer as part of the data structure (e.g. vtables), an index into a table is used instead.

Yes, because it's learned from their experience. WASM has been designed with security in mind from the very start, and implemented by experienced browser teams with a very deep understanding of the security risks of doing so.

"Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly"

https://www.youtube.com/watch?v=glL__xjviro

"The Security Risk of Lacking Compiler Protection in WebAssembly"

https://arxiv.org/abs/2111.01421

One of the things that killed Flash was not being supported on iOS while Wasm runs fine (and actually pretty well!) on iOS which is pretty good for reach.

On the other side, not being able to run on iOS didn't kill any server side language (think Java.) And Java client side (Android) is very different from Java server side, down to the sets of developers.

Currently WASM is both a client side and server side runtime. It's not clear where it will be in 5 or 10 years. I don't see a compelling server side story. Why WASM and not C#, Java, Node, Python, Rails (I intentionally don't write Ruby) or whatever any of us is using now with its standard runtime?

Personally I'm not super familiar with its benefits if any on the server and would actually not use it on the server myself and just build binaries directly, probably using Go. But I've seen some references to Wasm on the serverside for something similar to containerization or loading plugins. It does seem less obvious to me than the client side.

What makes you say Wasm is a server side runtime / imply that it's meant to be one?

With go as an example, you know the saying “cgo isn’t go”? Well, you could use C, C++, Rust or anything else that compiles to wasm from any other language.

There have been a few people who say if wasm (WASI on the server) existed already, Docker wouldn’t need to exist. Docker runs a whole OS just to run your binary - imagine the benefits of Docker but just running your binary.

It’s all early days so I am slightly waving my hands, but a lot of this works now. Check out _wasmtime_.

For the client I use a simple go -> c++ compiler I wrote and compile to wasm from that actually, on my side projects. It had zero overhead interfacing to / calls to C/C++ (including generics<->templates) since it's just generating that. Example web game made with that: https://github.com/nikki93/raylib-5k

I think I've seen wasmtime before. If I needed to interface to any C/C++ things on the server I would probably just write in C/C++ (or Gx) yeah.

In a phase: code sharing.

Say you are a C# developer and there is a C / C++ / Rust thing you want to use as a dependency.

Well, WASM is your interop layer. Same with Node.js, Deno, Go etc. You can start to share alot more code with a solid interop layer that WASM presents.

wasm does not have a solid interop layer, especially compared to past attempts such as CLR. What you get at the moment is more or less the C FFI, but more awkward to use because of the sandbox.

Just like CLR has been doing for 20 years.

IBM and Unisys almost since the 1960's, depending on which model we are talking about.

> Why WASM and not C#, Java, Node, Python, Rails (I intentionally don't write Ruby) or whatever any of us is using now with its standard runtime?

I don't understand why you use a framework instead of a language there, but it seems to be in the same category of mistake as asking “why <compilation target> and not <thing that can be compiled to that target>”. They aren't mutually exclusive alternatives.

iOS was the final nail in the coffin, but Flash had been having years of an endless flood of severe security problems. It was having major problems hanging on prior to Apple playing their hand.

Losing Flash's excellent authoring tools is still a hard blow though.

So basically CLR, not to mention the 60 and 70's bytecode environments.

I think you missed the part about it running in the browser? But yes, some previous technologies are similar to some new technologies, that's not really an insight at this point. Especially not about bytecode interpreters which seems like a standard practice.

> I think you missed the part about it running in the browser?

.NET Core started as the Silverlight runtime, didn't it?

The extent of Wasm's availability on browsers is quite big right now. Both iOS and Android and all major desktop browsers. That sort of reach is what I meant by the term "the browser" used generically. Different from being an extension to one or a few browsers or something like that.

Silverlight was never a native part of the browser.

.NET did run in the browser from day 1, even if only on IE.

> I think you missed the part about it running in the browser?

The article expressly stated that was not the exciting part, for them.

This is another iteration of the same old byte code blah blah, and each iteration has gotten better, and this is the best yet. Maybe.

That's like saying that the Watt steam engine [1] was basically Newcomen's atmospheric engine [2], not to mention the Aeolipile [3] from ancient Greece.

Yeah, if you squint hard enough, everything new is just the reinvention of the wheel [4]. And yet – sometimes small, incremental improvements are what it takes to push a concept (steam powered machines, or bytecode for execution in the browser) from niche applications to being a breakthrough technology. I don't know if WebAssembly will be that incremental improvement, but claiming that it won't because Java tried and failed is a lazy, fallacious argument.

[1] https://en.wikipedia.org/wiki/Watt_steam_engine

[2] https://en.wikipedia.org/wiki/Newcomen_atmospheric_engine

[3] https://en.wikipedia.org/wiki/Aeolipile

[4] Speaking of reinventing the wheel: Those radial tires, eh, who needs them? They're basically just like cross ply tires. Not to mention the spoked wooden wheels that have been around since forever.

So far looks like it, created from resistance against PNaCL, and now clamming new ideas that are actually quite old.

Yes, in the sense that everything that shares some history or idea is the same thing.

Like C and O are both chemical elements, so basically interchangeable, or like horse carriages and oil tankers are both methods of transporting things.

https://github.com/oracle/graal/tree/master/sulong

> What can wasm accomplish in that way that Java couldn't? I'm really confused about the hoopla.

Provide relatively efficient support for languages other than JavaScript that is reliably available in major browsers without user action, an insecure plugin model, etc.

On the browser side:

What killed Java was to a large part loading times. First the Plugin had to load, then the bytecode had to be run. On many systems one immediately knew when Java was used by the browser getting slow and sleeping for a while.

Flash loaded a lot faster (also systems were better, generally) however Flash apps completely messed with user experience.

Nowadays JavaScript can do a lot of things better (say changing URL, history support, back button) which can be integrated with a wasm tool for having a way more seamless integration.

As a user you simply don't notice if something is using JS or wasm.

From there it imo carries over to the server side and other places. Java simply got a bad reputation as resource hog used for bad UI in Applets and many people looked elsewhere.

And then wasm supports C and C++ (and more) with huge eco system of libraries, applications, ... (While of course these days a Java VM (incl. Android) is often used with non-Java languages as well)

I think, the main point is that it isn't owned by Oracle.

But also, that it's more for non-GC languages.

Some folks have need to create startups to fulfill a need we don't know we need to have solved.

Well, unlike Java, Wasm is not the product of a for-profit company. It's a W3C standard that actually does solve many problems most people didn't realize they had. It essentially obsoletes virtualization (CTO of Docker famously said "If WASM+WASI existed in 2008, we wouldn't have needed to created [sic] Docker. That's how important it is"). It will allow the creation of a unified software ecosystem across languages (Wasm "components" are designed to allow you to e.g. import numpy into a JavaScript project. See https://hacks.mozilla.org/2019/08/webassembly-interface-type...). The virtual machine is designed from the ground up to make many types of vulnerabilities, such a stack smashing, impossible. And, as an open standard, it's not beholden to the whims and lawyers of Oracle.

I'm not 100% certain the W3C working group won't end up fumbling it, but if you're not excited about wasm then you probably just don't know much about it.

Yet there are enough for profit companies on its genesis and foundation.

As for Docker, it is basically Java Application Servers full with YAML spaghetti to the point it makes me miss Websphere 5.

Or even better, mainframe and microcomputers language environments like on IBM i, z/OS and Unisys ClearPath.

Maybe its founders should have learned what preceded it.

The founders know very clearly what preceded it as they're working with the authors of these previous attempts (JVM, CLR, etc) to integrate their stacks with Wasm.

And yet they claim novelty while walking used trails...

Most of the entire tech stack all the way down to transistors had for profit companies involved in their genisis and foundation.

Except the " Wasm is not the product of a for-profit company." seems to be unaware of it.

Oracle was the company that completely open-sourced OpenJDK and even their own paid support JDK is just a minor modification of the former. Java and the JVM is also among the few languages/platforms with separate specifications, and multiple completely independent implementations.

If anything, Java is a much much safer bet than the oligopoly of WebKit/Blink.

It provides a security model that actually works. WASM code can't access the outside world, except for channels you explicitly provide to it.

Everything before it eventually let you have full access to the host file system, if you asked nicely, were given permission, or leveraged a bug in the system.

wasm is only as secure as the runtime that you're using, and I would be extremely surprised if none of them have sandbox-breaking bugs in the long term.

Can you elaborate? To my understanding you compile code into opcodes and it's as safe as the stack machine going through the opcodes. To my understanding the runtime is the part of the compiled code, and not the stack machine going through it.

Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro

"The Security Risk of Lacking Compiler Protection in WebAssembly"

https://arxiv.org/abs/2111.01421

Wasm outright forbids things like GOTO and other potentially insecure features opting instead for structured programming. Java has been the subject of countless security vulnerabilities.

Wasm also has the ability to stream bytecode and validate/compile as it streams (fast parsing was a major design goal) resulting in much faster startup times.

Wasm is easier to integrate into the JIT/VM already shipping in browsers so they don't have to ship two massive engines.

Wasm is a bit lower level which should result in faster execution than the JVM in the future.

Wasm doesn't require garbage collection.

Wasm has unsigned integers.

Wasm isn't encumbered by Oracle.

Which Java vulnerabilities are you referring to which require breaking bytecode compatibility?

I misspoke (and updated my comment).

Ok. I'm also curious about your comment regarding GOTO. How is it potentially insecure?

> Ok. I'm also curious about your comment regarding GOTO. How is it potentially insecure?

Really? Is that a question?

The trend over the years has been to structure our code. GOTO throws all of that away. Jump straight over the guards.

The Java language doesn't have a goto statement, and so all code is properly structured. A labeled break statement is almost a goto statement, but it still obeys structuring rules -- i.e., you cannot jump into the middle of a loop.

At the bytecode level, all structured constructs get compiled into forms that rely on goto statements. Is this inherently insecure? Should the bytecode require structured programming too? How does this guard against malicious use any more than verified bytecode that relies on gotos?

That doesn’t make code insecure, it’s just extremely powerful and very useful for compilers and optimizations even if wouldn’t be desired in a modern language for issues that gave nothing to do with security.

Yes, it has its uses.

But not really in high level languages

goto or lack thereof has nothing to do with wasm's security. It could have added goto tomorrow without breaking the sandbox. Indeed, there are a couple proposals (funclets, multiloop) that are basically dressed up goto.

WebAssembly isn't owned by Oracle.

That's the most important reason to use WebAssembly instead of Java.

It's also nice that it can do all kinds of things Java can't, but that's just icing on the cake.

OP used "couldn't" and was referring IMHO to the days of Java applets.

wasm runs in your browser. Java does not.

Java could have been made to run well in a browser, giving applets good access to the DOM of their containing page wouldn't have been too difficult.

Not only it wasn't, it has always been possible to do so from Applets.

When I wrote good access, I was really thinking that Java would have needed to provide an API at least as good as JQuery, not just a low-level way to walk nodes in a tree.

The API was there nevertheless.

It used to, though.

They are using the past tense of Java. In case you don’t know, the primary use of Java when it came out was to run “applets” inside the browser. And it was terrible. It was later when it became mostly a server-side thing (which at the time was dominated by languages like Perl, PHP, etc.)

To be precise, applets were an early application of Java. But Sun Microsystems actually developed it in the long-standing dream of the “universal binary.”

The project began in 1991 targeting set-top boxes. [source](https://web.archive.org/web/20100210225651/http://www.java.c...)

WASM is another iteration of the same noble idea done with different technologies at a different moment.

Java and the JVM have been incredibly successful. WASM has the potential to bring the dream of a universal binary even farther.

>But Sun Microsystems actually developed it in the long-standing dream of the “universal binary.”

Never heard of UCSD Pascal?

History is rewritten one faulty comment at the time.

It did once upon a time, and ironically there are now WASM versions as well.

Nothing. People have been able to compile other languages into java bytecode for decades already. That didn't turn java into the one true runtime to rule them all, and webassembly will not be any different.

I wish browser makers would focus into making the browser user and development experience actually work instead of going after the latest shiny feature.

> Nothing.

How about not relying on the JRE? Mobile support? Partitioning between applet world and JS world?

How are any of this relevant if we talk about a hypothetical future if Java was continued to be used in browsers?

Browsers would include a JRE (which they actually did at a time as well, but that’s just a tiny technicality either way), there wasn’t even mobiles capable of browsing the net at the time, but there is nothing inherently unsolvable, it’s not like there is no partitioning between wasm and js world, but in this alternative reality there wouldn’t be js. Java could have access to the DOM.

Being able to compile languages to Java bytecode doesn't help if you still have to convince users to install a Java runtime environment.

WebAssembly doesn't have this problem: almost every user is already running a browser that supports it.

In the early days of Java, it was bundled with the browser. But because Sun didn't make their own (popular) browser, they couldn't dictate the terms for what features a browser was expected to include.

Become a web standard.

Java != JavaScript

Reply on news.ycombinator.com