Discussion of staff viewing user data.

Dec 10 23:28 UTC 2010

This item is for discussion about protocol for Grex staff looking at user's
data, specifically data that is protected from viewing by normal users.  What
are the circumstances under which staff should look at things?  Sometimes it's
legitimate; ie, if the user asks you to look at something, possibly even edit
one of his or her files (say, a shell startup file, if the user is having
problems with it).  On the other hand, reading someone's personal email is
clearly not all right under all but the most extreme circumstances (e.g.,
under court order or something like that).

The policy right now is vague; what should it be?

response 2 of 18:

Dec 11 07:09 UTC 2010

  
form above:
  
"When staff does have to look at private information, the basic
  principle is to look as narrowly as possible."
  
which for valisdation p;urposes, and as cross noted HUNDREDS of times, i do.
  

response 4 of 18:

Dec 11 16:02 UTC 2010

The way to do this without having any questions about privacy, is to
get permission from the user first.  I think it would be better to do
this than to assume reading private files is necessary.  If our current
process does not give contact information, that would be the place to
start, rather than assuming there is no other way to do things or trying
to justify such.

response 6 of 18:

Dec 11 21:03 UTC 2010

resp:4 This is another useful thing about asking for an email address in
 newuser; that information goes into a log that can be viewed by staff 
without looking at the users' files.

The process that the board adopted several years ago was straight 
forward and didn't involve any reading of any files at all (except one's
 personal email).  It works as follows:

1. The user sends email to "porters@grex.org."  That email goes into a 
ticket tracking queue managed by the "RT" software.
2. One of grex's porters "takes" that ticket in RT and sends an email to
 the user asking, "How did you hear about Grex?" 3. The user responds
with, really, whatever he or she wants. 4. The porter runs "validate
user" at the Grex command line. 5. The porter "resolves" the ticket.

That's it.  No where in there does it talk about looking at users' files
 or anything else.  No where does it talk about proactively contacting 
users.  If people want to change this process, that's the type of thing 
that needs to be discussed publicly, especially if any of those changes 
involve looking at files that are protected by the user: even the .plan 
file (granted, newuser does say that staff can see that information, but
 staff still shouldn't be poking around in people's directories without 
their permission.  I'd say that even running "finger user" as root is 
qualitatively different).  Then again, none of porters on Grex who are 
not also staff members with root access have the ability to do that.

Speaking of directories, I don't think that staff should be "checking 
up" on users with unfamiliar login names, either.  There was an incident
 last week where I ran "w" and saw a staff member reading an unusually 
named file that I happened to know was a temporary file created by the 
"pico" editor.  Thinking that was odd, I ran "ps auxwwe" and looked for 
the staffer's "more" process, then saw that the PWD environment variable
 in ps's output showed that the file was in another user's home 
directory.  The file was world readable, but a quick scan showed that it
 contained email messages the user had composed to someone else.  At
that  point, I stopped reading, but the other staffer did not.

When I confronted him about it, I was accused of alternately running a 
key logger on his sessions (not true) or somehow snooping on his tty 
(also not true).  The other staff member then went on to say that he had
 seen this user with an unfamiliar - to him - login name and wanted to 
see who he was, so he looked in his home directory, saw these strangely 
named files, and became curious as to what they were, so he read them.

There are many things wrong with this scenario, in my mind.

First, despite the fact that these files were world-readable, they 
clearly contained personal communications: this was obvious upon the 
most cursory inspection.  At that point, regardless of how curious 
someone is as to *why* those files were there, they should have stopped 
reading them.  Unless there's some compelling reason to be reading those
 files, or unless specifically asked by the user, I claim that personal 
communications like that should be strictly *off-limits* for staff 
members, even if root access is not required to view them.  It's one 
thing to stumble on them, but once you determine what they are, stop.

Second, being a system administrator on a large timesharing system 
brings with it certain privileges: having root access basically gives 
you access to anything on the machine.  However, that also brings 
greater responsibility.  Because one has that access, one needs to be 
even more careful than a non-system administrator about respecting the 
privacy of users.  There needs not only to be good judgment, but also an
 air of responsibility when it comes to user data.  Reading people's 
files when you're on staff, unless you've got a real reason to, gives 
the air of being cavalier about privacy.  This is a good way to get the 
users not to trust the staff (particularly when it was so obvious that 
that's what was happening), and right now, we need to get more people 
interested in Grex.

For a long time, the staff has had an almost paternalistic attitude 
towards the system and users.  This was okay, in the sense that it was 
meant to protect the community, but that time is past.  It's not 1991 
anymore; we're swimming in the resources we once so lacked.  Snooping 
around looking for abuse is going to drive users away and isn't going to
 help anybody.  Let's not do it.

Finally, that's just not an appropriate way to learn.  If a staff member
 has a question about Unix, they can ask one of the more knowledgeable 
staffers.  They can do a web search.  They can post in the systems 
conference.  They can email the staff mailing list.  But reading user's 
email (by the way, by my cursory glance, there was nothing in those 
files that would give any indication as to why they had funny names; I 
knew the answer, because I know how text editors work) is not an 
acceptable way to learn.

response 8 of 18:

Dec 11 21:40 UTC 2010

resp:6 Hmm; backtalk seemed to mess up the formating when I entered that
from Safari.  Weird.

response 10 of 18:

Dec 19 18:33 UTC 2010

Simply limit root access to one staffer, or two at the most.  Not every
member needs root.  anybody that worried about staff reading their email
wouldn't use email on this kind of board anyway.  Or they'd use
encryption.  Actually couldn't an encryption routine be added, i.e.:

'would you like to encrypt this file? (y/n)'

If yes then the user is prompted to put in a password, the file is
encrypted and the only person who can de-encrypt it is the one who has
the password.  Then even staff couldn't read the files.

response 12 of 18:

Dec 20 02:40 UTC 2010

resp:10 encryption won't solve the problem. root can always hack your 
key. In root you trust :p

response 14 of 18:

Dec 20 04:02 UTC 2010

A system admin could modify sshd to record users' passwords. They could
also read encrypted e-mail by snooping terminal sessions if they went to
the effort of making the necessary modifications.

The point is the only reason for a user to think they have any privacy
on a system is by trusting the system admins to restrain themselves from
violating that privacy.

And without a clear directive from the board on what staff can and can
not look at, and a staff with a reputation of adhering to that
directive, it is impossible for users to have that sort of trust in Grex.

response 16 of 18:

Dec 20 04:34 UTC 2010

So then say the encryption password has to be inputted via an offsite 
email so that no record of it exists on the system.  There has to be a way 
for users to fully protect the privacy of their files even from root, if 
they are willing to accept the risk of not being able to access the data 
themselves if they lose the pw.  How else can you protect users from 
snooping roots like TS?