Re: Data Haven problems

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

wcs@anchor.ho.att.com wrote:

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

Hardly. (*.gi0 and *.jp0 for a start?)
But what are data havens for, if not for controversial data?
One of the greatest needs, if not _the_ greatest, in our times
for a data haven is probably for storing porno. There is a
tremendous, world-wide demand for porno. Yet, there are numerous
countries where sex.gif's found on your disk (encrypted or not,
they can use thumb-screws to force the key out of your hands)
will put you in a very difficult situation (loss of social
status, jail, decapitation). It might be much more convenient
for, let's say, a Saudi teenager to store his encrypted private
gif's in a data haven in Sweden, download them when he feels
the urge and purge the copies after every use.

Mats

On Mon, 9 Jan 1995, Mats Bergstrom wrote:

> Hardly. (*.gi0 and *.jp0 for a start?)
> But what are data havens for, if not for controversial data?
> One of the greatest needs, if not _the_ greatest, in our times
> for a data haven is probably for storing porno. There is a
> tremendous, world-wide demand for porno. Yet, there are numerous
> countries where sex.gif's found on your disk (encrypted or not,
> they can use thumb-screws to force the key out of your hands)
> will put you in a very difficult situation (loss of social
> status, jail, decapitation). It might be much more convenient
> for, let's say, a Saudi teenager to store his encrypted private
> gif's in a data haven in Sweden, download them when he feels
> the urge and purge the copies after every use.

My feelings exactly.

Are we going to fall prey to the medias asault on porno and resort to 
self-censorship?  If a data haven resorted to filtering out all gifs and 
jpegs, or even porno, then it wouldn't be one I wouldn't use it, for my 
porn, nor for my other data.  If it is going to be a datahaven it can;t 
fall to such things as filtering data for controversial subject the owner 
doesn't like.


i want to know everything          http://www.mcs.com/~nesta/home.html
i want to be everywhere                     Nesta's Home Page        
i want to fuck everyone in the world               &
i want to do something that matters         /-/ a s t e zine

> 
> On Mon, 9 Jan 1995, Mats Bergstrom wrote:
> 
> > Hardly. (*.gi0 and *.jp0 for a start?)
> > But what are data havens for, if not for controversial data?
> > One of the greatest needs, if not _the_ greatest, in our times
> > for a data haven is probably for storing porno. There is a
> > tremendous, world-wide demand for porno. Yet, there are numerous
> > countries where sex.gif's found on your disk (encrypted or not,
> > they can use thumb-screws to force the key out of your hands)
> > will put you in a very difficult situation (loss of social
> > status, jail, decapitation). It might be much more convenient
> > for, let's say, a Saudi teenager to store his encrypted private
> > gif's in a data haven in Sweden, download them when he feels
> > the urge and purge the copies after every use.
> 
> My feelings exactly.
> 
> Are we going to fall prey to the medias asault on porno and resort to 
> self-censorship?  If a data haven resorted to filtering out all gifs and 
> jpegs, or even porno, then it wouldn't be one I wouldn't use it, for my 
> porn, nor for my other data.  If it is going to be a datahaven it can;t 
> fall to such things as filtering data for controversial subject the owner 
> doesn't like.
> 
> 
> i want to know everything          http://www.mcs.com/~nesta/home.html
> i want to be everywhere                     Nesta's Home Page        
> i want to fuck everyone in the world               &
> i want to do something that matters         /-/ a s t e zine
> 

My problem is not that people will bitch about my DH.  My problem will
be arfholes or yellow journalists uploading K*dd*e p**n to my DH, then
making a long report how I cater to p*dofiles and other evil denezins
that pop from time to time.  Then, I get the police knocking at my
door, asking me to come to Club Fed for a looooonnnggg vacation.

Of course, the DH will be hidden by a good remailer (anon.penet.fi), but
it is trivial to use traffic analysis to find where the DH lies.  Just
monitor traffic from/to the remailer and do a series of store/retrives.
Then for confirmation, forge a mail from the dh site to the remailer with
the password (obtained from sniffing) to yourself.

This is the main reason I haven't worked on this code for so long, as
well as finals and other distractions.  Until I find a decent solution
to this problem (The alpha test will be a snap... just allow certain
people to send/get and ban all others, but once in full working mode
this ceases to be a solution.) I am hesitant on setting up a working
DH.

On Mon, 9 Jan 1995 dfloyd@io.com wrote:

> My problem is not that people will bitch about my DH.  My problem will
> be arfholes or yellow journalists uploading K*dd*e p**n to my DH, then
> making a long report how I cater to p*dofiles and other evil denezins
> that pop from time to time.  Then, I get the police knocking at my
> door, asking me to come to Club Fed for a looooonnnggg vacation.
>
I myself see nothing wrong with selectivly choosing your users at this 
juncture.  With an experimental server that wouldn't have the back-up to 
protect itself fomr attacks in real-space(police feds guns dogs fundies) 
you DO need to be careful.  If you wanna turn this into a profit 
thing(which is possible) you then would get to choose your clients.  I 
guess what I meant o say in tha tlast letter, was directed towards a 
full-fledged, well established and backed DataHaven that was not run for 
profit, but rather as a service to help the public(yeah, I know this 
lists idea on those projects, I wont go that direction no more) and thus 
would need to be open liek that.
 
