Re: Frothing remailers - an immodest proposal

[kevin@elvis.wicat.com]

>I have some concerns about Kevin's frothing remailers.  Like so many of
>the proposals we see to put more responsibility into the remailer net,
>this opens vulnerability to a single bad remailer.  If I trust the first
>remailer in the net to choose my path for me, as I might be tempted to
>do with a froth, then if that remailer is corrupt my anonyminity is lost.
>With user-supplied chaining I am secure unless all of the remailers on
>the chain are corrupt.

Firstly, I certainly do not propose that we remove user-supplied
chaining; it is obviously vital to true anonyminity. What I am
suggesting is that we allow remailers to introduce more noise into the
mix using information that users cannot easily obtain for themselves
(e.g. which remailers are in operation at this moment). In the
apparently common case of unencrypted messages crossing the net, this is
at least no worse than the current situation. Of course, we would also
have to allow users to specify that no munging of the route be allowed
(some form of scripting). Trusting remailers to obey this request
requires no more trust than we already place in them (which, I believe,
is considerably more than most seem willing to admit).

If you succumb to the temptation and trust remailer #1 totally, then you
of course run the risk of sacrificing anonyminity. However, if you do
not trust remailer #1 so completely and specify a chain of remailers,
but allow remailer-generated routing between the points on that chain,
you gain resistance to traffic analysis as well as making it possible
for smaller transient remailers to play a useful role.

>I also do not like the kind of close-knit, cozy cooperation among the
>guild of remailer operators which seems to be envisioned in this and
>similar proposals.  Do you like the idea of messages on the remailer
>operators list saying, I am getting objectionable messages from your
>remailer, would you mind dropping in a log so we can see who is sending
>these messages which violate the Politically Correct Speech Act?

I don't see what would prevent this from happening now. The only degree
of cooperation I require from remailer operators is that they agree on
some software standards and that, if they choose, they create extended
webs of trust via signing one another's keys. There is no requirement
that all remailers or remailer operators trust all other remailer
operators; in fact, I think this would be undesirable, even if the trust
were justified.

Again, remember that control lies with the user. If you choose, you can
allow a remailer to bounce your mail through its web of trust before
forwarding it to the next point on your chain. I do not believe that
this increases the risk of losing anonyminity. I do also propose that
this be the default behavior in order to provide naive users with some
degree of security, as well as using their traffic to obscure that of
more sophisticated users.

>I do like Kevin's ideas about a dynamic remailer net, but I think
>another approach would put more smarts into the client program used by
>the originator.  Granted, his information will be somewhat more out of
>date as the message makes its way through the network.  But depending
>on thie time scale at which the froth, um, froths, this should still
>allow a lot more dynamism among the set of remailers.  Using either IRC
>or, as Todd suggested, Usenet to maintain an active remailer list might
>work.  We could also have a distributed set of sites which provide the
>information by finger like the pinging sites we have now.

True, all true (I seem to be saying this a lot today). My transient
remailer problem can be solved by publishing the times of availability
(assuming, of course, that my remailer will always be up when
scheduled). My only serious objection to this is that there will always
be more clients with more operating systems and platforms than there
will be servers. I don't expect that it will be easy to create new
standards for remailers and get significant numbers of operators to
implement or use them, but I do believe that that task is easier than
making smart clients available on all possible platforms.

[ Safe-TCL comments deleted]

>What you need then is some way for various messages to interact with each
>other, so that, for examle, a message could wait until there were a
>certain number of other messages inside the machine before it sent itself
>out.  You would also want a way for a message to suspend itself until
>some future event, such as having a certain amount of time passing, or
>waiting until some message with desired properties arrived.

This is a fine suggestion; as I mentioned in an earlier message,
scripting is not useful without data to operate on. You have suggested a
number of data that a remailer could usefully provide to a message,
making scripting more useful. Of course, you have to trust that the
remailer is not lying to your script.

[ More Safe-TCL comments and a plea for smarter clients rather than
smarter servers, to which I reply with the earlier argument, deleted.]

--
    Kevin