The browser has taken over many of the tasks of an operating system. It is becoming the place where external agents of others come to your machine to do their job. This job may not be one that you would approve of. You must trust browser plug-ins but you are at liberty to remove them; they don't come automatically. Even when you trust them they are somewhat at the mercy of the browser and cannot do the right thing by you unless the browser performs correctly. But just what is "correct"?

When someone pointed out a bad thing that browser could do to me recently I had to admit that I had no idea whether the designers of browsers would have thought it their duty to prevent this. I decided to try to capture, ex post facto, what it was that I expected a browser to do for me. Java, JavaScript, plug-ins, ActiveX controls each present their distinctive problems. I will adopt the term Active Content in this note for these varieties of guest code.

Even before active content there are some plausible security principles. You might imagine that visiting one site is sensible only to that site. You might further imagine that the sites learns only which pages were fetched. Some might be so naïve as to imagine that the web site cannot associate two different page fetches as being from the same user. Even without the publicity about cookies they should not have expected this for sites must know where to send the page's content and that will presumably have some consistency between requests no matter what the transport mechanism. The referrer field of the GET method tells a site which page at another site held the URL for the accessed page. This violates the rule that a site learns only which pages are fetched. If site X has a page with a link to a page at site Y then Y will learn that the user came from X. On the other hand X and Y could have conspired to gather this information even without the browser's referrer function as follows: X sends a short message to Y each time it delivers a page with a link to Y; the message includes the IP address of the browser to which the page was delivered. If Y gets a request shortly thereafter, it learns what it would learn with the referrer function. A simpler collusion is for X to include in the URL data after the "?" identifying X to Y. Browser security cannot protect you from collusion between sites.

One simple model for active content is as a mere extension of the behavior at the web site that you are visiting. In this view you trust or distrust that site according to external considerations and would like to think of the active content as merely site behavior on an extension cord. The active content should be able to do just what it could do if it were acting at home except for issues of latency and bandwidth. The Java sandbox adopted this goal.

Browsers are applications and applications, for Mac and Windows are traditionally implemented to instantiate concurrent instances in the same address space. By this I mean that if I have multiple word processor documents open at once, their state resides in the same address space along with the application code that defines their behavior. When browsers implement behavior interpretively, thus delivering active content, the same address space is shared. Isolation that is provided by the OS does not help active content insulated from other state. The various interpretive languages each attempt to limit the actions taken by the guest code.

There is a demo page for Netscape's signed object technology. Its text indicates that I must grant the applet access to all of my files, after which it promises that the applet will access only one. Just now with Netscape 7.0 on MacOS 9.0.4 the applet crashed before showing the first dialog box.