Live data from Hacker News

The Road to the WASM Component Model 1.0

bytecodealliance.org

41–50 of 111 posts

Re: The Road to the WASM Component Model 1.0

#41
post #3

Please please please bring it to the browser. I'm so done with the terrible ergonomics of everything at the was bounary having to pretend it's JavaScript

Pretty sure the JS shim is still needed to talk to web apis, even if it might look slightly different (there is a 'use component' now in the JS shim in Mozilla's experiment similar to the old 'use asm' for asm.js - at least that's what the post says).

Re: The Road to the WASM Component Model 1.0

#42
post #2

I'm unreasonably excited about WASI. WASI is the thing which takes WebAssembly from a tool for running stuff in a browser to a tool that can run entire portable sandboxed applications on a computer - with controlled filesystem and network access. I don't ever want to run untrusted code from the internet outside of a sandbox ever again. If WASI lives up to its full potential I won't have to - we'll have a robust, cros…

Use cases I am more excited about: 1) Replace webhooks in web apps with wasm binaries provided by the customer, but that run in the web app servers. 2) Safer plugin system for professional software (plugins for photoshop, plugins for IDEs, etc) 3) Safer mod system for games and server-side mods that run on the game-maker server.

We had that in the 90's with Java. Why would this approach succeed today?

Re: The Road to the WASM Component Model 1.0

#43
post #13

Earlier quoted context omitted.

I'm curious if people have a good story for why WASI will succeed where Java failed

Programs written in Java require installation of a middleware called Java runtime. It adds extra friction for end-users. And even if one has Java runtime installed, a newer version may be necessary for a recently-published application. With WASM it may be the same, unless al major OS vendors integrate a WASM runtime so that it doesn't need to be installed separately.

> Programs written in Java require installation of a middleware called Java runtime. It's possible to link or embed a Java runtime in an existing application.

Re: The Road to the WASM Component Model 1.0

#44
post #2

I'm unreasonably excited about WASI. WASI is the thing which takes WebAssembly from a tool for running stuff in a browser to a tool that can run entire portable sandboxed applications on a computer - with controlled filesystem and network access. I don't ever want to run untrusted code from the internet outside of a sandbox ever again. If WASI lives up to its full potential I won't have to - we'll have a robust, cros…

Use cases I am more excited about: 1) Replace webhooks in web apps with wasm binaries provided by the customer, but that run in the web app servers. 2) Safer plugin system for professional software (plugins for photoshop, plugins for IDEs, etc) 3) Safer mod system for games and server-side mods that run on the game-maker server.

Check out https://extism.org, it is built for those kinds of use cases. However I think WASI and components could enhance it.

Re: The Road to the WASM Component Model 1.0

#45
post #2

I'm unreasonably excited about WASI. WASI is the thing which takes WebAssembly from a tool for running stuff in a browser to a tool that can run entire portable sandboxed applications on a computer - with controlled filesystem and network access. I don't ever want to run untrusted code from the internet outside of a sandbox ever again. If WASI lives up to its full potential I won't have to - we'll have a robust, cros…

Sorry but how exactly does the sandboxing help? You download and run an app that you expect to be useful and that you need. The app needs permission to access your data. If you want to use the application what choice do you have except to grant it access?

Point being you wouldn't run untrusted code in the first place and for "trusted code" you end up accepting it's access requirements anyway.

So logically I'd think that the malware would just get piggy bagged into actual non-obvious utility apps and nothing is gained.

Second problem is that the security model hoops make for terrible APIs and user experiences. Just look at the current filesystem browser APIs. It must be mentally challenging to design APIs to Be usable and the nerf them for security purposes to make them "not too usable".

Finally one must note that at least right now the webasm ecosystem is rather immature and the de-facto only tool (emscripten) is an amateur hour hobby project. So it's going to take some decades still before the tooling is really getting there.

Re: The Road to the WASM Component Model 1.0

#46
post #19

Earlier quoted context omitted.

