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

WebAssembly: Mozilla Won

robert.ocallahan.org

Post reply on HN
Print view View original

51–60 of 375 posts

Re: WebAssembly: Mozilla Won

#51

Post by _0w8t »

Nokinside wrote: post #42
_0w8t wrote: post #39

Earlier quoted context omitted.

This is not about unsafe WASM which should be rejected by verifier. This is about the raw machine output that the compiler generates from WASM. As with JIT for JS currently nothing verifies WASM compiler output. So a bug in the compiler may result in a WASM that passes the verifier to be translated into unsafe machine code.

Same thing applies to NaCl verifier. Bugs in verifier can cause problems. Verification or generation bugs are bug, not security weaknesses in the architecture. (I should not need to mention this but compiling is form of verification).

NaCl verifier in practice is much simpler than WASM compiler leading to a significantly reduced attack surface.

Re: WebAssembly: Mozilla Won

#52

Post by jonloldrup »

k__ wrote: post #45
TazeTSchnitzel wrote: post #37

Earlier quoted context omitted.

To the extent that asm.js and JavaScript are, yes. Everything is well-defined, so in theory any Turing machine should be able to run it, but it's certainly going to be easier to implement efficiently on a typical modern 32-bit or 64-bit CPU in a computer or phone than on something more unusual.

So I could write an application in, lets say Rust, compile it to WASM and run it on Linux, macOS and Windows browsers without anything extra?

yes, but the API you'll code against is limited

Re: WebAssembly: Mozilla Won

#53

Post by dtzur »

k__ wrote: post #45
TazeTSchnitzel wrote: post #37

Earlier quoted context omitted.

To the extent that asm.js and JavaScript are, yes. Everything is well-defined, so in theory any Turing machine should be able to run it, but it's certainly going to be easier to implement efficiently on a typical modern 32-bit or 64-bit CPU in a computer or phone than on something more unusual.

So I could write an application in, lets say Rust, compile it to WASM and run it on Linux, macOS and Windows browsers without anything extra?

Yes, that's the goal

Re: WebAssembly: Mozilla Won

#54

Post by petters »

JBiserkov wrote: post #33
wand3r wrote: post #19

Earlier quoted context omitted.

Potentially the article title is a reference to a story that was posted a few days ago called, Chrome Won .

Funny enough, when I googled 'Chrome Won' the first result was "Repair Chrome if it crashes or won't open" https://support.google.com/chrome/answer/142063

Interesting that Google makes that mistake in 2017.

Re: WebAssembly: Mozilla Won

#55

Post by SimonPStevens »

It's worth pointing out that Mozilla can only continue to put pressure on Google and fight for the open web if people continue to use Firefox and support them. Consider switching to Firefox even if you prefer Chrome. Report websites that don't support FF. We are all better off for the existence of Mozilla, and strong viable competition to Chrome and IE.

Re: WebAssembly: Mozilla Won

#56

Post by TekMol »

What are the main benefits of WebAssembly over asm.js?

I understand that asm.js was a subset of JavaScript that allowed the compiler to create faster code. For example because it could be sure that variable types do not change during runtime.

But what do we gain with WebAssembly? Faster download+compilation times? How much faster?

Re: WebAssembly: Mozilla Won

#57

Post by TazeTSchnitzel »

k__ wrote: post #45
TazeTSchnitzel wrote: post #37

Earlier quoted context omitted.

To the extent that asm.js and JavaScript are, yes. Everything is well-defined, so in theory any Turing machine should be able to run it, but it's certainly going to be easier to implement efficiently on a typical modern 32-bit or 64-bit CPU in a computer or phone than on something more unusual.

So I could write an application in, lets say Rust, compile it to WASM and run it on Linux, macOS and Windows browsers without anything extra?

Yep! It's a completely portable target and fulfils the promise of “compile once, run anywhere”, although how well it runs depends on the particular browser.

(It is pretty amazing you can compile C code to something that actually runs on multiple machines, it's very nice.)

Re: WebAssembly: Mozilla Won

#58

Post by roca »

jonloldrup wrote: post #52
k__ wrote: post #45

Earlier quoted context omitted.

So I could write an application in, lets say Rust, compile it to WASM and run it on Linux, macOS and Windows browsers without anything extra?

yes, but the API you'll code against is limited

That's not really true. With JS glue code (including many libraries already written) Wasm modules can access anything JS can do. E.g. there are Wasm demos showing access to WebGL2, audio generation, camera/microphone, HTTP, storage, gamepads, ...

Re: WebAssembly: Mozilla Won

#59

Post by vanderZwan »

krona wrote: post #50
chii wrote: post #38

Earlier quoted context omitted.

i hate how HN now has titles that require knowing previous posts to understand. That's the domain of reddit.

> ...that require knowing previous posts to understand Also known as "culture". It's part of what keeps communities alive, and I don't think it's bad in and of itself.

Exactly - these posts don't exist in a vacuum.

More importantly, the posts weren't written for HN specifically, but in the context of discussing the open web and WebASM. Within that community this reference will be pretty obvious.

Re: WebAssembly: Mozilla Won

#60

Post by brudgers »

dullgiulio wrote: post #6
_0w8t wrote: 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 question reminds me of Ken Thompson's Turing Award essay, Reflections on Trusting Trust, http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/p761-th...
Post reply on HN