Unix, having been originally designed for more than one user, as in timesharing, propagated from earlier systems, the idea that each user should be able to view his access to the machine as private from other users — each user within his own realm. One user could neither see nor interfere with another’s use of the machine. The goals of Unix and its immediate predecessors was to provide the user with the convenience of having his own machine. Each user was confined to his realm, and safe there from travails in other realms. Unix and its ilk, did one more thing — it provided tools such as compilers and loaders to its users, for they might not have the knowledge or means to install the tools themselves. Furthermore with centrally provided tools, disk space was saved, but it was then necessary to protect those shared tools from acts in any realm, lest one realm impact another.
Those who built early timesharing systems, were programmers and built the systems for programmers and their professional colleagues. The programs running within the system were extensions of the users and did whatever the programmer-user desired. It was the late 70’s before most in the profession began to try to distinguish between user and programmer. Here is a short cultural history of early computer practice.
These designs implicitly assume that application code does just what the user wants it to do. Any other behavior is deemed a bug and the remedy is to fix the bug. There is no thought that the programmer who is in a position to fix the bug may have different interests than the user who suffers from the bug. Indeed the programmer and user may, unbeknownst to the user, have incompatible interests. The Trojan horse is the primary example of this.
The Mac or Wintel system has just one realm per machine. Within a realm the application program runs with all of the authority of the user. Not even the tools or kernel are safe. This makes the job of viruses and Trojan horses easy.
Two developments have recently made this issue even more critical, especially in combination:
If applications are to run with authority limited to their legitimate requirements then the user would seem to have the added job of telling the computing platform what that authority is. The present note is to argue that such user effort usually displaces other work required in conventional systems, and when the work is indeed additional, it addresses basic user needs that conventional systems do not address.
In Unix, MacOS and Windows 95 the user must select what instance of a document (some sort of work product) is to occupy the attention of the application and user. In Unix the user selects the instance by providing to the application, some sort of forgeable name for the instance. The application uses its authority to access any of the user’s files by name, and accesses the one named by the user. A malicious application may access other unselected instances as well. In a capability system the user and system would provide to the application an unforgeable name (a capability) to the instance. The application would lack authority to access any other file. There seems to be no extra work here for the user or the application.
Communication software is notorious for stepping on the work product of other installers. This is ranted upon at length here where I claim that the authority required by the installed application is likely to be critical to other vital system functions. The user knows that there is a modem connected to his computer and it is no conceptual burden on the user to grant the modem to the application. Many times I have had to reboot my Mac because some forgotten program still had hold of the modem. I could neither find out what program it was, nor regain the use of the modem short of rebooting the machine.
Even with plausible benign security policies of browsers I am left to the mercy of the hundred or so “applications” which make my PC useful, not to mention the viruses.
In a personal computer built on capability patterns there would be capabilities to address books held by just those programs that I trust to use those addresses as I wish. Some of these capabilities would alert me upon access to the lists while other capabilities would access the list silently. Some would enable adding names to the list and others would only allow reading. Some would allow reading only that subset having to do with work. Alternatively I would have separate address books for separate parts of my life. Applications with a capability to one book would be oblivious to the existence of others.
CapDesk illustrates a user interface that is compatible with solving this problem.
IP connections are enough different to warrant discussion here. They are important in their own right and the pattern goes beyond communications.
Several well known scams are based on the ease of sending out IP data grams. This is the essence of unconfined computation. I run only a few programs that need to access IP. I, as user, would be willing to explicitly grant such programs categorical access to IP. It is like installing a modem on an application instead of installing in on my computer. This need not be an obscure concept. Conversely I can ask which programs have access to IP. This can be made graphical and most users will quickly see the ramifications.