WebAssembly Weekly - WebAssembly Weekly News

Issue #134

on “binary security of webassembly”

WINGOLOG.ORG

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.

Exploring WebAssembly AI Services on Cloudflare Workers

CLOUDFLARE.COM

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.

Writing JavaScript tools in other languages – a new trend?

2ALITY.COM

The JavaScript tooling ecosystem is vast and ever-changing. Until recently this ecosystem was almost exclusively written and developed in JavaScript, which makes sense - allowing the tooling to be maintained by the developers who consume it. However, when running outside of the browser, compiled native binaries have a number of advantages over JavaScript, they are faster and are better able to parallelise tasks.

This blog post looks at the growing trend of writing JavaScript tooling (compilers, bundlers etc.) in a range of other languages (e.g. Rust, Go). One significant disadvantage of this approach is portability, native binaries are machine-specific, so either you ship multiple binaries, or re-compile from source at the point of installation. WebAssembly is a portable runtime, which provides near-native performance - it clearly has a lot to offer in this regard.

Using C++ in a web app with WebAssembly

ESCIENCECENTER.NL

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.

A lightweight design for serverless Function-as-a-Service

ARXIV.ORG

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.

And finally

AssemblyScript has definitely not published a string proposal for WebAssembly. Nothing to see here.