I try to describe here the strategic nature of a box that implements capability discipline to all of the software inside.

It is a system where diverse interests can each install software applications, such as web sites. Each such application is impacted by other such applications, inside the box or out, only as explicitly allowed by the design of that application. Also such applications keep their secrets as they choose, against even purposeful penetration attacks launched within the same box.

There would typically be an “operator” of that box but his access can be limited to allocating physical resources such as space, time, bandwidth etc. Of course the capability discipline relies, for its protection against the operator, on some degree of obscurity and hardware tamper resistence.

A system such as Keykos or Eros, in addition provides persistence so that applications do not need to represent their state separately in non volatile “files” as well as internal data structures.

Applications communicate by mutual consent, choosing to affect and be affected by communicants to just the degree that they wish. Such communication can be on the microsecond time scale if that suits the needs.

Problems such as viruses can be essentially eliminated insofar as the native capability is adopted by an application. Trojan horses can also be kept at bay at least by reasonable and conventional definitions of such animals.


It is possible to provide degrees of compatibility with legacy systems such as Unix. To the degree that complete compliance is provided viruses, trojan horses and other ills of current systems will largely persist. There are a number of intermediate possibilities to consider, however.

Unix, or at least “least common denominator Unix” such as Posix, suggests a design point. There is a general scheme of providing an illusion to the legacy application under which each entity to which the application needs access, is presented in the conventional manner. Thus an application whose input and output are are streams of ascii characters will begin execution with a directory where “in” names the file with the input and in which the standard file opening system calls produce a file containing the results. No other files are needed. If there were a Trojan horse within the application intent on erasing all files ending in “.c”, it would find none.

I don’t know what the practical limits are to this approach. Certainly applications using several Unix processes could be supported but I don’t know whether that would be a good investment.