From: Hal <hfinney@shell.portal.com>
Date: Tue, 31 Jan 95 20:53:20 PST
To: cypherpunks@toad.com
Subject: Re:  Frothing remailers - an immodest proposal
Message-ID: <199502010434.UAA26114@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

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 anonymity is lost.
With user-supplied chaining I am secure unless all of the remailers on
the chain are corrupt.

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 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.

A few notes about Safe-TCL.  I posted some ideas on using this as a basis
for remailing some time back.  Safe-TCL defines three times at which
messages could be activated (scripts in them run).  One is on message
sending, one on message reading (so it can put up dialog boxes and
interact with the recipient in other ways), and the third on receipt,
which is when it enters the user's mailbox.  The actual safe-tcl
implementation does not include support for this third mode, but it would
be pretty easy to add.  If you had that, messages could come to your
machine and activate to do various things that you allow them to do.  If
you allowed them to send mail as one of those things, this would be a
start towards a remailer.

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.

There has been intermittent discussion of similar topics on the safe-tcl
mailing list.  The motivation there is not supplying remailers, of
course; rather there is a desire to have something with similar
functionality to the much-ballyhooed Telescript, but less bound by
proprietary constraints.  Telescript scripts can move through the network
and interact with other scripts (at least, they will supposedly be able
to, but the exact manner is apparently secret for now).  Providing the
simple act of motion to mail agent scripts without stamping them with a
record of everywhere they have been is really all a remailer would do.
(I wonder if Telescript agents have to carry around with them a record of
every path they've taken?)

Sending a message through a safe-tcl based remail network might be more
cumbersome than our current techniques.  You might have to precede the
message body with a safe-tcl program a few lines to a couple of pages in
size depending on the complexity of remailing you want.  But again with
proper clients this can be hidden from the user.  I think emphasis should
be on smart mailer clients rather than more cooperation among nodes in
the remailer network.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLy8O8hnMLJtOy9MBAQHMjwIA40ZIvNtOvMN/mWtY4bSN0MYMravR9bNr
zhZ519K+g6w5ZsW71c/kM7BFz15BjB9pIcTMjUQv/C8YJNGrdFEzhg==
=1okU
-----END PGP SIGNATURE-----