Hacker News Reader

Comment by dimitar | Hacker News Reader

I wonder what the FSF might say about this development.

The draft design documents state that any WebAssembly code will have an equivalent text representation - so that is almost comparable to human readable source code. It will not be a linear list of instructions like an assembly source code but will be structured as WebAssembly is supposed to have an AST representation. [1]

I cannot see why FSF will have problem with this then, since if you are distributing a .wasm file you can construct an isomorphic text source code representation from it. This is in spirit with the user should get the source code of whatever they are executing. (Though I agree, it would not be equally readable as original C/C++ source code from the .wasm file was compiled, but then something is better than nothing)

[1] https://github.com/WebAssembly/design/blob/master/TextFormat...

The FSF is very clear what they mean by "source code"; the GPL defines it as "the preferred form of the work for making modifications to it". Decompiled .wasm isn't the preferred form (as you say yourself it's not going to be as readable as the original), so it's not source code, any more than the output of a Java decompiler or a disassembler would be.

Wouldn't you have the same problem with a minifier, then? Minified js isn't "preferred" for anything except parse time.

From what I've seen, the current GNU approach to JavaScript emphasizes encouraging websites to use code that is actually free software (i.e. legally redistributable, etc.) and marked as such; I expect they consider that more meaningful than merely being technically able to look at the source.[1][2] You can do that just as well with assembled code, so I don't think they'd care that much, but I can't speak for them.

[1] http://www.gnu.org/philosophy/javascript-trap.en.html

[2] http://www.gnu.org/software/librejs/

I don't think it makes much difference from an open/legal point of view. In fact it could clarify things: any F/OSS project compiling down to this target will have the source somewhere available and anyone wanting not to join the party can keep their code obfuscated. In fact it would make just copy+pasting OS code into proprietary projects less convenient and remove the "how was I to know?" defence: anyone using the code would have had to search out the repo and could not have missed the licensing terms unless stupid or deliberately ignoring them.

Yeah, since it is binary format, will the web start to serve closed-source JS-like scripts?

There's nothing stopping people distributing closed-source obfuscated scripts at the moment. There's not a massive difference between minified javascript and decompiled asm.js.

Am I the only one who thinks there actually is quite a difference between minified & obfuscated javascript vs bytecode?

Minification & obfuscation can only do so much without changing the logic of the script. Sure, spaces are removed, variable and function names make no sense, but most of the logic is still there just as the developer intended.

If we look at compiled Java/C++/Any high level language code, how the application logic is presented is substantially different from the original logic of the application. Making it so much harder to understand how the application works.

I disagree. Obfuscation is essentially the same as a separate compilation and can do as little or as much to distort the original logic as compiling to a lower level language.

E.g. an obfuscator could make all method calls into one identical named overload, while a compiler could emit appropriately named subroutines. The compiler preserves the logic better in this case.

Minimization is something different, but minimizers do not attempt obfuscation, it is more of a side effect of their goal.

Not much of a difference if you're running your JS code through Googles closure (https://developers.google.com/closure/), this basically does a complete re-compilation of your JS, removing dead code, unused variables, and lots of other optimizations, and in the end spits out a big ASCII blob that could just as well be byte code. It has nothing in common with the original source code.

And then you throw JSNice at it, give it to a college student, wait a weekend, and have a nicely readable source version.

Source: Am college student, for fun I disassemble websites, including the funny VM Google built for ReCaptcha.

Additionally, I wonder what the EU thinks about this, as anyone who has the ability to use a software has the right to take it apart, inspect it, and learn from it. This right can not be signed away with contracts (making the "Do not decompile" clause invalid) and is violated by all these closed source web projects.

Tbh, I should probably just decompile, deobfuscate and refactor the Google Inbox client source, and publish it on GitHub over summer break, just to show Google how useless and annoying their obfuscation is.

java bytecode can be decompiled to a very high level source code, unless explicit measures are added to actually obfuscate it.

I don't think so. There's a plan for a text representation of WebAssembly to show when you view source. That should be pretty similar to obfuscated JS

Be aware that change already happened years ago, between minifiers, obfuscators and asm.js.

Try view source on any Google web app, like Inbox. For all intents and purposes it's pretty much closed-source already - deciphering that mess is a nightmare

it can be a nightmare but I did extract some small features from gmail... they minify names and things like that but they also add bloat in their obfuscation process. But I still think that a binary web would be a step backward.

Reply on news.ycombinator.com