Mozilla, Cloudflare & Others Propose BinaryAST For Faster JavaScript Load Times

[dimko]

I'm angry but I don't know what to protest against.

Potential additional security issues within browsers. Potential incompatibilities between browsers. More scary - potentially between platforms. Higher entrance level on browser market. Inability of user to look into source code of scripts/web page. Impossibility to use spiders to analyse pages, which can easilly be used for legitimate purposes.(I have written a crawler for badly designed trades/barter site, not doing anything offensive, just overall improved my own experience. I offered suggestions of things I have later on implemented in my scripts, which were refused, with that said, no java scripts affect my crawler this time, but I just gave it as example,, someone else would not be so lucky as I am)

I can probably find more reasons but I am falling asleep as I type this stuff.

[dimko]

It's a tree data structure, with extents for collections. Traversing a datastructure like this is very low risk.

When you deal with executable code there is always good chance of implementing new bugs that did not exist before. We are tlaking 0 days exploits, etc. Also barriers may fail in unexpected way. I would not agree that security vulnerability chances are low. Even if they increased by one per cent - we are talking millions of compromised machines here. You just need to send compromising code in an advertising. Also not sure, if code can be easilly decompiled. If not, makes security research into compromised JS apps more difficult.

[dimko]

It's a tree data structure, with extents for collections. Traversing a datastructure like this is very low risk.

With that said, would be curious to see it as an optional 'click to enable' option.

[randomizer]

For instance, you can already (for decades!) enable site compression from the webserver.

That's solves a different problem. Server compression reduces the payload and therefore the request time, but it doesn't improve the time required to parse the JS. This proposal gives the browser a pre-parsed AST, which cuts out a whole lot of work that the browser would normally have to do before execution.

[ssokolow]

When you deal with executable code there is always good chance of implementing new bugs that did not exist before. We are tlaking 0 days exploits, etc. Also barriers may fail in unexpected way. I would not agree that security vulnerability chances are low. Even if they increased by one per cent - we are talking millions of compromised machines here. You just need to send compromising code in an advertising. Also not sure, if code can be easilly decompiled. If not, makes security research into compromised JS apps more difficult.

It's literally just moving the "convert stream of textual bytes into optimized representation of a tree structure" part onto the server.

Every last "Is this JavaScript valid? Does it satisfy the sandboxing requirements?" check remains in the browser and still gets run on it.

If anything, this should be slightly more secure because there will be only one way to encode a given binary AST, rather than the forest of variations in JavaScript necessary for human-friendliness (eg. non-significant whitespace, comments) or legacy reasons (eg. optional semicolons) and that'll make testing a parser for it easier and more reliable.

As for making it harder to decompile, we already do the irreversible parts of an optimizing AST transformation like throwing out variable names. This is just running code through a minifier and stopping before the final "convert back to JavaScript" step. It should be trivial for the "beautify code" button in your developer tools to accept this.

[microcode]

When you deal with executable code there is always good chance of implementing new bugs that did not exist before. We are tlaking 0 days exploits, etc. Also barriers may fail in unexpected way. I would not agree that security vulnerability chances are low. Even if they increased by one per cent - we are talking millions of compromised machines here. You just need to send compromising code in an advertising. Also not sure, if code can be easilly decompiled. If not, makes security research into compromised JS apps more difficult.

Just to be clear, BinaryAST is not compilation, there is no "decompilation". There is a simple, direct mapping between javascript source code and BinaryAST. For all intents and purposes, BinaryAST is just JavaScript, but not text.

[niner]

Just to be clear, BinaryAST is not compilation, there is no "decompilation". There is a simple, direct mapping between javascript source code and BinaryAST. For all intents and purposes, BinaryAST is just JavaScript, but not text.

If that were true it would be a BinaryST, not a BinaryAST. The "Abstract" in AST means "give me the meaning, not the exact way that meaning is represented", i.e. everything that doesn't affect the output of compilation like white space or comments is missing. Also there's nothing stopping someone from optimizing the AST before delivery by e.g. inlining callees where you can prove what it called, removing unused code, etc.

That said, all these things are also possible before delivering the actual source code and indeed that's what happens with Javascript minifiers and obfuscators. But it does mean that we will get the harder to debug versions of the code all the time.

[microcode]

If that were true it would be a BinaryST, not a BinaryAST. The "Abstract" in AST means "give me the meaning, not the exact way that meaning is represented", i.e. everything that doesn't affect the output of compilation like white space or comments is missing. Also there's nothing stopping someone from optimizing the AST before delivery by e.g. inlining callees where you can prove what it called, removing unused code, etc.

That said, all these things are also possible before delivering the actual source code and indeed that's what happens with Javascript minifiers and obfuscators. But it does mean that we will get the harder to debug versions of the code all the time.

I just don't really see how BinaryAST itself would have any real impact on debugging or reverse engineering difficulty, I suspect Chrome DevTools will have a source transform to compliment their pretty print option, and you will probably just be able to look at pretty printed equivalent source like usual (with minified code).

[ssokolow]

That said, all these things are also possible before delivering the actual source code and indeed that's what happens with Javascript minifiers and obfuscators. But it does mean that we will get the harder to debug versions of the code all the time.

Given that a minifier is just dumping its optimized AST back to source, I don't see how this will make things appreciably harder to debug once developer tools have support for rendering it back to source. They're going to keep finding ways to optimize the AST regardless of whether they're serving it as BinaryAST or minified JavaScript.