Remailer economics, Java & remailers

[cman@communities.com (Douglas Barnes)]

In a previous post I mentioned that in a remailer economy, remailer
users should have the opportunity to earn pre-paid service tokens by
acting as part of a remailer network. I also mentioned that this had
the benefit of providing cover traffic for the remailer user's own
activities.

Some people pointed out that their ISP agreements forbid them to
run remailers (!), and that not everyone is willing to tackle the
(as yet undetermined) legal liability or risk of general legal
hassle (which we've seen so far) of running a remailer.

First of all, the user client should present the user who wishes to
earn service tokens with the choice of registering as a terminal
or non-terminal remailer link. People get paid more to be terminal
links, since that's the person who is most likely to get hassled.

Second of all, most of the attacks on remailers, as well as any
ISP technique for detecting them, are based on some remailer's use
of SMTP which is a logged service operating on a known port. This
would be avoided by coevolving Mixmaster with "remailing bandwidth
and reputation" servers (spiritual descendents of Raphe's remailer
pinging service).

Something which is taking a small step in this direction is the
WWW front end to remailers available at c2.org as:
http://www.c2.org:80/remail/by-www.html. Note that it has
lots of security problems, but it has interesting conceptual
aspects (it is also extremely easy to use.)

Note that if one were using Java, one could fetch the application
via Netscape, and run it within an HTML document in a Netscape
window, but the sending of the mail could be done using any
appropriate network port or protocol without routing back through
the server where the document came from -- the applet would just
open socket(s) as appropriate and go for it. (Depending on the
user's security settings, a variety of "is it ok for this applet
to do such-and-so" messages may be displayed.)

My gut feeling is that serious remailer users and operators will
ultimately want a standalone application (which can still be
written in Java, and share code with the applet version), but that's
a religious war we don't need to get into again.