Live data from Hacker News

WebAssembly: Mozilla Won

robert.ocallahan.org

1–10 of 375 posts

Re: WebAssembly: Mozilla Won

#2
Interesting perspective. I've largely kept out of that fight for many reasons, but it is interesting to see a counter-argument to the Mozilla/Firefox just apes Chrome story.

Re: WebAssembly: Mozilla Won

#3
I think this is a good thing. It probably prevented a new DirectX style dark age of the web.

Probably! I don't pretend to be able predict what path companies would have went in the next few years.

It's really good to see that there is a will to agree and that there is more than one player. Could always be more, also for keeping standards sane. (WebSQL officially failed because there isn't more variety)

Re: WebAssembly: Mozilla Won

#4
post #2

Interesting perspective. I've largely kept out of that fight for many reasons, but it is interesting to see a counter-argument to the Mozilla/Firefox just apes Chrome story.

> but it is interesting to see a counter-argument to the Mozilla/Firefox just apes Chrome story

I think looking at Quantum (https://wiki.mozilla.org/Quantum) and Phonton (https://www.ghacks.net/2017/03/31/firefox-photon-new-design-...) this becomes even more clear.

Re: WebAssembly: Mozilla Won

#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, WebAssembly application call-stacks are maintained by the JS VM, outside the memory addressable by the application, which reduces the exploitability of application bugs. (Though, again like asm.js and unlike PNaCl, the compiler is trusted.) ---

Re: WebAssembly: Mozilla Won

#6
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.

Re: WebAssembly: Mozilla Won

#7
Asm.js was a brillant idea, but wasm is more like a bytecode. This is where is the part from NaCl the author missed. Wasm is derived from asm.js but also an improvement on LLVM to make a portable bytecode, that LLVM is not. One more step in the LLVM toolchain to get portability...

Re: WebAssembly: Mozilla Won

#8
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.

I think they are talking about something like the Ken Thompson hack? http://wiki.c2.com/?TheKenThompsonHack

Re: WebAssembly: Mozilla Won

#9
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.

It means that a bug in the compiler/optimizer could allow WebAssembly code to escape its sandbox.

This is a real issue, but o some extent this extra attack surface is mitigated because vendors are reusing JS compiler backends that are already part of the TCB.

Re: WebAssembly: Mozilla Won

#10
post #2

Interesting perspective. I've largely kept out of that fight for many reasons, but it is interesting to see a counter-argument to the Mozilla/Firefox just apes Chrome story.

> but it is interesting to see a counter-argument to the Mozilla/Firefox just apes Chrome story I think looking at Quantum ( https://wiki.mozilla.org/Quantum ) and Phonton ( https://www.ghacks.net/2017/03/31/firefox-photon-new-design-... ) this becomes even more clear.

I agree that Quantum is exciting, but if there's anything interesting about Photon the article you linked really didn't bring it out. What aspects were you thinking of?
Post reply on HN