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.
[0]: https://www.w3.org/community/webassembly/
[1]: https://github.com/WebAssembly/design/blob/master/TextFormat...
[2]: https://github.com/WebAssembly/design/blob/master/Tooling.md
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
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.
View-source is an explicit goal of WebAssembly's first launch: https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...
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.
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.
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.
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.
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.
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.