From: Nathaniel Borenstein <nsb@nsb.fv.com>
Date: Fri, 6 Jan 95 04:28:54 PST
To: db@Tadpole.COM
Subject: Re: Remailer Abuse
In-Reply-To: <4748.789282395.1@nsb.fv.com>
Message-ID: <Aj3HRaf0Eyt5ExIApP@nsb.fv.com>
MIME-Version: 1.0
Content-Type: text/plain


Excerpts from mail: 5-Jan-95 Re: Remailer Abuse db@Tadpole.COM (1180*)

> Heh. An anonymous remailer paid for by credit card... there'd
> have to be an additional level of indirection for it to work,
> which would make the methods for tracking those who don't pay
> quite problematic.

Again, this comes down to definitions of anonymity.  In this case, if
you start from the silly assumption that the anonymous remailer actually
keeps records that correlate messages to payment mechanisms, Doug is
right, but barely.  To break the anonymity, you'd need collusion between
the operator of the anonymous remailer AND First Virtual, because the
former knows which account sent a message, and the latter knows who that
account belongs to.  (And before you tell me that this sounds a lot like
the Clipper key escrow, I would point out that instead of two "trust us,
they're independent" agencies of the US government, in this case we're
talking about two independent private companies which are probably in
two different countries.  For my part, I figure that if the government
of Finland and the government of the US can actually agree that it's so
important to force the sacrifice of anonymity in a given case that
they're both willing to coerce companies under their jurisdiction, they
will probably have a very good reason for doing so.   Maybe I'm too
trusting, though.)

Moreover, and perhaps most important, even THIS can only be done if the
anonymous mailer keeps records of WHICH account paid for WHICH posting,
and if I were to operate a for-pay remailer, I wouldn't do that anyway. 
It sort of defeats the whole point of the service.

> Also, most remailer abuse tends to be of the hit-and-run variety,
> which is still nicely enabled by FV.

Only if you assume that the same people aren't responsible for multiple
hit-and-run attacks.  I would tend to assume the opposite.

Russ Nelson saw the first point quite clearly, and wrote:

Excerpts from mail: 5-Jan-95 Re: Remailer Abuse nelson@crynwr.com (1177)

> Sure, I'll know who used it, but I'm not going to keep that
> information.  (Yes, yes, FV says that I have to keep records of who
> bought what, but I'll label all my information with a random number,
> that simply says that X bought information worth Y, not *what*
> information.)  And if you don't trust a remailer operator, then you
> won't use it.

All I'd add here is that the requirement to keep records is one that we
have to pass on from the credit card world.  If you didn't keep ANY
records, my understanding is that all that this would really mean in
practice is that there would be an extremely strong presumption AGAINST
you in certain dispute-resolution situations.  That's just my
understanding, however, and it doesn't in any way supersede or
supplement our legal terms and conditions, available from
fineprint@fv.com.  (You should try them, I find them more effective than
Sominex.)

Excerpts from mail: 5-Jan-95 Re: Remailer Abuse wcs@anchor.ho.att.com (2028)

> I'd be worried about a couple of issues - 
> one is just the transaction cost - can you successfully market remailer use
> at a buck a shot or whatever you'd be charging beyond FV's 29c stamp,
> or would you have some convenient way to aggregate bill?

Depending on how often you aggregate, you can charge almost any amount. 
20 cents might be very reasonable.  If you run a cron job once a month
to post aggregated billings to anyone who had two or more outstanding
uses, you'd make only a small amount on the two-time users, but you'd
get serious aggregation from the regular users.  (You might also want to
bill the really-high-volume users weekly, to prevent them from going
into shock at their huge monthly bills.)

> Beyond that, though, are some traffic analysis problems -
> remailers require a fair bit of traffic to be useful, and unless
> you receive a reasonable amount of encrypted traffic, 
> and support encrypted email for purchasing remailer service
> and other merchandise, an eavesdropper would have a fairly good source
> of traffic data on your remailer users, especially since buying and using 
> remailer service requires two messages within an hour or so.

Well, I think low-volume remailers are always a bit vulnerable to
traffic analysis attacks, aren't they?    One thing you could do is
build a variable time-delay into the remailer, to make it harder to
correlate messages coming in with those going out.  To take paranoia a
step further, you could allow people to encrypt their mail TO an
anonymous remailer with the remailer's public key, and let the remailer
send it out unencrypted.  No snooper should be able to correlate the
*contents* that way, and it avoids lots of key management problems by
only using the remailer's key, not the user's. 

> An alternative billing mechanism, which wouldn't use Chaum-patented cash,
> would be to sell a bunch of one-shot random-number tokens.
> When you sell the tokens, you add them to the database of valid tokens,
> and when one comes in on a message you delete it.
> This allows you to sell more than one message or service-period per 
> FV transaction, and separates the purchase and use by a longer time,
> without adding the need for record-keeping based on the user's ID.
> It obviously does require encrypted reply messages.

I think this could work quite nicely, at first glance.  This is also the
kind of service for which you might want to wait until after the "yes"
reply to deliver the "goods".   My only concern, would be the key
management issues, but they might be manageable in this case by using
the equivalent of a session key, instead of a permanent personal key.  I
think this is a promising idea.    -- Nathaniel