The Wayward Developer

In defense of WebAssembly


There’s a recent InfoQ article making the rounds on social media with the title “Recent study estimates that 50% of websites using WebAssembly apply it for malicious purposes”. The article is based on a study published in June this year titled “New kid on the Web: A study on the prevalence of WebAssembly in the wild”, which went relatively unnoticed until I shared it in late October on several social media sites.

The paper studies the prevalence and application of WebAssembly in the Alexa Top 1 million sites, which the InfoQ article provides a decent summary of, except for the sensationalist title not entirely untrue to the study, that, instead of a general inquiry into the usage of WebAssembly on the web, was presented as security research, which is unfortunate for reasons I am about to discuss.

The study classifies the modules encountered as belonging to one of several categories, two of which, mining and obfuscation are additionally labelled as “malicious”. Now, in and of itself obfuscation is certainly not malicious, unless we consider all proprietary software distributed only in compiled form malicious. As for mining, I believe there is a case to be made for generating revenue by utilizing a visitor’s hardware resources as opposed to advertisement, but even without that consideration it is at worst unethical, the same way as advertisement, especially distracting, deceptive, or resource-heavy advertisement is unethical.

All the reactions I have seen, however, were less concerned of the actual use cases discussed above, but the technology itself, proposing solutions like running WebAssembly modules only after explicit consent of the user, or outright blocking WebAssembly in content filtering extensions, which more than anything else reveals a lack of understanding of the technology.

WebAssembly is not native code, it’s a bytecode running in a virtual machine, similar to Java bytecode, except its instruction set is designed to be as close to the instruction sets of modern CPUs as possible. Furthermore, unlike the JVM, WebAssembly has no access to its environment, except through explicitly imported and exported objects. Also, at the time of this writing¸ WebAssembly modules can be instantiated only by JavaScript. All of this means that WebAssembly is at least as secure as JavaScript, and in most cases more secure.

WebAssembly cannot do anything that JavaScript cannot do already, but whatever it does, you are better off with it, because it does it faster and using less memory.

You can share/upvote/discuss this post on Reddit, HN, Medium, Twitter, Facebook, and LinkedIn. You can also follow me on this site and other platforms.