In-Reply-To: <40ED9CC5.3603.398179@localhost> (01)
I have a lot of thoughts about this, both as a user and as an archive admin. (02)
As an archive administrator, we field requests from people all the time
who want to have contact information changed or removed. People get
very excited about this. Today we received an email from someone who
wrote into a public guestbook over 6 years ago with their full name,
home phone number and email address. Its been on the site for 6 years
and today it was a house on fire that needed IMMEDIATE ATTENTION. This
appears to be normal and we get folks pleading with us to get google to
expunge their cache more quickly, etc. (03)
My thought is that, in most cases, it is totally fine to remove names
and contact information from documents as long as the authorship for a
document remains unique and it doesn't damage the 'content'. We had an
edge case for this recently when someone wanted their name removed from
a document that they had approved, but did not author, from 10 years ago
because it implicated them in socially disapproved behaviour. In the
end, we err on the side of respecting people's current wishes and
replaced the person's name with initials. (04)
As a user, I definitely want to be able to control my contact
information. Software and systems are out of my control and I would
/like/ to be able to keep the same email address for long periods of
time. For people who use temporary addresses, this is not a big deal,
but I only recently had to lose one of my email addresses I'd had since
1988 because the company it was with changed its name. I would like my
current email addresses (where I control the domain name) to last
effectively forever. (05)
My current problem is that my primary mail program (KMail) creates a
message ID with my email address in it. Good lord. So systems like
blueox use the email address as a key into the database. Ugh. I wonder
what mozilla will do. Perhaps it will include my home phone number and
social security number as my message ID. (06)
I disagree with the notion that archive administrators should not be
responsible for their archives and being responsible for them means
being in relationship with the data and the people that produce it. One
can "take a hard line" and say that the warning was posted and your SOL,
but in the end that seems to be saying that the archive owner is not a
part of the community it is archiving for. (07)
I think there's no question that a Good Archivist is one who, like
Eugene here, is always in some manner of dialog about the contents of
the archive. That doesn't mean revisiting the same questions every day,
but I think it does suggest that, at this point, we should respect
concerns about privacy and fear-of-robots and try to accomodate where
possible. (08)
The thing about spam is that much of it is now generated by
out-of-control bots just spamming for spamming's sake and not even
trying to generate real sales. Lame DoS through email and virus spew is
now very common. (09)
I mostly protect myself with semi-functional perl scripts and Bayesian
filters, but technology change has effects which are unexpected by
many. When folks were posting to Usenet back in the early 1990s, it is
fairly well established that most of them didn't expect to have their
comments be instantaneously searchable from any cafe in any major city
15 years later and that robots generating endless streams of unwanted
email would dominate the contact attempts based on those Usenet posts.
The way they behaved and the things they said were not said in the
context of "permanent, omnipresent information about me". How things
change :) (010)
So, my opinion is: try to make systems that expose your users to as few
malicious attacks as possible, have fairly generous policies for
removing contact info, have fairly restrictive rules about removing
actual content, try to be understanding when people freak out after some
discovery or attack has them perceive vulnerability caused by the
system, and err on the side of doing what the author requests when the
damage to the DataStream is minimal. (011)
blinc (012)
--
This message is archived at: (013)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=40ED985B.6010206@grassrootreview.org (014)
|