From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Sun, 8 Jan 95 20:49:40 PST
To: dfloyd@io.com
Subject: Re:  Data Haven problems
Message-ID: <9501090448.AA14477@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text/plain


dfloyd asks for ideas about preventing spamming in data havens,
for the code that he's working on.  It's a hard job.
A related problem is how to prevent your data haven from becoming
the porno-ftp site of the week, and either being swamped with
traffic or raided by the Post Office Reactionary Neighborhood Police.

One way to stop spamming is to charge sufficient money for the service
that using it always pays for itself - spamming is then reduced
to a source of profit, e.g. no problem.  If people want to  hire
you to store spam, it's their money they're wasting.  But that
requires an anonymous digital cash infrastructure, which we don't
really have yet.  And it's a lot less interesting academically (:-)
than finding solutions which can also work in a cooperative system,
or at least a system that doesn't charge per transaction.

Probably the most important step you can take is to build in
operator-selectable filtering, because the problems keep changing.
Operators probably need to be able to block storage and retrieval
by specific users and sites (It's easier to prevent access by 
president@whitehouse.gov than it is to detect forged requests, 
and you probably want to keep both real and fake Cantor&Siegel users off,
plus the bozo of the month and the broken-remailer of the day.)
Some operators may find it useful to limit the amount of data
that can be stored or retrieved by a specific user or site, 
though this is less useful with anonymous and pseudonymous remailers
around, since "a specific user" becomes vaguer.

Filtering by filename and type can also be useful - if you don't allow
files named *.gif and *.jpg, users may be less likely to
spam you with pornography.  Namespace control in general is an issue -
do users get to choose filenames, or list directories, or do they
have to know the names of files to retrieve. 
Another issue is whether files can only be retrieved by the sender -
probably a local policy issue.  

Some sites may only accept encrypted files, which reduces the spam 
potential considerably, as well as reducing your exposure to the
porn police, though it's difficult to do anything about files that are
encrypted with a public key whose private key has been posted to the net,
or fake crypto headers in an otherwise unencrypted file,
unless you put in lots more code to check the insides of files and
watch the net for such postings, which is unrealistic.  There's also
the problem that PGP and especially RIPEM files are non-stealthy,
and users may not want to leave even keyids in their files.

		Bill