Hacker News Reader

Comment by gcoda | Hacker News Reader

It might be a good idea. But scripts inside HTML not compiled because every user should have a right to see what gets executed of his device. Or this is just my fantasy and not design choice by early days engineers? I feel really conflicted about wasm and this.

Maybe now we can just put index.exe and forget about openness of web already

View on HN

I don't know of anyone who actually audits the JS they run. I know people (like Richard Stallman) who don't run JS at all, and people (like my roommate) who use NoScript with exceptions for websites they trust—which is a trust by website, not by code; they'll trust any JS that origin produces in the future. I suppose there are people running GNU LibreJS and running any JS that claims to be freely licensed, but again without looking at the code to see if it's heavily obfuscated. And then there's the rest of us, the vast majority, who just run all the JS we se.

If we already had people who audit JS before running it, preserving auditability would be worth doing, but keeping the ability to do something that (I think) literally nobody has done in over 20 years of JavaScript isn't worth trading off actual technical improvements for.

Fortunately we have something very different and (IMO) more practical, that makes this very different from an "index.exe" model: we have isolation between websites enforced at the browser level. aim.exe can read my saved quicken.exe documents. hangouts.google.com cannot interact with my bankofamerica.com account; it can't even know that I have one.

I think I have a right to see source to all the code that runs on my device with full privilege. I also think I have a right to limit the powers of code to which I don't have source, including both limiting what sorts of things it has access to and how much CPU, memory, etc. it's allowed to consume. I don't really know that insisting on the right to see source to code that runs confined is actually going to measurably improve my computing freedom.

Anyway, with this format, Devtools will be able to display the source code. It's optimized for sending + parsing, but it can be decompiled without loss of anything meaningful.

There is even a proposal to support keeping comments in the file.

> aim.exe can read my saved quicken.exe documents. hangouts.google.com cannot interact with my bankofamerica.com account; it can't even know that I have one.

Although these days we have sandboxed native software as well. iOS, Android, Mac App Store and I believe Windows has something like this now too?

This is an encoding of the JS AST, so it has a 1-to-1 mapping to JS (modulo whitespace, but the JS would probably be minified anyway). It would be trivial to build a tool to convert this back into JS, and browser devtools will probably do that automatically.

Technically, the tool to convert back to JS is already implemented. For the moment, it loses only comments and layouts and even comments might remain (see issue #11 on github).

It seems that you (like a great number of other people) assume that an ordinary person without special skills cannot comprehend what some code does once it is compiled. But that assumption is fortunately wrong. It is easier than you think to learn to read disassembly of machine code. It would be much easier to read higher level bytecode such as Android VM's smali.

So don't fear compilation. What is truly worrying is any attempt to restrict access to code that is run by a computer. Even a highly skilled reverse engineer cannot do anything if there is no way to access code.

s/ordinary person without special skills/someone who could understand the source code of the compiled artifact/ and I'm with you.

Nowadays, most JS is uglified/minified on build anyway. I believe that times when after-build JS code was readable for the end user are long gone.

Actually, this format is much more readable than minifed JS, as it maintains variable names, etc (there is a proposal to also support comments without meaningful loss of performance).

Of course, this does not prevent developers from minifying/uglifying the JS code first, if they so decide.

it just feels like putting lipstick on a pig, use binary to solve the problem of bloated utf8 files.

utf8 isn’t “bloated.” A utf8 file with just ASCII characters (every character you’ll see in JS, with the exception of foreign language strings) is identical to the ASCII encoding. You may be thinking of UTF16, which does use two bytes for every character.

Reply on news.ycombinator.com