Modules

In the first, we choose to draw the boundary between individual code units
(for example, objects or functions). We create a programming language that
enforces capability discipline on programs written in that language.
What would such a language look like? At first, it seemed it would have
to be quite esoteric, but as our understanding of capability languages has improved,
we realise that capability languages are really only slightly different
from standard object-oriented languages. Typically all they change is some details:
no globals10, opacity and unforgeablity of objects (which then become the
capabilities themselves), access to anything outside the program itself mediated
through capabilities11.
This means we have an interesting design choice available: rather than inventing
a new capability language, we can modify an existing one. The former
choice is seen in E[15] and the latter in Squeak-E (Smalltalk), Joe-E[11] (Java)
and Caja[1] (Javascript).
Because of the natural correspondence, mentioned above, between objects
and capabilities, the concern often expressed over managing the hundreds or
thousands of capabilities a fully-featured program might need is dealt with quite
simply: programmers deal with thousands of objects quite easily and naturally
– the fact that these objects are now capabilities does not change the ease with
which they can be handled.
In this case, because capabilities are directly controlled by the language,
authentication should not be required to preserve unforgeability, but may be in
order to restrict delegation, depending on implementation12.