Hacker News Reader

Comment by pjmlp | Hacker News Reader

Just target the JVM or CLR, enjoy 25 years of ecosystem maturity in libraries, and bytecode instrumentation, and be done with it.

View on HN

JVM and the CLR are great, but what WASM offers that those do not is sandboxing. Being able to load in external plugins without having to worry about them opening random files they shouldn't, or starting network connections is some extremely useful functionality.

For this case, where the entire application is WASM you could get benefits if you for some reason have a malicious dependency. Instead of it being able to run with full user permissions, it will be limited by the interface offered.

Until it becomes a juicy attack vector, worth exploring monetarily like everything else.

"Everything Old is New Again: Binary Security of WebAssembly"

https://www.usenix.org/conference/usenixsecurity20/presentat...

Just one of the papers slowly coming up on USENIX and other security related conferences.

Want a proper sandbox outside the browser?

Use OS processes, containers and OS IPC.

If you think using containers provides improved security over WASM I don't think you understood the paper. At no point did they demonstrate compromising the host of the WASM program, just corrupting the state of POC's. There are obviously risks associated with that, but nothing that improves by going with isolated/containerized native code.

Yes currently lacking ASLR and read-only memory sites increase some risks, but strongly typed function pointers, control flow restricted to function entry points and call stack isolation more than make up for it

I think a lot about security, during the last 30 years, and worshiping WASM sales pitch isn't one of them.

Also I explicitly mentioned that is the first paper of many others, that are starting to appear on cyber security conferences.

It's a 4 year old paper, and the biggest issue it brought up, malleable read-only data, is currently being addressed with the memory control proposal. The fact that a virtual environment can't prevent all types of erroneous program behavior is not particularly noteworthy. The fact of the matter, in particular when comparing WASM against containers, WASM is a generational step forward in terms of permissioning and isolation.

For my bonafides, this is me discussing this class of vulnerabilities 8 years ago: https://groups.google.com/g/emscripten-discuss/c/gGjklbJiX1c...

To a degree, everything can be exploited, for sure. Memory safety always remains an issue. The sandboxing I was referring to however was the sandboxing from arbitrary syscalls. While some operating systems have functionality to do so (for example OpenBSD's pledge), this is unfortunately still very much a niche feature.

Containers solve this problem to a degree, but running GUIs or plugins within them is non-trivial for end users.

Or use OS processes etc and WASM sandbox.

Browser engine is a very juicy attack vector. So it makes sense to use browser engines IMO.

> but what WASM offers that those do not is sandboxing

The OS's themselves offer sandboxing, not the app platform. Mac has a locked down permissioning system and Windows has App Containers. Linux has a few sandboxing options available, like flatpak

Personally I've been running native apps on Windows / Linux for ages. No problems so far. I do not see any real value in sandboxing in my environment. What I do see is how crippled sandboxed apps are comparatively to native desktop apps.

>I do not see any real value in sandboxing in my environment

I would not like to run stuff with an implicit permission to read my browsing history and all the ssh keys.

Mature desktop Spring Boot app, eating 500 MB and starting 15 seconds.

I'm not joking, no...

Already chosing Spring for a desktop application was the first major error.

> _Just target the JVM or CLR_

In that case: or transpile to Go. Just as cross-platform, but native binaries, fast build, and probably simpler code-gen. Still get GC, still get a fine ecosystem & stdlib, still can make wasm from the generated Go code, still can use boxing/unboxing (`any` instead of `object`) if the source lang is not-statically-typed.

Unless you have C deps or "native GUI" needs (ie. C deps) of course =)

Does Go have a mature cross-platform GUI toolkit?

wasm doesn't either :)

JVM does.

Better performance too.

Can you run JVM or CLR apps in the browser?

Where is the browser in "Orca: WebAssembly Apps Without the Web."?

Where is Orca in "Can you run JVM or CLR apps in the browser?"

If you don't have an answer you can help us all not replying

Nowhere, you apparently missed the point this isn't related to the Web, too eager to reply anything.

The person was just curious about another thing, you apparently missed that you are in HN.

Microsoft has ported CLR (.NET Core) to Webassembly and it runs in the browser. You can indeed run CLR code in the browser. That is how Blazor works

It's pretty bloated and slow compared to alternatives. This may improve if WasmGC gets integrated instead of part of the payload, but it's still not a great solution, especially on constrained devices. The flip side, is running in server mode means the laggy round trip actions that feel somewhat painful in contrast, reminding me of ASP.Net WebForms and how painful that was in practice.

Welcome to the future! https://en.wikipedia.org/wiki/Java_applet

This is not Java applet. The browser can already run WASM code natively.

This is the JVM but using WASM as bytecode, which is to say it is yet another WASM interpreter but this one provides a runtime with a canvas.

Basically a Apple II running UCSD Pascal.

Yes, there are multiple efforts which compile JVM bytecode and CIL bytecode to WASM.

Why would you need to if they run outside the browser?

It is way easier to get someone to click a link than to get them to download and run your app.

Orca requires to download and run your app.

Then what is Orca useful for?

Maybe replacing containers...I had a better developer experience and a better overall quality of life when I deployed war files into a servelet container (tomcat). I wasn't patching operating system vulnerabilities across a jagged sea of micro service images or patching vendor supplied images either (literally had to do that with Kafka). I deployed a fucking war file. That's it. And I'd also imagine that a WASM module\app would have a much snappier start time without having to lug around the overhead of a container...And "Alpine Linux" can go ahead and kiss my ass (no offense).

Reply on news.ycombinator.com