1995-01-06 - Re: Remailer Abuse

Header Data

From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: jrochkin@cs.oberlin.edu
Message Hash: 8e1686d1f243e66c0760e254c75d5a21fc87c1dc23b74af26b0e422379b8f033
Message ID: <4j3PEYr0Eyt5IxI7VW@nsb.fv.com>
Reply To: <1185.789426406.1@nsb.fv.com>
UTC Datetime: 1995-01-06 21:21:06 UTC
Raw Date: Fri, 6 Jan 95 13:21:06 PST

Raw message

From: Nathaniel Borenstein <nsb@nsb.fv.com>
Date: Fri, 6 Jan 95 13:21:06 PST
To: jrochkin@cs.oberlin.edu
Subject: Re: Remailer Abuse
In-Reply-To: <1185.789426406.1@nsb.fv.com>
Message-ID: <4j3PEYr0Eyt5IxI7VW@nsb.fv.com>
MIME-Version: 1.0
Content-Type: text/plain


Excerpts from mail: 6-Jan-95 Re: Remailer Abuse jrochkin@cs.oberlin.edu (3378*)

> 1) The initial remailer has no way of knowing how many subsequent links
> there are in the chain, and so doesn't know if I've paid him enough to
> reimburse everyone else.  I can easily cheat. 

This depends entirely on your definition of "cheating".    Basically, my
proposal (which I think crossed in the mail with yours, so I'm not
claiming that you misunderstood it -- in fact you anticipated *most* of
it, I think) was to charge once for entry to the "system", and to
include in that charge as many "hops" as you feel are necessary.  No
cheating involved -- the truly anonymous hops would only be accessible
from within the "system", i.e. from a similar anonymous remailer
"inside" the system or from one of the fee-for-entry systems.  If this
is the charging model, then the objections about knowing the chain
length, etc. all go away.

> 2) This system requies a good deal of cooperation and organization among
> remailer operators. 

Not that much, just a revenue sharing arrangement based on income and
volume.  Consortia do this sort of thing all the time, though most
consortia aren't formed in quite the atmosphere of paranoia that often
surrounds remailers.....

> Assuming that there will be some free as well as some charging remailers,
> I'd also like to use some of each in my chain.  I see some problems with
> the Remailer Trade Association allowing those transactions to happen.
> (will they accept incoming mail from a non-affilated remailer, which surely
> won't be paying them at the end of the month?  Surely not, which means if I
> use any affilated remailers in my chain, no affilated remailers can come
> afterwords. So all affilated remailers I'm using have to come before all
> non-affiliated remailers, which is an undesirable restriction which could
> aid traffic analsysis. If there are several affiliations, things get even
> more complicated.)

Actually, I think this could be serialized -- you could design it so
that you could use free remailers either before or after the consortium
members, but once you left the consortium system your message would have
to somehow pay to get back in again.  That would be a mess, and not my
preferred way to do it.

> And it isn't an issue of
> certain sacrifices you have to make in order to set up for-pay remailers,
> as a Chaum digicash based for-pay remailer system would work admirably, and
> none of my objections would apply to it.

Yes, it is is true that if digicash starts working for real money, it
will answer your objections quite nicely.  However, there are lots of
objections to that sort of system, too, they're just different ones.  As
both the FV and Digicash folks have pointed out many times, we have very
different technologies that fill very different requirements, it's not
an either/or choice.  I think you could build interesting anonymous
remailers on each system, too.  -- Nathaniel





Thread