The End User's View

In current browsers, the user's choice with respect to JavaScript is truly limited. He/she can either turn JavaScript completely off or on for all sites.

We introduce the notion of a security policy for JavaScript. From the user's perspective, a security policy is a bundled set of preferences with respect to the following capabilities given to scripts that execute on the user's machine:

• Access to reflected objects: A script has access to a number of objects in the JavaScript hierarchy. For example, document.referrer indicates the page from which the user arrived at the current page, and navigator.platform indicates the operating system on the user's machine. A policy aggregates access permissions to these property policies of all reflected objects.
• Access to external interfaces: A script also has access to a number of external interfaces, such as ftp (ftp: URL) and e-mail (mailto: URL) protocols. It also has access to calls in the Java language, through which it can capture the user's IP address, for example (by calling java.net.InetAddress). Again a policy aggregates access permissions to all external interfaces.
• Actions in the event of access violations: A policy also specifies the action to take by the JavaScript interpreter if a script attempts to violate the current policy.

Most end users will not want to be bothered with such low-level details as the exact specification of a policy. Thus we offer a small number of increasingly strict predefined policies from which the user can pick; see Figure . The chosen policy, the global security policy, will be in effect whenever the user starts visiting Web sites. A user can also pick predefined policies to be in effect only for specific sites (site-specific security policy). The user may specify either a hostname or a specific URL for which this policy should be in effect; see Figure . For example, it makes sense to allow a more lenient policy when browsing within an intranet than when accessing the external Internet. In fact, as part of an overall corporate security policy, the employees' browsers can be initialized with a strict policy for external sites and a liberal policy for internal sites.

  

Figure: User Interface for Setting Browser Security Policy

  

Figure: User Interface for Setting Site-Specific Security Policies

As for many security tools (see, e.g., [WT98,ZS96]), it is hard to design a user interface that, on the one hand, does not restrict the power user from fully exploiting the provided functionality, and, on the other hand, does not confuse the average user, the confusion leading to possible unwanted security implications. For example, [WT98] call the problem of choosing access rules and policies the abstraction property and observe that such notions are often alien and unintuitive to a wider user population. Another factor mentioned in [WT98] is that users get little feedback when they make an error in configuring security aspects. Consequently, we think it is very important that reasonable default settings be chosen for the average user and that good representative examples be chosen to explain in which situations a given policy is adequate.

We envision that corporate administrators will want to incorporate policy management (creating and updating policies, installing new policies on each desktop's browser, etc.) via some sort of directory service integration (e.g., LDAP-like solution). Home users might also want to have tools to easily create or download (from certifiably trusted site) and then install new policies on their desktop. Thus, policy management and its tools seem like a fruitful area of further work.