For the language of the cache applet, we choose Java because of the large amount of research efforts invested on Java security. Its platform-independence and built-in security mechanisms contribute to our decision. In the Active Cache environment, the Java security problem is simplified by the fact that the applet is used for only one purpose: processing a user request at the proxy site and constructing a response. Thus, the java.io libraries, the process/thread management libraries and other system-related libraries are simply absent from the cache applet's run-time environment to prevent the security problems associated with their use.
The security interface of the cache applets is quite simple: all an applet can do is to ask whether some objects exist in the cache, read and write the objects, and communicate with the server where the applet comes from. Furthermore, accesses to objects are restricted as described in Section 2.
The restrictions are designed with the assumption that each server is a security entity, applets from the same server trust each other, and applets from different servers do not cooperate. Thus, an applet has read access to all information in documents and objects from the same server. However, each applet can only manipulate the objects that it creates or is attached to. We impose this constraint for simplicity and safety. The flexibility of the scheme is not compromised, because one applet can always be attached to many documents.
The restrictions are enforced by two mechanisms. The ActiveProxy class implements the constraints. Java's type safety and run-time mechanisms prevent applets from bypassing the ActiveProxy class and gaining raw access to information and resources. Recent research results have significantly improved the robustness of Java's run-time environments (11, 11). Thus, we rely on the existing mechanisms to force the applet to use the ActiveProxy class to access its objects as well as the computation and networking resources. The ActiveProxy class is also the place where we keep track of resources consumed by each applet.
In addition, we use static examination of the classes and functions called in the cache applet code to prevent manipulations of Java ``class'' methods to circumvent our restrictions. When the cache applet is first loaded, the proxy examines the symbol table to check for ``class'' method calls and calls to unloaded packages. If the applet cannot pass the inspection, the proxy will not cache the reply.