Grex Statement on Root Use and User Privacy

Jun 8 13:39 UTC 1997

The Grex staff was asked to try to formulate a policy for when it is or is
not OK to use root to look at files or mail belonging to an individual users.
The discussion at the staff meeting was more descriptive than perscriptive.
Staff members described situations where they used root to look at mail or
look at files.  I've expanded on their comments to produce this document which
has been circulated among the staff and seems to be an acceptable description
of how roots on Grex handle privacy issues.

These situations *always* require judgement.  There are some things that are
clearly OK, and some things that are clearly not, but there are wide gray
areas, where a staff member must use judgement.

Grex's situation is in some ways unique:
  - Many users are hard to identify with certainty.
  - We have more than the usual number of hostile users.
  - Staff is volunteer, and does not always have time to handle crises.

There are several classes of problems that may require a staff member to
look at a user's mail or files:

  - Lost Passwords:  Every day, we have several users who forget their
    passwords and ask for help.  Before resetting a password and mailing
    the new password out to someone, we need to be reasonably sure that
    the person we send the password to is the person who originally created
    the account.  Since many people give very little real information when
    they create an account, this can be challenging.

    In all cases, we try first to authenticate the person using public
    information (.plan files, .forward files, web pages, etc) or information
    explicitly given to staff (the newuser log files).  We don't go further
    unless the user expresses some urgent desire to get back on the account
    (usually to access email sent there).  Then, if the staff member feels
    inclined to believe that the user is who he claim and if that user
    requests it, a staff member may check to see if non-publically readable
    files have the contents the user says they have, or if there are other
    clues to the owner's identity on the account.

    When a staff member does this, it is important to keep the search as
    narrow as possible, and not to repeat or reproduce any information found,
    no matter how trivial, particularly not to the presumed "owner" of the
    account.

  - User Assistance:  Sometimes a user will have problems with their account,
    such as a screwed up .login or mailbox file.  In such cases, users
    sometimes request a root to go in and fix it for them, either because
    their accounts are so broken that they can't access it or because they
    lack the knowledge to do it themselves.

    This is one of the clearest of the OK situations, but some caution is
    still required.  The staff member should get *explicit* permission from
    the user, and should make clear to the user what kinds of stuff the
    staff member is likely to be looking at in the course of making repairs.
    The staff member should be reasonably confident that this is the real
    owner of the account, should try to look only at what needs to be looked
    at, and should not repeat or reproduce anything seen.

  - Users causing problems on Grex:  Some users cause problems on the system
    by doing things like running programs that place a heavy load on the
    system or attempting to break into the system.  When staff notices such
    things (which may be things with obvious effects on the usuability of
    the system, or may just be subtle things that show up in our logs), it
    is often somewhat urgent to find and fix the problem.  This may require
    looking into a user's directory without any form of permission from the
    user.

    NOTE:  By "causing problems" we do mean technical problems, not social
    problems.  No degree of rudeness and unpleasantness would justify any
    staff investigation of a user's private files or mail.  Only actions that
    appear to undermine system security or performance may do so.

    In many cases it is unclear if the user is causing problems deliberately
    or accidentally.  If the user is running a program that slows down the
    system, for example, a staff member may have to look at the program to
    try to determine if it could be the cause of a problem, and if it is
    deliberately so or accidentally so.  When we look at such a program, the
    goal should be exclusively to determine its intent and its impact on Grex.
    We shouldn't be "borrowing" copies (exception:  Grex staffers sometimes
    collect copies of programs designed to crash or crack the system for use
    in testing our system security), and we shouldn't be repeating any
    detailed information about the program to anyone except other staffers.

    In cases where the problem appears accidental, we generally try to contact
    the user and advise him on how to avoid the problem in the future. Details
    of what we may have seen are not repeated to anyone except other staffers.

    In cases where the problem appears deliberate, we may look more broadly
    through the user's files to try to get a complete picture of what he may
    have been doing.  We quite often compile relevant information and pass it
    on to administrators of the sites the user uses to connect to us, and to
    other sites that may have been compromised by the user.  Copies are likely
    to go to national organizations like CERT that track security problems.
    We may leave such accounts active, and may do more than the usual amount
    of monitoring of the activities of such users.  However, even in these
    situations, we try to keep information unconnected with the problem
    private.

  - Users causing problems on other systems:  We sometimes get complaints
    about users from our system causing problems on other systems on the
    internet.  All such complaints are taken with a degree of skepticism.
    We want to try to figure out who is doing the complaining, and we want
    to have enough detail to judge the validity of the complaint.  We do not
    necessarily launch an investigation every time someone somewhere
    complains.

    Among the most common complaints are those about users sending email that
    bothers someone.  Staff will readily help people figure out if the
    email really came from Grex, and will give out information about Grex
    accounts that is publically accessible to any Grexer (NOTE: this includes
    records of from where that user connects to Grex).  We do not look into
    any private information in response to such complaints.

    Complaints of Grex users attempting to crack other systems may trigger
    a more thorough investigation of their accounts on Grex, along the lines
    described in the previous section.  

  - Cooperation with proper authorities:  If we are contacted by law
    enforcement officials we will cooperate with any legal search for
    information on Grex.  We will freely give out any public information
    that is already available to any Grex user (including records of when
    people logged in and from where they did so) and we will assist in
    the understanding and interpretation of such information.  Private
    information, such as the contents of a user's personal files and mail,
    would be made available only if a valid search warrant were provided.

    We will not normally try to act on judgements on issues like libel and
    slander.  People with problems of that sort should work through the
    proper legal authorities, and we will cooperate with those authorities.

