Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hacks.mozilla.org

Post reply on HN
Print view View original

91–100 of 265 posts

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

#91

Post by mrbonner »

JoshTriplett wrote: post #2

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…

I am very interested in the inter "process" comm (or, inter "module" comm to be precised). From the surface, this runtime and modular system look pretty similar to the based OSGi runtime plus OSGi security. Not that I wanted to scare folks here as OSGi has a bad reputation of being bloated :-)

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

#92

Post by jdance »

nabla9 wrote: post #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.

I like the JVM and have done lots of code for it, but the java download&install / setting up PATH / non native gui-look / no exe-files / should i get se/ee/jre/sdk etc etc must be a big contributing factor to its lack of being more popular (client side). A lot of the experience has been clumsy, ugly and unintuitive from the start

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

#94

Post by weberc2 »

stefan_ wrote: post #81

This is historically the kind of thing that people think is very cool and important, but has turned out to not matter at all. "Languages matter" must be the biggest enduring fallacy of computer programming. It has an obvious corollary in believing processor architectures are important.

It matters a whole lot. There's lots of code written in various languages and it's often prohibitive to use it in your own project because making the languages speak with each other (especially if you have performance concerns) is a lot of work. I don't expect WASM to make this trivial, but to say that it doesn't matter is patently wrong.

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

#95

Post by gridlockd »

biggestdecision wrote: post #77
JoshTriplett wrote: post #15

Earlier quoted context omitted.

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.

WASM modules by themselves can do pretty much nothing besides allocating memory. If you want to use some API, you have to explicitly expose it, as a user.

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

#96

Post by pcwalton »

armitron wrote: post #87
JoshTriplett wrote: post #39

Earlier quoted context omitted.

The security here is based on sandboxing code and providing limited capabilities. If you're embedding wasm, you choose what capabilities to give the sandbox. For instance, if a game wants to support mods via wasm, it could give the mods APIs to the game world but not to the network or filesystem. A database plugin might have access to interpret a database object handed to it but not exfiltrate data over the network.…

It's not like what you propose hasn't been tried before. The main practical issue that I don't see this post address, is the combinatorial explosion that stems from fine-grained sandboxing of any complex application. There are bound to be executable paths through the state space that both pass initial muster and can be used by an attacker to craft a sandbox bypass. In other words, finegrained sandboxing does not solv…

You seem to be arguing that sandboxing is not a security benefit. On the contrary, sandboxing is maybe the security success story of the past decade.

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

#97

Post by arendtio »

Narishma wrote: post #93

Are those drawings supposed to be clickable? When I do so, it just opens and immediately closes a new tab or window. Firefox 70 on Windows if it makes a difference.

Works for me. Opens a new tab with an image, e.g.:

https://2r4s9p1yi1fa2jd7j43zph8r-wpengine.netdna-ssl.com/fil...

FF 70 on Arch Linux.

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

#98

Post by gridlockd »

pjmlp wrote: post #53
vbezhenar wrote: post #37

Earlier quoted context omitted.

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.

WebAssembly also has its security issues. Lack of bounds checking for multiple data accesses mapped to the same linear memory block.

How would you enforce bounds checking while supporting unsafe languages?

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

#100

Post by armitron »

pcwalton wrote: post #96
armitron wrote: post #87

Earlier quoted context omitted.

It's not like what you propose hasn't been tried before. The main practical issue that I don't see this post address, is the combinatorial explosion that stems from fine-grained sandboxing of any complex application. There are bound to be executable paths through the state space that both pass initial muster and can be used by an attacker to craft a sandbox bypass. In other words, finegrained sandboxing does not solv…

You seem to be arguing that sandboxing is not a security benefit. On the contrary, sandboxing is maybe the security success story of the past decade.

You missed my point, which is not sandboxing.

Webassembly through fine-grained sandboxing promotes software decoherence by amplifying the number of dependencies (since the major downside to working in this fashion is now advertised to be reined in).

When the number of dependencies goes up, combinatorial explosion ensures that the state-space is full of possible attacks. Fine-grained sandboxing does not solve this anti-pattern but can in fact make it a lot worse. You can examine each and every dependency and make sure that its sandbox is kosher but that does not guarantee anything about the interactions and transitive relationships between dependencies. The metasystem is now an amplified (by sheer number of dependencies) state-space that attackers can seek to manipulate.

Since security is a systemic rathen than an isolated affair, the model that the OP advocates for is broken.

Post reply on HN