> Of course, the DH will be hidden by a good remailer (anon.penet.fi), but
> it is trivial to use traffic analysis to find where the DH lies.  Just
> monitor traffic from/to the remailer and do a series of store/retrives.
> Then for confirmation, forge a mail from the dh site to the remailer with
> the password (obtained from sniffing) to yourself.
>
Well for an experiemnt that is fine, and I don't see it then much mroe 
then a listerv file service with encryption, unless i am missing 
something in teh DataHaven you have planned.  But later on when you wanna 
get serious and shit, you could get better shielding then that, depending 
on how much money you wanna spend.  Everythign from offshore sites with 
sattelite feeds or radio feeds(encrypted of course) with physical securiy 
measures and such.
 
> This is the main reason I haven't worked on this code for so long, as
> well as finals and other distractions.  Until I find a decent solution
> to this problem (The alpha test will be a snap... just allow certain
> people to send/get and ban all others, but once in full working mode
> this ceases to be a solution.) I am hesitant on setting up a working
> DH.
> 
I would set one up if I had the code tha tmet my standards(I don't have 
time right now to write it myself, but maybe if this thread goes well i 
will be inspired enough to order a few pizzas and go for it).  Right now 
my connection is muc much too slow to allow such traffic.  This is 
somethign i have been doing some serious thinking about also.  I cn 
actually see it bieng possible for me to have a small scale experiemntal 
data haven up and running in the near future, acting not only as a drop 
box, but also as a storage place and database of obscure information.

dfloyd@io.com writes:

>My problem is not that people will bitch about my DH.  My problem will
>be arfholes or yellow journalists uploading K*dd*e p**n to my DH, then
>making a long report how I cater to p*dofiles and other evil denezins
>that pop from time to time.  Then, I get the police knocking at my
>door, asking me to come to Club Fed for a looooonnnggg vacation.

well i remember a suggestion a while back to only accept encrypted
files. i don't remember who made the suggestion, but this seems like a
good idea for several reasons:

1) most journalists won't know how to encrypt their files (ok, this is
an admittedly short-term advantage, as journalists get smarter)

2) you will have no idea *what* is stored, and absolutely no way of
finding out, even if you wanted to. you should advertise this feature
widely. 

3) it will help promote the use of crypto, as those who want to use
the DH will have to have a way to encrypt their files.

and charging, even an extremely minimal fee, will help to reduce
wanton usage. but then you get into the whole electronic payment
infrastructure problem again...

-avi

On Tue, 10 Jan 1995, Avi Harris Baumstein wrote:

> dfloyd@io.com writes:
> 
> >My problem is not that people will bitch about my DH.  My problem will
> >be arfholes or yellow journalists uploading K*dd*e p**n to my DH, then
> >making a long report how I cater to p*dofiles and other evil denezins
> >that pop from time to time.  Then, I get the police knocking at my
> >door, asking me to come to Club Fed for a looooonnnggg vacation.
> 
> well i remember a suggestion a while back to only accept encrypted
> files. i don't remember who made the suggestion, but this seems like a
> good idea for several reasons:
>
I like this too, it keeps the data safe not only in transit, but also on 
the site itself.  So I don't have to re-encrypt files, they are alredy 
crypted, and signed(another good bonus) by the sender or account holder.
 
> 2) you will have no idea *what* is stored, and absolutely no way of
> finding out, even if you wanted to. you should advertise this feature
> widely.

depends on how it is encrypted, if they encrypt it too the datahaven, 
using your public key, that argument won't work, BUT if they are suing it 
as a anon drop box, then they can encypt it to another publik key of the 
recipient(an anon key of course) and oyu would never be abl to read it.  
This is a good feature of a data-haven, one that may be able to produce 
profit int eh future if tha is a motive.

-----BEGIN PGP SIGNED MESSAGE-----

In article <9501090448.AA14477@anchor.ho.att.com>, you wrote:

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

Pornographic images aren't spam _per_se._ What makes them troublesome is
the huge number of people who wish to download them when their
availability is widely known.  (My ISP's ftp site is being bogged down
by lots of accesses; it is speculated that these are people trying to
access pornography kept there.)

The obvious fix here is the same as the proposed fix for remailer
spamming:  charge for access.

As a (presumably) fixed-location data haven, one would want to be able
to use some kind of anonymous e-money for payment, but one could also
use good, old-fashioned credit card numbers, too.

