Earlier quoted context omitted.
Java was wildly successful. It was kicked out of browsers because of its huge attack surface. WASM implementations seem to be going with a sandbox approach out of the gate.
A sandbox mostly used by cryptominers already.
The Bytecode Alliance: Building a secure, composable future for WebAssembly
141–150 of 265 posts
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#142Can you use wasm instead of regular js/html? I'm thinking for rich GUIs it would be great, even just for company internal sites. I can't find any good examples though.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#143Can you use wasm instead of regular js/html? I'm thinking for rich GUIs it would be great, even just for company internal sites. I can't find any good examples though.
However, I'd discourage you build complex GUI-s in WA. If you do that it means that you have to reimplement everything how the browser works and your end users are accustomed to.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#144Earlier quoted context omitted.
When you use WebAssembly, you're in control of the sandbox. You can pass things into the sandbox and let the module use it. There's no signing/certificate/appstore system tied to WebAssembly.
How is this different from current web browsers for running JavaScript apps? Don't you think there is lockdown now?
WebAssembly is a thing that web page Javascript can choose to use, and the Javascript is in control of what it exposes to WebAssembly. WebAssembly doesn't grant or somehow take away any privileges to the web page. (Ignoring performance, it would be possible to implement WebAssembly inside of a Javascript library as an interpreter.)
>Don't you think there is lockdown now?
No? Anyone can author and host a website, anyone can view html+js saved on their own machine, etc. Open source web browsers exist, are fully-featured, and are popular.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#145Earlier quoted context omitted.
> First of all, congrats on forming the alliance! No Google on board, it means no Chrome support
What does Chrome have to do with a plugin for my image editor or a command line tool on my server?
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#146Can you use wasm instead of regular js/html? I'm thinking for rich GUIs it would be great, even just for company internal sites. I can't find any good examples though.
I have a recent note that says (from HN id=21495338), try makepad.github.io/makepad . My recollection is that this is such an example.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#147Don't take it bad, but it looks like the java launch a (long) while ago. What makes wasm better than java ?
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#148Earlier quoted context omitted.
The WASI and Bytecode Alliance approach is based on capability-based security, granting only the access needed for a module to do its job.
To expand on this, capabilities allow us to go further than pledge(2): it enables selective forwarding of capabilities to other nanoprocesses, such as only forwarding a handle to a single file out of a directory, or a read-only handle from a read-write one, etc...
I fear that at the end of the day, capabilities will have the same fate as other sandboxing mechanisms: nobody will use them. And, just so that their application works and avoid support burden, developers will tell people to use a setup that enables access to everything.
pledge(2) and unveil(2) learned from the past and are way simpler. I really wish WebAssembly had adopted similar mechanisms.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#149Earlier quoted context omitted.
Reading through this, this sounds like mostly a capability based architecture, with process isolation replaced with a statically typed bytecode in which you can verify that each module can only use capabilities passed to it. I was wondering why the focus on copying memory between the processes. It should be possible to make capabilities which represent a pointer and a length (and maybe an access mode), which could be…
What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. Since we want to support those languages as first-class citizens, we can't requ…
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#150First of all, congrats on forming the alliance! > Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data That's what we are working towards on Wasmer, the server side WebAssembly runtime - https://github.com/wasmerio/wasmer In fact, we already have a lot of different language integrations (maintained by us and the community) and our software is the pione…
Disclaimer: I'm from the Enarx project ( https://enarx.io ) which is associated with the BytecodeAlliance. I think a good analogy is: wasmer is to qemu as BytecodeAlliance is to rust-vmm. Wasmer is a general purpose WASM runtime. But BytecodeAlliance is a place to build tooling for the construction of runtimes (WASM or otherwise), including special purpose runtimes. I think there is a lot of space for both in the gro…