This document informally specifies the behavior and desired security properties of the Treehouse broker.

Broker

At a high level, the broker is responsible for interposing on privileged API calls in the worker and virtualizing the browser's API. For details, see Section 3 of the paper.

Interposition

The broker must prevent direct access by guest code to privileged API methods and properties in the worker. To do so, the broker runs first in the worker, before guest code. It iterates over all properties of the global object, and (with the exception of some unprivileged properties named in a whitelist, such as setTimeout and Object) replaces each with a shim. The shim is installed by calling Object.defineProperty with both configurable and writable set to false in the property descriptor.

The broker may retain private references to some privileged properties. If it does so, it must not leak any such references to guest code, and must not use the referenced property except at the behest of the monitor.

The broker must not perform computations using any values that the guest code can alter. This includes properties found on a prototype chain that guest code has write access to. If, for example, the broker checked the value of some string using RegExp.test, guest code could cause the check to always pass:

RegExp.prototype.test = function () { return true; };

Unfortunately, guest code may need to alter the prototypes of such native objects for completely benign reasons, so the broker cannot simply freeze the prototypes of any objects it uses. Instead, the broker must retain its own reference to any prototype properties it employs:

var RegExp_test = RegExp.prototype.test;
var isSafe = new RegExp('ok', 'i');
isSafe.test = RegExp_test;
if (isSafe.test('OK')) {
  // ...
}

Security properties

We would like to prove (at least) the following properties:

1. Guest code cannot obtain a reference to privileged methods or properties.
2. Guest code cannot affect the correctness of computations performed by the broker.
3. The broker will perform a privileged action only if it receives a valid request from the monitor to do so.

Implementation plan

The broker will be implemented in several iterations, each progressively more powerful and complicated than the last. After each iteration, we will determine whether the security properties hold.

Iteration One

The initial iteration of the broker will not retain any references to privileged properties. It will simply install the shims and then perform no further computations. This makes properties 2 and 3 trivially true. Since the broker will not invoke importScripts, guest code must be concatenated with the broker into a single script.

Iteration Two

The second iteration of the broker will only retain a reference to postMessage. It will virtualize privileged properties of the global object by marshaling requests to perform privileged actions to the monitor. The broker will not perform any other privileged actions. If we are unable to prove property 2 for this iteration, security should not be compromised - provided the monitor is correct.

Iteration Three

The third iteration of the broker will also retain a reference to importScripts.

Iteration Four

The final iteration of the broker will retain a reference to all privileged global properties.

Virtualization

For any virtualized methods, the broker must marshal the request to the monitor, and construct a shimmed return object if necessary (as in the case of XMLHttpRequest, for example).

When possible, the shims should be generated automatically from the appropriate IDL.