Live data from Hacker News

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

hacks.mozilla.org

71–80 of 265 posts

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

#71
JVM was supposed to be this. Gosling said publicly that JVM is more important than Java. .

Many things went wrong. Microsoft was actively sabotaging JVM. They implemented very fast JVM for Explorer and their operating system that intentionally broke the JVM 1.1 standard. See Sun vs Microsoft 1997. Microsoft lost and paid damages. .NET was created to do more damage.

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

#72
This is great. I've been waiting for a module-level permissions system for a while now; it definitely seems like the best approach to mitigate supply chain attacks.

Hopefully once WASM has demonstrated the principle other languages will follow. This seems like it'd be especially useful in the JS ecosystem, where many modules are already small enough that they'd likely be able to run with no permissions at all.

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

#73

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…

For the Horde!

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

#74
post #58

The primary use case for WebAssembly is malware.[1] We're probably going to regret letting WebAssembly into the browser. Because vendors won't let it be locked down so much that it can't be used for ads and tracking. Which means it has to allow malware. [1] https://www.tu-braunschweig.de/Medien-DB/ias/pubs/2019-dimva...

Thanks for the reference.

Just so it's clear, the definition of "malware" used here is in-browser crypto mining and obfuscation. Only 1 in 600 of the top 1 million sites use WebAssembly. WebAssembly doesn't actually provide a new vector for malware.

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

#75
post #58

The primary use case for WebAssembly is malware.[1] We're probably going to regret letting WebAssembly into the browser. Because vendors won't let it be locked down so much that it can't be used for ads and tracking. Which means it has to allow malware. [1] https://www.tu-braunschweig.de/Medien-DB/ias/pubs/2019-dimva...

[deleted]

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

#76

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

Java failed to deliver safe sandbox. Browsers finally booted it because of numerous vulnerabilities. For me wasm looks exactly like another JVM attempt, but it's a good thing, because the idea is good, we just need better implementation. 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.

Technically I agree, but nowadays with 5G+Edge computing, where low latency application requirements are essential, there will be other performance constraints not tackled by Java that needs new solutions. Previous JVM attempts mostly focused on "write once, run anywhere". But now, "anywhere" means "anywhere and quickly" :)

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

#77

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. WebAs…

>WebAssembly also provides a fine-grained API surface area

Are there concerns about compatibility when browsers are inevitably forced to reduce that surface area because of a security flaw?

And how are we going to keep all browsers on the same page with regard to what functionality they provide? It will suck if wasm turns into a cross browser compatibility nightmare.

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

#78

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…

The post mentions:

> tiny IoT device

But, I've looked at this in the past and concluded wasm was a pretty poor fit for small devices: 1) it only addresses memory in 64KB pages (perhaps more SRAM than you might have) and 2) requires both single and double float support.

(1) might be possible to work-around by backing the memory space with smaller page allocations -- at the cost of indirection for every memory access. (2) seems pretty insurmountable -- it'll just need a chunk of extra C library.

Are you aware of any projects working on this for smallish microcontrollers?

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

#79
post #36

Earlier quoted context omitted.

Last I checked WebAssembly still didn't have a way of actually freeing memory it has allocated either.

You give it a heap. It doesn't allocate memory. It may allocate within its own heap, using whatever allocator/gc strategy it inherits from it's host language.

Which means it can't free. But that's also not accurate, anyway, there's a brk() method to grow the heap. Which is such a bad starting point for a new runtime.

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

#80
post #78

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…

The post mentions: > tiny IoT device But, I've looked at this in the past and concluded wasm was a pretty poor fit for small devices: 1) it only addresses memory in 64KB pages (perhaps more SRAM than you might have) and 2) requires both single and double float support. (1) might be possible to work-around by backing the memory space with smaller page allocations -- at the cost of indirection for every memory access.…

You don't have to support floats; you can, for instance, support loading and validating WebAssembly modules only if they don't use any floating-point operations.
Post reply on HN