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.
35 responses total.
Thanks for writing this, Jan. I do have one nitpick, though: I'm not comfortable putting looking at somebody's mailbox in the same category as looking at their .login. Of course we need permission to look at a mailbox, which is likely to contain lots of private information. A .login file, however, is pretty much a system file that I would assume most users just want to work. If somebody is complaining about something not working, and their .login file is the cause, I would probably just fix it.
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.
I think its a good overall statement of what we've been doing. Thanks Jan, for entering this.
This response has been erased.
Looksa like a fairly clear cut policy, looks good.
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.
This response has been erased.
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.
"User research" is definitely not the best phrase. I wasn't able to think of a really good way to phrase that. I agree idle curiosity is not sufficient reason - the reason needs to be materially related to keeping grex running and delivering good service. I also agree it's worthwhile to think in terms of devising tools to limit the "invasion". Perhaps another example will be helpful. Recently, it was determined that the copy of sshd we had on grex was seriously old, and probably had security holes in it. The first thing we did was to turn it off. The next step was to determine if it needed to be upgraded, and if so, how important this was. An informal poll amongst staff produced the opinion that *only* staff used it. If this was true, then fixing sshd is something that we could have classified as "low priority" and put off. However, upon further investigation, including nosing through non-publically readable log files, and looking to see how many people had .ssh/ directories, and which files were in those directories, it became clear that a small but significant number of non-staff people *were* using ssh to access grex. Sshd, accordingly, was fixed much sooner than would otherwise have been the case. There is no way we could have determined this without reviewing non-public information, including some that was stored in private directories. I'd like to think that the resulting small invasion of user's privacy was worth having sshd fixed sooner.
I would also. I use ssh all the time for everything :)
I'm *very* impressed with #0. I like the cautious approach, and the
use of "try to", "should", and "may" instead of such words like
"shall" and "must". Perhaps the first sentence of mdw's #6 should
be included to make sure that our staff won't feel handcuffed in
a bizarre situation.
Nice work!
Yes..... Quite PC ;-)
I haven't updated the document to reflect the comments here by Marcus and others, and I don't know when and if I'll get around to that. Probably for the time being this whole item and all responses should be viewed as the best description of what our policy is.
This response has been erased.
I don't either. I'm leaning ever so slightly toward no, for no particular reason that I can think of at the moment.
I don't see why the board has to act on it.
I agree. It's not a "policy". It's just a description of what we do, done partly to help users understand what goes on here, and partly to help us clarify our thinking on this. If any big controversy had erupted over any part of this, then maybe the board would have to consider it, but it seems not to be controversial, so I don't think there is any decision to make on this.
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.
I like waht John said in principle. However, I worry that such a stated policy could end up as lawsuit fodder if there were a disagreement about what is needed for system performance or security reasons.
I don't see the need for Board action.
This response has been erased.
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.
While it is the *right* of the Board to establish these guidelines, I would prefer to see them set by the staff so as not to "lock in" what staff may/may not do in an unforeseen circumstance.
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)
Policies or guidelines adopted only by staff are not *Grex* policies or guidelines. I believe that the principles embodied in the suggested guidelines are sufficiently important that they should have the Grex imprimatur.
If we want to adapt this as a policy, it first needs a lot more work. Inconsistancies in voice are the least if its problems. From my viewpoint, it isn't a high enough priority. Working on Backtalk or the 501(c)3 paperwork seem more critical to me right now. If someone wants to work on it to tighten up the writing and include some of the commentary that has appeared in this item, then that's fine with me. I'm not convinced the board needs to formally adopt this, but if it does, some work needs to be done first.
I think it would be reasonable for the board to adopt a statement of principle to the effect that in general it respects the privacy of users' depermitted files and email, and to request that the staff keep it and the users informed of the kinds of circumstances that allow exceptions. That could be a very short, simple motion, and items like this would be the mechanism by which users are kept informed.
One of the concerns at the board meeting was that if we adopt a policy saying what we will and won't do with users' files, it could leave us open to lawsuits if there were a disagreement on the meaning of the policy and what we had promised to do. I would like to get a legal opinion on any policy of this nature that we vote on.
Call them guidelines, and there are no legal questions.
I'd like something like what John describes in #27. It would be best to have the specific wording of such a statement of principle worked out in advance of the board meeting and discussed on-line. Trying to word such a thing during the meeting would be serious waste of time and somewhat perilous.
As a Board member on M-Net, I would strongly suggest that this type of thing be kept at the *staff* level. 8-)
i agree with not making 'policy' out of this. stating a 'guideline' or enunciating a 'general approach' akin to remmers' #18 is sufficient.
Maybe the board could affirm that it is an interresting and useful set of guidlines for staff to use to police staff action? That ought to make clear that staff has the freedom to act as needed, and still give others the guidlines that they seek.
The suggested guidelines leave the staff with the flexibility necessary, or if they don't, flexibility can be increased. In any event, though, these should be *grex* guidelines, not the private ones of staff. Affirming "an intersting and useful set of guidelines" is done by the board *adopting* the guidelines. I don't think leaving them in never-never land is the way to proceed.
re 34: Agreed.
You have several choices: