Re: Economic assumptions

Eric Hughes:
>Let's take remailers as an example.  One current suggestion is to add
>some sort of money system to the remailers as a condition of use.
>This is exactly the wrong priority at the current time.  The remailers
>are already hard enough to use, and adding a payment system on top of
>that will make them used even less.  Making a system harder to use
>increases the transaction cost.
> 
>The current priorities should be to lower these costs.  When the
>remailer system begins to be overloaded, then adding some restriction
>on use, perhaps by means of payment or a payment analogue, will be
>warranted, because it will lower overall transaction costs, trading
>off ease of use for throughput and reliability.
>
>What are some of these costs that should be lowered?
>
>-- Finding out that remailers exist and what they do.
   build a remailer "who" server into each remailer
>-- Finding a remailer to use.
   ditto 
>-- Deciding what remailer to use.
   ditto (remailer server should list remailer properties like
   keylength, private?, delay length, chaining?, mixing?, padding?,
   encryption required? etc)
>-- 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
>-- Formatting a message for a remailer.
   see above
>-- Receiving mail through a remailer.
   Get/Creating a nice client. At the moment, 100% of the mail in my mailbox 
is encrypted. I wrote a script called "deliver" which encrypts incoming
mail, then pipes it through procmail/slocal. I modified morepgp
and made it a lot more user friendly (and recursive).

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. If someone's 
machine doesn't have a client, they can telnet to a machine where one is set 
up (just like gopher, archie, www) by some generous cryptoaltruist.

  The current remailer solution of putting all of the remailer
system complexity on the server side can't make remailers too easy
to use. My Extropians list software attempted to make it easy
to use by allowing commands to be contained in-band with messages
to be posted. It's still too complex for the user who wants 
hot-key style operation.  (which is why I will eventually write a client
for it)

  Once you write a generalized client that can communicate with
standardized remailers, you can easily include digicash/postage
in the system.

>There much more need for improving the ease of use of remailers than
>for paying for them.

   Are you objecting to paying for remailers on a philosophical
grounds (anti-property/money)? No one has proposed paying real money
for remailer use (although that is a future possibility). There
needs to be some way to authenticate remailer users and limit use
in a "free" sense (instead of top-down rationing) The best way to do
this is to use some form of monetary system.

>The less expensive privacy is, the more privacy there will be.
>Privacy has non-linear benefit; the more that people are private, the
>better any individual's privacy actually is.

   Every standard is enhanced by more people using it. However, this
alone can't be a justification for making services into public goods
which are free to everyone.

   If the Detweilers of the world take advantage of totally free
remailers, they could end up limiting the privacy for all. The same
"free" philosophy has killed many a porno/music/book site (or
created absolutely long user queues reminiscent of food lines in
the xUSSR) Spamming/Spoofing attacks on remailers must be dealt with.

   The situation is not helped by either-or logic. We need both ease-of-use
and some notion of postage.


-Ray

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

me:
>>One current suggestion is to add some sort of money system to the
>>remailers as a condition of use.  This is exactly the wrong priority
>>at the current time.
[...]
[re: other transaction costs]
>>The current priorities should be to lower these costs.  

[later]
>>There much more need for improving the ease of use of remailers than
>>for paying for them.

rjc:
>   Are you objecting to paying for remailers on a philosophical
>grounds (anti-property/money)? 

Four words: Libertarian Political Correctness Witchhunt.

If it's not really clear that I was making a statement about
priorities, I don't think that repeating it a fourth time will help.

If, of course, I'm not all in favor of monetarizing remailers
immediately, could it be that I'm not in favor of ... money?
Please.

>   The situation is not helped by either-or logic. We need both ease-of-use
>and some notion of postage.

Are you talking about me?  It appears that you are, but I thought I
was only comparing priorities.

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.  

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?

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

We need DNS or something like DNS for this purpose.  We need something
where changes can propagate outward rapidly, which pushes data out,
and unlike BIND (the standard implementation of DNS), which pulls it
in after it times out.  The standard DNS query format could be kept,
but the current back end may not quite work.

And what about users on Compuserve, AOL, Genie, Delphi, and Prodigy?

>>-- Deciding what remailer to use.
>   ditto (remailer server should list remailer properties like
>   keylength, private?, delay length, chaining?, mixing?, padding?,
>   encryption required? etc)

Certainly a standard way of listing the properties of a remailer would
help.  This seems to be mostly a matter of syntax.

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.

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

If you don't have standard commands, then you need a way of specifying
semantics for all these various commands.  Not good.

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

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

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

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?

Eric