4 ms·

I see the comments here are overwhelmingly positive, so I will keep an open mind. That said, someone please correct me if I'm wrong, but this runs binary code l

I see the comments here are overwhelmingly positive, so I will keep an open mind. That said, someone please correct me if I'm wrong, but this runs binary code loaded over the internet in your browser? As a free-software advocate, this concerns me.

deleted 11y ago
[deleted]
jfbastien 11y ago
Software isn't free because you can see its source. JavaScript is no free-er, and no more view-source-able when minified, than WebAssembly is. View-source is an explicit goal of WebAssembly's first launch: https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webassembly-support-view-source-on-the-web https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...
s3th 11y ago
WebAssembly is an open source runtime developed under the governance of a W3C Community Group [0]. The binaries that get sent over the wire are simply more efficient ways to pack existing types of code. We will soon have a textual encoding that makes modules easy to introspect [1] and we have a long list of tooling plans to make sure that the web stays open and debuggable [2]. [0]: https://www.w3.org/community/webassembly/ https://www.w3.org/community/webassembly/ [1]: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat... [2]: https://github.com/WebAssembly/design/blob/master/Tooling.md https://github.com/WebAssembly/design/blob/master/Tooling.md
- kuschku 11y ago
  Great! We should make sure that browsers refuse to run any code in the future that isn’t available in its full source. Yes, that includes ReCaptcha /me looks angrily at Google
  - dlubarov 11y ago
    I think the idea is that WebAssembly apps will normally be closed-source, but browsers will ship with disassemblers, making it easy to inspect the app logic in a common text format.
    - lisivka 11y ago
      Then every exe file is open-source, because we have disassemblers. Don't lie to yourself: webassembly is for closed-source applications. They will be compiled by an obscure compiler, so dissassembling back to logical code will be too costly to be practical. We saw this many times: for v1, disassembler works perfectly and maps 1:1 from binary to code, but for version xxx.0 it's no longer true, because of various tricks and optimizations.
      - dlubarov 11y ago
        No one's saying wasm apps will be open source, just that there will be a reasonable way to inspect their logic. Of course making sense of certain wasm apps will be challenging. JS code can be hard to follow as well, if it was generated by a tool like GWT, or minified, or obfuscated.
        lisivka 11y ago
        I am agree, that wasm will be on par with generated/minified JS right now, but I predict that wasm will beat JS in future versions. My prediction is based on experience. It is very easy to introduce a binary thing which is hard to map to flat text. I.e. first version of wasm will be 1:1 map to JS, but NEXT versions of wasm will introduce optimizations, which are quite possible in compact binary format but are not possible in flat text format, so 1:1 map from wasm to JS will be broken.
- cjfont 11y ago
  I'm going to guess that the format lends itself better to code obfuscation than JavaScript, for those that do not want their code to be open.
  - matt4077 11y ago
    Even if it's easier to obfusfate WebAssembly, does that matter? If you run the 2MB+ JS libraries in se today through uglify.js it becomes almost impossible to understand the macrostructure just by reading the code. It's only through dynamic tools that we can even begin to understand minified JS today. Those are actually quite excellent: just try by starting the react or relay tools on facebook. That ecosystem is hopefully not changing, so what remains is simply that the format is now binary. I agree that that makes me somewhat uncomfortable but realistically it doesn't really change anything.