Though generally we try to keep anything we see when looking at private files
secret, we might someday see something that we feel must be reported to the
authorities.  This would be a difficult decision.  We might well choose to
report it, but have no policy on this at this time.

response 2 of 35:

Jun 8 16:49 UTC 1997

 I think that .login files should be considered at least somewhat 
private, since there may be a watch program (with a list of logins).  
Aside from that, I think that a .login  file is not as private as email. 

Overall, I think that these guidelines are very good.

response 6 of 35:

Jun 11 07:25 UTC 1997

One thing that was pointed out, but not in time to reach this document,
was that this is not an exhaustive list of *all* the reasons staff might
need to look at user files, only the *most common*.  Other cases that
could be mentioned are "system problems", "confused staff", and "user
research".

System problems include things like the mail queue is somehow flooded,
and the disk gets corrupted.  If the queue fills up, we might have to
look at items in the queue to see why the queue filled up, and in some
cases, we might well remove items from the outbound queue - this *could*
be the result of a "problem user", but it could also be the result of a
"dead remote system" - we've done this in the past with mail to m-net,
when m-net was down for an extended time (this became such a common
problem that today, we send *all* mail destined for m-net to m-net's
ISP.)  A seriously corrupted disk is another possibility that might
result in our seeing user files.  If something serious were to happen to
/a, our first choice would be to attempt to recover data off this disk,
if at all possible.  Depending on the nature of the damage, and how hard
we work, we might well have a *need* to see user files, to repair the
damage.

"Confused" staff is another possibility.  When things go wrong, we don't
always know if it's a malicious user on grex, elsewhere, the system
software acting up, or a hardware bug.  To narrow down the
possibilities, we might well examine user files or other resources, even
though the problem turns out ultimately to be something completely
different.

