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

On Asm.js

acko.net

Post reply on HN
Print view View original

121–130 of 185 posts

Re: On Asm.js

#121

Post by haberman »

adamtj wrote: post #83
captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

Asm.js is not Javascript. It's native code! It's not a VM bytecode. It's assembly language, and the target machine is your native CPU. It is sandboxed by the browser. It is present on any computer with a browser and Javascript, which is more computers than have a browser and Java plugin, or any other plugin for that matter. Asm.js is less mature that Java, but it will grow up. It is currently supported by more browse…

If asm.js is not VM bytecode, what is?

If asm.js is "native code," then what an example of VM bytecode that is not "native"?

Re: On Asm.js

#122

Post by hansjorg »

haberman wrote: post #121
adamtj wrote: post #83

Earlier quoted context omitted.

Asm.js is not Javascript. It's native code! It's not a VM bytecode. It's assembly language, and the target machine is your native CPU. It is sandboxed by the browser. It is present on any computer with a browser and Javascript, which is more computers than have a browser and Java plugin, or any other plugin for that matter. Asm.js is less mature that Java, but it will grow up. It is currently supported by more browse…

If asm.js is not VM bytecode, what is? If asm.js is "native code," then what an example of VM bytecode that is not "native"?

From what I understand, asm.js is using JavaScript as a kind of portable assembly language which means there is no VM.

Re: On Asm.js

#123

Post by pedrocr »

patrickaljord wrote: post #66
pedrocr wrote: post #62

Earlier quoted context omitted.

Which is why Google should have a PNaCl javascript implementation, so that it degrades gracefully like asm.js but the fast case is faster.

There you go http://trypepperjs.appspot.com/

Awesome. I had indeed seen this before and forgotten about it.

Re: On Asm.js

#124

Post by haberman »

hansjorg wrote: post #122
haberman wrote: post #121

Earlier quoted context omitted.

If asm.js is not VM bytecode, what is? If asm.js is "native code," then what an example of VM bytecode that is not "native"?

From what I understand, asm.js is using JavaScript as a kind of portable assembly language which means there is no VM.

No VM? What do you call V8, SpiderMonkey, etc?

Re: On Asm.js

#125

Post by casperc »

adamtj wrote: post #92
saosebastiao wrote: post #54

Earlier quoted context omitted.

I can fully recognize that Java is a fast and powerful language, but it also makes me want to shove huge wooden slivers up my fingernails. That doesn't change despite the truth of your statements.

The issue is not any particular language but the platforms. Asm.js is an assembly language that gives native-code performance to browsers that's theoretically on-par with the JVMs' JITs. You can think of asm.js as a bytecode (like JVM bytecode) that all browsers can interpret. Some browsers are now getting JITs for this "bytecode". You don't write asm.js in the same way that you don't write assembly or JVM bytecode b…

On a related note, are there anything preventing a language like Clojure(script) that already targets the browser to target asm.js instead? What would the advantages and disadvantages be (if any)?

Re: On Asm.js

#126

Post by jude- »

azakai wrote: post #112
jude- wrote: post #93

Earlier quoted context omitted.

The other big advantage of PNaCl is that you have the option of distributing it as a signed application that the user downloads once. This is critical for doing in-browser encryption or manipulating sensitive data. You need there to be a trusted runtime that makes this possible, but this can't be done in pure Javascript (where it's too easy to insert malicious code that leaks your keys). It's not enough to simply use…

> PNaCl code is compiled in such a way that the browser can do just-in-time static analysis to verify that the code cannot escape the runtime. You can (and people do) similar things to sandbox JS, by running it in an iframe or a web worker, for example, plus some static analysis. Also, the structure of asm.js ensures that the code inside it cannot access outside except through a small number of statically analyzable…

How do I verify the integrity of the sandbox JS, especially since I potentially have to download it each time I need it? Similarly, how do I verify the integrity of the asm.js code I'm receiving? Integrity is just as important, if not more important, than static analysis---for example, a malicious JS crypto library could pass a static analysis test, but intentionally generate weak keys.

There are ways to integrity checks manually, of course, but as far as I know the browser does not perform these integrity checks automatically (and it would be difficult to do so--you'd need to implement JS signing, and you'd need to implement PKI to get the right public keys to verify the JS signatures).

Re: On Asm.js

#127

Post by snrip »

I am surprised that Dart is not mentioned as a comparison in any of the comments. It is also heralded as a better and more performant Javascript. Is it because the use-case of ASM more limited? I would imagine that DOM integration in ASM would be tricky so that would set Dart apart.

Re: On Asm.js

#128

Post by billforsternz »

adamtj wrote: post #83
captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

Asm.js is not Javascript. It's native code! It's not a VM bytecode. It's assembly language, and the target machine is your native CPU. It is sandboxed by the browser. It is present on any computer with a browser and Javascript, which is more computers than have a browser and Java plugin, or any other plugin for that matter. Asm.js is less mature that Java, but it will grow up. It is currently supported by more browse…

Outstanding explanation, +1 and thanks for blowing my mind. I find myself sorely tempted to drop everything and throw myself into this exciting new world. One thing that always bothers me with these xyz.js technologies; Is there an explicit or implicit implication that they are actually implemented wholly or partially in an actual file called xyz.js ? In the particular rather than the general; Is there actually an important javascript source code file involved called asm.js ?

Re: On Asm.js

#129

Post by [deleted] »

ozten wrote: post #71
ma2rten wrote: post #40

I agree, an Unreal Engine compiled to javascript doesn't make sense. It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc. However, maybe there are some libaries which compiled to asm.js are small enough that they can still run in a browser without asm.js support, e.g. an compression or an encryption algorithm…

> I agree, an Unreal Engine compiled to javascript doesn't make sense. That demo runs at 60 FPS in my browser, allowing me to casually spend more money on more video games. Your objections seem ideological, as opposed to perf benchmarks, distribution improvements or other quantifiable terms. Can you expand on why it doesn't make sense?

[deleted]

Re: On Asm.js

#130

Post by jude- »

ris wrote: post #113
jude- wrote: post #93

Earlier quoted context omitted.

The other big advantage of PNaCl is that you have the option of distributing it as a signed application that the user downloads once. This is critical for doing in-browser encryption or manipulating sensitive data. You need there to be a trusted runtime that makes this possible, but this can't be done in pure Javascript (where it's too easy to insert malicious code that leaks your keys). It's not enough to simply use…

So your argument in favour of PNaCl is a completely incidental feature of it that could be (probably quite easily) added to regular javascript and is really just a workaround for the fact that the PKI trust model for SSL is totally broken? That's a pretty odd way to end up lumped with a technology.

I need to verify that not only does the JS I received behave correctly (i.e. it will be appropriately sandboxed), but also that the JS I received from the server is the one that the developer intended to serve me. This is because even with perfectly secure transport, a compromised server can always give me JS that is valid and stays sandboxed, but does bad things (such as generating weak keys).

I need to perform an integrity check on the JS to satisfy the second requirement, and the integrity check should not depend on the server that served the JS (since a compromised server could lie about its hash, for example). Moreover, the check needs to be automatic, and trustworthy. One solution is to check the hash of the JS against known-good hashes from the developers (i.e. get the JS from the website, and get the hash from a CA), and then cache the JS locally until I determine that a new version of the JS exists (I want to avoid re-downloading it over and over--that only gives MITM and MITS attackers more chances to serve me bad JS, and it's slow). Not an easy problem; otherwise we'd be doing it already :)

PNaCl offers the infrastructure to do this. I would use asm.js if it did so as well.

Post reply on HN