[deleted]
The Bytecode Alliance: Building a secure, composable future for WebAssembly
61–70 of 265 posts
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#62Does this mean we'll also have a mechanism like pledge(2) to assert that the root nanoprocess or any privileged brokers only needs access to certain APIs, and permanently close them? ¹ - https://man.openbsd.org/pledge.2
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...
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#63I was talking with a colleague today who mentioned that he had looked at WASM for a particular use-case (file-verification IIRC) and had concluded that for now the overhead of copying memory made it run worse than well-written JavaScript. It is also my experience that the overhead of memory copying can really put a damper on performance improvements. Now, I get that sharing memory is a huge safety issue - it kind of…
Yes. We know that WebAssembly in its present form doesn't yet have all the functionality we'll want to make all this efficient, so we're active in many areas in the WebAssembly standards process helping move it forward.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#64First 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 growing non-browser WASM market.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#65I'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…
no ability to exfiltrate data
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#66Don't take it bad, but it looks like the java launch a (long) while ago. What makes wasm better than java ?
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.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#67I 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, an…
Following up from your comment, if you want to start running WASI modules on Node.js (or in the Browser) today, you can use this npm package! (same API as future Node WASI integration)
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#68I'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…
no ability to exfiltrate data As we've learned with things like rowhammer and Spectre, this is a very high bar. How does this initiative plan to deal with side-channel attacks?
This is discussed in the blog post; see the discussion of "time protection".
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#69Earlier quoted context omitted.
> The existence of an LLVM WebAssembly backend helps. 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 b…
> So why aren't people just shipping straight up LLVM intermediate language VMs and instead go through wasm? This is answered in the WebAssembly FAQ: https://webassembly.org/docs/faq/#why-not-just-use-llvm-bitc...
Thanks. That one's on me doing incomplete research.
Still leaves open the question as VM for obfuscation (RE tooling, ease of implementation from scratch) though.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#70So much bullshit, in the end just to strip a little bit more the user and the developer of any liberty. The dream of us corp controlled appstore for pc desktops. Who will control what you can do through the sandbox? Intel, Mozilla, Google... So one day your soft will have to be signed by them and will refuse to let you adblock ... For your own safety...
Spot on. Websites will turn from bloated to extremely bloated. Shipping 5 MB of bytecode will help with:
* Obfuscating dark patterns e.g. aggressive fingerprinting based on hardware, OS, cache contents, timing
* Breaking ad blockers
* Breaking tracking blockers like Privacy Badger
* Preventing uBlock Origin from removing annoying elements
* Preventing scraping
* Offering different prices for goods and services based on the hardware and software (as it happened before)