This document is an early draft. Comments appreciated! Thanks.
Today, JavaScript is the pervasive representation for (somewhat) safe mobile code. For another representation to achieve universality quickly, it must be a subset of JavaScript, and so runs at least everywhere JavaScript runs.
Whereas JSON is a simple universal representation for safe mobile data, Jessie is a simple universal representation for safe mobile data and behavior.
Jessie is a small safe ocap subset of JavaScript that
- is pleasant and expressive to program in,
- can easily run within a JavaScript system,
- can be safely linked with adversarial SES code,
- can be easily implemented for standalone use,
- can be transmitted as lightweight safe mobile code,
- is amenable to a range of static analysis,
- omits most of JavaScript's bad parts,
- non-experts can use to write non-trivial non-exploitable smart contracts.
Unless stated otherwise, all references to EcmaScript refer to EcmaScript 2017, the eighth edition of the standard.
JSON <SA Jessie <DAT TinySES <SA SES <DA ES-strict <SDA EcmaScript
One language is a static subset (<S) of another if every program statically accepted by the smaller language is also statically accepted by the larger language with the same meaning.
One language is a dynamic subset (<D) of another if non-erroneous execution of code in the smaller language operates the same way in the larger language. The smaller language may treat some dynamic cases as errors that the larger language would not consider errors. Programs in the smaller language whose correctness relies on these errors, even if it does not provoke them itself, would generally become incorrect as programs in the larger language.
One language is absorbed (<A) by another if code in the smaller language can be run as code in the larger language without modification. A smaller language which is not absorbed may often be transpiled (<T) into the larger language by source-to-source transformation.
The diagram above illustrates the subsetting relationship between various subsets of EcmaScript. The vertical dimension represents syntactic subsetting by static means. The horizontal dimension represents semantic subsetting by either static or dynamic means. The word cloud in the contour between each language and its subset represents the features of the containing language omitted by that next smaller subset. The relative sizes of feature names reflects only their explanatory significance.
Each step needs to be explained. Proceeding from larger to smaller.
EcmaScript code may be in either strict mode or sloppy mode, so
the ES-strict sublanguage is a static, dynamic, absorbed subset of
full EcmaScript by definition. (Historically, the strict sublanguage
started by approximating a static and dynamic subset of the sloppy
language, excluding with and throwing errors where the sloppy
language would instead silently act insane. But this approximation has
too many exceptions to remain useful.) EcmaScript classes and modules
are implicitly strict, so the vestigial sloppy language is best seen
as an EcmaScript 3 compatibility mode.
Unlike full EcmaScript, ES-strict is statically scoped, ES-strict functions are strongly encapsulated, and implicit access to the global object is severely restricted. These are necessary steps towards ocap safety, but are not sufficient by themselves.
SES, or Secure EcmaScript, is a dynamic, absorbed subset of ES-strict. To achieve this subsetting, SES builds on Frozen Realms which builds on [Shadow]Realms. (Shims at Realms shim and Frozen Realms shim.) SES statically accepts all programs accepted by ES-strict and can run on ES-strict without internal modification.
Via Realms, SES removes ambient authority from the global scope, so
attempts to dereference a variable named, for example, document that
might succeed in ES-strict on a given host might instead throw a
ReferenceError within a SES environment run on that host. Via Frozen
Realms, SES freezes the primordials, so mutations that would succeed
in ES-strict might instead throw a TypeError in SES.
SES is the largest subset of ES-strict which is still an ocap language. Its purpose is to run as many conventional EcmaScript programs as possible while staying within ocap rules.
TinySES is a static, absorbed subset of SES. TinySES approximates
the smallest useful subset of SES that is still pleasant to program in
using the objects-as-closures pattern. TinySES omits this and
classes. Once initialized, the API surface of a TinySES object must be
tamper-proofed before exposure to clients. TinySES is not intended to
run legacy code or code that uses inheritance.
Jessie is a dynamic subset of TinySES. Jessie and TinySES have the same grammar and static restrictions. The Jessie grammar is simple enough to be parsed easily. Jessie imposes static validation rules that are easy to check locally, to ensure that objects are tamper-proofed before they escape. Statically valid Jessie programs enable sound static analysis of useful safety properties. A SES IDE can thereby flag which code is withiin the Jessie static restrictions and provide sound static analysis info for that code.
The only difference between TinySES and Jessie is that correct TinySES programs may rely on the presence of the entire SES runtime. Correct Jessie programs may only rely on a minimal subset of the SES runtime that standalone Jessie implementations can implement for reasonable effort. However, correct Jessie programs also cannot rely on the absence of the rest of the SES runtime. Jessie and TinySES programs may be linked with programs written in SES, and so may rely on SES's ocap rules to constrain these other programs.
Thus, every correct Jessie program is also a correct TinySES and SES program, and works unmodified within a SES environment run on a normal JavaScript implementation. Correct Jessie programs will also run on a standalone implementation of Jessie (which still needs to obey SES's ocap rules) in which it is linked only with other Jessie code.
JSON is a static, absorbed subset of all the languages above. JSON achieved universal adoption because
- it was a subset of JavaScript, which was already pervasive
- it was easy to implement on any language and any platform
Likewise, Jessie is small enough to be easily implemented as a compiler or interpreter in a wide range of other languages and platforms. Its character resembles a simple Scheme with records.
The Jessie grammar is based on the ECMAScript 2017 Grammar Summary. Unlike the Ecma page, lexical productions in the Jessie grammar are named in all upper case.
Unlike EcmaScript and SES, Jessie has no semicolon insertion, and so
does not need a parser able to handle that. However, Jessie must
impose the NO_NEWLINE constraints from EcmaScript, so that every
non-rejected Jessie program is accepted as the same SES
program. NO_NEWLINE is a lexical-level placeholder that must
never consume anything. It should fail if the whitespace to skip
over contains a newline. TODO: Currently this placeholder always
succeeds.
Jessie omits the RegularExpressionLiteral. Some Jessie
environments may instead include the
RegExp.make template
string tag. By omitting RegularExpressionLiteral and automatic
semicolon insertion, our lexical grammar avoids the context
dependencies that are most difficult for JavaScript lexers.
In Jessie, all reserved words are unconditionally reserved. By
contrast, in EcmaScript and SES, yield, await, implements, etc
are conditionally reserved. Thus we avoid the need for parameterized
lexical-level productions.
Jessie omits both the in expression and the for/in loop,
and thus avoids the need for parameterized parser-level
productions.
QUASI_* are lexical-level placeholders. QUASI_ALL should match a
self-contained template literal string that has no holes
" `...` ". QUASI_HEAD should match the initial literal part of a
template literal with holes " `...${ ". QUASI_MID should match
the middle " }...${ ", and QUASI_TAIL the end " }...` ". The
reason these are difficult is that a close curly "}" during a hole only
terminates the hole if it is balanced. TODO: All these
placeholders currently fail. There is not yet the logic needed to
tell whether a close curly terminates a hole.
Outside the lexical grammar, other differences from ECMAScript 2017 Grammar Summary are noted as comments within the grammar. The Ecma page uses a cover grammar to avoid unbounded lookahead. Because Jessie grammar is defined using a PEG (parsing expression grammar) which supports unbounded lookahead, we avoid the need for a cover grammar. TODO: Determine where difficulties arise parsing according to this Jessie grammar with bounded lookahead. If difficult, we may reintroduce a cover grammar.
Jessie array literals omit elision (i.e., nothing between commas).
Jessie treats async, arguments, and eval as reserved keywords.
Strict mode already limits arguments and eval to the point that
they are effectively keywords in strict code. Jessie does include
ellipses ... both as rest and spread, which provides the useful
functionality of arguments with less confusion.
Jessie omits mutation through computed property names. Jessie has syntax
for mutating only number-named properties, which include integers,
floating point, NaN, Infinity, and -Infinity. Jessie omits syntactic
support for mutating other property names, except when preparing an object
for delivery (before it is staticly required to be hardened). However, the
SES environment provides access to the Reflect
API, enabling explicit reflective property access. TinySES programs
may rely on Reflect to manipulate properties via EcmaScript property
descriptors. Jessie programs may not rely on the presence or absence
of Reflect or other elements of the SES runtime. Jessie programs
thus cannot use property descriptors, but must assume that the code it
is linked with may.
Jessie includes arrow functions, function functions, concise method
syntax, and accessor (getter / setter) syntax. Jessie omits
generators, async functions, async iterator functions in all their
syntactic forms: function functions, arrow functions, and concise
method syntax. Jessie omits symbols and general computed property
access.
The Jessie switch statement grammar requires that all cases be
terminated by a terminating statement, return, break, continue
or throw, avoiding a perpetually annoying hazard of C-like
languages.
All control-flow branches, including switch cases, must be blocks,
not naked statements, avoiding hazards and giving each branch its own
lexical block scope.
Jessie has no for/in statement, and so does not inherit the
non-determinism regarding property modification during for/in
enumeration. Everything useful about for/in is still available by
Object.keys, Object.values and Object.entries, (or in TinySES
through reflection) but without this non-determinism issue.
The Realms and Frozen Realms shims are designed to accommodate
initialize-time vetted shim code, to customize the realm's primordials
prior to freezing. A component of SES is just such a shim, which
customizes the primordials to better support defensive
programming. In Frozen Realms by themselves, even when the primordials
are frozen, the instances of
Set, Map, WeakSet, WeakMap, and Promise have mutable own
properties. This mutability of their API surface does not help them
serve the purpose of these abstractions, but does present opportunity
for one piece of code to confuse another. The SES shim wraps these
constructors to freeze their instances before returning them.
For Promise we also need to ensure that new promises made by promise
operations are similarly frozen. We use the constructor species mechanism
when we can. Otherwise, we also wrap the relevant Promise methods to
return frozen promises.
The following static restrictions are specified as if they occur post-parsing, by analyzing the abstract syntax tree.
The ES-strict eval can be used for both direct and indirect
eval. SES, TinySES, and Jessie all support indirect eval. The Realms
shim cannot support direct eval. Direct eval can only be supported
once platforms provide native support for Realms. Till then, to avoid
confusion, SES, TinySES, and Jessie implementations omit the syntax of
direct eval. However, this syntax remains part of SES as
specified. TinySES and Jessie omit direct eval by design.
SES can create objects whose API surface is not tamper-proofed and expose these to clients. This is easy to do accidentally, and hazardous when it happens. Even if the object was designed to be directly mutated by its clients, any client may freeze the object, preventing other clients from directly mutating it. Further, no purely static type system for EcmaScript can be both useful and sound in the face of the pervasive possibility of reflective property mutation.
To enable sound static reasoning, in Jessie all objects made by
literal expressions (object literals, array literals, the many forms
of function literals) must be tamper-proofed with harden before they
can be aliased or escape from their static context of origin. Thus,
direct property mutation can only be used to prepare an object for
release. Use of harden then marks the object as being ready for use by
its clients, who are thereby unable to mutate its properties. During
an object's initialization phase, due to the lack of aliasing, each
mutation can be reasoned about as-if it replaces the object in place
with a derived object holding the new property.
Looking up a function in an array and calling it would naturally be coded as
array[+i](arg)However, if the called function were written in SES it could use
this to capture the array itself. To protect against this, Jessie
statically rejects this call, forcing the programmer to write instead
something like
(1,array[+i])(arg)which is safe. However, the Jessie programmer might still encounter this hazard if storing a SES function on a named field of a record, looking it up by name and immediately calling it:
record.field(args)This would still give the SES function access to the record as its
this argument. We need sound static type checking to prevent this
case while allowing this syntax in general.
SES code can access the per-compartment global object using the same
syntax that JavaScript has always used to access the per-realm global
object --- a top-level this. Like E, Jessie code has no notion of a
global object, and so is statically prohibited from naming it. Thus,
Jessie does not need SES's notion of "compartment".
All the SES whitelisted globals are safe to provide to TinySES
code. However, we omit some of these from the definition of Jessie,
like RegExp and Date, to reduce the effort needed to implement a
standalone Jessie on a non-JavaScript host.
In JavaScript, module instances can have top-level mutable
state. Thus, if modules A and B both import or require module C, A
and B can communicate with each other via C. Thus, each SES
compartment needs its own loader. By contrast, Jessie has no
loader. Instead, Jessie modules have no top-level mutability, and all
exported values must be tamper-proofed. A Capability-Based Module
System for Authority
Control,
explains why such module instances safe to share between mutually
suspicious objects. Indeed, Jessie modules can be seen as a immutable
extension of a Frozen Realm's immutable primordials.
SES will bundle some convenience libraries to support ocap programming patterns, such as a membrane library. However, since these are additions to standard JavaScript, they are not shown on the subsetting diagram.
Although Proxy itself is not available in Jessie, the membrane
library built on Proxy and WeakMap is. A standalone Jessie
implementation can directly provide a membrane library adequate for
standalone Jessie use without implementing Proxy.
For the goals of SES, we cannot freeze arrays before releasing them to
clients. Such freezing would break tremendous amounts of legacy code
unnecessarily. Handing out mutable arrays, and mutating them, violates
no ocap principles. However, TinySES cannot soundly statically type
objects whose properties can be arbitrarily mutated and
overridden. Thus, TinySES can only type arrays that are made directly
by TinySES array literals, or those that TinySES code tamper-proofs
immediately when obtaining a fresh array from builtins like
Array.prototype.map. In the following legal TinySES code
harden(harden([x, y, x]).map(f))if TinySES knows that the array produced by .map is pristine and
fresh, it could soundly consider it a typed frozen object with no
extraneous or overriding properties. However, keeping track of such
freshness requires more type mechanism than we wish to require for
TinySES.
Without the outer harden the code above is still valid TinySES
code. But TinySES would consider the resulting value to be as untyped
as values received from SES code.
The import expression and import.meta expression
proposals, by themselves, introduce a security hole in JavaScript. The
ShadowRealm proposal's traps
provide the mechanism needed to plug these holes. On those platforms
that provide either of the security breaking features but do not provide
native support for Realms, safety can only be shimmed at the price of
a full parse. This is the current situation on some browsers.
Beyond subsetting EcmaScript, the Jessie grammar also includes the
infix tildot ~. (eventually) operator (like ! from Dr.SES). We hope infix tildot
~. will become part of the standard EcmaScript grammar. But until
then, infix tildot ~. trivially transpiles into calls to the Dr.SES
extended promise API. See Distributed Electronic Rights in
JavaScript.
We will add BigInt to Jessie, even though it will only be in EcmaScript well after ES2017.
Freezing the primordials does more that just turn non-errors into errors. It also changes how reflection describes these properties and objects. Thus, SES and Jessie are technically not subsets of ES-strict for programs using reflection, since these differences are detectable by means other than errors.
Arrow functions and concise methods have a [[Call]] behavior and no
[[Construct]] behavior, preventing them from being called as a
constructor, such as with new. However, Jessie function functions
can be called by SES code with new. Without this it is hard to see how
this could confuse a function function, but I am not yet confident
that this does not produce a hazard for the Jessie code.
Once EcmaScript supports BigInts, SES and Jessie will as well. Thus we need to add the bitwise operators back into the Jessie grammar. In fact, there was no good reason to omit them.
Should we add do/while back into the Jessie grammar? There's no
hazard here. We omitted it just for minimalism.
TODO: We must ensure that code containing "<!--" or "-->" that
could be parsed as an html comment according to the EcmaScript
Appendix B
grammar
is instead statically rejected. Otherwise the same source may parse
differently on different platforms, or even as script vs module code
on the same platform.
Can Jessie be soundly statically typed with a structural type system? What about trademarks/nominal-types and auditors? How would this map to the wasm type system which does tag checking but no deep parameterized type checking? If static checking makes sense, should we add some of TypeScript's or Flow's syntax for optional type declarations? Let's call such a variant Typed Jessie. Given declared function types for parameters and return values, can Typed Jessie infer the rest? How would these types play with the Cap'n Proto types? What about subtyping? What about contravariance?
It is plausible that Typed Jessie can be soundly statically typed without implicit runtime checks, but we have not yet verified this. The distributed messages of Distributed Jessie are likely to be typed, to be explicit about what API dependencies are exposed as protocols on the wire. These two purposes should use the same type system, so that Typed Distributed Jessie can be simpler.
Defensive JavaScript (DJS) and ProScript, as subsets similar in many way to Jessie, built to support mechanized formal reasoning by translation to ProVerif. However, the designs are somewhat different, as are the goals of the formal reasoning. TODO: Investigate whether Jessie could repurpose this work. Is the intersection of Jessie and DJS a reasonable language for us? Could Jessie be translated to ProVerif in a similar manner? Is ProVerif helpful for verifying the security properties we are interested in verifying?