JavaScript applications use and rely on a lot of third-party code, including modules, packages, libraries, and in some cases even user-provided code for extensions and plug-ins. Too often, applications are fully vulnerable to these code dependencies, so not only do their current security vulnerabilities impact the applications, so do future vulnerabilities. Over night, any dependency could get “upgraded” into an exploit, resulting in a security breach like the event-stream incident.

This is where SES comes in. SES is a JavaScript runtime library for running such third-party code safely inside a featherweight compartment. SES stands for Secure ECMAScript, where ECMAScript is the standards name for JavaScript. SES addresses JavaScript’s lack of security. SES supports practicing of the Principle of Least Authority (or POLA), so that the risk from most third-party code can be substantially reduced.

Early JavaScript provided no such compartmentalization. Essentially any software component could completely compromise any other component. However, starting in 2009 with ES5 (ECMAScript version 5), we introduced enablers such as Object.freeze, strict-mode, Promise, and Proxy to start securing JavaScript, so we could use it as an object-capability (ocap) secure programming language. The decade of work since ES5 means you can load a small SES library into any conforming JavaScript system to create a safer programming environment. The library in turn enforces that further JavaScript code loaded into the system must stay within ocap rules.

SES in Action

Here are examples of SES case studies, each addressing the need to reduce vulnerabilities to third-party libraries:

1. Salesforce: Salesforce uses a SES implementation derived from the SES code they co-developed with Agoric. Salesforce currently supports a five-million developer ecosystem on this implementation, using JavaScript as an ocap language.

2. MetaMask: With SES, MetaMask Snaps allows third parties to write plugins for custom behavior in the MetaMask wallet. One example is the Starkware plugin for their custom cryptography. MetaMask’s LavaMoat secures JavaScript dependencies in the build process through their SES plugins for Webpack and Browserify.

3. Moddable: Moddable’s XS JavaScript Engine (its ECMAScript 2018 engine for embedded devices) is the first engine to directly implement SES. Moddable employs SES both to improve the performance and to reduce the attack surface of these devices.

4. The Internet of Things: TC53, another standards organization under ECMA, has explicitly adopted SES as the base JavaScript for standardizing modules for home appliances, traffic control, and other devices in the Internet of Things. Name-brand manufacturers of household products in the IoT ecosystem are excited about this. Current device security is a nightmare. Writing IoT devices software in SES is a good starting point for building a safer world.

5. Node.js: Node, the leading JavaScript runtime environment for servers, has adopted elements of SES into Node core (e.g., frozen primordials). Node has over a billion downloads and tens of millions of active users.

Status

The SES-proposal and related proposals to TC-39 are standards-track enhancements to JavaScript, while the SES-shim is a library that provides those features. With security reviews scheduled in January 2020 SES is headed toward production readiness.

Further Reading

For further reading, I recommend Kate Sills’ essay “POLA Would Have Prevented the Event-Stream Incident.” An Agoric engineer, Sills looks at how malicious code in the event-stream npm package last year left some Bitcoin users’ private keys vulnerable. Sills explains how SES used to enforce the Principle of Least Authority (POLA), could have avoided this.

Thanks for reading! You can join the Agoric community on Twitter, Telegram, LinkedIn, and catch us at these upcoming events.