6 ms·

I wonder what the FSF might say about this development.

by dimitar 11y ago

kenrick95 11y ago
Yeah, since it is binary format, will the web start to serve closed-source JS-like scripts?
- andybak 11y ago
  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.
  - jmickey 11y ago
    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.
    - dtech 11y ago
      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.
    - flohofwoe 11y ago
      Not much of a difference if you're running your JS code through Googles closure (https://developers.google.com/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.
      - kuschku 11y ago
        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.
    - riffraff 11y ago
      java bytecode can be decompiled to a very high level source code, unless explicit measures are added to actually obfuscate it.
    - lallysingh 11y ago
      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
- kevingadd 11y ago
  Be aware that change already happened years ago, between minifiers, obfuscators and asm.js.
- vidarh 11y ago
  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
  - ytdht 11y ago
    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.
comex 11y ago
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 http://www.gnu.org/philosophy/javascript-trap.en.html [2] http://www.gnu.org/software/librejs/ http://www.gnu.org/software/librejs/
dspillett 11y ago
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.
sankha93 11y ago
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.md https://github.com/WebAssembly/design/blob/master/TextFormat...
- pm215 11y ago
  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.
  - saucetenuto 11y ago
    Wouldn't you have the same problem with a minifier, then? Minified js isn't "preferred" for anything except parse time.

I wonder what the FSF might say about this development.

by dimitar 11y ago

I wonder what the FSF might say about this development.

kenrick95 11y ago

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

andybak 11y ago
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.
- jmickey 11y ago
  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.
  - dtech 11y ago
    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.
  - flohofwoe 11y ago
    Not much of a difference if you're running your JS code through Googles closure (https://developers.google.com/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.
    - kuschku 11y ago
      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.
  - riffraff 11y ago
    java bytecode can be decompiled to a very high level source code, unless explicit measures are added to actually obfuscate it.
  - lallysingh 11y ago
    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
kevingadd 11y ago
Be aware that change already happened years ago, between minifiers, obfuscators and asm.js.
vidarh 11y ago
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
- ytdht 11y ago
  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.

comex 11y ago

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 http://www.gnu.org/philosophy/javascript-trap.en.html [2] http://www.gnu.org/software/librejs/ http://www.gnu.org/software/librejs/

dspillett 11y ago

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.

sankha93 11y ago

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.md https://github.com/WebAssembly/design/blob/master/TextFormat...

pm215 11y ago
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.
- saucetenuto 11y ago
  Wouldn't you have the same problem with a minifier, then? Minified js isn't "preferred" for anything except parse time.