WebAssembly gets nod from W3C and, most likely, an embrace from cryptojackers online

The World Wide Web Consortium (W3C) on Thursday published three WebAssembly specifications as W3C Recommendations, officially endorsing a technology touted for the past few years as a way to accelerate web code, to open the web to more programming languages, and to make code created for the web more portable and safe.

“The arrival of WebAssembly expands the range of applications that can be achieved by simply using open web platform technologies," said Philippe Le Hégaret, W3C Project Lead, in a statement.

"In a world where machine learning and artificial intelligence become more and more common, it is important to enable high performance applications on the web, without compromising the safety of the users."

Web Assembly is a binary instruction format that runs on a stack-based virtual machine, so it can operate on multiple chip architectures. The approved specs include: the WebAssembly Core Specification, which defines the virtual machine; the WebAssembly Web API, which defines a Promise-based (asynchronous) interface for interacting with wasm files; and the WebAssembly JavaScript Interface, which explains how JavaScript code can interact with WebAssembly functions.

It's been a long time coming. The tech surfaced in 2015, showed up as a preview in web browsers in 2016, reached cross-browser design consensus in 2017, and recently got a push from Fastly, Intel, Mozilla, and Red Hat to move beyond the browser.

Just as one does not simply walk into Mordor, one does not generally write WebAssembly. Sure, one could write it by hand, and some masochists do for the educational challenge, but it's more common to write code in a language like C/C++ or Rust and compile that source code to a wasm file.

Ostensibly, the reason to do so is performance: Wasm has the potential to run much faster than JavaScript, as much as 20x faster, it's claimed. Mozilla has clocked WebAssembly at only 1.13x slower than native code, but recent research suggests wasm can also fall short in terms of speed.

Security is another potential benefit since wasm modules operate in a sandbox that isolates them from the host runtime. But there's more to it than that.

Wasm's arrival isn't entirely without concern. Some developers worry that wasm binaries will be less readable than JavaScript source code, given that one of the web's primary virtues – at least from the user standpoint – is the ability to "view source" and see the code running in one's browser.

Wasm may also turn out to be less susceptible to user interventions. At the moment – at least until Chrome's Manifest v3 transition limits the content blocking capabilities of browser extensions for the supposed sake of speed and security – browser users can run add-ons that filter and customize web content. Web applications that arrive as binary blobs will probably prove to be more resistant to meddling.

At the same time, modern JavaScript is much less easy to read than it was in the past because so much of the code gets minified (condensed to improve load time) or obfuscated – good luck trying to figure out what a Facebook page is doing. And wasm binaries can be converted to a text format for human review, even if the output is not particularly self-explanatory or well documented.

While some developers insist WebAssembly doesn't really change the viewability of web-oriented source code, most of those using WebAssembly at the moment appear to welcome greater inscrutability. A study published in June 2019 from researchers at Technische Universität Braunschweig (Braunschweig Institute of Technology) found "over 50 per cent of all sites using WebAssembly apply it for malicious deeds, such as [crypto] mining and obfuscation."

While wasm is not indecipherable, it's more opaque than JavaScript to current security tools. "The existence of multiple languages, that interact with each other, renders effective malware analysis extremely difficult," the TUB study says. "This holds true for static, dynamic, as well as manual analysis likewise."

The researchers – Marius Musch, Christian Wressnegger, Martin Johns, and Konrad Rieck – say that while they only observed moderately sophisticated obfuscation in the wasm samples they viewed, they expect malicious code creators will get more creative, forcing security researchers to develop stronger WebAssembly evaluation mechanisms.

Our WebAssembly future brings with it a sense of déjà vu. ®