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.
The Bytecode Alliance: Building a secure, composable future for WebAssembly
71–80 of 265 posts
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#72Hopefully 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
#73I'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…
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#74The 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...
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
#75The 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...
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#76Don'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.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#77Don'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…
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
#78I'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…
> 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
#79Earlier 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.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#80I'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.…