SIPB LOG NON-RETENTION POLICY (draft)

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119.

Section 1. A SIPB service targeted broadly to the MIT 
community, or larger, must not privately keep MIT user- or 
MIT computer-identifiable (that is, the log entry of 
activity which can be identifiable to a single MIT 
individual or private MIT computer) logs of normal operation 
of the service unless it has permission from the Board or 
that MIT individual, except if permitted below.

Section 1a. Logs which are required to be kept by law or by
MIT IS&T policy are exempt from this policy.  Service
maintainers should notify users that they are keeping logs
under these circumstances.

Section 2. For unforeseen emergency situations, such logs may 
be kept for as long as eight days with the permission of the 
SIPB EC, and the EC may retroactively extend permission to 
24-hours prior to notification of the EC.  Service 
maintainers should notify a broad audience (for example, 
announcing over zephyr or e-mail) that such an emergency 
situation is in effect, and that such logs are being kept.

Section 3. "Private" logs generally mean logs that are only 
accessible to maintainers of the service.  Public logs, 
accessible to all users of the service, for example 
linerva's /var/log/wtmp, are permitted.  Service maintainers 
should describe what public logs are being kept, and how 
users may access them.  By distinguishing between public and 
private logs and permitting public ones, we achieve 
transparency as well as avoid situations where a service 
maintainer is pressured to disclose the contents of the 
private logs or uses the contents of the private logs for 
personal gain.

Section 3a. If a user's activity is ostensibly just to send
a message to a recipient, and the user can view the contents
of the message before it is sent, the recipient (a SIPB
service or service maintainer) may privately log the
message.  One example of this form of logging are discuss
archives of mailing lists.

Section 4. We distinguish between logs of "normal" operation 
and "exceptional" operation.  Logs of exceptional operation, 
for example of someone trying to hack the service, or logs 
of a crash or other failure of the service, or changes to 
the service done by the service maintainers (for example, 
the "sudo" log), may be privately kept.  Service maintainers 
should describe what sorts of general user- or 
computer-identifiable exceptional operation are being 
logged.

Section 5. Logs of normal operation of activities by a user
for which the log is readable by that user (an example of
such a log, is .bash_history) are permitted.
Service maintainers should describe what is being logged and
how a user may access his or her log.  This achieves
transparency so that the user knows exactly what is being
logged so can choose whether or not to use the service.
However, the Board should bear in mind that the "aggregate"
of all the user logs, or a particular "other" user's log,
which is likely only accessible to the service maintainers,
may be valuable, exposing service maintainers to pressure to
disclose the contents of the logs.  The Board should also
bear in mind that users may not be able to adequately judge
how dangerous the user's activity log is or might become in
the future to the user if the log is disclosed.

Note that .bash_history is only an example of a
user-readable log.  .bash_history is a feature of Athena,
not a SIPB service, so this policy is not applicable to it.
Also, .bash_history has the additional features that the
user may clear it, edit it, or turn off logging entirely.
Service maintainers may implement such features for their
user-readable logs.

Section 6. By forbidding private logs entirely, instead of 
specifying a maximum time period that logs may be retained, 
we avoid the problem of securely deleting such logs after 
the time period has expired.  (The Board may grant such a 
log retention exception to a particular service if it feels 
that the service benefits from limited logs, and that the 
service has measures in place to securely and thoroughly 
destroy logs older than the retention period.)

Section 7. If a SIPB service itself hosts a non-SIPB 
service, for example scripts or XVM, this policy only covers 
the SIPB-maintained portion of the service, and does not 
extend down to the sub-service hosted by the SIPB service.

Section 8. This policy applies to "publicly accessible,
released" SIPB services targeted broadly to the MIT
community, or larger.  "Limited access" or "beta" SIPB
services, which may still be in their testing or development
stages are exempt from this policy, as logs may be useful
for the testing and development of the service.

"Limited access" generally means services for which users
and the service maintainer are not strangers to each other,
a personal relationship exists between users and the service
maintainer, and users feel they have some reason they can
trust the service maintainer with the user-identifiable
information the service maintainer is logging about them.
Multics may be an example of such a service.

Section 9. This policy is scoped to protect the privacy of
members of the MIT community.  Service maintainers also
should not log activities of users and computers beyond the
MIT community.  However, the practice is permitted, and may
be useful, for example, if a SIPB service wished to survey
the behaviors of internet users as a whole.

Section 10. This policy only serves as a baseline for SIPB 
services.  Individual services may adopt stricter policies 
(for example, eliminating logs permitted by Sections 4 or 5, 
or employing cryptographic protections such as requiring the 
keys of two service maintainers to access the aggregate user 
log, or permitting users to clear their user log), but not 
looser ones.

Section 11. This policy takes effect in one month, with the 
exception of the following SIPB services which are granted 
the specified extension in order to comply with the policy: 
[...nominate here your favorite SIPB service with slow 
maintainers or for which modifying the service to comply 
with this policy is especially difficult].