Re: [Mailman-Developers] full anonymisation approach
Aside: I think if you actually use such a list you'll discover that most "shy" people are far more afraid of being flamed than they are of social stigma *outside* of the discussion thread. OTOH, it is likely to bring out the worst in trolls. IMHO YMMV etc. We can't overlook the fact here that shy people and most of the others facing one social stigma or other do benefit from anonymous conversations and 12-step program lays focus on such websites. Though one of the many ill-effects is that some people may get dependent on the virtual society totally avoiding confrontation from the real one as referenced in [1]. Second ill effect is that internet anonymity is more vulnerable to abuses as people don't hold any responsibility of their behaviour in such a system. Hence, internet anonymity is a double edged sword (reference [2]). The shortcomings are considerably significant but we can't overlook the advantages of using anonymity to treat such cases as the research suggests.
In my opinion the requirements are:
- Keeping list members anonymous from each other.
OK, that follows from the above motivation. However, do you want the list identity to be consistent within threads, or will you assign a new list identity to a poster address for each post? Do you want list identity to be consistent across threads, or will you assign a new list identity to a poster address each time they first post to a new thread?
I plan on keeping list identity of a poster constant in a thread, i.e., I generate a new list identity for a first post to a new thread. Reasons of this were mentioned by me in http://www.mail-archive.com/mailman-developers%40python.org/msg15283.html
If identity is consistent within threads but not across threads, how do you determine that two posts are in different threads? For example, if post B points to post A in the References field, but the subject was changed in a significant way (ie, other than listrivia prefixes, Re: and friends, and whitespace changes that occasionally creep in due to mishandling of folding whitespace), are they in different threads?
I had been following this topic on discussions list by Aanand Shekhar Roy and had also read about it online as I had realised that grouping messages in threads is a trivial necessity for my implementation. Hence we will not be relying on the subject header of a mail because of the problems you have mentioned. So, we will be using the In-Reply-To header of the mail to map the messages to their respective threads. Hence tweaking with subject will not be treated as a new thread as long as the user is using Reply-To feature, which is essential while conversating in a thread. Also using references won't be reliable as after the length of thread becomes large few entries from the references are dropped
- Not allowing any way out for revealing any one's identity except if the user chooses to reveal it himself.
That's not a reasonable requirement. It is often possible to deduce an author's identity from their choice of argument or writing style, or their employer's automatically added footer. You could argue that message content is a user choice, but I don't think many users would be happy with that point of view.
I think you want to limit yourself to stuff that MUAs and MTAs put in the headers, including but not limited to originator addresses, display names, and comments. Speaking of "originator", what do you propose to do about non-subscribers who are CC'd?
We can remove the CC and BCC fields as if sent to a non-subscriber using CC the original id of the originator will be displayed and if a subscriber is CC'd then the mail bounces as posting address is a fake address. The originator can use one of the many available anonymous mailer services for personal anonymous mails.
You might also propose removing standard signatures (ie, everything after a string matching "\n-- \n").
Removing other footers is much more chancy, but you could try to catch them.
Yes, we can modify all footers and signatures in handlers.
I'm not sure that requirements 1) - 3) are a good fit for several of your use cases, but these requirements seem like a reasonable start.
I'll try to improvise on this part.
Regards Rashi
Sorry, I forgot to add the footnotes for the previous mail on this thread.
footnotes: [1] http://counseling.caltech.edu/general/InfoandResources/Shyness [2] The Internet: Biographies (google books)
Regards Rashi
Rashi Karanpuria writes:
Sorry, I forgot to add the footnotes for the previous mail on this thread.
footnotes: [1] http://counseling.caltech.edu/general/InfoandResources/Shyness [2] The Internet: Biographies (google books)
OK, Thanks. I've been going through mail in order due to connectivity problems. Didn't see this before the last message. All cool on the references!
Rashi Karanpuria writes:
Aside: I think if you actually use such a list you'll discover that most "shy" people are far more afraid of being flamed than they are of social stigma *outside* of the discussion thread. OTOH, it is likely to bring out the worst in trolls. IMHO YMMV etc.
We can't overlook the fact here that shy people and most of the others facing one social stigma or other do benefit from anonymous conversations and 12-step program lays focus on such websites.
I'm not overlooking the possibility, and if you want to use the word "fact" you should cite serious research (or reliable textbooks that cite the serious research). Psychology (especially clinical) is a field that's rife with real crap (see Kahnemann _Thinking Fast and Slow_ for an introduction). For GSoC purposes, I'm willing to assume that there are benefits for the use case you describe.
What you're overlooking is that you use words like "anonymous" and "conversation" without specifying them properly. Is an "anonymous" mailing anonymous enough for the users? How about the FUD effect if there is a public incident where a stalker manages to identify a victim through your anonymous list implementation? The design of your implementation is going to depend sensitively on the answers you give to these questions.
I plan on keeping list identity of a poster constant in a thread, i.e., I generate a new list identity for a first post to a new thread. Reasons of this were mentioned by me in http://www.mail-archive.com/mailman-developers%40python.org/msg15283.html
OK. Remember that identifying threads is inaccurate.
I wonder if it would be useful to have a feature where a user could change her ID, or link an old ID to a current one. (That's not a requirement for this product, but IMHO you should consider the possibility with designing modules/internal APIs.)
So, we will be using the In-Reply-To header of the mail to map the messages to their respective threads. Hence tweaking with subject will not be treated as a new thread as long as the user is using Reply-To feature, which is essential while conversating in a thread. Also using references won't be reliable as after the length of thread becomes large few entries from the references are dropped
I disagree. You should use both. The RFC for References does not specify which, if any, References are to be kept, but most implementations keep all, most of the others I've seen keep the most recent. If any are kept, they help verify the members of the predecessor set, even if the order can't be fully relied on.
Speaking of "originator", what do you propose to do about non-subscribers who are CC'd?
We can remove the CC and BCC fields as if sent to a non-subscriber using CC the original id of the originator will be displayed and if a subscriber is CC'd then the mail bounces as posting address is a fake address.
I don't understand what you mean by "posting address is a fake address."
The originator can use one of the many available anonymous mailer services for personal anonymous mails.
You absolutely cannot rely on originators to be clueful about this (in fact, isn't that your original motivation: the obvious answer is "if you want to be anonymous on a list, use an anonymizer service").
participants (2)
-
Rashi Karanpuria -
Stephen J. Turnbull