The WebAssembly Summit was held in Silicon Valley, on the 10th February 2020. The venue, Google’s newest building at 1625 Plymouth St Mountain View CA.
This extremely well organised event kicked off with a clear message for its new WebAssembly community …
“Be actively awesome to each other!”
The single-track line up of speakers was superb. Lin Clark, from Mozilla, kicked off the event; delivering an amazing and thought provoking opening keynote about building a new kind of ecosystem.
If you only have time for a tiny snack of Lin's brilliant (23:57) talk, at this present moment, please note that the SecondState team has created 2 snippets for you. The SecondState team have also taken the liberty of creating both English & Chinese subtitles, for these snippets, for your convenience.
Snippet 1 - Lin explains how, in traditional (non Wasm) software applications, hackers are able to build malicious software libraries which other software developers will then trust and therefore bake into their application's dependency trees. These attacks are on the rise. The good news is that the Wasm community is choosing to negate these sort of attacks, through clever design, making Wasm users secure by default.
Snippet 2 - Lin explains how, "WebAssembly can provide the kind of isolation that makes it safe to run untrusted code". In WebAssembly each module is sandboxed by default and Wasm has memory isolation between modules. Interestingly, with the Interface Types Proposal, modules can exchange data in a way that is safe and fast. This interesting and exciting talk paved the way for more talks to come.
From there, the following speakers took to the stage and also proceeded to deliver a deluge of invaluable information about the future of WebAssembly.
Alon Zakai, creator of Emscripten, now from Google, provided great insights into “Shipping Tiny WebAssembly Builds”.
Ashley Williams, from Cloudflare, gave an excellent talk about the future of WebAssembly and its relationship with other supporting technologies such as Javascript.
Tadeu Zagallo, from Apple, shared interesting results from research and development into benchmarking areas of compilation, startup and runtime for WebKit’s WebAssembly implementation.
Peter Salomonsen demonstrated how to compose and perform music using WebAssembly; rendering his real-time audio demonstration to a very impressed audience.
Jonathan Beri, defined Internet of Things (IoT) in terms of embedded systems and went on to explore WebAssembly’s use as an intermediary language for embedded runtime environments.
Kevin Hoffman, from Capital One, articulated the benefits of Wasm and showed us how to build a containerless future with WebAssembly. Kevin introduced several new ideas and tools to support those ideas (mid and high level runtimes). The overarching message, one which I agree with; WebAssembly is the future of distributed computing.
In the spirit of efficiency and convenience, the SecondState team has once again created another snippet (also with English & Chinese subtitles, for your convenience) which outlines the benefits of Wasm in the cloud; articulating Kevin's accurate views about WebAssembly's superior security, in terms of buffer overflow exploits and so forth.
Brion Vibber, from MediaWiki, discussed Wikipedia’s ogv.js media-compatibility-shim architecture as well as the ongoing challenges that exist in the in-browser rich-media space. Brion demonstrated how to use WebAssembly as a video polyfill.
After enjoying a full day of absorbing everything Wasm, as well as networking with other industry professionals, it was time for the last presenter Ben Smith, from Google (who is also chair of the WebAssembly Community Group), to give the closing keynote.
Ben’s talk was entitled WebAssembly: Expanding the PIE. As Ben (pictured below) mentioned, and as some may not even be aware, “5 years ago WebAssembly literally did not even exist”.
Interestingly, the broader notion of compiling C and C++ code in such a way that it would be compatible with modern browsers was demonstrable as far back as 2013 thanks to emscripten and asm.js. This pioneering development by those like Alon Zakai — pictured below — (who founded emscripten in 2010 and then went on to co-created WebAssembly and asm.js), provided concrete evidence that, at the very least, it was going to be possible to bring C and C++, and therefore eventually other languages to the web.
Left: Alon Zakai, Middle: Tim McCallum Right: Ben Smith
From a WebAssembly specific perspective, in 2015 a very small group of developers had managed to come up with both an executable (binary) and s-expression (text) format of WebAssembly. One feature request at the time was to create a mechanism which could convert between the two formats. Ben’s initial work to create such a mechanism was called sexpr-wasm (which stands for s-expression to wasm).
Over the next 4.5 years, sexpr-wasm continued to be developed, and in September of 2016 it was renamed to WABT.
WABT is an incredible suite of tools for WebAssembly, and is fundamental to WebAssembly development and deployment. WABT aims for full fidelity and compliance with the WebAssembly specification.
I would personally surmise that every developer who has performed some task using WebAssembly, has used WABT.
WebAssembly’s humble beginnings
The initial design of WebAssembly was humble; it was designed to do no more than what the aforementioned asm.js could do. That being, allowing computer software written in languages such as C and C++ to be run as web applications.
Ben’s talk outlined how WebAssembly has now become so much more. Ben’s presentation was one about growth and prosperity. Specifically about striving for win/win scenarios, in terms of, as Ben puts it, expanding A PIE.
As mentioned, WebAssembly started with a very humble set of goals a.k.a. A [small] PIE. Let’s take a look at the pie circa 2015.
A PIE, circa mid-2015
A, ability, what can Wasm do?
P, producer, who/what can make Wasm?
I, interoperability, who can Wasm talk to?
E, embedder, what can run Wasm?
// play around with numbers and memoryP, producer, who/what can make Wasm?
// C++I, interoperability, who can Wasm talk to?
// JavascriptE, embedder, what can run Wasm?
// A Web browserFast forward to 2020
WebAssembly has come a long way in just a few years.
A, ability
There are currently over 100 different projects which are made using WebAssembly. These include free-hand drawing applications, media players, Gameboy emulators, in-browser compression/decompression applications and even an augmented reality sudoku puzzle solver application.
P, producer
At present there are around 15 programming languages that can compile to WebAssembly, in a stable and production ready fashion. These include .Net, AssemblyScript, C, Haskell, Rust and Zig. Many more are under development.
I, interoperability
WebAssembly now has a capability-based API design which allows WebAssembly code to interact with the outside world whilst still preserving the sandboxed nature of WebAssembly. Also the ever-powerful and useful set of Web APIs are now becoming part of a continual reality.
E, embedder
WebAssembly can now be run on a host of different platforms. There are about 20 Wasm runtimes which are under active development. Wasm is not restricted to just the browser anymore. There are examples of blockchain implementations, serverless applications, OS executables and IoT implementations which are deployed on self-contained and constrained embedded runtime environments.
It is amazing to see so many different projects and runtimes.
Going full circle
Whilst driving this sort of progress and enjoying the expansion of the pie, I am also reminded that we must also go back full circle and reflect on the messages in Lin’s opening keynote.
With WebAssembly moving outside of the browser we need to remember that we are also moving to areas which may not necessarily have the browser’s same sandboxing capabilities. Sandboxing facilitates one of WebAssembly’s key benefits. Security!
Nowadays around 80 percent of code (in a given project) consists of pre-existing libraries and dependencies. This is brilliant in terms of reuse and efficiency. Software developers are well aware that pre-existing modules allow us to save time and also build better software; by standing on the shoulder of giants. Unfortunately, attackers can implant malicious code into these reusable modules. Software developers must try to avoid widespread vulnerabilities and in doing so will be protecting the users of their software.
One of the best ways to achieve a high level of security, safety and privacy is to ensure that software products do not have access to the end-user’s system resources. Traditional Virtual Machines (VMs) and containers provide a level of sandboxing; taking away the software’s ability to access the host system.
So how does WebAssembly achieve this same level of safety in terms of isolation?
The security of WebAssembly is deliberately built in by design. For example, WebAssembly sandboxes each module by default; modules do not have any access to APIs or system calls. With WebAssembly, if the developer wants a module to access an API or a system call, they are required to explicitly declare that they want access and then provide this information as part of the shipped module. This makes the intent of the module very obvious; public and transparent.
WebAssembly System Interface (WASI)
The WebAssembly System Interface (WASI) provides a type of capability based security whereby different modules can have different permissions to different resources. The future plan is for WebAssembly to apply a fine-grain form of per-module virtualisation. With this sort of design a developer would be able to spot malicious modules and not include that code in the dependency tree of the application which they are building.
Importantly, as Lin mentioned, security guarantees do not just fall out directly when using WebAssembly, we have to follow good conventions and bake security guarantees into our tools. This will take some work.
As a community we can choose to make our users secure by default.
These sorts of deliberate patterns and designs are already starting to be baked into tools which are provided by projects such as the bytecode alliance.
I saw an incredible amount of new projects and use-cases for WebAssembly during the summit. I left the event completely inspired by the future possibilities of WebAssembly. I also left the summit with a saying in mind.
“We don’t want to have a trade-off between developer productivity and user safety. We want both!”
Lin concluded her presentation by quoting her teammate and WebAssembly co-creator Luke Wagner, by saying …
“We have an opportunity to build new secure-by-default foundations for native development that are portable and scalable. We need to take deliberate cross-industry action to ensure this happens in the right way”
The future of WebAssembly proposals
As a new World Wide Web Consortium (W3C) member, I am thoroughly looking forward to participating in the upcoming calls which relate to WebAssembly proposals as well as broader WebAssembly Community Group (GC) topics, as mentioned throughout this article.
If you are interested in the the latest progress of WebAssembly proposals, you can read the transcripts and view the presentations of WebAssembly Community Group (CG) meetings via GitHub. For example, these meeting notes are from the CG meeting which was hosted by Google, in San Francisco for two consecutive days following the Wasm Summit; the 11th & 12th of February 2020.
Thank you!
I would like to thank the organisers of this excellent event. The participants were indeed all “actively awesome”. I met so many new people from the leading technology companies and projects from around the world.
I am a big fan of "Wasm by example" by Aaron Turner as well as wasm-pack and its creator Ashley Williams so it was awesome to be able to say hello and thank you in person.
Bottom left: All speakers, top left: Ashley Williams, right: Tim McCallum & Aaron Turner
If I had to give one piece of feedback, “please hold this event again next year”. I think that we will all be amazed by what the community will have achieved by then.