Skip to content

OCap Discipline

Dan Connolly edited this page Jul 21, 2023 · 4 revisions

In brief:

  • modules should not export powerful objects (for example, objects that close over fs or process.env) (#2160)

  • program scripts are indicated with #!/usr/bin/env node at the top (and +x file permissions). They are free to import all the authority they need and then delegate it.

  • test scripts are named test-*.js. Note that tests don't export anything.

Background

A key to cooperation without vulnerability is object capability discipline, which consists of:

  • Memory safety and encapsulation: There is no way to get a reference to an object except by creating one or being given one at creation or via a message; no casting integers to pointers, for example.
    From outside an object, there is no way to access the internal state of the object without the object’s consent (where consent is expressed by responding to messages).

  • Primitive effects only via references The only way an object can affect the world outside itself is via references to other objects. All primitives for interacting with the external world are embodied by primitive objects and anything globally accessible is immutable data. There is no open(filename) function in the global namespace, nor can such a function be imported -- converting a string to file access is much like converting an integer to a pointer.

Object Capabilities are often abbreviated as OCaps; hence OCap discipline.

On the Agoric platform, OCap discipline is enforced on contracts.

While JavaScript platforms (browsers, node) don't enforce OCap discipline in general, SES lets us layer it on top.

References

See also;

Clone this wiki locally