The feelthy peexture business might well be the cash cow that keeps a
data-haven/fortress remailer afloat (if that's not too mixed a metaphor).

                          | PROOF-READER, n: A malefactor who atones for
   Alan Bostick           | making your writing nonsense by permitting
   abostick@netcom.com    | the compositor to make it unintelligible.
finger for PGP public key |      Ambrose Bierce, THE DEVIL'S DICTIONARY
Key fingerprint:          | 
50 22 FB 46 41 A3 17 9D F7 33 FF E1 4E 1C 89 79  +legal_kludge=off

-----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQB1AgUBLxGxHOVevBgtmhnpAQEEnAL/blauOWwrahdpEK+NbH4WC5V5fekmUYdg
tT5VU+d2C5PGF9Bm5cXtNlZczbI84f+jsBmxRDlXQAsec56D7M7ZwjBMcp2X8t9Z
+FlsU90fRN3NGbYOK/vlSOmzjPBQxf8A
=gvPB
-----END PGP SIGNATURE-----

On Mon, 9 Jan 1995, Alan Bostick wrote:

> Date: Mon, 09 Jan 1995 13:46:11 -0800
> From: Alan Bostick <abostick@netcom.com>
> To: wcs@anchor.ho.att.com, dfloyd@io.com
> Cc: cypherpunks@toad.com
> Subject: Re: Data Haven problems
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> In article <9501090448.AA14477@anchor.ho.att.com>, you wrote:
> 
> > 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.  
> 
> Pornographic images aren't spam _per_se._ What makes them troublesome is
> the huge number of people who wish to download them when their
> availability is widely known.  (My ISP's ftp site is being bogged down
> by lots of accesses; it is speculated that these are people trying to
> access pornography kept there.)

In many ways this shows how publically available porn could just pummel 
traffic analysis.

> 
> The obvious fix here is the same as the proposed fix for remailer
> spamming:  charge for access.
> 
> As a (presumably) fixed-location data haven, one would want to be able
> to use some kind of anonymous e-money for payment, but one could also
> use good, old-fashioned credit card numbers, too.
> 
> The feelthy peexture business might well be the cash cow that keeps a
> data-haven/fortress remailer afloat (if that's not too mixed a metaphor).
> 
>                           | PROOF-READER, n: A malefactor who atones for
>    Alan Bostick           | making your writing nonsense by permitting
>    abostick@netcom.com    | the compositor to make it unintelligible.
> finger for PGP public key |      Ambrose Bierce, THE DEVIL'S DICTIONARY
> Key fingerprint:          | 
> 50 22 FB 46 41 A3 17 9D F7 33 FF E1 4E 1C 89 79  +legal_kludge=off
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.1
> 
> iQB1AgUBLxGxHOVevBgtmhnpAQEEnAL/blauOWwrahdpEK+NbH4WC5V5fekmUYdg
> tT5VU+d2C5PGF9Bm5cXtNlZczbI84f+jsBmxRDlXQAsec56D7M7ZwjBMcp2X8t9Z
> +FlsU90fRN3NGbYOK/vlSOmzjPBQxf8A
> =gvPB
> -----END PGP SIGNATURE-----
> 

073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!

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

   This is interesting; during the last week or so that I've not been 
current with the list, I've started to implement a data-haven that takes 
information over sockets or MIME e-mail, and requires the use of PGP 
keypairs for the data.  I don't *WANT* to know what data they're 
transferring me.  If digicash would ever reply to one of my applications, 
I could sell it on a digicash/day basis.  Blah.  Neat idea, but the $ 
part is kinda limiting.

-jon

( --------[ Jonathan D. Cooper ]--------[ entropy@intnet.net ]-------- )
( PGP 2.6.2 keyprint: 31 50 8F 82 B9 79 ED C4  5B 12 A0 35 E0 9B C0 01 )
( home page: http://taz.hyperreal.com/~entropy/ ]---[ Key-ID: 4082CCB5 )

On Sun, 8 Jan 1995 wcs@anchor.ho.att.com wrote:

> Date: Sun, 8 Jan 95 23:48:36 EST
> From: wcs@anchor.ho.att.com
> To: dfloyd@io.com
> Cc: cypherpunks@toad.com
> Subject: Re: Data Haven problems
> 
> 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.
> 

[Problems of payment schemes and lack of anonymous payment infastructure 
deleted]

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

To some degree this requires the evaluation of the "authority attention" 
level the data haven has achieved.  If the real sensitive data is more 
extreme than a porn deposit, (I assume we are talking 'legal' and not 
kiddie porn BTW) then the spam involved will serve to properly mask, to 
some degree, stego'd files within the porn.  Part of a data haven, it 
seems to me, will be security by obscurity.  Just on the basic level that 
a haven with all encrypted files will be somewhat secure by obscure, in 
that the authority most likely to be interested in the data probably will 
not be attentive.  A repository holding some legitimate spam, be it porn 
or gifs or whatever, is unlikely to attract the level of SERIOUS 
attention that the sensitive data it contains may warrant.

To sum:  Spam's usefullness is a function of current authority attention, 
likely authority attention and authority attention the sensitive data 
warrants.

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

A better policy might be to encrypt all files that are not encypted, 
perhaps through some key assignment system.  The spam thus adds to the 
total traffic analysis problem, and the security of the spam is not 
material.  i.e. better encrypted spam than plaintext spam.

> 		Bill
> 

-uni- (Dark)
0

073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!