[masswerk]

Sorry to say, but the web isn't about writing apps in the language of your choice. If it's beyond plain, passive HTML, it's about running applications on foreign hosts/resources without a well specified license to do so. Scripting languages provide both audible code and a small load as compared to binary object code (which is, why we had them on servers and clients in the first place).

If we turn the web into an anything-goes bonanza using binary code without any keys, credentials, or permissions, WebAssembly (and Turing complete CSS as well) may be well the beginning of end of the web as we know it, giving raise to a new, leaner and more restricted platform (for which some are already on the lookout, BTW).

[Edit] A small real world example: Client asks me to implement a third party plugin to allow them direct communications with their users via their website. A quick scan of the source code tells in a minute that the script isn't just doing that, but is also tracking user behavior and is phoning home related data. Now I can ask the client, if they really want to expose their users to this. With WebAssembly, there's no chance to do so.

[icebraining]

Try looking at the source of Google.com and saying all it's doing in under a minute.

You could look at the APIs it's using - why is it calling XMLHttpRequest or looking at the user's cookies? - but you can do the same with binaries, you just have to use a tool, e.g. 'nm -D <binary>' shows you the external functions the program calls.

I held the same position until circa 2008 (?), when JS minifying became truly widespread; nowadays, I think that battle is already lost.

[masswerk]

So, just give up?

(Please mind that there has to be a strict relation between a minified code and a plain source code provided at some repository. This is not true, at least in terms of the resources needed to verify this and the probability of this being covered by average budgets, for binary codes. – Recommended reading: "Reflections on Trusting Trust" by Ken Thompson)

Edit: At best you're winning a year's worth of Moore's law in performance and are paying for it in terms of page load. On the down-side, binary code is just as bad an idea as e-voting: You're putting the interests of your users against literary trillions of dollars of interest in exploiting the system (yes, the leverage would be enorme) – and if the worst has become true, it's already too late to revert.

[Rapzid]

Probably solve it the way we do with the rest of shared libs and open computing:

Require the source. Download compiled code from trusted sources.

Download a nuget package; dll's. Download an apt package; binaries and so's. This won't blow up web.

[masswerk]

Not your everyday real-life story. Client: "Integrate this (see attachment)". You, "No, they have first to hand over the source code in order to allow me auditing their software." Client: (gone).

As for the real-life example given above: The third party is billing the client only a few bucks, since the real business is in profile building and exchanging profiles. So, are they expected to hand out the source code for 5 bucks or so? Probably not. Who is to lose? Everyone visiting the website.

[MichaelGG]

Why are you under the impression there won't be disassemblers and decompilers for WebAssembly?

It's not like a bunch of minified JS is going to be "quick" to go through.

[masswerk]

Even, if there would be a suitable disassembler, this would just account to an exponential curve in terms of auditing any software. (We're not speaking of minutes here anymore, but rather of months or even years – who will be willing to pay for it?) BTW, with minified JS, you've just to recode variable names (while anything adequate to system calls has to be in plain text somewhere by definition), with WebAssembly, this becomes an entirely different story. – No comparison.

[MichaelGG]

This is basically the same case for traditional binaries. I'm no RE expert, but when I've done such work it consists of "renaming variables" including functions and looking for calls to imported functions. Intentionally obfuscated code is harder.

But nothing stops JS from loading a bunch of encrypted strings, self-modifying at runtime, using eval+substring (at various offsets) on loaded and renamed functions to make it hard to know if there are calls to other functions, let alone what they are.

It can still be done, and obfuscated JS is probably easier than obfuscated x86 but saying it makes an audit only take minutes means it's not really being obfuscated.

[Senji]

>But nothing stops JS from loading a bunch of encrypted strings, self-modifying at runtime, using eval+substring (at various offsets) on loaded and renamed functions to make it hard to know if there are calls to other functions, let alone what they are.

There is a solution to that. Control the platforms. You have like what, 4? major vendors of browsers. Convince them to make eval disabled by default and you warp the entire usable market. The percentage of people who would bother to go hunting the setting to turn it on would be minuscule.

Use the power of the default to affect the whole space.

[masswerk]

I really don't get the down voting: While we've come globally to the conclusion that we require signed software, curated app stores and kill switches for traditional applications, because sh#t happens, we're going to distribute binary software in the browser without any such limitations? With the average user not even knowing that she is running some software from untrusted sources? (Yes, I know, it will be sandboxed, and there will never be a zero-day anymore in any browser ...)