Remailer Crisis - Part II

[joelm@eskimo.com (Joel McNamara)]

The "remailer-in-a-box" solution seems to be on its way to solving the
ebbing number of remailers problem.  The next step is to think of remailers
in a supply and demand context.  From a "maximizing your resources"
standpoint, it doesn't make sense to have one hundred remailers available
(aside from the chaining implications), if the usage/demand needs are met by
twenty.

It's important to create an infrastructure for a large scale remailer
network, but the next step is to actually drive demand (obvious benefits of
increasing privacy levels, blunting traffic analysis, creating a large
enough population that will vocally protest if attempts to restrict
remailers are made, etc.).

I see two ways of doing this.

The first step is education.  Net users, especially the new ones, need to be
educated about the use and benefits/limitations of remailers.  Web pages are
a good start.  The information needs to be easy to understand yet
compelling.  Users need to be shown why remailers are important and be
encouraged to at least try using them once ("want some candy little boy/girl").

The second step is access.  With the advent of commercial Internet
providers, the defacto Net access points are becoming GUI PCs and Macs.  It
is critical that tools be built for these platforms that make using
remailers a transparent and simple task.  (I don't want to belittle GUI
users, I'm using Windows as I write this, but most would rather click a few
buttons and use a list box rather than remember the :: syntax for embedding
remailer commands in their e-mail.)  This was part of my motivation for
writing Private Idaho for Windows Eudora.  I see good GUI premailers or
integrated e-mail scripts as a critical element of remailer success.

Joel McNamara
joelm@eskimo.com - finger for PGP key