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
participants (5)
-
Alan Barrett -
Eli Brandt -
hfinney＠shell.portal.com -
Johan Helsingius -
Matt Blaze