Yet another could be described as "user research".  We don't always
*know* how everyone really uses grex.  In order to best support users,
we sometimes have to be more nosy than we might otherwise care to be.
For instance, one issue that recently came up is that we will soon be
replacing /usr/ucb/mail.  The current mail program implements an option
"set replyall".  The new replacement implements a similar, but different
option, "set Replyall".  We don't know how many people attempt to use
either of these options, but if we did, that might well influence our
decision as to how to handle migrating from the old to the new version.
(In this particular case, we will probably end up not collecting this
data, simply because there are probably 14,000 .mailrc's we'd have to
examine, and the value of the resulting data is probably not worth the
effort to collect it.) In some cases, we might just use the results of
such research "internally" to better support software, in other cases,
we might well want to "publish" the results of such research here in
co-op, (in such a fashion as to statistically hide any one person's
identity), so that people here in co-op could make better decisions.
(For instance, we might report something like "there were 1532 .c files
in 279 user accounts, out of 15237 user accounts total.")

Even this is not necessarily an exhaustive list of the cases where staff
might feel they have a legitimate need to see user files.  The only
general phrasing I can think of is that staff works to preserve user
privacy to the extent reasonable, while still delivering the best
feasible service to users.  (where "reasonable" and "feasible" indicate
that these are grey areas that inevitably boil down to a question of
individual judgement.) I think everyone on staff would agree that anyone
who had any information where privacy was "real important", *should* not
store or transport that information on grex.  That's because the *real*
purpose of grex is *not* as a private information repository, but a
public place to *share* information - and there are many places where we
have already made many tradeoffs to facilitate public sharing at the
expense of true privacy.

response 8 of 35:

Jun 11 17:30 UTC 1997

Also, such user research would, by preference, be done by a robot, not by hand.
So we'd create a little program that would look through people's .mailrc files
and count how many had "set replyall" in them.  This way we wouldn't see any
thing else they might have in their .mailrc files (it is possible to have
some private information in there, notibly mail aliases).

The basic principle to apply here is to look as narrowly as possible.  Using
a robot means that we find out how many users use that command, and maybe
which users they are (so we can send mail to them advising them of a change),
but we don't see anything else that may be in that file.  That's a general
idea that applies whenever we look at private files -- when possible, we
try to use tools like "grep" to pick out only the information we need and
not look at everything.  Even when we must look at the whole file, we should
try to apply mental filters -- get the information you need, don't go reading
everything even if it is up on your screen.

As always, there is a lot of judgement required here.  Pretty clearly
looking if a user uses "set replyall" is less of an invasion of privacy than
looking at what mail aliases he has.  But there is always danger that our
common-sense understanding of what people might consider private doesn't
necessarily match their own feelings.  We have to try to err on the side of
caution, and we have to weigh the importance of getting the information we
want against the degree of the invasion of privacy.

I don't think we will ever be able to produce a complete document describing
how to deal with this issue.  I think thinking about it is helpful.

response 10 of 35:

Jun 13 13:12 UTC 1997

I would also.  I use ssh all the time for everything :)

response 12 of 35:

Jun 14 12:16 UTC 1997

Yes..... Quite PC  ;-)

response 16 of 35:

Jun 21 04:32 UTC 1997

   I don't see why the board has to act on it.

response 18 of 35:

Jun 23 13:52 UTC 1997

I guess I would like to see the board take some kind of
official pro-privacy position, something along the lines of
"Grex respects in principal the privacy of users' personal
depermitted files. Agents of Grex will not access such files
without the owner's explicit permission, except as needed for
system performance or security reasons."

I think that the list enumerated by Jan and others is a pretty
good description of what the exceptions are.

Issues of privacy, access to personal financial records etc. on
the internet is getting to be a big concern. It would be nice
to see Grex take a pro-privacy stand, especially since on so
many sites, the prevailing rule seems to be that users' personal
data is fair game for access and exploitation.

response 20 of 35:

Jun 24 18:23 UTC 1997

I don't see the need for Board action.

response 22 of 35:

Jul 2 01:16 UTC 1997

I recommend that the board formally adopt this policy after it is polished
for consistent wording. I recommend this as the policy sets down
guidelines for root staff, who are appointed by board action. This is, in
effect, part of their job description, which it is clearly the right of
the board to establish. 

The polishing needed is to speak in consistent voices. The above draft is
written partly in the first person plural ("We..."), partly in the third
person plural ("Staff will..") and partly in the third person singular ("A
staff member....."). The passive voice is also used. I suggest that the
first person plural not be used (it does not define who "we" are), while
the others can be employed depending on the circumstances. Much of the
policy is already stated as instructions and suggestions, which is a good
choice, when given to new root staff.

response 24 of 35:

Jul 2 15:31 UTC 1997

Any policy adopted by the board could always contain a caveat
that would avoid undesirable "locking in". Perhaps some language
such as "We recognize that circumstances unforseen by these
guidelines..."  (etc., I'll let somebody else finish the
sentence)