Live data from Hacker News

The Bytecode Alliance: Building a secure, composable future for WebAssembly

hacks.mozilla.org

141–150 of 265 posts

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#141
post #128
post #66

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.

This is just snark. Confining malware to the sandbox is a win. Malware authors would love to load something more damaging and more valuable, and they fall back to cryptomining as a last resort to get value out of your machine.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#142
post #129

Can 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

#143
post #129

Can 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.

Yes, of course, you can draw anything on a regular HTML canvas and all you need is a thin layer of JS to do some interfacing.

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

#144

Earlier 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?

>How is this different from current web browsers for running JavaScript apps?

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

#145

Earlier 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?

Obviously it has with it controls the biggest OTHER use case for WebAssembly (the v8 runtime used in both the browser and Node) and thus can very much influence WebAssembly towards what they like (or slow it down adoption wise etc), even in areas not related with the web directly...

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#146
post #129

Can 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.

Nice! though confusingly its an editor that run JavaScript pages. https://makepad.github.io/makepad.html

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#148

Earlier 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...

Capabilities are also more complicated.

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

#149
post #125

Earlier 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…

That future possibiilty reminds me of https://en.wikipedia.org/wiki/Singularity_(operating_system) - where process/address-space isolation was replaced with fine-grained static verification of high-level code (presumably not the first experiment in this area).

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#150

First 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…

How does Enarx differ from MesaTEE?
Post reply on HN