Live data from Hacker News

WebAssembly: Mozilla Won

robert.ocallahan.org

21–30 of 375 posts

Re: WebAssembly: Mozilla Won

#21

Is there anywhere a "hello world" or simple DOM modification program which I can implement with WebAssembly?

AFAIK you cannot access the DOM from WebAssembly right now, although it probably will come in future versions.

But you can use the WebAssemblyExplorer https://mbebenita.github.io/WasmExplorer/: There is also a nice video about using WebAssemblyExplorer and even uses a simple WebAssembly-Module: https://www.youtube.com/watch?v=3XrGjSnPHGY&t=310s

Re: WebAssembly: Mozilla Won

#22
post #5

This article in few lines lists key differences between PNaCl and WebAssembly: --- WebAssembly defines no new platform APIs other than some APIs for loading and linking WebAssembly code, relying on standards-based Web APIs for everything else. WebAssembly differs from asm.js by defining a bytecode format with some new operations JS doesn't have, so some spec work was required (and has been done!). Like asm.js, WebAss…

I don't really understand what "the compiler is trusted" means. What could an evil compiler really do? Maybe add a spinning loop to waste CPU cycles, but that can be done in JS too.

The "compiler" here refers to the WebAssembly -> machine code compiler, not the C -> WebAssembly compiler. NaCl used some clever tricks to guarantee the safety of raw machine code.

Re: WebAssembly: Mozilla Won

#26
post #17

I don't really like the headline. I don't want Mozilla to "win", and I don't think Mozilla wants to either; I want the open web to flourish. That said, the article is very informative, and well-balanced. It was really good of Google and the other browsers to join the wasm bandwagon. And yes, although as the author himself points out, "proclaiming a "winner" is unimportant or even counterproductive", Mozilla does dese…

It's a tricky title because out of context (i.e. reading the title on HN without clicking through to the content) it sounds a little puerile, but upon reading the article, the title fits very well.

The general message being: "Mozilla are being very diplomatic and restrained, whereas many in their current position would be outright celebratory"

Re: WebAssembly: Mozilla Won

#27
post #13

Earlier quoted context omitted.

I don't really understand what "the compiler is trusted" means. What could an evil compiler really do? Maybe add a spinning loop to waste CPU cycles, but that can be done in JS too.

Both PNaCl and WebAssembly need a compiler to a get the machine code run by CPU, but the output of PNaCl is checked via NaCl verifier while nothing checks that the output of WebAssembly is safe machine code. As the verifier for NaCl is likely to be an order magnitude smaller than a component in WebAssembly implementation that verifies and compiles the bytecode to the native code, PNaCl attack surface is much smaller.

This.

Webassembly is an overcomplication. But, as always, I suppose we have to live with it.

Re: WebAssembly: Mozilla Won

#28
post #5

This article in few lines lists key differences between PNaCl and WebAssembly: --- WebAssembly defines no new platform APIs other than some APIs for loading and linking WebAssembly code, relying on standards-based Web APIs for everything else. WebAssembly differs from asm.js by defining a bytecode format with some new operations JS doesn't have, so some spec work was required (and has been done!). Like asm.js, WebAss…

I don't really understand what "the compiler is trusted" means. What could an evil compiler really do? Maybe add a spinning loop to waste CPU cycles, but that can be done in JS too.

The « Reflections on Trusting Trust » paper by Ken Thompson addresses this exact issue: http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/p761-th...

Re: WebAssembly: Mozilla Won

#29
post #13

Earlier quoted context omitted.

I don't really understand what "the compiler is trusted" means. What could an evil compiler really do? Maybe add a spinning loop to waste CPU cycles, but that can be done in JS too.

Both PNaCl and WebAssembly need a compiler to a get the machine code run by CPU, but the output of PNaCl is checked via NaCl verifier while nothing checks that the output of WebAssembly is safe machine code. As the verifier for NaCl is likely to be an order magnitude smaller than a component in WebAssembly implementation that verifies and compiles the bytecode to the native code, PNaCl attack surface is much smaller.

It would be possible to leverage a simple machine code verifier similar to NaCl's in a WebAssembly backend. Nobody does it right now, but there's been some work on taking WebAssembly as input to their Subzero PNaCl->NaCl compiler.

Re: WebAssembly: Mozilla Won

#30

Congrats for winning! This does not change Firefox being on its final death throes though. Chrome won where it counts.

Nobody lost. We all "won", because, for the time being, Chrome is important for Google: They need to keep the open web as a platform competitive with Apple's iOS ecosystem, as well as Facebook's walled garden, because Google rules advertising in the first, but not in the latter two.

Thus, Google's interests align with the users', and also Mozilla's. It's perfectly possible for this to change when, for example, it becomes lucrative for Google to move people from the open web to android apps. At that point, we should all hope to have Mozilla and others like it still around.

It shouldn't be surprising that Google can outcompete any other organisation when it sees something as relevant to the absolute core of its business.

Post reply on HN