On Sat 2015-02-21 08:49:49 -0500, "Stephen J. Turnbull" <step...@xemacs.org>
wrote:
> You can say "I know that". The problem is that your users frequently
> will not, and may read more into "*full* anonymization" than can
> possibly be delivered. If we're going to deliver this feature as part
> of Mailman, it's really important that we be able to explain what use
> cases it's good for, and what it's not.
I think it's important to distinguish between attempts to anonymize the
users of the mailing list and attempts to hide the content of the
messages. It's also important to understand *from whom* we are
protecting the respective pieces of sensitive information.
The mailing list server *must* know the addresses of the subscribed
parties, in order to be able to send mail to them, for example.
The PSELS project [0] provides a mechanism for separation of the List
Moderator (who manages subscriptions and removals from the list,
potentially in a mostly-offline fashion) from the List Server (which
manages the online operation -- forwarding and message distribution).
In their model, the List Server still knows the subscribed addresses and
their keys, and knows how to transform the messages such that recipients
can read them, but the List Server cannot. This doesn't hide who is
receiving the mail or who is sending it from the List Server, but it
hides the contents.
Other projects might focus on stripping the metadata from message
headers at the mailman installation -- this doesn't hide the information
from the mailing list, but it might mean that recipients of messages
from the list wouldn't know things like where on the network other
senders were. It could even strip or replace the "From:" header so that
each recipient wouldn't know who the others are. But is this useful?
Surely to have a conversation on a mailing list (as we are here) it's
useful to at least have persistent pseudonymous connections between
messages, otherwise how do you know who's talking to whom?
> None of the use cases you've proposed so far are particularly
> appealing to me, but the one that comes closest is the "group therapy"
> application. So let's look at that use case and what its requirements
> are.
>
> 1. Who can be trusted with the keys?
> 2. Who needs to be anonymous?
> 3. What are the social threats if anonymity is breached?
> 4. What are the technical threats to anonymity (ie, how can it be breached)?
>
> I'm sure there are more questions needing answers, but that's a good
> place to start.
This kind of threat analysis is critical to making any sort of useful
proposal in this space. It doesn't have to be complete, and it can
potentially change over time if you need it to, but please start with
these questions so that we understand what problem you're looking to
solve, and so that you can better evaluate whether a proposed set of
changes actually addresses the identified problem.
--dkg
[0] http://www.ncsa.illinois.edu/People/hkhurana/ICICS.pdf
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
