Hughes: U> But source code is not available. The trouble is that all U> the decent terminal programs for PC's are shareware or U> commercial (or were originally shareware and have become U> commercial). I too would like to know of any U> source-available PC terminal programs, but I suspect there U> are none because of the prevailing shareware culture. U> I'll give you all of my Fido/FidoNet and FidoTerm sources. You can already have ReadMail. U> communications programs use FOSSIL drivers, but many (if U> not most) terminal programs don't support it. Commercial people still sneer at amateur systems like FidoNet. Their loss. FOSSIL is widely supported otherwise. FidoTerm and Fido/FidoNet both support FOSSIL, as do "all" FidoNet programs. U> One incentive would be for the BBS operators to phase in a U> policy that they will accept no e-mail which is _not_ U> encrypted. Comments? SHEESH!@+#)(#$ You oughta see what most sysops think. It's embarrassing. In their defense, NO ONE WILL TELL US what is reasonable. I know, I know how much is presently undefined and without precedent, but the broadest general parameters and guidelines are not that obscure. I'm also part of the BBSLAW mailing list (out of EFF) and it's finally contained some applicable stuff. What you wanna bet the lawscum won't let me repeat in any manner the recent thread on email? (Yes I'm asking.) (Most sysops are terrified that an in-transit, third-party message will contain some illegality and they will all be BUSTED. Hence, it is routine for them to review personally every in-transit message, and kill or bounce them! I am not kidding. (I know this must have been dealt with in the Internet (is kumr/cygnus/etc liable when I tell you that RICHARD NIXONS VISA CARD NUMBER is 4131 34534 456456 456546?) but somehow, no one's ever passed this info on to us.) --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG rom fidogate!f111.n125.z1.FIDONET.ORG!tom.jennings@kumr.lns.com Thu Oct 22 11:19:49 1992 Return-Path: <fidogate!f111.n125.z1.FIDONET.ORG!tom.jennings@kumr.lns.com> Received: from kumr.lns.com by toad.com id AA22497; Thu, 22 Oct 92 11:19:49 PDT Received: by kumr.lns.com (/\==/\ Smail3.1.25.1 #25.3) id <m0mi78E-0000hbC@kumr.lns.com>; Thu, 22 Oct 92 11:19 PDT Received: by fidogate.FIDONET.ORG (mailout1.26); Thu, 22 Oct 92 11:15:22 PDT Date: Thu, 22 Oct 92 11:03:26 PDT Message-Id: <3229.2AE6EFB9@fidogate.FIDONET.ORG> From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) Subject: thread (was Re: A To: cypherpunks@toad.com X-Mailer: mailout v1.26 released Just a slightly amusing message forwarded from PUBLIC_KEYS... From: Wes Cowley@1:125/180 To: Wes Perkhiser@1:125/111 Subject: Loss of thread (was Re: A ;Status: (read 2 times) ;^AINTL 1:125/111 1:125/180 ;^APID ReadMail ;^AMSGID RM1:125/111=2AE68513
----------------------- Do not change this line -----------------------------< WP>>"Hi, how are you, and what's your key?" WP>>P.S. Will that be a new pick-up line? It beats "What's your sign?"
"Do you want to swap keys, or just come up to my pad, one time?" * OLX 2.1 TD * The computing field is always in need of new cliches. --- DCI/Chauncy 0.7 * Origin: Bird Lake - (813)265-3256 (1:377/14.0) SEEN-BY: 100/520 102/890 105/36 125/111 125 180 185 135/71 340 163/438 170/109 SEEN-BY: 216/21 234/1 253/513 261/1136 285/27 312/2 374/14 26 48 98 377/3 14 15 SEEN-BY: 377/33 37 396/1 2200/101 ;; -- tom jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET: tom.jennings@f111.n125.z1.FIDONET.ORG
Re: about a policy to require encrypted email. Here is a statement I would like to see become policy and law: "A provider of communications services cannot be held liable for the consequences of encrypted communications that pass though its system." Here is the argument to support it. If I am a common carrier, I am already off the liability hook by the nature of common carrier. Suppose I am not a common carrier, for example because I provide a value-added service such as electronic mail. Also suppose that I can't observe the contents of traffic that flows through my system because it is encrypted. Then I have no means to take any action whatsoever with regard whatever consequences might occur from that traffic. I cannot be held responsible for actions I cannot take, much less know of the existence of. Such a policy would give BBS operators a complete defense against claims of liability arising from email traffic. It doesn't solve the problem for public discussion areas, but it's a good start. It would also drive the deployment of encryption technology. Eric
"A provider of communications services cannot be held liable for the consequences of encrypted communications that pass though its system."
Far too simple. Suppose the provider is a BBS operator who *knows* what their users are passing through the system? Suppose the provider has keys to the encrypted communications? Suppose those keys are only to be used under duress (e.g. under a court order)? Suppose the provider is a parent and the user is their teenage daughter? Suppose the encryption is easily breakable? 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. The courts are gradually making that happen. But control relates directly to the specific facts of the particular case -- not whether encryption is in use. The case law on liability for content is gradually being made. So far, no particularly horrible precedents have been set (I don't think there are precedents yet in the arrest-the-record-store-owner-for-rap- records-the-cops-don't-like issue). In a good decision, Compuserve was let off the hook for a message sent by someone who Compuserve even paid to moderate a corner of their service -- because Compuserve didn't control the content of that corner. I realize that this group has a tendency toward extremism, but let's temper that with a bit of wisdom, too. John
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
The Compuserver decision some months ago supported this indirectly: Compuserver was held not liable for mail and postings on their system, because they don't claim to read them. I don't beleive Compuserve is a common carrier, so the precedence supports the result you want. dean
participants (4)
-
Eric Hughes
-
gnu@cygnus.com
-
Tom.Jennings@f111.n125.z1.FIDONET.ORG
-
tribble@xanadu.com