Remailer Standards (was Economic Assumptions)

[rjc@gnu.ai.mit.edu (Ray)]

Eric:
> Enough of this.  I'd rather discuss lowering transaction costs.  rjc
> comments on my list:

> >>-- Finding out that remailers exist and what they do.
> >   build a remailer "who" server into each remailer

> I point out this doesn't help if you don't know where the first
> remailer is.  What I was specifically referring to was public
> education.  Were remailers ubiquitous, there would be a chapter on
> them in each of the latest rage of 'how to use the internet' books.
> They could be a well-used service, like archie.  

  But this has nothing to do with writing code. There are plenty of
people on this list who aren't writing code, who most likely have
better writing skills than CS/Engineering majors, and who have the
time to write remailer faqs and evangelize remailer use. This type of project 
can be done in parallel with remailer development. I don't see why any 
priority scheme is needed. Cypherpunks, as often repeated, are not a 
monolithic group governed from the top-down who obey directions to focus all
their efforts on one priority. 

> In fact, they are not.  There are numerous reasons for this, some of
> which are self-referential (as in, there aren't a lot of remailers
> yet) and some of which are not.  For example, there's no FAQ for
> comp.mail.remailer, because there's no such group.  Why shouldn't
> there be?

   Maybe because it would get voted down or maybe because no one has
RFD'd it yet. Nothing is stopping anyone from going ahead and doing
this. An alt group would be better.

> >>-- Finding a remailer to use.
> >   ditto 

> I specifically made this a separate item because it has a different
> solution.  Let's assume the potential user has some beginner's
> document about remailers.  How do they go about finding out what
> remailers exist?

> Well, the document could have a list of them, but that doesn't exactly
> work well in the face of rapid changes.  Some centrality in the
> initial query seems called for.  That could be a stable machine, or
> some stable name, even.  What the query actually looks like is less
> important.

   This is already included in my new remailer, but I proposed a 
"remailer server" for keeping an up to date automatically generated
list of working remailers almost a year ago (I even hacked up some
partially working code for it) when it became obvious that Karl's
list of remailers weren't good enough (although it was a good effort)
The biggest problem is getting a stable machine or
a stable network of 'DNS'-like machines.

   There is already a similar mechanism for MUDs. Besides the static
list of running muds there is a MUD "mudwhod" server which maintains
a list of running muds and who is logged into them.

> There is, also, the question of trustworthiness.  That mythical beast
> the reputation system might be applicable, but I know of none to judge
> for suitability.  More generally, there are questions of policy.
> What, for example, is the policy of the remailer in case of
> administrative request for mappings?  Are there liquidated damages
> available to someone whose privacy is breached?  These legal issues
> are not so easily made into syntax.

  This type of standardization is only likely to spontaneously evolve
after a remailer network is already up and running and these policy
issues come up. I don't think we can centrally draft some kind of
Constitution/Bylaws for remailers which covers all possible future
problems. Remailer politics and legal systems are an unexplored area.
I think we should leave it up to the remailer operators for now since
they will have to deal with these issues first hand.

> >>-- Figuring out how to use a particular remailer.
> >   standardize remailer help system, standard remailer command format
> >   (but not neccessaily the commands themselves) Sorta like an SGML for
> >   remailers

> I think the commands ought to be standardized, just like RFC-822
> standardized on the To: field.  I realize this is going to create a
> little havoc for the half-dozen or so remailer developers who have all
> chosen not to talk to each other during their developments.

   All someone needs to do is write up an RFC and submit it.

> >>-- Formatting a message for a remailer.
> >   see above
> Personally, I don't think we need multiple algorithms for this.  Is
> there any compelling reason, other than to avoid wasting existing but
> not yet deployed code?

   It could be that the best encapsulation method for remailer
messages hasn't been developed yet. I certainly think the
recursive-pasting token method needs a lot of work. A method should
be general enough to work with any RSA/Pkey system and not rely on
PGP's standard format. Cut lines definately needed to be standardized
abstracted away from the underlying cryptosystem.

> >>-- Receiving mail through a remailer.
> >   Get/Creating a nice client. 

> There's a transaction cost to switching clients which is huge.  It's
> completely unrealistic to expect everyone to use a particular client
> for remailers.  It just won't happen.  Far better is to rework
> existing clients to support remailers and to get those changes into
> the main distributions.

   Either way works, and the actual method used will probably be
a combination of both. However, getting cypherpunk software
installed in existing distributions will require some politics and
lobbying on behalf of cypherpunks. (e.g. getting remailer mods into
something like Eudora might be really hard)

> >Reducing complexity cost:
> >  All of this could be lowered by creating an easy-to-use
> >remailer client which is compiled (or perl/tcl interpreted) and 
> >installed with every unix out there so it becomes ubiquitous.

> The dream of universal software.  When I can unpack some software and
> type 'make', and do nothing else except read the man pages that 'make'
> caused to be formatted, I'll call that universal software.  And not
> before.

   Already exists. Almost every Unix system I have encounted comes with
atleast Perl4, and many come with TCL. Perl is a standard environment
and any correctly installed Perl should run a correctly written Perl
script. I'd say that one can create a remailer/client in Perl that
can be installed by almost anyone. (as long as you don't rely on
"absolute" paths which change, or non-standard environment variables)

> I'm glad lowering these transaction costs garnered a response.  But
> what I really want to see is, what did I forget about transaction
> costs to use remailers?

  The biggest thing you're missing is the fact that many users can't
even understand how to use LISTSERVs or run mail(1) To many people,
typing "::\n request-remailing-to: xxxx" and encrypting it, then adding
"Encrypted: PGP" is a huge transaction cost. I don't use remailers
for similar reasons. A simple mod to the elm script, "mailpgp" which
detects a remailer in the To: address, prompts you for "mail
anonymously to? " and then does all the underlying remailer commands
and chaining stuff automatically would be a huge benefit. Even
better would be a script which asks you "Mail anonymously?" and if
answered yes, it would automatically pick a remailer and do the
nasty stuff.

  Emacs and Elm are pretty standard, plug in elisp/perl scripts 
would work fairly well to encourage remailer use but
some evangelization would be required also to encourage use and educate.
I once suggested that someone set up a porno-server on the remailer
network as the ultimate carrot-and-stick method for getting people to use
remailers. I still think this is a good idea. (after all, the
two biggest uses of Julf's system I see are in the sex newsgroups and in 
IRC phreak/warez trading)


-Ray
-- Ray Cromwell        |    Engineering is the implementation of science;   --
-- rjc@gnu.ai.mit.edu  |       politics is the implementation of faith.     --