Design: Unreadable wasm binary encoding has advantages

[bobOnGitHub]

Have just looked briefly at project today and am very interested in using it in general development work.

However, if the end result means an end user running wasm in their client browser can access human readable code this is a missed opportunity.

There is no reason to provide the end user with this facility - a developer can have access to it via map files or some similar mechanism requiring the original source.

While it is impossible to deter the determined from decompiling/reverse engineering a product, any deterrent is useful to have ( if you want to give it away include the source / a link to it). If the effort/risk in stealing outweighs the cost of legally licensing. etc etc etc.

The added element of ip security in not providing readability would likely encourage wider/faster adoption (it's a complete no-brainer for me).

On the other hand, if there is no security benefit....then with.faster hw/js engines over time, switching back to C/C++ and maintaining a further expanded skill set does not look so appealing.

Please consider NOT providing a mechanism to make wasm binary encoding readable. Someone else will do it eventually anyway - in the meantime use the resources elsewhere and let us enjoy a short era of unintelligible client side code.

Bob.

[RyanLamansky]

The newest versions of Chrome are already capable of converting binary WASM into a text format.

[bobOnGitHub]

Are you saying I can go from (following taken from wikipedia entry )

20 00
42 00
51
04 7e
42 01
05
20 00
20 00
42 01
7d
10 00
7e
0b

to

int factorial(int n) {
if (n == 0)
return 1;
else
return n * factorial(n-1);
}

or recognizable as such using chrome as it stands ?

[RyanLamansky]

No, it returns the not-quite-formally-specified-yet "WAST" format described here: http://webassembly.org/docs/text-format/ .

get_local 0
i64.const 0
i64.eq
if i64
    i64.const 1
else
    get_local 0
    get_local 0
    i64.const 1
    i64.sub
    call 0
    i64.mul
end

Web Assembly is optimized for a small, easy-and-fast-to-parse binary format. It doesn't retain enough information to completely recover the original syntax. The larger and more complex the function, the less recognizable the decompilation will be. This is especially true if you look at how structs, classes, templates, and other higher-level features are handled.

[bobOnGitHub]

Excellent (That's the "intermediate representation" listed in the wikipedia article) - I thought you were suggesting it could already be "prettified" further - I'd prefer if it couldn't be (out-of-the-box).

And I'd prefer if everything was done / not done and designed to keep it that way.

(I got the impression there was a plan to ultimately be able to translate it back to reasonable pseudo code albeit without meaningful identifiers, in the browser.)

[jfbastien]

Forbidding binary to some form of human-readable source isn't something that WebAssembly can forbid. Anyone can implement their own thing, however pretty / readable. The group instead concerns itself with specifying a portable, size- and load-time-efficient format suitable for compilation to the web.

We're also concerned with making something usable, which is why we're specifying a low-level text format, and will likely work on debugging capabilities.

It is a non-goal to guarantee any legal protection for or against decompilation, reverse engineering, or other non-technical concerns. This is left up to your own lawyers, and I urge non-lawyers to avoid speculation. We do not want to be in the business of providing legal advice.

It looks like prior discussing addresses your question? I'll close, feel free to reopen or continue discussing if not.

[johnworthley]

chintailease.wast.zip

Any idea on how to disassemble this .wast file to the original source code?