However, an important issue is confinement of privileges [26]. It should not generally be possible for one program to delegate a privilege to another program (that right should also be mediated by the system). This is the fundamental flaw in an unmodified capability system; two programs which can communicate object references can share their capabilities without system mediation. This means that any code which is granted a capability must be trusted to care for it properly. In a mobile code system, the number of such trusted programs is unbounded. Thus, it may be impossible to ever trust a simple capability system. Likewise, mechanisms must be in place to revoke a capability after it is granted. Many extensions to capabilities have been proposed to address these concerns. Kain and Landwehr [23] propose a taxonomy for extensions and survey many systems which implement them.
Fundamentally, extended capability systems must either place restrictions on how capabilities can be used, or must place restrictions on how capabilities can be shared. Some systems, such as ICAP [15], make capabilities aware of ``who'' called them; they can know who they belong to and become useless to anyone else. The IBM System/38 [4] associates optional access control lists with its capabilities, accomplishing the same purpose. Other systems use hardware mechanisms to block the sharing of capabilities [24]. For Java, any such technique would be problematic. To make a capability aware of who is calling it, a certain level of introspection into the call stack must be available. To make a capability object unshareable, you must either remove its class from the name space of potential attackers, or block all communication channels that could be used for an authorized program to leak it (either blocking all inter-program memory-sharing or creating a complex system of capability-sharing groups).
Name space management can potentially have good confinement properties. For example, if a program attempts to give an open FileInputStream to another program which is forbidden access to the file system, the receiving program will not be able to see the FileInputStream class. Unfortunately, it could still likely see InputStream (the superclass of FileInputStream), which has all the necessary methods to use the object. If InputStream were also hidden, then networking code would break, as it also uses InputStream. This problem could possibly be addressed by judicious redesign of the Java class libraries.
Stack introspection has excellent confinement. Because the stack annotations are not directly accessible by a program, they can neither be passed to nor stolen by another program. The only way to propagate stack annotations is through method calls, and every subsequent method must also be granted sufficient privilege to use the stack annotation. The system's access control matrix can thus be thought of as mediating delegation rights for privileges. Because the access matrix is consulted both at creation and at use of privileges, privileges are limited to code which is authorized to use them.