Is the security limited to sandboxing of the code itself or is there some sort of verification process involved?
The Bytecode Alliance: Building a secure, composable future for WebAssembly
31–40 of 265 posts
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#32Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#33I 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…
Completely! Here are some examples on how to embed Wasm in different languages:
* Python - https://github.com/wasmerio/python-ext-wasm
* PHP - https://github.com/wasmerio/php-ext-wasm
* Go - https://github.com/wasmerio/go-ext-wasm
* .Net - https://github.com/migueldeicaza/WasmerSharp
...and many more! (just check the Wasmer repo)
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#34Don'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. WebAs…
So why aren't people just shipping straight up LLVM intermediate language VMs and instead go through wasm?
Incidentally, would you consider wasm as a destination language for virtual machines for obfuscation? I.e. is it reasonable enough to implement it all in about a week? Plus I fear like the decompilation/disassembly tooling might be there too soon for it to be a real viable option, but maybe nobody's been working on that yet.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#35Earlier quoted context omitted.
Interesting! Is that written up somewhere public?
Some of it; see https://hacks.mozilla.org/2019/08/webassembly-interface-type... for the starting point that this will be based on.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#36In 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.
Last I checked WebAssembly still didn't have a way of actually freeing memory it has allocated either.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#37Don't take it bad, but it looks like the java launch a (long) while ago. What makes wasm better than java ?
Now if I don't need sandbox, it's going to be a tougher sell. But who knows, may be it'll outperform JVM on bare metal some day.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#38In 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.
Last I checked WebAssembly still didn't have a way of actually freeing memory it has allocated either.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#39Real worried when I see phrases like "secure by default" that this will involve some sort of security certificate or formal verification process which a government or other malicious actor can use as a weapon against its enemies. Is the security limited to sandboxing of the code itself or is there some sort of verification process involved?
We're providing mechanisms here, not identity-based policies.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#40I'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…