Netscape Navigator allows scripts to have digital signatures attached to them. These signatures can control the level of privilege that a script is allowed to have in a web browser. This is ultimately under user control but if the user allows, the scripts can be secured at source.

The signature combines the identity of the signatory and a checksum of the content. The content cannot be modified without invalidating the checksum and hence voiding the signature.

It would be difficult to establish the exact security criteria beforehand, so Netscape Navigator forces scripts to request the privileges they need. Then, you can allow or deny the access which can be stored and mapped against the identity of the person signing the script. This means a security policy can gradually be established by training the browser to recognize and make decisions on access. Initially, no access is available but after some time, your browser preferences will contain a very sophisticated set of rules that govern the access to the secure values.

To sign your scripts, you will need additional tools and utilities. These are available from Netscape and should form part of your publishing pipeline.

An alternative is to serve your scripts separately from a secure server. Scripts served in this way will assumed to have been signed by the secure server itself.

As a way round the inconvenience of signing scripts after every minor correction, you can sign the codebase of a script. This means you can establish a security setting for scripts from a specific web server. It is slightly less secure than signing a checksum but more convenient during development. It is recommended that proper signing be used, once the script changes are less frequent and the development process is complete, the scripts will be more stable and signing will be carried out less frequently. With some automation in the publishing work flow, you may be able to sign scripts as part of the releasing procedure that your developers employ.

Your web page may contain more than one script. For signed script access control to work, all of the scripts on a page must be signed. If an unsigned script is present, it defeats the entire signing status of the whole page. Scripts can be signed by more than one person. Netscape Navigator will try and find the highest most complete coverage of the scripts in a page. Ideally it will find a particular signer who has signed all of the scripts. Other signers may have conferred a higher level of security but not on all of the scripts. The more complete coverage will prevail.

Although these fairly strict same-signer policies apply to the scripts within a window, scripts in multiple windows may operate under a slightly relaxed policy. The "same signer" policy is a variation of the "same origin" policy. Different signers cause the browser to behave as if the pages were from different origins. Both scripts may have rights to request UniversalBrowserRead access which might work around the problem.

Unsigned scripts have quite restricted access to window properties for windows that contain signed scripts. This means that untrusted and insecure scripts cannot access secure data by subverting an already trusted script.

Warnings:

• MSIE version 4 does not support the Netscape Navigator privilege model. Therefore scripts are always unprivileged. The MSIE security model is based on zones. This is a fairly coarse grained approach and simply allows scripts to be executed or not as a whole. The Netscape Navigator model allows access to be controlled object by object.

• Being so closely related to the MSIE browser, the WebTV box also does not support signed scripts.

Web-references:

http://developer.netscape.com/software/signedobj/ http://developer.netscape.com/library/documentation/signedobj/signtool/