Scribbling issue

Jan 9 18:59 UTC 2004

In item #71, Valerie wrote:

"I've written a command that people can use to remove all of the responses
 they have ever made, from an item, from a conference, or from all of
Grex.
 It's running now to remove all of the responses I entered as "valerie".
 It takes a long time to run."

Something occurs to me that is a strong argument that users using such a
program as this should be disallowed by staff.

If user "abc" is a longtime user with a lot of posts and then leaves, or
simply goes away for a while, login "abc" could get reaped and recycled.
Somebody troublemaker then could run newuser and get the login "abc" and
then run Valerie's program and scribble hundreds of posts they never made.

For instance, I just noticed that my old login Kerouac is reaped. I don't
care, I don't particularly want it anymore.  But I have many posts on here
under that login. Could someone else now run newuser, get Kerouac, and
then user Valerie's program to remove my posts.  My posts, not theirs?  It
seems to me that staff needs to ensure that only the person who made the
post can scribble it, and if four users in ten users have had login "abc"
and made posts, how does a program like Valerie's tell which user had the
login when a particular old post was made?

response 2 of 58:

Jan 9 19:22 UTC 2004

What I don't like about this is 'it takes a long time to run', which slows
grex down. Then everyone else has to do fixseen on every conference where the
responses were scribbled, which slows grex down even more.  I am in favor of
removing this script so that people cannot do this sort of global scribble.

response 4 of 58:

Jan 9 19:57 UTC 2004

I couldn't write a script like that and I bet most other users also do not
know how to do so.  

response 6 of 58:

Jan 9 20:17 UTC 2004

If valerie had used 'nice' to run it, it probably wouldn't have bogged 
down the system.

Do I think it's a polite thing to do?  No.  But I don't think it's 
reasonable to stop people from scribbling their responses, and I don't 
given that I don't think we can prohibit them from automating the 
process.

response 8 of 58:

Jan 9 20:18 UTC 2004

I meant that last sentence to read 'But I don't think it's reasonable to 
stop people from scribbling their responses, and given that I don't 
think we can prohibit them from automating the process.'

response 12 of 58:

Jan 10 02:17 UTC 2004

I don't think #1 is true.  I don't recall any place that Picospan uses UID.

response 14 of 58:

Jan 10 05:26 UTC 2004

Here is a typical header for a response in a picospan item:
    ,E
    ,R0000
    ,U1017,bhoward
    ,Abruce howard
    ,D2887870b
    ,T

extracted from one of the conferences.  Note the ,U line which encodes
uid and login.  As others have pointed out, it is the combination of
both these things that uniquely identify the owner of a response (or
for that matter, item) when picospan needs to determine ownership to
decide whether you are allowed to do something.

response 16 of 58:

Jan 10 15:32 UTC 2004

Re #14:  Right, Picospan response headers contain both the uid and
the login id.  To verify that Picospan actually uses them both, I
created an account with the same login id as a long-deleted user
who had posted in the test conference and tried to retire and freeze
the user's items.  Picospan wouldn't let me do it, as expected.

response 18 of 58:

Jan 10 16:18 UTC 2004

If you used newuser to create a new account with the same login id
as your old  one, then the answer is yes.  Your new account got a
different uid than the old one, and Unix uses uid's to determine
file access rights.

response 20 of 58:

Jan 10 20:19 UTC 2004

Picospan and Backtalk require both login and UID to match before you can
scribble an response.  Unfortunately it isn't as careful about
fairwitnesses.  If a fairwitness is reaped and you capture the old login
id, it will work for you.  Yapp fixes this defect.

Valerie wrote her reap program in quite a hurry.  If one were to spend a
bit of time at it, one could write one that runs much faster with less
impact on the system.  I could write a backtalk script that would do
pretty well.  I have no plans to do so, but if the system load were the
only objection to such "blitzcraig" scripts, then it would be a
surmountable problem.

response 22 of 58:

Jan 10 22:13 UTC 2004

>Yapp fixes this defect.

Uhh, the YAPP that runs on m-net sure doesn't.  OR maybe you're talking about
a newer version.
Plus, valerie's reap program is too user-friendly to be a quick hacked-up job.
Plus, there's also the 'nice' command.