WebAssembly: Key to a high-performance web, or ideal for malware? Reg speaks to co-designer Andreas Rossberg

State of Wasm: 'Better support for high-level languages', plus interesting cross-platform news

93 Reg comments Got Tips?

Interview WebAssembly will not magically speed up your web application and may be as significant running in environments other than web browsers as it is within them, a co-designer of the language told The Register.

WebAssembly (Wasm) was formally approved as a W3C recommendation in December 2019. The technology is a low-level programming language designed to be compiled into machine code for execution with the performance of native code. A Wasm virtual machine is embedded into a host such as a web browser, where code runs in a sandboxed environment and respects the browser's security policies. It is implemented in Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge (both the original and Chromium-based versions).

There are languages that compile to Wasm, including C/C++, Rust, and others in various stages of experimental support, including Go, C#, TypeScript, Java, Ruby and Swift.

There is also a misconception about what is actually slow on the web. For most typical web pages that are not computation-heavy, it's not the execution of user code that is the most expensive. It's all the rendering and the dynamics of that going on, and that is not affected by WebAssembly.

Wasm has lots of promise for improving the performance of web applications, but its reputation was tarnished when researchers at the Technische Universität Braunschweig in Germany looked into its usage on the million top websites as listed by Amazon's Alexa analytics. According to their June 2019 paper (PDF), one in 600 of these sites execute Wasm code, but in 55.7 per cent of these cases, it was being used for cryptocurrency mining, a form of parasitic computing whereby users are tricked into generating revenue for a third party.

The researchers also identified cases where Wasm was used to obfuscate other malicious code, commenting that the technology "does open the door for completely new obfuscation techniques … and enables the circumvention of existing analysis systems and defensive mechanisms," since existing anti-malware solutions rely on inspecting JavaScript code. "We are currently only seeing the tip of the iceberg of a new generation of malware obfuscations on the Web," the paper states.

Faster web apps, or stealthier malware?

Is Wasm speeding up the web, or opening up new forms of malicious computing? We spoke to Andreas Rossberg, a senior staff researcher and engineer at Dfinity and a member of the W3C WebAssembly Working Group. Formerly at Google, he was co-designer and specification author of WebAssembly.

"It's a fact of life that any capability you add to the web platform can be abused," he said. "This is one that can be abused particularly conveniently. Tools that do malware detection have to be aware of it. In principle, I don't think that's necessarily harder for WebAssembly than it is for JavaScript. But it's a whole new thing, so these tools will have to do a lot of work to get to the same point where they are with JavaScript. It's just inherent to the process of extending the platform with something new. That's unfortunate."

Leaving aside malware, Rossberg said Wasm is working well, though there is much more to do, and its benefits are not always well understood. "The motivation for the first version of the release was that we wanted to replace asm.js [a subset of JavaScript designed for performance optimisation] and that worked right out of the box. For the first version we deliberately limited the scope to the low level language domain," he said. "We are following a roadmap for better support for more high level programming languages. One of the things that blocks broader usage is that right now it's difficult to compile more interesting languages into WebAssembly because it lacks certain features."

One of the goals of the project, he said, is to enable greater diversity of programming languages on the web, but currently people who want to use other languages are compiling to JavaScript rather than Wasm "because that's easier in the absence of these features."

Rossberg said that Wasm "is really just this sandboxed virtual instruction set. It doesn't have any capabilities in itself. But one of the first questions you get is, how do I access the DOM? The answer is you can't directly, you have to go through JavaScript, and that's by design.

"One thing people get really confused about is if something would be magically faster by running WebAssembly. The answer is that it depends on what code you generate and how good the engine is. People are always suggesting how we should compile JavaScript to WebAssembly so it runs faster, which is completely nonsensical, because it would probably be much slower if you go through that extra indirection and this abstraction layer.

"There is also a misconception about what is actually slow on the web. For most typical web pages that are not computation-heavy, it's not the execution of user code that is the most expensive. It's all the rendering and the dynamics of that going on, and that is not affected by WebAssembly."

What this means is that an ideal use case for Wasm is for libraries that are computationally intensive, in areas like multimedia editing, simulation, compilers and debuggers, encryption, and games. Most developers should not have to think about Wasm. "For the average developer, they will have to rely on libraries providing this. And that's intended," said Rossberg.

WebAssembly future: three big themes

There are three areas which Rossberg identifies as significant future developments. One is better support for high-level languages, as mentioned above. Another is a "new initiative called WASI, WebAssembly System Interfaces, which is an infrastructure for defining and providing modules for the WebAssembly ecosystem, that could be used across different environments.

"When you are running an application on the web, the environment is quite different from traditional operating systems, there are things you don't have and can't do. If you want to port software, you need to emulate quite a bit of stuff. It seems useful to have a generic infrastructure in which can define something like a virtual operating system on top of WebAssembly. It's still pretty early.

"The third thing is that WebAssembly is gaining traction outside the web. My company is doing just that, using WebAssembly in distributed computation. There is the edge computing use case, as a means for sandboxing execution. There are people who want to put it into IoT and embedded devices. I predict that we're going to see a lot more adoption and real-world use in all these other spaces."

Is this just reinventing Java's JVM? Cross-platform is a big benefit, and so is sandboxing, but it is not new.

"When we designed WebAssembly, we carefully looked at existing things like the JVM and .NET, and tried to learn from the problems they had. One of the big differences, design wise, is that WebAssembly is more low-level. It's just a virtual instruction set that mirrors what common CPUs provide. It's not an abstraction over a specific programming language like the JVM or .NET. The JVM Is almost just abstract syntax for Java. It's not necessarily a natural fit for other languages that compile to it, even if you can do that. And it's pretty heavyweight; there's Java's object model in there.

"This is exactly the opposite of what we try to do with WebAssembly. We do something that is agnostic of whatever is your source language, and that also makes it more lightweight. That makes it more attractive to constrained spaces like embedded."

Another difference is in the sandboxing. "We were very careful with WebAssembly to have a machine-verified proof of its safety," said Rossberg. This means avoiding things like Java's JNI (Java Native Interface) or .NET's Platform Invoke. "The concept in WebAssembly is that you can import stuff from your host environment, that is hosting the WebAssembly engine. For example, a web browser would define a certain interface that WebAssembly can see in order to provide certain functionality. That interface would have to be provided by the host."

WebAssembly has lots of promise, despite common misconceptions, but the name, said Rossberg, is itself confusing. "I used to give talks which were titled, neither Web nor Assembly." On one thing he is clear though. "The shorthand is officially spelled Wasm, not WASM - it's a contraction, not an acronym." So there is no need to shout. ®


Biting the hand that feeds IT © 1998–2020