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

171–180 of 265 posts

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

#171

Post by mike_hock »

bestouff wrote: post #12

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

A non-technical advantage might be that it's not owned by one company.

Also, things don't get adopted because of their technical merits but because of random chance[1], or we wouldn't have Javascript today. So having "just another" go at trying to establish a sensible standard is good enough for me.

[1] From a technical standpoint, I consider politics, hype, parasitic corporate behavior, etc, "random chance."

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

#172

Post by int_19h »

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.

JVM bytecode semantics were all about Java - it forces the Java object model on you, for example. It was never designed to allow a diverse ecosystem of languages.

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

#173

Post by connicpu »

pjmlp wrote: post #111
gridlockd wrote: post #98

Earlier quoted context omitted.

How would you enforce bounds checking while supporting unsafe languages?

That is exactly the point, don't advertise WebAssembly as safe bytecode, if unsafe languages are part of the picture without any kind of control. Secondly, nor ISO C or ISO C++ forbid implementations that do bounds checking by default. In fact that is what most modern compilers do by default in debug mode. Finally look at memory tagging in Solaris SPARC ADI, Apple iOS or the upcoming ARM extensions support on Android…

The point of the byte code being safe is that no operations performed by WASM code could cause a memory unsafety bug from the perspective outside the sandbox. If your code violates its own memory rules then it will only mess up the logical state of its VM memory chunk, and probably produce an incorrect result. The same thing can happen in any safe language if you access the wrong indexes in an array because of a logical error in your code

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

#174

Post by StavrosK »

kaetemi wrote: post #138
Narishma wrote: post #119

Earlier quoted context omitted.

> Imagine embedding a WebAssembly runtime like wasmtime, and telling people they can write their extensions in any language they want. Is that desirable? Won't it lead to a bloated mess with every extension dragging in a different language runtime with it?

Web developers don't seem to have any concern about using gigantic quantities of memory. Don't hire a web developer to develop for games. :)

It's almost as if spending time optimizing memory usage isn't worth it because server RAM is cheap!

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

#175

Post by eeZah7Ux »

eeZah7Ux wrote: post #70
greatgib wrote: post #22

So 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…

More downvotes?

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

#176

Post by simonebrunozzi »

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…

> and I'm incredibly excited about WebAssembly outside the browser.

What's your take on the browser, instead? Curious to hear your point of view.

p.s. Thanks for working with the Alliance, I think it's great news overall.

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

#177

Post by swiley »

vanderZwan wrote: post #56

I 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…

WASM has some pretty zany ideas about computing that make the “ASM” part feel a little strange.

Web binary lisp sans tail call optimization is a little more fitting IMO.

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

#179

Post by swiley »

saagarjha wrote: post #160
pjmlp wrote: post #111

Earlier quoted context omitted.

That is exactly the point, don't advertise WebAssembly as safe bytecode, if unsafe languages are part of the picture without any kind of control. Secondly, nor ISO C or ISO C++ forbid implementations that do bounds checking by default. In fact that is what most modern compilers do by default in debug mode. Finally look at memory tagging in Solaris SPARC ADI, Apple iOS or the upcoming ARM extensions support on Android…

> In fact that is what most modern compilers do by default in debug mode. Assuming that “debug mode” is -g or equivalent, then I have not seen a modern compiler that does this.

He’s probably talking about instrumentation (valgrind, ASAN etc.)

That’s part of why running instrumented code feels like running python.

Post reply on HN