Skip to content
This repository has been archived by the owner on Feb 2, 2021. It is now read-only.

SubsetRelationships

Jump to bottom
Kevin Reid edited this page Apr 16, 2015 · 1 revision

(legacy summary: Relationships of Cajita, Valija, and various versions of JavaScript)

Caja Today

JavaScript and Caja are jointly in transition. The language in the middle of the digram below is Cajita, the Caja kernel language. Cajita is a genuine object-capability language we discovered in a subset of JavaScript. As an object capability language, Cajita omits all of JavaScript's mutable static state. In other words, all global implicitly accessible objects, like Object.prototype, are immutable. Cajita strengthens JavaScript's one encapsulation mechanism -- lexical variable capture by closures -- into a true security boundary. To make defensive programming practical, Cajita omits various accident prone features of JavaScript, such as the magical this keyword.

The following diagram explains the current relationships between Cajita and JavaScript.

http://google-caja.googlecode.com/svn/trunk/doc/images/cajita-vs-valija.png

  • ES3R is used in various EcmaScript discussions for "EcmaScript 3 plus reality", meaning, consensus JavaScript as implemented by current A-grade browsers.
  • ES5 is the draft standard for the next version of JavaScript.
  • ES5-strict is a more principled sublanguage of ES5 supported by ES5's "use strict" directive.
  • Caja defines two variants of JavaScript:
    • Cajita (Spanish for small box) is the Caja kernel language --- an object-capability language supporting defensive programming.
    • Valija (Spanish for baggage) is the ES3 subset of ES5-strict. Old JavaScript code can easily be ported to Valija. Once ported, it will work on both current and future JavaScripts. Valija exists only to accommodate old code. The additional elements of JavaScript it includes, such as this, make it unsuitable for writing defensive code. Instead, Valija is used only to isolate potentially offensive code.

Besides the normal object-capability constraints, Cajita was shaped by the need to simultaneously support all four of the depicted relationships, as well as is practical today.

  • T = TranslationTarget. Cajita is implemented by translation to JavaScript as run by current browsers.
  • N = NiceNeighbor. Cajita code coexists with some amount of untranslated JavaScript code. This coexistence must have a well defined semantics and useful safety properties. Today, the NiceNeighbor property supports safety only in one direction -- protecting untranslated JavaScript from potentially offensive Cajita code.
  • S = SimpleSubset. The first enemy of security is complexity. Due to JavaScript's history, it is needlessly complex. Cajita is approximately the simplest subset of JavaScript we could find with no loss of functionality for new code.
  • E = EmbeddedEmulation. JavaScript, and therefore Valija, supports mutable static state, which violates object-capability rules. To support multiple isolated Valija sandboxes on one web page, we translate Valija to Cajita so as to emulate this static state in terms of isolated Cajita object states.

Among secure JavaScript variants, ADsafe, Jacaranda, and dojox secure are all designed for a similar degree of support for NiceNeighbor and SimpleSubset. Rather than translate to ES3R, they instead take a verification-only approach, which has various engineering benefits such as zero runtime overhead. However, for ES3R, verification requires blacklisting rather than whitelisting, which is harder to secure.

Note that Jacaranda does define a set of static rules for permitting safe limited use of this. A future Cajita may adopt these rules.

Facebook's FBJS2 and Microsoft's WebSandbox have no intermediate object-capability language, but rather, emulate JavaScript directly in JavaScript, i.e., conventional sandboxing. This supports isolation of potentially offensive code, but provides no direct support for secure cooperation or the writing of defensive access abstractions.

Caja Tomorrow

Currently, each of the above relationships are fragile or imperfect in various ways documented on each of these respective pages. On browsers that implement the next version of JavaScript, ES5, these relationships will be strengthened, as explained in this section.

http://google-caja.googlecode.com/svn/trunk/doc/images/ses-vs-es5.png

The Secure EcmaScript working group of the EcmaScript committee seeks to define a simple secure subset of future JavaScript, to be known as "Secure EcmaScript" or SES. Based on lessons from Cajita and these other systems, we propose that SES and future EcmaScript be co-designed to improve all four relationships between them. In this section, we explain first how Cajita will coexist better with ES5. We then explain some deficiencies in those relationships suggesting further improvements in future EcmaScripts and in Cajita as a proposal for Secure EcmaScript.

  • T = TranslationTarget. Cajita can be translated trivially to ES5-strict, and the resulting translated code should be able to run at close to full speed.
  • N = NiceNeighbor. Because ES5 enforces the primary security mechanisms Cajita depends on -- closure encapsulation and frozen objects -- untrusted untranslated ES5 objects can be given direct access to Cajita objects without being able to harm their integrity.
  • S = SimpleSubset. Once the Cajita's target language supports the ES5 meta operations, it becomes practical for Cajita too as well.
  • E = EmbeddedEmulation. Once Cajita supports the ES5 meta operations, it becomes practical to emulate these operations in the embedded language, bringing it up to full ES5-strict.
Clone this wiki locally