Cure For Bad Software? Legal Liability 456
satch89450 writes: "SecurityFocus had a column that I missed when it was first published a few days ago, titled 'Responsible Disclosure' Draft Could Have Legal Muscle, but I discovered it when researching an answer to a comment on the CYBERIA mailing list. In this article, Mark Rasch discusses how the Draft would set the rules for reporting security vunerabilities, and in particular define the boundaries of liability assumed by bug-disclosers. By adopting a "Best Practices" RFC, the IETF could help the reporters of security-related bugs do their job, and put the onus of fixing the bugs on the vendors who make the mistakes, where it belongs. (The RFC draft described in the article, 'Responsible Vulnerability Disclosure Process, is here at the ISI repository.) This is, of course, in direct opposition to the process that Microsoft's Scott Culp, Manager of the Microsoft Security Response Center, would like to see. As Microsoft is more part of the problem than part of the solution, I believe that the path to a formal process would better serve the entire community - and that community includes Microsoft's customers. I'm taking this seriously because the mainstream press is talking about the issue, and what it's going to take to fix it. Here is an example from BusinessWeek that scares me silly. I'm glad I'm looking to change careers from software development to something safe, like law."
Re:Open Source Software As Well (Score:3, Informative)
IMHO, even as buggy as Microsoft's software is, they are the best suited to defend themselves. In a liable industry, they might stand the best chance of surviving.
Re:Open source and liability (Score:1, Informative)
It is like somebody giving out free basketballs. If the free basketballs were made with defects, you have no basis for forcing the giver to fix your basketball. They have incurred no legal duty to you. There is no quid pro quo.
OTOH, if you paid for the basketball at a sporting goods store, the store and the manufacturer are liable for any defects in the product.
Scythe
Re:careful what you wish for (Score:4, Informative)
As for the duty - the draft RFC says the company has the duty to disclose and either provide a patch or admit there's no fix. This proposal doesn't aim to create better software from the beginning, only to inspire software companies to quickly and responsibly respond to reported vulnerabilities. So, in essence the software company is not liabile for the trashcan software's initial release. What if there's no fix? If the company admits it as the RFC calls for, does the whole thing stop there, no liability? Also, the RFC rests on the premise that the vulnerability is reported to the company, but not publicly. If someone finds a bug and decides to report it publicly, is the company excused from responsbility because the reporter didn't follow the RFC process? That's one huge loophole.
The biggest problem in my mind is damages. Even if the RFC becomes a legally recognized standard of care and the software company drops the ball, what's the loss? Except for critical systems used, for example, in medical facilities or some such that might get someone killed (Mr. Rasch's unsafe car analogy is a red herring; generally, the security holes in software don't put my life at risk), it's generally going to be lost data and the person-hours required to restore it, perhaps lost business during the downtime. The damages will be pulled out of the sky by some bean-counter.
Tort law (liability for you non-law talking types) generally involves the concepts of assumption of risk and contributory negligence as well. How far will this proposal go in forgiving the people who aren't keeping backups of their critical data but lose it due to some reported vulnerability the company did not correct? Are these irresponsible users excused because the programmer missed a bug or security hole? What about Company X's system that gets hacked through some glaring security exploit and my personal information gets swiped. In addition to Company X suing the software company, am I also eligible to sue?
Many of us protest everytime a cracker's jail sentence and fines are jacked through the skylight based on some victim company's astronomical estimate of the "loss" from an attack where no actual damage is done, but some files are swiped. A security breach by some acne-faced script kiddie isn't worth $1 million - what's good for the goose . . . The hackers (non-perjorative) of the world will become what they have beheld.
Best Practices and voluntary standards are great, but the liability bandwagon has travelled too far already. Accountability in software should be driven by the market, not the courts. When someone sells worthless software - stop buying from them. We don't need something more to sue people over.
Re:Is good software possible? (Score:1, Informative)
I agree with you about unreliable platforms making reliable software development difficult and have posted a response to a response illustrating problems with SAPI 5.0 (Microsoft speech API).
However, what about API standards like POSIX? Well defined in terms of behavior, arguments, etc. Unlike shoddy libraries from certain companies, POSIX platforms are CERTIFIED to be correct and calls have return values defined for virtually any situation (as it should be). What excuses apply then? Sure, platforms are a factor, but what about when they are not???
Re:Merchantability (Score:3, Informative)
The only software that is licensed is that which is agreed to before any money is paid. If you call up Microsoft and ask for a site license, they can hand you a list of restrictions. If you walk into CompUSA and buy the software, you've bought it free and clear.
(And are only bound by existing law. You can't copy it, but you also can't use it to bludgeon someone with, and not because of any restriction from the vendor.)