Live data from Hacker News

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

hacks.mozilla.org

1–10 of 265 posts

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

#2
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 extensible, you typically expose a C API for people to link to, or you embed a specific language like Lua or Python. Imagine embedding a WebAssembly runtime like wasmtime, and telling people they can write their extensions in any language they want.

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

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

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

#5

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?

We launched the Alliance to formalize collaboration on pre-existing projects we were all already collaborating on. We'd love to collaborate with others as well, and we're having a lot of additional conversations at the moment.

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

#6
I saw a comment about this on HN before, forgot who it was by. But it was interesting, someone mentioned the spec for WebAssembly is generic enough to apply outside of the web. I'm suspecting we'll see languages converting on node.js a la web assembly for back-end logic in your preferred language, but in any runtime this includes NodeJS but also excludes it as we see future runtimes. What's your view on this? Also, Aside from WebAssembly being in every modern browser what do you think will be the next killer feature for WebAssembly?

It would also be interesting to have an embedded WebAssembly plugin runtime, much like Lua is used all over now that you mention all those examples.

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

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

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

#8

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?

I'm sure they'll join sooner or later. Don't forget Apple.

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

#9
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.

I’d rather start with something provably secure and slower, and then optimize its performance and features over future iterations and versions.

Starting with speed and trying patch in security doesn’t seem to make things actually secure.

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

#10

I saw a comment about this on HN before, forgot who it was by. But it was interesting, someone mentioned the spec for WebAssembly is generic enough to apply outside of the web. I'm suspecting we'll see languages converting on node.js a la web assembly for back-end logic in your preferred language, but in any runtime this includes NodeJS but also excludes it as we see future runtimes. What's your view on this? Also, A…

> someone mentioned the spec for WebAssembly is generic enough to apply outside of the web

Absolutely. The spec provides a set of instructions and their semantics. Browsers provide a set of common runtime APIs. Non-browser environments can provide the sandbox with any API surface area they want.

> in any runtime this includes NodeJS but also excludes it as we see future runtimes

node.js is working on WASI support, and I'd also expect to see versions of JavaScript that run inside the WebAssembly sandbox. When we say "any language", that includes people who want to run JavaScript.

> Aside from WebAssembly being in every modern browser what do you think will be the next killer feature for WebAssembly?

Shared-nothing linking; libraries that don't have to trust each other with their entire address space. I see WebAssembly as the future plugin interface for any software that wants to be extensible.

> It would also be interesting to have an embedded WebAssembly plugin runtime, much like Lua is used all over now that you mention all those examples.

wasmtime is easy to embed; it only takes a handful of lines to load a WebAssembly file, hand it a few functions of your choice, and run it.

See https://github.com/bytecodealliance/wasmtime-demos for various demos of how to embed wasmtime.

Post reply on HN