Tim McCallum is with Second State
Editor’s note: Tim attended the WebAssembly Summit last week and spoke in depth with the Wasm community. WebAssembly has grown a lot over the years, but let’s not forget WebAssembly’s greatest strength: security.
We don’t want to compromise between developer productivity and user security, we want both!
On February 10, 2020, the WebAssembly Summit was held in Silicon Valley. The venue is located at 1625 Saint Hill View in Plymouth, California, Google’s newest building.
The organizing campaign is well organized and sends a clear message to the new WebAssembly community:
“Be actively awesome to each other!”
“To be partners in each other’s progress!”
Wasm Summit Main topics
The line-up of speakers for this summit is excellent. Lin Clark from Mozilla kicked off the event with a thought-provoking and stunning opening talk on building a new WebAssembly ecosystem.
After that, the speakers took to the stage to talk about the future of WebAssembly in a litany of litany.
Ashley Williams from Cloudflare gave an excellent presentation on the future of WebAssembly and its relationship to other supporting technologies such as Javascript.
Tadeu Zagallo from Apple shared some interesting research and development in the benchmarking area of compilation, startup, and runtime for WebAssembly implementations of WebKit.
Peter Salomonsen impressed the audience by demonstrating how to create and play music using WebAssembly.
Jonathan Beri has defined the Internet of Things (IoT) in terms of embedded systems and continues to explore the use of WebAssembly as an intermediary language for embedded runtime environments.
Kevin Hoffman, Head of architecture at Capital One Bank, explained the benefits of Wasm in the cloud. Kevin introduced some new ideas and tools (intermediate and advanced runtimes) to support these ideas. I can’t agree more with one important message here: WebAssembly is the future of distributed computing. (I also wrote an article on WebAssembly’s relationship to distributed computing.)
Brion Vibber from MediaWiki discusses Wikipedia’s OGv.js media-Compatibility -shim architecture and the challenges of the media-rich space within the browser.
After enjoying a full day of absorbing Wasm information and networking with other industry professionals, it’s time for the final speaker from Google, Ben Smith, who is also chair of the WebAssembly Community Group, to deliver the closing keynote.
Ben’s speech is “Make PIE Bigger”. As Ben (below) mentioned, some people may not realize that “Five years ago, WebAssembly didn’t even exist”. Interestingly, it was possible to prove that compiling C and C + + code is compatible with modern browsers using Emscripten and ASM.js back in 2013. Alon Zakai founded Emscripten in 2010 and later co-founded WebAssembly and ASM.js. Groundbreaking developments like his provide concrete evidence that C, C + +, and eventually other languages can be used on the Web.
From a WebAssembly-specific perspective, in 2015, a small number of developers managed to develop executable (binary) and S-expression (text) formats for WebAssembly. One feature requirement was to create a mechanism that could convert between the two formats. Ben’s initial work to create this mechanism is called Sexpr-WASM (stands for S – Expression to WASM).
Over the next 4.5 years, the program continued to grow and was renamed WABT in September 2016.
Wabt is a super powerful set of tools for WebAssembly and is the foundation of WebAssembly development and deployment. The goal of WABT is to fully maintain and conform to the WebAssembly specification.
I personally believe that every developer who has used WebAssembly to accomplish something has used WABT.
WebAssembly’s humble origins
WebAssembly’s original design was modest and limited to the asM.js mentioned earlier. That is, allowing computer software written in languages such as C and C + + to run as Web applications.
Ben’s talk explains how WebAssembly applications have evolved so much. Ben’s talk focused on growth and prosperity, and in particular on winning all. Make the PIE bigger, as Ben said.
As mentioned earlier, WebAssembly started with a very low-key set of goals. A small Pie.
Let’s look at Pie circa 2015.
Pie in mid-2015
A: Capabilities, what can Wasm do? // Play around with numbers and memory P: producer // C++ I: interoperability, with whom can I interact? // Javascript E: Embedder, what can run Wasm? / / Web browser
WebAssembly in 2020
WebAssembly has come a long way in just a few years.
A: ability
There are currently over 100 different projects using WebAssembly. These include freehand drawing apps, media players, Gameboy emulators, in-browser compression/decompression apps, and even an AR Sudoku puzzle application.
P: producer
There are currently about 15 programming languages that can compile into WebAssembly in a stable, production-oriented manner. These include.net, AssemblyScript, C, Rust, Haskell, Rust and Zig. More are in development.
I: interoperability
WebAssembly now has a capability-based API design that allows WebAssembly code to interact with the outside world while still retaining the sandbox nature of WebAssembly. Moreover, a collection of once-powerful and useful Web apis is now being implemented.
E: embedder
You can now run WebAssembly on many different platforms. There are currently about 20 runtimes under active development. WebAssembly is no longer limited to browsers. There are examples of blockchain implementations, serverless applications, operating system executables, and Internet of Things implementations that are deployed in standalone and constrained embedded runtime environments.
It was amazing to see so many different projects and runtimes.
Going Full circle
While advancing this process and enjoying Pie’s expansion, I would say that we must also go back to square one and reflect on the message delivered by Lin Clark in his opening keynote address.
As WebAssembly moves beyond the browser, it’s important to keep in mind that we’ll encounter situations that don’t necessarily have the same sandbox capabilities as browsers. Sandboxes help implement one of WebAssembly’s main strengths: security!
Right now, about 80% of the code (in a given project) consists of pre-existing libraries and dependencies, which is great for reuse and efficiency. Software developers are well aware that pre-existing modules allow us to save time and build better software. This is standing on the shoulders of giants. Unfortunately, attackers can implant malicious code into these reusable modules. Software developers must avoid widespread vulnerabilities to protect their users.
One of the best ways to achieve a high degree of security, security and privacy is to ensure that software products do not have access to end users’ system resources. Traditional virtual machines (VMS) and containers provide a layer of sandbox that deprives software of its ability to access the host system.
So how do we achieve the same level of security in terms of isolation?
WebAssembly’s security is carefully designed. For example, WebAssembly sandboxes each module by default; The module does not have any access to the API or system calls. With WebAssembly, if a developer wants a module to access an API or system call, he or she needs to proactively declare that access, and then provide that information as part of the included module. This makes the intent of the module very open and transparent, with nothing hidden.
The WebAssembly System Interface (WASI) provides a function-based security that allows different modules to have different permissions on different resources. The vision for the future of WebAssembly is to apply a fine-grained form of per-module virtualization. Using this design, developers can detect malicious modules without including the code in the dependency tree of the application they are building.
Importantly, as Lin mentioned, the guarantee of security does not come directly with using WebAssembly. We must follow good practices and integrate security guarantees into our tools. It’s going to take some work.
As a community, we can choose to make our users safe by default.
These well-thought-out patterns and designs are beginning to be integrated into tools provided by projects such as the Bytedance Alliance.
During the summit, I saw a lot of new WebAssembly projects and use cases. By the end, I was inspired by the future possibilities of WebAssembly. I left the summit with one thing on my mind. “We can’t compromise developer productivity and user safety. We want both!”
Lin ended her talk with a quote from her team member and Star Trek co-creator Luke Wagner:
“We have an opportunity to build a new portable and scalable default security foundation for native development. We need to take deliberate cross-industry action to make sure this happens in the right way.”
As a new member of the W3C, I look forward to participating in the conference calls that will cover the WebAssembly proposal and the broader WebAssembly Community Organization (GC) topics, as discussed in this article.
I want to thank the organizers of this event. In fact, all of the participants were “energetic and outstanding”. I met many new friends from leading technology companies and projects around the world. If I had to give one piece of feedback, it would be “please do it again next year”. I’m sure you’ll be amazed at what the Wasm community can accomplish.