> I don't ever want to run untrusted code from the internet outside of a sandbox ever again WASM is great, but I think it's a wrong approach for sandboxing problem. It's technically possible to sandbox native applications (compiled into target machine code) using OS-builtin mechanisms, but it's not done for compatibility reasons, because this is the way things were done last 50 years or so.

Exactly. It is entirely a misconception to believe that WASM is this silver bullet on sandboxing and it is not that great security-wise I’m afraid. It is only now being inspected by researchers and attackers who have found sandbox escapes [0] (chrome 0day), out-of-bounds [1] / use-after-free [2] and many other [3] flaws [4] in WebAssembly which I also agree that it is not enough for sandboxing at all. [0] https://nvd…

There's no reason to believe that [0] has anything to do with WASM, [1] and [2] are runtime implementation bugs, [3] is a vulnerability in a "weak" sandboxing library VM2 - it has nothing to do with WASM as such, and [4] is another implementation bug in an experimental WASI feature of that specific runtime which is gated behind a build flag.

------

[Re: 3] https://github.com/patriksimek/vm2

> vm2 attempts to sandbox untrusted JavaScript code within the same Node.js process as your application. It does this through a complex network of Proxies that intercept and mediate every interaction between the sandbox and the host environment.

> JavaScript is an extraordinarily dynamic language. Objects can be accessed through prototype chains, constructors can be reached via error objects, symbols provide protocol hooks, and async execution creates timing windows. The sheer number of ways to traverse from one object to another in JavaScript makes building an airtight in-process sandbox extremely difficult.

[Re: 4] https://github.com/search?q=repo%3Abytecodealliance%2Fwasm-m...

Re: The Road to the WASM Component Model 1.0

#47
post #2

I'm unreasonably excited about WASI. WASI is the thing which takes WebAssembly from a tool for running stuff in a browser to a tool that can run entire portable sandboxed applications on a computer - with controlled filesystem and network access. I don't ever want to run untrusted code from the internet outside of a sandbox ever again. If WASI lives up to its full potential I won't have to - we'll have a robust, cros…

Hey, this is also my interest. I was just looking into whether it was possible to e.g. build an archive extractor that runs like a normal program but does the actual extraction completely in wasm. Unfortunately, AFAICT it's possible but requires custom code; you can't ( yet , I hope) just compile unzip/libarchive/whatever with CC=wasicompiler and get a sandboxed binary. But we're getting close.

You should be able to do exactly that though? Why do you think you can't?

You will of course need to include a lot of support code to provide the relevant syscalls and otherwise emulate the environment that the code expects. But there are plenty of examples of that at this point.

Re: The Road to the WASM Component Model 1.0

#48
post #42

Earlier quoted context omitted.

Use cases I am more excited about: 1) Replace webhooks in web apps with wasm binaries provided by the customer, but that run in the web app servers. 2) Safer plugin system for professional software (plugins for photoshop, plugins for IDEs, etc) 3) Safer mod system for games and server-side mods that run on the game-maker server.

We had that in the 90's with Java. Why would this approach succeed today?

Why wouldn't it? It's a different technology stack, developed with the benefit of decades of additional experience running hostile code on the web.

Re: The Road to the WASM Component Model 1.0

#49
post #2

I'm unreasonably excited about WASI. WASI is the thing which takes WebAssembly from a tool for running stuff in a browser to a tool that can run entire portable sandboxed applications on a computer - with controlled filesystem and network access. I don't ever want to run untrusted code from the internet outside of a sandbox ever again. If WASI lives up to its full potential I won't have to - we'll have a robust, cros…

Why not just run a vm?

Re: The Road to the WASM Component Model 1.0

#50

It’s great we are past the “wasm is not replacing JavaScript” phase. Or “you don’t need DOM for wasm . That’s what JavaScript is for”

I don't get it why you need direct DOM access. Just wrap it in JS calls. It's not like current websites are super fast and creating a wrapper will slow it down unnecessarily.
Post reply on HN