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
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!
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 )
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!
participants (8)
-
abostick＠netcom.com -
Avi Harris Baumstein -
Black Unicorn -
dfloyd＠io.com -
Jonathan Cooper -
Mats Bergstrom -
Nesta Stubbs -
wcs＠anchor.ho.att.com