November 4, 1994
TO: D. Leith
FROM: J. Winters and the Rest of the WWW Technical Committee
SUBJECT: Privacy and Confidentiality Issues in SLAC WWW Information
cc: C. Dickens
Some information like confidential enterprise data and papers in progress are generally too sensitive to be put on the Web at all. Other information like accelerator operations logs and The Interaction Point may most appropriately be restricted to those logged in from the SLAC Internet address. However, material that is useful to distribute should generally be made available to the global WWW community. Lab management should encourage information owners to contribute material to the Web and maintain it. This sharing will help restore a collegial atmosphere to SLAC computing.
Institutional responsibility for putting information on the Web, specifying its accessibility (SLACwide or global), and removing it lies with the group leaders or their designates. Group leaders must also authorize all WWW servers because with current technology, they can present serious security issues if incorrectly configured.
Individual information providers are accountable for materials they place on the Web. Before installing their first item, providers must have a discussion with their group leaders on privacy issues. For subsequent items providers must interrogate themselves about the consequences of making the material available. Group leaders can modify the status of any item. To promote informed decisions, SLAC must proactively develop a common view of what types of information need what kinds of privacy restrictions and publicize the model through presentations, discussions, and on-line and printed documents. This privacy proposal tries to strike a balance between making SLAC information available on the Web in a timely and minimally onerous fashion while meeting SLAC's needs to restrict access to a subset of its information. The model may well evolve as WWW technology improves. To implement the proposal, more resources must be dedicated to SLAC's WWW effort.
N.B.: This document only addresses problems pertaining to the privacy and confidentiality of SLAC information on the Web. (These are hereinafter collectively referred to as "privacy" issues.) To implement the proposal, extra resources must be dedicated to WWW. Some of these will be used to develop related documents that treat WWW security, page creation standards and procedures, server establishment, and other topics. Without proper resources people will bypass the rules and procedures that do exist.
WWW was conceived at CERN by Tim Berners-Lee in 1989 and has spread very rapidly around the world in the past year. One recent estimate put growth in bytes retrieved at 1% per day!* Although WWW started as a tool for HEP collaboration, it is now being used not only by research laboratories and universities, but also by businesses, governments, not-for-profit organizations, and even individuals.
Since its inception SLAC has practiced an open information policy as part of its computer environment. Most on-line material has been readable by anyone who had computing privileges here. (In VM, that meant a READ password of ALL on most minidisks.)
The Web provides an opportunity for SLAC to extend its open information environment to people and groups around the world. This occasion also requires new decisions about the public or private nature of individual documents.
* Matthew Gray, Web Server Maintainer, Student Information Processing Board, MIT.
SLAC must address:
However, we also need to be concerned about issues of privacy. Information may be irrelevant, embarrassing, misunderstood, or even dangerous if read by the wrong audience.
Access to information on WWW may be granted variously. When considering making files available, document owners should initially consider the questions and answers below. These do not limit all relevant inquiry since only the document owners, who know their material best, can form the most appropriate set of questions.
Given current WWW technology, restriction to a particular group at SLAC is impossible to implement securely, so SLAC information that must have such limited access should not be put on the Web at all.
Enterprise data like personnel, financial, and salary information and drafts of papers in progress generally fall into this category. Serious consideration should also be given before installing preliminary hardware and software evaluations, vacation schedules, and some pager numbers.
Restriction can currently be handled securely by limiting access to users whose Internet addresses match a portion of SLAC's Internet address (IP number string). Accelerator Operations logs, The Interaction Point, the Stores catalogue, and problem reports like PROBTRAK are common examples of this category.
Given current WWW technology, restriction to a group of collaborators at SLAC and elsewhere is impossible to implement securely. Casual browsing may be discouraged by parsimonious use of passwords for particular files or file hierarchies, but their use creates an additional load on those responsible for Web information and software.
Some experiment planning and discussion documents fit into this category.
The Beam Line, SLAC Pubs, preprints, the "white pages" of the SLAC phone book, and SCS documents for users are common examples of this category.
These include questions about the consequences of making their pages globally available. Will publicizing this information hurt someone? Infringe on the safety of the Lab? Betray plans of the Lab before their time? Make the Lab look unprofessional? Disseminate research results prematurely? Present working documents without necessary context? Broadcast incomplete drafts? And is this information appropriate for reading by some but not all people on the Web?
SCS will provide a document on risks, standards, conventions, procedures, and software for installing and maintaining WWW servers. Before setting a server up, the owner must register centrally each one. The exact procedure is still to be determined but will include assignment of a unique name according to standard conventions.
To implement the proposal the following steps should be taken:
The model is a collaborative work in progress. As the technology improves in server code, tools, etc., it may well prove beneficial to iterate the model to take advantage of these advances.