I assume here a properly paranoid user U who’s world spans cultures that might well want to exploit U’s computer for nefarious ends. Perhaps U is a lawyer who defends unpopular clients. Perhaps U is a political analyst. Perhaps U is a consultant to fiercely competitive firms. Perhaps U is a peace-maker. Perhaps U is a spy.

I choose e-mail as an application here because it easily illustrates several security problems more clearly than other sorts of applications. I assume an e-mail client that runs on the computer operated by U and fetches e-mail via a protocol such as POP and sends via SMTP. My e-mail client (from Apple) has learned to do many useful things over the years and I don’t want to give them up for a bare bones client. On the other hand I do not want to trust this now large undocumented software package to be free of low level exploits such as buffer overruns, or high level exploits such as willingness to deliver my entire mail name list to anyone who is able to run on my computer and ask nicely.

The solution I explore here is to divide the client code along certain cleavage lines and impose simple external security rules. This note is to explore such potential application surgery.

My current client (e-mail program), from Apple, is written and installed with the notion that there is just one instance per machine. The client has builtin file and directory names which are by convention unique. It stores my e-mail there. One solution for U is to buy one computers for each world in which he operates. Now a virus from correspondent X will not learn of the identity of correspondent Y from another world. This sort of proves that multiple instances of the client are possible. Virtual machines might ameliorate the hardware cost but still leave us with awkwardness of legitimately moving data between worlds.

This unique instance notion stems more from the OS and file name conventions than the application. The notion was in the head of the programmer of the mail app but had little influence on the code we wrote. The program logic probably assumes ‘one client instance per machine’ as it addresses its ‘private files’ but we propose to endow each client instance with what appears to be its own file tree, named as it would be in a conventional system.

To keep worlds separate it is easy to acquire distinct e-mail addresses for distinct worlds. Each client instance would know of just one POP address. If e-mail crypto is needed than a mail client may be bundled with a PGP client where each bundle knows just one RSA secret key. This bundle can be such that neither PGP nor the mail agent knows of other bundles, or that indeed that there is anything unusual about its environment. They need not be aware of plural bundles!

U might want to see views of all his e-mail chronologically across worlds. This sounds difficult at first except when we note that there is no legitimate reason to send such information to anyone but U, via the screen or into a file provided by U. This calls for cleavage of the application and probably across a data abstraction boundary. This presumably requires cooperation of the programmer of the app. An information diode must be installed allowing information to flow from the client in each world, to a client component running in a confined compartment with very limited information outflow. The same steps also allow for searching across various worlds of e-mail.

The techniques of the previous paragraphs have a confined program fetching mutable and mutating data from a place with which it is not allowed to share a lock. There are various hacks to solve this. Some involve flakey but still secure search integrity. Others involve limited signal flow in the dangerous direction. Still others are more complex.

In such a more complex protocol a client might occasionally get a request for a read capability to an unchanging tree of e-mail. Such requests are likely to easy to comply with without interfering with normal service. Still the dilemma of deleting e-mail and records thereof remains in light of having provided such a capability.

All of the hooks to provide such cleavage logic are easy in systems such as Keykos. There remains the problem of adapting the client code to such cleavage.