Re: An alternative to remailer shutdowns

["E. ALLEN SMITH" <EALLENSMITH@ocelot.Rutgers.EDU>]

From:	IN%"unicorn@schloss.li"  "Black Unicorn" 22-MAY-1996 19:03:58.98

>On Tue, 21 May 1996, Ben Holiday wrote:

>> On Tue, 21 May 1996, Daniel R. Oelke wrote:

>>> The second is to simply include the
>>> consent-code along with the encrypted peice of mail and a legal notice
>>> stating that decryption of the mail constitutes your consent to receive
>>> the mail, as well as your agreement to hold the remailer-operator harmless
>> 
>> By reduction - you could just do a rot13 on the message and 
>> append the "legal notice".   If all the information for decoding
>> a message is present in that message, is a different encoding
>> mechanism really any different from straight ASCII text?  
>> (i.e. Netscape 9.13 might have auto decoding built it....)
>> Then, the user doesn't do anything "extra" - does this invalidate 
>> the notice?

>A person has notice of a fact if he knows the fact, has reason to know it,
>should know it, or has been given notification of it.  Restatement,
>Second, Agency section 9.

>The important issue here is what constitutes constructive or implied 
>notice (the second example above).

>Constructive notice exists where a party could have discovered a fact by
>proper diligence and where the situation casts a duty on him to inquire
>into the matter.

>A person who has _actual_ notice of circumstances which would set of the
>"alarm bells" of a prudent person has constructive notice of the issue
>itself where a notice clause was available and easily referenced.

>See F.P. Baugh, Inc. v. Little Lake Lumber Co., 297 F.2d 692, 696.

>Also comes the question what notice is adequate?  Notice reasonably
>calculated, in all circumstances, to apprise all interested parties of
>actionm and opportunity to present their objections, says U.S. v San Juan
>Lumber Co., 313 F.Supp. 703, 709.

>I'm not going to discuss what constitutes a legal agreement here for the
>purposes of waiving rights to hold the remailer operater harmless.  These
>are traditionally unnegotiated agreements that courts are not likely to
>want to enforce.  (Back of a ski lift ticket, notice that the garage is
>not responsible for theft).

	Umm... the RSA licensing agreement isn't exactly a negotiated contract.
What makes the difference between the contract in question and the RSA
licensing agreement (to use it as an example)?

>If a court feels that the remailer operator is being negligent or some
>such, a notice like you are talking about is not likely to be very
>effective.

	Part of this depends on negligent in what sense. If, due to the
message being encrypted, the remailer operator couldn't read it to see if it
was copyright-violating anyway, would he/she be negligent to send it on?  

>I find that making the user decrypt the message as acceptance of the mail
>is clever, but what exactly does it accomplish?  The user can still have
>his copyrights violated in the text, what does it matter that he did or
>did not accept the mailing?

	The primary use of the contract is to avoid complaints from the user
for "harrassing" email, not to avoid copyright problems. I'm not sure if there
is anything that could be done to avoid the copyright problems, aside from the
disposable output addresses with multiple remailers using them. (One
possible problem with these is that it could be argued that the remailer
operators sending to such addresses can read over the mail before encrypting it
to the front end and check to see if it's a copyright violation. However, they
would appear to be covered by the exemptions that should be in the copyright
law, namely for ISPs - if they aren't covered, then the Net is dead anyway.)
One method around this would be for the initial user to specify the output
address - or, preferably, input address that outputted to multiple different
output addresses - to use, and encrypt the message for that addresss. However,
this would require common knowledge of the input addresses, which could lead
to their being shut down quickly or the owner being held liable. One could have
a group of input/output providers with a common public/private key for the
initial user to use for the final encryption, although then you'd need to be
careful about who you let into this group.
	-Allen