1992-10-23 - Keystone

Header Data

From: Eric Hughes <hughes@soda.berkeley.edu>
To: cypherpunks@toad.com
Message Hash: 7eafa220d02ff7674103b943a51cc62015c3bc371211bcd6d8b3a9f5e836b8a1
Message ID: <9210231726.AA11213@soda.berkeley.edu>
Reply To: <9210230728.AA25822@cygnus.com>
UTC Datetime: 1992-10-23 17:27:18 UTC
Raw Date: Fri, 23 Oct 92 10:27:18 PDT

Raw message

From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 23 Oct 92 10:27:18 PDT
To: cypherpunks@toad.com
Subject: Keystone
In-Reply-To: <9210230728.AA25822@cygnus.com>
Message-ID: <9210231726.AA11213@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


My proposal:
> "A provider of communications services cannot be held liable for the
> consequences of encrypted communications that pass though its system."

First let me point out that this wording is intended to be clear, not
to be legally useful.  This wording cannot stand for itself without
reference to the rest of the body of law.  I never intended it to.

It is also a mistake to think that I am advocating the converse,
namely, that the provider would be responsible for all unencrypted
communications.  Nor do I think that this should be the only defense a
provider has available.

gnu:
>Far too simple.  Suppose the provider is a BBS operator who *knows* what
>their users are passing through the system?  

The defense of encrypted communications is not germane here.  Such
knowledge did not come from the communications because they were
encrypted.  If the provider could read them, then they weren't
encrypted to the provider.  Therefore such knowledge came from some
other source.  A claim that arises from such knowledge is not met by
this criterion.

The defense of encrypted communications is not a blanket defense.

>Suppose the provider has keys to the encrypted communications?

Then the defense does not apply.  If the provider has keys to the
communications, then they are not encrypted as far as the provider is
concerned.  The question is not the _form_ of the communications, but
their _legibility_.

>Suppose those keys are only to be used under duress (e.g. under a
>court order)?

If the keys are in the possession of the provider and the provider and
the user have an agreement that the provider is not to use them in any
way other than archiving them, then the law cannot expect the provider
to routinely breach that agreement to search for possibly illegal
content.  The court may then subpoena these keys if necessary.

>Suppose the provider is a parent and the user is their teenage
>daughter?

The defense of encrypted communications is not germane here.  There is
a parent/child relation which creates a claim which the encrypted
communication defense is irrelevant to.

>Suppose the encryption is easily breakable?

The test of due diligence may be applied.  If the state of the art is
that the encryption is unbreakable, then the communications should be
consider to be encrypted.  If the cipher is automatically crackable,
such as monoalphabetic substitution, then the communications should be
consider _not_ encrypted.  Remember, the question is not _form_, but
_legibility_.

>The principle you are looking for is that if the service provider has
>no *control* over the content, then they should have no *liability*
>for it either.  

No, this is not the principle I was getting at.  I was referring to a
principle which was more restricted in its use but which is also
clearer in its interpretation.

This defense is a subset of the defense of no control.  If you can't
read the content, then _a fortiori_ you can't control it either.  It's
really very clear that if you have no basis for distinguishing
communications except for size, time, sender, and recipient, that you
can't act on anything that passes through the system.

>The courts are gradually making that happen.  

This is a good sign.  I heartily approve.  But it is easier to define
legibility with regard to encryption than it is to define control.
Referring to encrypted communications is much less ambiguous and
should be considered a step in the larger direction.

Eric





Thread