Re: Warning about exposing anon id

I agree with Alan's position that anonymization not be done automatically
on reply to mailers, but in fairness Julf has argued that the "least
astonishment" position goes the other way.  Apparently for several years
anonymous/pseudonymous servers have operated on the talk groups which
do the automatic anonymization.  People there have come to expect that
when they reply to an anonymous message their own identity will be protected.
Providing an anonymous server for which this established behavior does
not occur will no doubt astonish many experienced users of these services.

Still, I think the current behavior is wrong, and IMO the sooner people
learn a new way of using anonymous servers, the better.  When we do
deploy anonymous servers which allow replies, it will be important to
include disclaimers which remind people that their replies will not be
anonymous.  Unfortunately, some or most newsreaders do not show header
fields, and I dislike sticking disclaimers into the message body itself.

Hal

It seems that an anonymous remailer can operate in one of three ways -
it can reveal your psuedonym, it can reveal your identity, or it can
reveal nothing and simply give you a generaic "anonymous" identity.
Unfortunately each mode of operation is inapproprate as a default behavior:

- If it reveals your psuedonym, you could inadvertently expose map your
name to your psuedonym if you reply to a remailed message and include your
real identity.

- If it reveals your real identity, this could lead all sorts of obvious
problems with people who don't expect this behavior.

- If it simply strips out all identifying information and calls you some
generic anonymous name, this could lead to problems for people who expect
a reply to their messages.

I think the best solution is to require any message sent through a remailer
to include explicit instructions as to how it should be handled.  For example,
require something like an "X-Identify:" field that would be used to select the
return address behavior, with options like "real-id", "psuedonym", or
"anonymous".  Messages that don't include the field should bounce, probably
with some instructions as to how to fix the message to make it go through
properly.

-matt

> It seems that an anonymous remailer can operate in one of three ways -
> it can reveal your psuedonym, it can reveal your identity, or it can
> reveal nothing and simply give you a generaic "anonymous" identity.

There is one more option - use two separate sets of anon id's. This is the
way anon.penet.fi Mk II is going to operate.

> - If it simply strips out all identifying information and calls you some
> generic anonymous name, this could lead to problems for people who expect
> a reply to their messages.

Yeah. This problem is solved by the aforementioned "double" id approach...

> I think the best solution is to require any message sent through a remailer
> to include explicit instructions as to how it should be handled.  For example
 > ,
> require something like an "X-Identify:" field that would be used to select th
 > e
> return address behavior, with options like "real-id", "psuedonym", or
> "anonymous".  Messages that don't include the field should bounce, probably
> with some instructions as to how to fix the message to make it go through
> properly.

No way. 75% of my users just can't deal with the extra headers. I frequently
get messages like:

	"Dear Sir. I not understand you help. I not read English.
	I chinese. Send chinese help."

 Julf

Julf writes:
>There is one more option - use two separate sets of anon id's. This is the
>way anon.penet.fi Mk II is going to operate.

How will this work?  Will you have a separate name space of "heavyweight"
anonymous IDs for messages that explicitly ask for a psuedonym (like with
a password) and those that don't?  If so, that sounds like a nice solution.

-matt

Matt Blaze says:
> I think the best solution is to require any message sent through a
> remailer to include explicit instructions as to how it should be
> handled. [...] Messages that don't include the field should bounce,
> probably with some instructions as to how to fix the message to make
> it go through properly.

For messages that are deliberately sent through remailers, I agree
that the sender should provide explicit instructions to direct the
operation of the remailer.  However, I would note that the mere act of
deliberately using a particular remailer can constitute an explicit
instruction for the remailer to perform its "standard" processing.

Messages that are inadvertantly sent through remailers by innocent folk
who simply reply to a (pseudonymous) message that they have received,
or simply write to an address that they have seen advertised, are
different.  I think that such messages should function as much like
ordinary (non-anonymous) mail as possible, consistent with the goal of
protecting the recipient's identity, to avoid surprising the innocent
sender.  Servers like the present implementation of anon.penet.fi do not
satisfy this requirement.

--apb (Alan Barrett)

> From: Matt Blaze <mab@crypto.com>
> - If it simply strips out all identifying information and calls you some
> generic anonymous name, this could lead to problems for people who expect
> a reply to their messages.

One option I was thinking about was to separate the namespace into
"pseudonyms" and "anonyms".  The former would be persistent, the
equivalent of the present anXXXX addresses, and IMHO should have
some sort of human-readable `handle', even if it has to be randomly
generated from a dictionary.

When a non-user replies to a pseudonymous post (or a user does not
specify the pseudonym to use, if this is applicable), an anonym will
be allocated, consisting mostly of a largish random number.  To keep
the database size under control, anonyms should probably be deleted
after a certain period of disuse.

If someone later decides to create a `real' pseudonym, this system
ensures that they will not be unpleasantly surprised by finding that
they already *had* one, and put their signature under it.

   Eli   ebrandt@jarthur.claremont.edu