Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

The toolchains for building WebAssembly from numerous languages, for one thing. The existence of an LLVM WebAssembly backend helps. (While eventually there were other languages that targeted the JVM, for a long time if you wanted the JVM sandbox you had to write Java.)

WebAssembly also provides a fine-grained API surface area; you can run a WebAssembly sandbox with no external functions provided, or just a few.

WebAssembly's sandboxing isn't tied to the web; we're keeping all the same security properties when running code locally, and we're protecting modules from each other too.

Also, the WebAssembly bytecode format is designed from the beginning to support many different kinds of languages, including languages that directly store types in memory, rather than keeping everything as garbage-collected or reference-counted objects on the heap.

View on HN

>WebAssembly also provides a fine-grained API surface area

Are there concerns about compatibility when browsers are inevitably forced to reduce that surface area because of a security flaw?

And how are we going to keep all browsers on the same page with regard to what functionality they provide? It will suck if wasm turns into a cross browser compatibility nightmare.

WASM modules by themselves can do pretty much nothing besides allocating memory. If you want to use some API, you have to explicitly expose it, as a user.

Just like MSIL, Xerox PARC microcoded bytecode, IBM mainframes language environments and plenty of other examples.

Yes the concept, as well as implementations, existed for decades. I think WASM is hype because it comes from the Web/JS community and they have good communication, but technically there is nothing new under the sun.

I would say that being a success instead of a failure is something new. The JVM was successful but not for plugins, nor for embedded safety.

Also the fact that many vendors have reached a consensus on both a MVP and an update process to future features looks like a win. If Sun, Microsoft, Apple, and Google had all been on board with the (supposedly free software) JVM the story would have been very different.

Ironically WebAssembly advocacy keeps being defensive against JVM, while cleverly forgetting the dozens of other formats that also offered similar capabilities, including executing C derived languages.

> The existence of an LLVM WebAssembly backend helps.

So why aren't people just shipping straight up LLVM intermediate language VMs and instead go through wasm?

Incidentally, would you consider wasm as a destination language for virtual machines for obfuscation? I.e. is it reasonable enough to implement it all in about a week? Plus I fear like the decompilation/disassembly tooling might be there too soon for it to be a real viable option, but maybe nobody's been working on that yet.

LLVM IR is an unstable format, changes a lot and only has one implementation.So it's not well suited for a standard. Google actually did use it for PNaCl but fortunately Mozilla prevailed when wasm was created. "Do what LLVM does" is not a valid strategy. On a related note, I'm glad that Firefox doesn't support the "Do what sqlite does" WebSQL api either, but Chrome (sadly) does.

Plus it’s not really portable.

It is intentionally not portable.

> So why aren't people just shipping straight up LLVM intermediate language VMs and instead go through wasm?

This is answered in the WebAssembly FAQ: https://webassembly.org/docs/faq/#why-not-just-use-llvm-bitc...

Thanks. That one's on me doing incomplete research.

Still leaves open the question as VM for obfuscation (RE tooling, ease of implementation from scratch) though.

Do you have a typo in your second line? I can’t figure out what your question is.

Reply on news.ycombinator.com