All Major Browsers Now Support WebAssembly (bleepingcomputer.com)

An anonymous reader writes: "It took only two years for all browser vendors to get on the same page regarding the new WebAssembly standard, and as of October 2017, all major browsers support it," reports Bleeping Computer. Project spearheads Firefox and Chrome were the first major browsers to graduate WebAssembly from preview versions to their respective stable branches over the summer. The second wave followed in the following weeks when Chromium-based browsers like Opera and Vivaldi also rolled out the feature as soon as it was added to the Chromium stable version. The last ones to ship WebAssembly in the stable branches were Apple in Safari 11.0 and Microsoft in Microsoft Edge (EdgeHTML 16), which is the version that shipped with the Windows 10 Fall Creators Update. Both were released last month. WebAssembly, or wasm, is a bytecode format for the web, allowing developers to send JavaScript code to browsers in smaller sizes, but also to compile from C/C++/Rust to wasm directly.

Comments

Original Article

[theweatherelectric]

Better to get content from the source. BleepingComputer appears to just read Mozilla blogs and repackage them as its own. Here's the original Mozilla blog post.

Well that's unfortunate.

[Anonymous Coward]

Already about 1/2 of web pages I can only get to work by using "view source" and clipping out links from the source which for some idiotic reason the site wants to demand javascript to do something that pure HTML could do just fine, such as display an image or move to another URL when you click on the link.

Can't wait until that has yet another layer of obscuration due to WebAssem.

The modern web's idiocy only ever grows larger and larger. Can't wait for WebAssem based obscuring images over the text you're trying to read, or more obscured privacy obliterations or the like. At least firefox will have a way to shut that idiocy off.

Re:Well that's unfortunate.

[TheRaven64]

If you send a lot of random shit at something, of course it's going to crash.

If your thread model for something that is expected to accept random crap from the Internet is 'it's fine as long as input is well formed', then you are going to have a lot of fun dealing with security vulnerabilities. Contrary to your assertion, well-written code does not crash when you send it a lot of random shit, it gracefully handles errors.

Worst idea ever.

[Anonymous Coward]

What most people don't realize is webassembly is just a way to obfuscate the web in the same manner people already obfuscate compiler binaries.

Furthermore it will lead to integrated 'all in one' scripts that cannot be easily disentangled, making it harder for end users to filter what scripts on a website they are running.

Additionally it no doubt has engineered defects in it to help national intelligence apparatus' to more easily exploit target browsers, while also providing fingerprint opportunities far more opaque than even current browsers capabilities to deanonymize you.

Think twice before you let webassembly ruin the web for you!

Tremendous mistake

[Okian Warrior]

I think Web Assembly is a tremendous mistake.

This will end up being nothing more than an insecure vector for people you don't know to run programs on your computer.

1) It claims to be secure by only executing in a sandbox. Have other attempts at sandboxing had security flaws?
2) Assuming the sandboxing works as advertized, is there a way for the sandboxing to break the sandbox in ways the coders hadn't considered? (Such as periodically using a lot/little CPU time or memory as a way to communicate to a different tab?)
3) Can Web Assembly be used to steal CPU cycles, so your computer can be used for BitCoin mining or anything else while visiting a web page? (And no, that they can do this already doesn't invalidate the argument.)
4) Does Web Assembly add a level of obfuscation to the code, making it harder to see what it's doing?

We once had a period where E-mail attachments were automatically opened and run, where Excel macros activate when a spreadsheet is viewed, and where myriad ActiveX libraries were available for use by anyone.

Anyone remember that era?

We've locked down the ability to install and run programs on our computers, but now we've moved the goalposts. Our browser will now download and run programs for us from any random website, any website that contracts out to an agency to supply advertizing, and and website advertizing contractor who doesn't vet his clients.

"Oh, we're so sorry! That malware delivery got through our vetting process. We've terminated that one client, please feel safe downloading the ads from all of our other clients - they're clean. Pinky swear! :-)"

For the next 10 years expect to see a steady stream of exploits and patches. A mini industry will crop up selling antivirus checkers for web pages, and AdBlock extensions for browsers.

It's deja vu all over again.

Re:Tremendous mistake

[ByteSlicer]

I think Web Assembly is a tremendous mistake. This will end up being nothing more than an insecure vector for people you don't know to run programs on your computer.

Not to spoil a good rant, but Web Assembly is just a more compact serialization (binary instead of text) of a subset of EcmaScript/JavaScript.
Everything you can do with it, you could already do with normal scripts, and it was already very common to "minify"/obfuscate these scripts into an unreadable mess.

So, if there are security issues with WAsm, they're also present in plain JS, and were already present a couple of years ago.
The only thing that changes is that your browser now doesn't need to download as much data for scripts, since the binary format acts as a compression.

Re:Tremendous mistake

[garethjrowlands]

... Web Assembly is just a more compact serialization (binary instead of text) of a subset of EcmaScript/JavaScript.....

Much of what you say is morally true. But it's not technically true.

It's true that wasm is a binary serialisation of an abstract syntax tree (AST) but that AST is defined _without reference to JavaScript_, see https://github.com/WebAssembly... . In contrast, the asm.js spec is genuinely a subset of JavaScript.

You're right that wasm doesn't introduce new capabilities to the browser as such. In the current 'MVP' version of wasm, the only way to invoke web assembly is via JavaScript, and the only way for wasm code to interact with the browser is via JavaScript.

But it does make certain scenarios, such as running large compiled C programs, much more practical. It is, by design, a far more efficient compilation target than JavaScript or asm.js, see https://github.com/WebAssembly... . For example, we can expect Unity running on wasm to become commonplace, see http://webassembly.org/demo/ .

...if there are security issues with WAsm, they're also present in plain JS,...

You can't be sure of that. The wasm codepaths will reuse much of the existing JavaScript execution engine but there will be new code and that new code could - and probably will - have security vulnerabilities. But probably no more than any other major browser feature.