Date: Fri, 10 Oct 2014 00:12:28 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: liability (was: Re: Thoughts on Shellshock and beyond) I ended up writing a lengthy message (this one), but I am unsure if it's a good idea to have this topic discussed once again (such discussions had already occurred on other mailing lists years ago). In fact, that's the main point I am making - while I've just spent/wasted some time on writing the below, maybe we should stop right here? So if anyone has something new or some important historical references to add, please feel free to post, but I'd rather not see us digress into (I think) mostly irrelevant analogies in financial markets, with even more irrelevant detail on the French trader (referring to Sven's other posting here). I mention some paywalled articles below. If anyone has URLs to free copies of those, please post. On Thu, Oct 09, 2014 at 11:11:34AM +0200, Sven Kieske wrote: > so at least when you're making money of software you should > be responsible for this software. That's tricky. Is an Open Source project that accepts donations, sells CDs/DVDs, or/and runs ads on the website "making money"? What if they also offer related paid services or even occasionally sell commercial licenses to the same software? Would they be liable e.g. for up to all payments they ever received (or more?), even if 99.9% of the users never paid anything? That may easily put them "out of business", or discourage them from starting the project in the first place. Of course, you can hope to reduce undesired effects of a new law by careful wording, listing categories of software it does or/and does not apply to, etc. However, getting the legal system involved at all is a huge risk... yet you'd like to use it to reduce risk elsewhere? The legal system is already akin to an over-engineered software program, and you're proposing to make it even more complex (more buggy, and requiring more resources to run). What's worse, you don't get to write that "program", and you can't replace it on your "computer" with some alternative (short of moving to another jurisdiction, and even that option might disappear if the law becomes universally accepted). You can request a "feature", and if the powers that be listen, they'll implement that "feature" in some arbitrary way that you might not like, yet all of us would be stuck with it. In my opinion, this is extreme danger, possibly way beyond the risk from software vulnerabilities (to the extent that risk could be reduced by such measures). Indeed, these are different types of risks, so a direct comparison of this sort may only make sense in specific contexts (e.g., effect on a country's economy or on people's quality of life analyzed in some specific way). I am not saying I am strictly against this approach, although that is my current stance given the (frankly) rather limited impact that software vulnerabilities actually have on us so far despite of being widespread. (I think the negative impact of introducing liability for software vulnerabilities might well be broader.) What I am saying is that it's a really tough tradeoff, and that in my opinion anyone who feels confident about it is either wrong in being so confident or has values different from mine. > that's also not just my opinion (and I didn't invent these > thoughts), some credit has to go out to mr Schneier who > you might happen to know ;) > > see: > > https://www.schneier.com/essays/archives/2003/11/liability_changes_ev.html Oh, this is definitely an old topic, much older than 2003, although that was a year when it was discussed more. There were two related articles published in IEEE Security & Privacy, 2003 vol.1, Issue 1 - January-February: http://www.computer.org/csdl/mags/sp/2003/01/index.html Two Views on Security Software Liability: Let the Legal System Decide Daniel J. Ryan , Law Offices of Daniel J. Ryan pp. 70-72 Two Views on Security Software Liability: Using the Right Legal Tools Carey Heckman , Darthmouth College pp. 73-75 Here's the abstract for the first one of these: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1176999 "Rather than use the product liability screwdriver as a chisel, why not consider a package of more effective tools. Corporations and individuals that market software despite knowledge of software security flaws should face criminal prosecution as well as civil lawsuits with punitive damages. Perhaps bounties should be available for the first to discover and establish the existence of a security flaw. Publishers should be required to post to the Web and otherwise publicize promptly patch availability. The software equivalent of an Underwriters Laboratories should establish and constantly improve security-related standards and testing protocols. It should be made readily apparent whether a program has passed and at what level. Prospective customers should be educated and encouraged to insist on software that has passed. Stronger software security is important. Software developers and publishers must do better. But product liability is not the right legal tool for the job." To me, this suggests a much more limited use of the legal system: with liability only for continued marketing of software with security flaws already known to the vendors. Even that, though, is incompatible even with current best practices, where vendors of any large piece of software almost constantly have some vulnerabilities (and fixes for them) in the pipeline, yet they don't stop marketing the software during those periods (which would be almost all the time, and would ruin their businesses). I haven't read the actual articles. Anyone found them non-paywalled? This presentation appears to argue in favor of strict liability and backs this up with some theory: http://www.slideshare.net/aliasnetwork/software-liability Open Source is briefly mentioned on slide 10. I think it fails to consider (at least) the negative impact extra regulation will have on innovation. To limit liability risks, a software product would need to be compliant with current best practices, not with potentially better practices that are not yet widely accepted and would necessarily be considered at least good by courts. [ While we're at it, I think the same problem - negative impact on innovation - applies to another old idea, insurance for IT-related risks including security compromises: http://fearlesssecurity.com/cyber-whatever-that-is-insurance-yet-again/ Worse, besides innovation this would also discourage diverse setups - e.g., use of less popular operating systems, which insurers have no statistics on and don't want to bother with - even though these setups might actually be safer from actually occurring attacks (at least the non-targeted ones) precisely due to the diversity. ] Some maybe-relevant historical publications: http://link.springer.com/chapter/10.1007/3-540-58618-0_67 Liability and computer security: Nine principles Ross J. Anderson Proceedings of Third European Symposium on Research in Computer Security Brighton, United Kingdom November 7-9, 1994 pp. 231-245 Here's the abstract: "The conventional wisdom is that security priorities should be set by risk analysis. However, reality is subtly different: many computer security systems are at least as much about shedding liability as about minimising risk. Banks use computer security mechanisms to transfer liability to their customers; companies use them to transfer liability to their insurers, or (via the public prosecutor) to the taxpayer; and they are also used to shift the blame to other departments (we did everything that GCHQ/the internal auditors told us to). We derive nine principles which might help designers avoid the most common pitfalls." A related thought is that if vendors would be liable for software vulnerabilities, they'd want to proactively turn those into non-vulnerabilities as far as the law is concerned, by proactively transferring liability onto other parties (their customers, etc.) Right now, they can do it in EULA. If they would be legally barred from that, they might find other ways. For example, rather than say "We disclaim all liability" in the EULA, the program could have e.g. execution of arbitrary code from e-mail messages described as intended behavior that the user authorizes. OK, perhaps that would impact the vendor's sales, if their competitors don't do the same. But possibly they'll find smarter ways, including those that would use "computer security mechanisms" (as the above abstract says) - just not those protecting the users, but rather those helping transfer liability away from the vendor. Some older publications I happened to find, apparently by lawyers: http://heinonline.org/HOL/LandingPage?handle=hein.journals/rutcomt8&div=16 Product Liability and Software Michael C. Gemignani Rutgers Computer & Tech. L.J. 1980-1981 p. 173 http://www.jstor.org/discover/10.2307/40684795 LIABILITY FOR COMPUTER SOFTWARE BRUCE DUCKER The Business Lawyer Vol. 26, No. 4 (April 1971) pp. 1081-1094 Unfortunately, these are also paywalled. Most discussion on infosec mailing lists that I can find now is from the period 2000 to 2005, although I vaguely recall seeing this topic brought up in 1990s as well. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.