I consider here how to visibly render the security situation on a personal computer whose architecture is capability oriented.

I have seen images in Windows depicting computer components and cables between them. Such images allow a user to understand where information is able to move. I want to do the same thing for the information flow within the computer and show how such flow is governed, both generally and specifically as the computer is currently configured. The advent of bluetooth (and IR ports before that) may require such imagery to speak to the paranoid about how information can leave his machine. The perimeter drawn graphically may be a strategic part of the solution.

I hope to treat these specific security issues:

Installation Propriety

There is no good reason that the code from Microsoft that installs their browser should run with the authority to delete or to damage the Netscape browser or conversely. We address these issues more completely here.

When software is installed it requires a variety of resources and facilities. Here are some typically required:

All of these are immutable.

The Apartment

This section is written from a system design perspective (not the user perspective!). I imagine an operation that the user can do that creates a guest apartment in his machine. The apartment comes equipped with bootstrap code that imports foreign code and gives it control. To do this the bootstrap code must have the authority described above and also some authority to fetch the foreign code. Its only police function is perhaps to: The apartment comes equipped with the authority described in the previous section. The apartment will remain accessible to the user and be deletable, along with its yield, according to durability rules.

There are two facets to the apartment, the tenant’s facet and the landlord’s facet. The computer user, owner and operator holds the landlord facet and the application is the tenant and holds the tenant facet. Via the landlord facet, the user can:

The landlord facet does not provide any other access to the apartment. Some degree of tamper resistance may be required here.


Durability ensures that applications do not deteriorate as a side effect of some innocent action. An installer for an application can easily arrange to make the application safe from accidental deletion. In fact I would propose that only the specific command to delete an application be able to impact that application. This means that if the application depends on some shared library then it is impossible to delete the library while the application still exists. It is also possible to find out what durable objects depend on some such shared mutable object.

Graphically I propose icons for the various apartments with lines running between them with a vertical component. Higher apartments would depend on lower apartments. This dependency is a partial ordering. The rule that Something upon which something else still depends, cannot be deleted. transforms into the rule that You cannot delete something which is connected to something higher.. This is graphically easy to understand. Efforts by the user to delete something not at the top can evoke a clear explanation of the rules as they apply to this particular situation.

See Software Distribution for further uses of apartments. See also compartments for a closely related idea.


There are two cases that are confused above. I will call them the static and dynamic apartments. An apartment becomes static just about the time that a factory that it produced becomes sealed. A dynamic apartment continues its activities independent of any instances that it has produced. Only static apartments can be durable. Here are some reasons why some apartments may not be static:


Confinement is somewhat of a dual to durability. If a user chooses to connect the yield of a discreet factory to some other unconfined thing, then the system could depict this situation. There are delicate issues of access of a confined object to a screen. Tempest is especially easy if the image producer wants to export information.

We say that a factory is discreet and also that its yield is discreet. This is very confusing. The properties of the factory and its yield are distinct yet related. The factory is not confined but is widely trusted not to divulge requests and to produce confined objects.

Technical arguments about confinement use diagrams that divide the world into two parts: inside and outside. I suspect that the same concept is necessary for conveying the correct ideas to the user. We need to design a secure confinement GUI along with a comprehensible explanation for the user about what is at stake! I don’t know whether the parts of a confined world are always abstracted from the user.

Here I speculate about images bearing on these ideas.

Service for Hire

There may be data and applications on the personal computer under the agreement that their use will be metered and some payment be made. The system can provide a degree of assurance that this agreement is kept. Depending on the degree of trust between the vendor and user, the hardware may need to be tamperproof. If the hardware is tamperproof then the hardware vendor may be in a position to provide a money back guarantee that the system will not crash nor various other problems arise.

See Why Johnny Can’t Encrypt by Whitten and Tygar for the devastating results of actually testing the usability of PGP. The authors address issues unique to security interfaces and those issues must be addressed here as well.

See this for worries about complex display hardware.