A few months ago a team of security researchers published a paper, Everything Old is New Again: Binary Security of WebAssembly, which highlighted a number of security issues with WebAssembly. Their main argument was that memory unsafe languages, such as C++, can result in vulnerabilities when compiled to WebAssembly, i.e. they are still unsafe.
This post, by an engineer who worked on FireFox, provides their own personal critique of the paper. Their initial stance, which I must admit I shared also, was that isolation (sandboxed) model of WebAssembly is highly secure, therefore in order to exploit a weakness in an unsafe program, you have to willingly provide the WebAssembly module with APIs that they can usefully exploit.
“Don’t ship memory-unsafe programs, or if you do, don’t give them eval capabilities.”
“Garbage in, garbage out”
You can always use a safe programming language like Rust instead!
However, the author does concede that a primary goal for WebAssembly was to allow existing C, C++ applications to run in the browser, and that the toolchain authors (e.g. Emscripten) do have a responsibility to minimise the capabilities exposed to WebAssembly, most notably by removing the use of eval from within the toolchain itself.
Artificial Intelligence (AI), and more specifically Neural Networks are computationally intensive, which is why they are ideal candidates for running on the cloud. However, moving data to, and results back from the cloud introduces latency which can be problematic for some use cases. This blog post explores how neural networks can be brought closer to the applications that use them by running on WebAssembly within the edge network.
C++ is a popular language in various different fields, including scientific computation. This blog post provides an introduction to WebAssembly, using C++ and Emscripten, for people wishing to run C++ algorithms in the browser. The author has picked Newton-Raphson, an iterative approach to root finding.
This post is actually the start of a series, with the other four articles referenced at the end. It’s great to see WebAssembly being used by the wider programming community.
The lightweight nature of the WebAssembly runtime makes it an interesting alternative to the likes of Docker. This is something that Cloudflare, Fastly and various open source projects have been exploring for the past couple of years. This paper takes a scientific approach and measures the effectiveness of WebAssembly as a serverless runtime, looking at ‘cold start’ times and other performance metrics.
AssemblyScript has definitely not published a string proposal for WebAssembly. Nothing to see here.