response 91 of 110:

Sep 10 00:47 UTC 2003

Imposter

response 93 of 110:

Sep 10 04:06 UTC 2003

Staff doesn't in general do a lot of warnings.  During that last hours, I
deleted files from probably 500 users, and nuked maybe 100 accounts.  I
didn't warn any of them.  In most cases, I took only the briefest look at
what they had.  If they had a big file named psybnc.tgz, I nuked it without
even bothering to check if it a copy of psybnc, rather than something
entirely innocent.  I did manage to free up a lot of diskspace though.

I used to be a lot more careful about these things.  I'd check things
carefully, send warnings, follow up on stuff.  Not any more.  Too much
crap and too little time.

I don't actually want to send 500 emails to various user telling them that
psybnc is not permitted on Grex.  I don't want to read 500 replies.  I don't
want to keep track of which users have been warned.  Sorry, no deal.  If
you leave a copy of psybnc on your account, I'll probably just delete it,
but I'll lock the account if it looks to me like they know this isn't
allowed (eg, if they stick it in a directory named ... or ' ' or something).
If they have exploits on the account, I'll nuke it.  I don't care if they
tried to use them or not.

When cleaning up disk space, I give people the fairest assessment that I can
give in 30 seconds.  I'm probably not wrong often.

You want us to send warnings to a user if they start doing stupid stuff?
I think you have no concept of the shear numbers of people doing stupid stuff
on Grex.  The case of setting your mail to forward to some other user is
in some way even more dubious than some of the others.  I could remove the
user's .forward file, and send him email, but I could hardly assume that
a person who set up all his Grex mail to forward elsewhere is going to
log onto Grex to read his mail.  Where should I send the warning?

Yeah, we probably could have gotten a warning to polytarp, but you want us
to send warnings as a matter of policy.  99.9% of the time, we don't know
the users doing this.  How do we warn them?

Should the rule be different for users we know?

Processing staff mail and cleaning up the disks aren't exactly huge amounts
of fun.  Do you think you'll improve the way these jobs are getting done
by passing some policy mandating that they be done in a way that doesn't
make sense to the people doing them?  Do enough of that, and they'll fire
themselves.

The staffers are all sensible people.  If you have sensible complaints and
sensible suggestions we'll handle them.  If you want to bring a policy up
for vote, go ahead.  Just don't expect it to pass or anything.

response 95 of 110:

Sep 10 07:27 UTC 2003

Really not worth explaining so much to someone who is just killing time.

response 97 of 110:

Sep 10 20:08 UTC 2003

Re #89: Um, no.

response 99 of 110:

Sep 13 20:16 UTC 2003

What a three ring circus.

response 101 of 110:

Sep 14 00:12 UTC 2003

Dah?  Do you read anything other than your own responses?

response 103 of 110:

Sep 18 00:53 UTC 2003

Actually, can I ask for jp2's to be reset?  PLEASE?!?! :)

response 105 of 110:

Sep 18 02:19 UTC 2003

That was funny, on a very weird level

response 107 of 110:

Sep 23 08:26 UTC 2003

There's actually two things here; our normal response to routine
problems, and our response to exceptions.  Our normal response to
routine matters is highly oriented around what usually seems to resolve
the problem 99% of the time.  These are generally pretty boring, even to
the most anal of staff.  They aren't always the things we'd like to do,
but well, that's life.  For the exceptions, our policy has always been
that we don't want any more rules to constrain what we do than
necessary.  Our goal here, after all, is to keep grex running as a
useful service, and it would be irresponsible of us to follow rules that
do not serve that purpose.  Privacy here is something of a red herring.
Pretty much anything people do on grex is at least potentially visible
to staff, if only by accident.  ECPA makes this an explicit right in the
case of problems, with various safeguards and limitations.  People who
attempt to hack the problem resolution process pretty much at one stroke
define themselves to be an exception to both the normal rules process we
follow here on grex and to the normal expectation of privacy defined
under ECPA.  The surprising thing here is that the normal rules were
still such a reasonable and useful response to a non-normal situation.

I'm sure polytarp already knows this, but I may as well state this for
the record: staff people on grex already have the ability to see
anything on grex without a user's password.  That's just the way root
works on Unix.  Material stored on grex is also at least potentially
vulnerable to inspection by various other bodies, using various legal
and illegal methods.  Generally you shouldn't store it on grex, if you
don't mean to publish it.  There are all sorts of other reasons why you
shouldn't store such data here anyways.  When you use grex for private
data, you are trusting grex staff not to abuse your trust and generally
to do the best job possible of securing your data, but there is no such
thing as absolute security, and a free timesharing service is very far
from most computer people's notion of security these days.

response 109 of 110:

Nov 28 19:49 UTC 2004

YEAH