Live data from Hacker News

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

hacks.mozilla.org

11–20 of 265 posts

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

#11
post #7

In my opinion this is a fascinating approach, and it may end up transforming our industry. But the main question I've had is how big the overhead is, specifically since modules don't share their wasm Memory. That means data will be constantly copied between them. Compared to regular static or even dynamic linking, that may be a noticeable slowdown.

> specifically since modules don't share their wasm Memory. That means data will be constantly copied between them.

We're working on that. We want to make it possible for modules to share memory in a controlled way, without giving access to their entire address space.

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

#13
Super cynical, I realize, but whenever I see the description “secure by default” for something computer related, and they don’t mean, “we unplugged it,” I assume what they really mean is, “we made the code so complex we can’t find the problems.”

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

#14

And a key point: "Our founding members are Mozilla, Fastly, Intel, and Red Hat" Where are Google, Microsoft and the other big names you would expect?

> Where are Google, Microsoft and the other big names you would expect?

Those folks are the incumbents. What do they have to gain from joining? Google especially has developed a colossal amount of tooling in-house that gives it an edge over others; new tech may make the lives of competition easier. Ditto to an extent for MS, though there, I suspect it's more bureaucracy and not seeing anything to gain.

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

#15

Don't take it bad, but it looks like the java launch a (long) while ago. What makes wasm better than java ?

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.

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

#16
post #7

In my opinion this is a fascinating approach, and it may end up transforming our industry. But the main question I've had is how big the overhead is, specifically since modules don't share their wasm Memory. That means data will be constantly copied between them. Compared to regular static or even dynamic linking, that may be a noticeable slowdown.

>specifically since modules don't share their wasm Memory. That means data will be constantly copied between them.

It is possible today to have modules import memory from the host, which means the host can provide the same imported memory to multiple modules. Then modules can pass pointers to each other without needing any memcpys.

It does require the modules to not tread on each other though, such as by requiring them to have distinct static offsets (poor man's linking), or by requiring them to be PIC / compiled with relocation info so that they can be relinked by the host loader.

It doesn't seem to me from reading TFA that this is going away, merely that there are planning to add alternatives to make it more fine-grained.

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

#18

And a key point: "Our founding members are Mozilla, Fastly, Intel, and Red Hat" Where are Google, Microsoft and the other big names you would expect?

Other than on the committee that designed WebAssembly, you mean?

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

#19

I'm one of the folks working with the Alliance, and I'm incredibly excited about WebAssembly outside the browser. Happy to answer questions. Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data. Imagine supporting a safe plugin API that isn't just for C and languages that FFI to C, but works natively with safe datatypes. Today, if you want to be extens…

[deleted]

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

#20
post #4

And a key point: "Our founding members are Mozilla, Fastly, Intel, and Red Hat" Where are Google, Microsoft and the other big names you would expect?

Google and Microsoft probably don't have much use for WebAssembly outside the browser, whereas companies like Fastly and Cloudflare run customers' untrusted WebAssembly on their edge server networks.

[deleted]
Post reply on HN