Not a good idea...
At 10:35 PM 3/7/96, owner-cypherpunks@toad.com wrote:
I wonder whether they've actually considered the liability situation in re: blocking sites that shouldn't be blocked? I mean, sure, they seem nice enough about setting things right (like with the Nynex sites whose url's had "xxx" in the paths), but it seems to this non-lawyer that a case could be made for damages inflicted by being known as a purveyor of filthy indecency for even a short while.
We need to be very careful here. A service like "SurfWatch," voluntarily used by others, has entered into no contracts with sites to meet defined standards of what should and shouldn't be blocked. It is essentially a "review" service, like a reviewer of books, movies, restaurants, etc. Sure, some books, movies, and restaurants are "hurt" by negative reviews, but this is life in a free society. It has not yet reached the point in these Beknighted States that a bad review can be the basis of a tort (though I could be wrong...nothing would surprise me these days). Let me use myself as an example. "TimWatch" offers to inform people of sites he thinks are not desirable for them to visit. I freely admit that my criteria are imperfect, and people can choose to follow my advice or not follow my advice. I may even sell a software package ("TimWatch") to let users screen sites at their own machines. Now, do we as Cypherpunks really think TimWatch or SurfWatch should be liable for "damages" because someone got their feelings hurt? Absent a contract, spelling out the performance expected, of course not. If SurfWatch can be sued for a "bad review," then Siskel and Ebert had better find a new line of work. --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."
If SurfWatch can be sued for a "bad review," then Siskel and Ebert had better find a new line of work.
I might be stretching things a bit, but couldn't you call a CA a "review service"? Essentially instead of having a banned list, you have an "accepted list". Right now, CAs seem to be all using the same narrow critera for putting someone on the accepted list -- knowledge about the identity of someone running the site. If CAs are liable, then why not SurfWatch? Or better yet, if SurfWatch isn't liable, then why should a CA be? The problem of liability is a real one, at least with a protocol like X.509. Sites need to have certs to interoperate with the rest of the world, and CAs seem to expose themselves to liability by issuing certs. That means that certs are going to cost money, or at least more than they would otherwise. And that could have a chilling effect on the widespread deployment of crypto. As was recently pointed out in another context, security is economics, and anything that adds cost to security means less security for everyone. I think in general we ought to oppose laws which expand liability for things people do online; liability can almost be viewed as another form of regulation. A judgment against a tobacco company would probably have the same effect as an outight ban on cigarettes. What's more, protocols which force authentiion on people who might only want or need encryption aren't good. With liability figured in authentication costs a lot more money than basic encryption. Say what you want about patents, the other main hurdle standing between us and really free crypto, but if we're willing to wait, they'll go away. Our goal ought to be totally free access to crypto tools without legal interferrence, cost (even for commercial applications), incompatibility with dominant standards, or risk of liability.
On Thu, 7 Mar 1996, Alex Strasheim wrote:
I might be stretching things a bit, but couldn't you call a CA a "review service"? Essentially instead of having a banned list, you have an "accepted list". >
Nice try. Wish my students were that creative. I don't think it works, though, at least when CA's represent that their info is suitable for relying parties to use in financial transactions (something Siskel & Ebert do not do!). A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin@law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | It's warm here.
Nice try. Wish my students were that creative. I don't think it works, though, at least when CA's represent that their info is suitable for relying parties to use in financial transactions (something Siskel & Ebert do not do!).
(Sorry, this ends up rambling way off topic at the end... it turns into a rant about preinstalled CAs.) But when did they make that representation? Is such a representation inherent in every CA? If it is, doesn't that imply that the only reason for a CA to exist is to provide trust for financial transactions? It's clear (to me, at least) that there are other uses for a CA. Netscape has represented its products as suitible for commerce, and it doesn't seem unreasonable to argue that this representation gives customers and banks an expectation that a certificate from a preinstalled CA confers a degree of trustworthiness on the cert holder. But a CA that doesn't come pre-installed shouldn't be viewed as having made any implied representations at all. If a CA controls the distribution of its key by asserting a copyright, and if it requires everyone who downloads it to click on a form that says they've read and understand what a cert from that CA means, then that's what it should mean. Suppose I run a Netscape Commerce server, and I set up a secure forms processing service. Anyone can anonymously pay me to set up a perl script on my SSL server to accept their form data. My script will take the data, encrypt it with PGP, and then mail to whatever email address my customer (the web page owner) has specified. Who's liable? Me, Verisign, or Netscape? All of us? I suspect that if I pass credit card numbers to thieves I'll get in trouble, but I don't have any assets. Verisign didn't make any representations directly to the public, and they probably followed the procedure they negotiated with Netscape when they issued me my cert. Netscape put together a complicated high-tech system and told the public (which doesn't understand cryptography) that their system was suitible for commerce -- it's even in the product's name! They didn't build in prudent safeguards to prevent me from running my forms processing service, which is such a trivial thing to set up that it should have been forseen. (Q: I've never gotten a real cert -- do I have to agree to something that would prohibit my forms processing business?) (Could a lawyer asking a jury for a judgment against Netscape show them the picture of Andressen from the cover of Time, the one where he's sitting on a throne, hubris personnified?) It seems to me that the claims of commerceworthiness, preinstalling CAs, and the like are going to turn out to be bad for everyone. They're bad for Netscape because they exposes them to liability unneccessarily. Why should they say their products are suitible for commerce when they can instead say that they encrypt the traffic using what are believed to be strong algorithms? Everyone will make the jump from that to commerceworthiness on their own. What does commerceworthiness mean, anyway? Transcations up to $1,000? $1,000,000? Remember that SSL web tools are begining to function more and more as front ends of other kidns of progrms -- there's more at stake here than credit card numbers typed into forms for consumer purchases. Preinstalling CAs is great if you want to relieve users of the necessity of deciding for themselves who they should trust. You, or a system that you designed, will make those hard decisions for them. But it's not so great if you don't want to be held accountable for almost every single decision regarding trust on the web. It's also bad for those of us who want to see crypto widely deployed on the net. Solid free code exists, but the cost of licensing the patents and buying certs is keeping crypto expensive and slowing deployment. Preinstalling CAs means that a would be commerce server operator has to buy a cert or operate from a competitive disadvantage. It's a significant cost -- the cert is more expensive than the RSA licence. It costs as much as a Fast Track server. The patents will go away. When that happens, the only thing preventing totally free crypto will be the cost of the certs. I suspect that Netscape started thinking about the CA system, they were selling SSL servers for around $2,000. A $300 cert isn't such a big thing in those circumstances -- there's not much of a marginal difference between $2,000 and $2,300. But now the price of a server is only 15% of that $2,000, and the price of the cert looks awfully high. What will it look like when SSL web servers are free? Finally, it's bad for consumers. Apart from the obvious observation that the cost of the certs will get passed on to consumers, it's important to note that it costs money to have someone else decide who you should trust. The quality of that decision making affects its cost, and it should be the marketplace, not a handful of corporate managers, that determines where the optimum price/quality point is. Different customers ought to be able to make different choices depending on their needs. That choice is possible now in an abolute sense, but managing CAs will be confusing for users, and Netscape's preferential treatment of certain CAs will clearly hinder open competition among CAs. It will also tend to impose an unnatural homogenity on users who have different security needs. A guy who never buys anything online but wants to be able to browse web pages without his ISP knowing what he's looking at has different security needs from another person who does most of his shopping on the web. Security *is* economics, and it's important to keep the floor as low as possible. The current CA system is one of the main things keeping the floor higher than it ought to be.
On Fri, 8 Mar 1996 13:14:25 -0600 (CST), Alex Strasheim <cp@proust.suba.com> wrote:
Who's liable? Me, Verisign, or Netscape? All of us?
I suspect that if I pass credit card numbers to thieves I'll get in trouble, but I don't have any assets.
Verisign didn't make any representations directly to the public, and they probably followed the procedure they negotiated with Netscape when they issued me my cert.
"For secure servers, VeriSign currently offers a 'high-assurance' Class 3 Digital ID for electronic commerce servers. " This is from Verisign's home page. They are saying that this class of certificate is safe to do commerce with.
Netscape put together a complicated high-tech system and told the public (which doesn't understand cryptography) that their system was suitible for commerce -- it's even in the product's name! They didn't build in prudent safeguards to prevent me from running my forms processing service, which is such a trivial thing to set up that it should have been forseen. (Q: I've never gotten a real cert -- do I have to agree to something that would prohibit my forms processing business?)
I would think that netscape would only make agreements with CAs that accepted liability. I would also think that Netscape would only be liable if they were found to have put in a CA that they had reason to believe was not taking due diligence to ensure that the key really belonged to the company that claimed to own it. Dan Weinstein djw@vplus.com http://www.vplus.com/~djw PGP public key is available from my Home Page. All opinions expressed above are mine. "I understand by 'freedom of Spirit' something quite definite - the unconditional will to say No, where it is dangerous to say No. Friedrich Nietzsche
participants (4)
-
Alex Strasheim -
djw@vplus.com -
Michael Froomkin -
tcmay@got.net