pcwalton 11y ago
Before, we had asm.js. asm.js isn't very readable. By contrast, Web Assembly has a nice human-readable (though terse and low-level) IR. It even looks like Lisp, if you like that :) Web Assembly is a small step toward better human inspectability of the compiled blobs your browser is executing, compared to Flash, Java, and asm.js. To be sure, it doesn't mandate that the source be available in the form preferred for editing. But the Web hasn't done that since 1997.
- mrec 11y ago
  Agreed. It might also be nice to have wasm blobs compiled from open source code supply a standard metadata link to that code (the project's GitHub repo or whatever) so that UAs can offer nice affordances to replace Ctrl-U if they want to.
kibwen 11y ago
I don't think the downvotes are necessary here, this is a legitimate question. Understand that Wasm is ideally just an alternate way to drive the same virtual machine that Javascript currently manipulates. This isn't the same thing as, say, a NPAPI plugin like Flash was. Wasm is still subject to the same security restrictions as the rest of the web platform. Furthermore, and I could be wrong here, but I believe that the "binary" representation of Wasm is really just custom, trivially-reversible compression for faster data transfer and parsing. The OP even mentions that a "standard textual representation" is the next step on the agenda, which I imagine will work similarly to today's source maps for code that compiles to Javascript.
- tracker1 11y ago
  Well "just a binary representation" in the same way that .Net's CLR is just converted C#/VB/F# etc... Unless you know the source language, and have some sort of reverse-compiler (or source maps), then getting back to a readable/usable source isn't so easy. Though that doesn't mean you can't trace through what goes down the wire, it won't be quite as low-level as x86 assembly, but will be lower level than most are comfortable with.
  - kibwen 11y ago
    But this is already true today with Javascript transpilation and minification. I have been in the unenviable position of needing to reverse-engineer compressed Javascript for which no "readable" source was available, and even with prettifiers the experience is hardly enjoyable.
    - tracker1 11y ago
      Absolutely agreed... one of the reasons that source maps are nice... but if you nuke sourcemaps in production, good luck... If it's someone else's source, then you may be SOL, just the same, it is what it is... if you're reverse engineering a gui, best bet is to create a clone... if it's an api, better to look into the wire protocol.
tomjen3 11y ago
I hear this argument a lot. It may have been true once, say 5 years ago. Today I can already do that -- look at the output of the Google closure compiler with advanced optimizations turned on. Sure it is javascript and not binary, but all comments have been removed, all variables have been given short and meaningless names that are frequently reused and all the structures have been turned inside out. And those optimizations are only for speed.
- CaptSpify 11y ago
  And I've never understood this argument. Yes, JS allows people to ship obfuscated code. Doesnt mean we should give up and stop expecting readable code.
gkya 11y ago
I am a bit baffled too, but in the end of the day, it's no different from running javascript. Most pages load probably millions of lines of JS and you can't audit it (disclaimer: I totally made up that number). For the security conscious, the only way is to implement very strict JS/cookie whitelisting, which is what I do. For the others, well, I guess it's no different from running JS in the end of the day. I wonder if this will make it's way into WebKit, and if so its implications for Xombrero, will I have to maintain a seperate WASM whitelist, or disabling JS will disable it too? TBH I plan not allowing even the most trustible website run such code on my computer.

deleted 11y ago

[deleted]

jfbastien 11y ago

Software isn't free because you can see its source. JavaScript is no free-er, and no more view-source-able when minified, than WebAssembly is. View-source is an explicit goal of WebAssembly's first launch: https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webassembly-support-view-source-on-the-web https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...

s3th 11y ago

WebAssembly is an open source runtime developed under the governance of a W3C Community Group [0]. The binaries that get sent over the wire are simply more efficient ways to pack existing types of code. We will soon have a textual encoding that makes modules easy to introspect [1] and we have a long list of tooling plans to make sure that the web stays open and debuggable [2]. [0]: https://www.w3.org/community/webassembly/ https://www.w3.org/community/webassembly/ [1]: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat... [2]: https://github.com/WebAssembly/design/blob/master/Tooling.md https://github.com/WebAssembly/design/blob/master/Tooling.md

kuschku 11y ago
Great! We should make sure that browsers refuse to run any code in the future that isn’t available in its full source. Yes, that includes ReCaptcha /me looks angrily at Google
- dlubarov 11y ago
  I think the idea is that WebAssembly apps will normally be closed-source, but browsers will ship with disassemblers, making it easy to inspect the app logic in a common text format.
  - lisivka 11y ago
    Then every exe file is open-source, because we have disassemblers. Don't lie to yourself: webassembly is for closed-source applications. They will be compiled by an obscure compiler, so dissassembling back to logical code will be too costly to be practical. We saw this many times: for v1, disassembler works perfectly and maps 1:1 from binary to code, but for version xxx.0 it's no longer true, because of various tricks and optimizations.
    - dlubarov 11y ago
      No one's saying wasm apps will be open source, just that there will be a reasonable way to inspect their logic. Of course making sense of certain wasm apps will be challenging. JS code can be hard to follow as well, if it was generated by a tool like GWT, or minified, or obfuscated.
      - lisivka 11y ago
        I am agree, that wasm will be on par with generated/minified JS right now, but I predict that wasm will beat JS in future versions. My prediction is based on experience. It is very easy to introduce a binary thing which is hard to map to flat text. I.e. first version of wasm will be 1:1 map to JS, but NEXT versions of wasm will introduce optimizations, which are quite possible in compact binary format but are not possible in flat text format, so 1:1 map from wasm to JS will be broken.
cjfont 11y ago
I'm going to guess that the format lends itself better to code obfuscation than JavaScript, for those that do not want their code to be open.
- matt4077 11y ago
  Even if it's easier to obfusfate WebAssembly, does that matter? If you run the 2MB+ JS libraries in se today through uglify.js it becomes almost impossible to understand the macrostructure just by reading the code. It's only through dynamic tools that we can even begin to understand minified JS today. Those are actually quite excellent: just try by starting the react or relay tools on facebook. That ecosystem is hopefully not changing, so what remains is simply that the format is now binary. I agree that that makes me somewhat uncomfortable but realistically it doesn't really change anything.

pcwalton 11y ago

Before, we had asm.js. asm.js isn't very readable. By contrast, Web Assembly has a nice human-readable (though terse and low-level) IR. It even looks like Lisp, if you like that :) Web Assembly is a small step toward better human inspectability of the compiled blobs your browser is executing, compared to Flash, Java, and asm.js. To be sure, it doesn't mandate that the source be available in the form preferred for editing. But the Web hasn't done that since 1997.

mrec 11y ago
Agreed. It might also be nice to have wasm blobs compiled from open source code supply a standard metadata link to that code (the project's GitHub repo or whatever) so that UAs can offer nice affordances to replace Ctrl-U if they want to.

kibwen 11y ago

I don't think the downvotes are necessary here, this is a legitimate question. Understand that Wasm is ideally just an alternate way to drive the same virtual machine that Javascript currently manipulates. This isn't the same thing as, say, a NPAPI plugin like Flash was. Wasm is still subject to the same security restrictions as the rest of the web platform. Furthermore, and I could be wrong here, but I believe that the "binary" representation of Wasm is really just custom, trivially-reversible compression for faster data transfer and parsing. The OP even mentions that a "standard textual representation" is the next step on the agenda, which I imagine will work similarly to today's source maps for code that compiles to Javascript.

tracker1 11y ago
Well "just a binary representation" in the same way that .Net's CLR is just converted C#/VB/F# etc... Unless you know the source language, and have some sort of reverse-compiler (or source maps), then getting back to a readable/usable source isn't so easy. Though that doesn't mean you can't trace through what goes down the wire, it won't be quite as low-level as x86 assembly, but will be lower level than most are comfortable with.
- kibwen 11y ago
  But this is already true today with Javascript transpilation and minification. I have been in the unenviable position of needing to reverse-engineer compressed Javascript for which no "readable" source was available, and even with prettifiers the experience is hardly enjoyable.
  - tracker1 11y ago
    Absolutely agreed... one of the reasons that source maps are nice... but if you nuke sourcemaps in production, good luck... If it's someone else's source, then you may be SOL, just the same, it is what it is... if you're reverse engineering a gui, best bet is to create a clone... if it's an api, better to look into the wire protocol.

tomjen3 11y ago

I hear this argument a lot. It may have been true once, say 5 years ago. Today I can already do that -- look at the output of the Google closure compiler with advanced optimizations turned on. Sure it is javascript and not binary, but all comments have been removed, all variables have been given short and meaningless names that are frequently reused and all the structures have been turned inside out. And those optimizations are only for speed.

CaptSpify 11y ago
And I've never understood this argument. Yes, JS allows people to ship obfuscated code. Doesnt mean we should give up and stop expecting readable code.

gkya 11y ago

I am a bit baffled too, but in the end of the day, it's no different from running javascript. Most pages load probably millions of lines of JS and you can't audit it (disclaimer: I totally made up that number). For the security conscious, the only way is to implement very strict JS/cookie whitelisting, which is what I do. For the others, well, I guess it's no different from running JS in the end of the day. I wonder if this will make it's way into WebKit, and if so its implications for Xombrero, will I have to maintain a seperate WASM whitelist, or disabling JS will disable it too? TBH I plan not allowing even the most trustible website run such code on my computer.