[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another problem w/Data Havens...



At 4:33 PM 1/18/95, Paul J. Ste. Marie wrote:
>[. . .] As long as
>some piece of info is considered to be a thought-crime, everyone who accepts
>info from a wide range of sources is at risk.

We might have a test case right now for part of that idea--the
Scientologists. They're essentially claiming that the various newsgroups
should be shut down because somebody put thoughtcrime on them. I would
posit that the operator of any automated data transmission/massaging
service is not responsible for the data that passes through her equipment.
Consider, for example, if I used a bang path to route an illicit email note
through, say, apple.com. Does that make Apple Computer responsible for what
I send?

Tying in with some of Eric's comments, this could be viewed as a
fundamental flaw in the 'net: it's the sender, generally, who initiates and
controls the connection, not the recipient. We could view this as an
advantage: how can you blame me for what somebody else does to my computer
without my knowledge, especially if I have no way to stop it short of
getting off the 'net completely?

>> ... The service could even be advertised as a different form of timestamping
>>(or notarizing). Not only do you get the file back signed, but you get it
>>back encrypted and signed. ...
>
>That would still be a useful service, however, but it does transfer the risk
>from the DH operator to the encryptor.  Since he isn't leaving evidence on a
>hard drive, his window of vunerability is somewhat less.

Less to nonexistent. If no human sees it on the encrypting site, no human
can be responsible for it. "They" would have to ban the service outright,
or try to prove that you knew that your site would be used for illicit
purposes. If putting a warning to not export crypto software on an ftp site
is sufficient protection--and, judging from the number of sites which do no
more than that, it is--then a simple statement that the service is not to
be used for any illegal purpose should do fine here.

>    --Paul J. Ste. Marie
>      [email protected], [email protected]

b&

--
[email protected], Arizona State University School of Music
 Finger [email protected] for PGP public key ID 0x875B059.