Concepts precede names for those concepts unless you are a student learning concepts invented by others. A computer user will learn concepts for which he needs no names. This is especially true in graphical interfaces where a user knows how to move something by dragging while not knowing that it is called “dragging”. Even in the Unix shell he will know of the working directory but not “working directory” nor know what the “wd” in “pwd” stands for.

I think that good user interface design requires the designer to give names to these concepts. They are probably necessary to use in documentation intended for programmers of code that is involved in these interfaces.

“Perimeter” is a term for a concept that I think is critical to a user interface that helps a user deal with the security of his data. It is very close to and perhaps isomorphic to concepts used in formal security proofs for capability systems. The user term refers to a set of objects that are shown graphically while the formal term refers to sets of program objects. Four sorts of perimeter are discussed under the generic term insulation. In that context we use the term environment instead of perimeter. How to depict an environment or perimeter graphically is germane to the choice of term.

Perimeters may intersect as in the VCSK example—i.e. environments are not necessarily nested. One perimeter veils the implementation details while another confines the content of the segment. An apartment may involve more than one perimeter.

Membranes are like perimeters but punctured in a principled way. Their purpose is different and I don’t want to include either category in the other.

Perimeters are an emergent phenomenon. You can’t ask the kernel where the perimeters are. There is no authority within the system to audit a perimeter except in the kernel. The kernel has the authority but lacks the logic. It is not clear how such authority should be reified outside the kernel.

It is often, perhaps always, natural to chunk the stuff within a perimeter. Graphically this means making the perimeter and stuff within into a single icon. When the perimeter is for abstraction in it may be necessary to chunk it. There may indeed be no need to draw a line depicting a perimeter in a user interface with multiple items on each side. The first time I drew such a picture was to illustrate the emergent concept of a perimeter to someone who was trying to understand the claims of factory logic from the kernel’s perspective. Factories and Forts produce perimeters but they quickly lose track of just what set of objects are within the perimeter. A perimeter divides objects into two sets and they stayed divided even though the kernel had no representation of the perimeter or sets. I suspect that the user does not need this perspective.