The Bytecode Alliance: Building a secure, composable future for WebAssembly
1–10 of 265 posts
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#2Imagine 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
#3Where are Google, Microsoft and the other big names you would expect?
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#4And 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?
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#5And 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?
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#6It 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
#7But 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
#8And 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?
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#9In 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.
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
#10I 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…
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.