Slashdot Mirror
Liability and Computer Security
Pelerin writes "In the latest
Crypto-Gram,
Bruce Schneier has written an interesting essay with some thoughts about the current lack of business incentives for
the deployment and production of more secure software. His main recommendation/prediction is this: "Step one: enforce liabilities. This is essential. Today [...] the marketplace rewards low quality. More precisely, it rewards early releases at the expense of almost all quality. If we expect
CEOs to spend significant resources on security -- especially the security of their customers -- they must be liable for mishandling their customers' data. If we expect software vendors to reduce features, lengthen development cycles, and invest in secure software development processes, they must be liable for security vulnerabilities in their products." Schneier's five-step plan for thinking about security is also good.
Pelerin continues: "All well and good, but this raises some questions in the case of a company offering security solutions based on open source / free software.
- Where does the chain of liability end? Can somebody attempt to recover damages from Linus when a kernel security hole shows up?
- Can a case be made for lower insurance rates for free software solutions? (I mean, can it be made to the accountants and the lawyers, not the techies).
- When liability enters the picture, which mechanisms can allow free software to compete based on its merits, not on the likelihood of surviving a liability lawsuit?
It would be amusing if a HUGE sticker were required to be slapped on the outside of software boxes containing such licenses, stating that "Food for thought: The publisher of this product would like you to know that he feels entitled to FUCK OVER YOUR COMPUTER AND ALL ITS CONTENTS and he won't owe you a dime."
In big alarming black-on-yellow letters.
Pity it'd never happen, but...
Only the dead have seen the end of war.
It seems to me that this is exactly the kind of test case that needs to be looked at when discussing legal liability for software. If the patch is available, how much of the responsibility is on the administrator to apply it and how much is on the software company not to have written the buggy code in the first place? You can certainly argue that the availability of the patch should exempt the manufacturer from liability, but just how long does the patch have to be available to count? Is it acceptable if the patch is only available one month before the exploiting code shows up? One week? One day? One hour? Or should software authors have an affirmative responsibility to send patches to users, the same way that car manufacturers have to contact their buyers in the event of a recall? Who is liable when the patch is available but unapplied is the really interesting issue, not who is liable when no patch is available.
There's no point in questioning authority if you aren't going to listen to the answers.
This insurance will get much cheaper if you use good systems and have the required competence to make them secure.
Some problems will have to be resolved by the legal community:
The last point is important, since you are only responsible for problems caused by your equipment, as long as they are not due to some criminal action by somebody else that you could not easily detect.
To stay with the car analogy: If somebody sabotages your brakes in a way you don't notice until they stop working, accidents that result may not be your responsibility.
An additional point: While a car manufacturer has certain responsibilities, not everything that can go wrong is their responsibility. Only things they claim or are required by law to claim have to be backed up by their product. If you hit a tree because you don't know how to drive or if you start sliding on ice, that is certainly not the manufacturer's fault.
In the case of software this gets a little more complicated, as there is no "unit" of software. My feeling is that Manufacturers will not face legal requirements for characteristics their software will need to have, because such characteristics might be impossible to specify (not saying people will not try). Instead I think that cheap "computer operation insurance" will only be available for products where either the Manufacturer takes legal responsibility for some characteristics of the product or where the insurance companies have a strong indication that the pice of software has these characteristics.
I also think that Computer Scientists and other people that produce code and systems will have to have a kind of "Malpractice Insurance" whenever they commercially create code for others.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
It's worth recalling that the proposed changes to UCITA (since only two states were dumb enough to immediately adopt the original model law) contains a truly incomprehensible couplet.
Commercial contract can waive all liability. I seem to recall that the "technical self-help" measures (which allows them to write software that actively damages your system if it thinks your license has lapsed) has been removed, but it still gives them broad rights to gag you when you try to report problems, to falsely claim others haven't reported problems, to falsely claim that the problem either doesn't really exist or has been fixed, etc. It can do all of this because you handed over hard cash and a bona fide contract exists. (I'm not so sure it's bona fide - a contract requires an *exchange* of items of value, and I don't see much value in this software.)
In contrast, free software isn't covered by a contract (since no money was exchanged) and UCITA explictly requires that warranties apply.
This means that Microsoft (to pick a company at random), a company with billions of dollars in the bank and easily able to afford decent product testing, gets a free walk. Meanwhile Joe Sixpack, a professional programmer who released a simple "scratch my itch" program, can lose his house in legal fees defending himself even if he ultimately wins the court cases.
The commentators (UF law professors, working under the aegis of the ACM?) suggested that the voting delegates seemed indifferent to this indefensible state of affairs. Hopefully they'll either fix it, or the lawmakers in the various states will quickly realize that UCITA 2.0 is just as bad as the original.
But it's something that MUST be considered whenever we talk about the need for liability law to start applying in the software world. We can see the importance of having your own source code, but the people who would actually write the laws are still hearing from Microsoft et al, not us.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
This is very different from designing bridges or buildings, for example, where the thousands of decisions going into the design tend to reinforce the basic premise of its fundamnetal soundness. The mathematics of each calculation are usually verified by calculations done during other parts of the work. Due to this feedback, systematic failures are extremely rare, and when they do happen, often end up showcased on History Channel programs such as "Engineering Disasters".
But it is possible to write secure software through good software engineering practices. Unfortunately, not many people seem to understand them. Only a few individuals like Dan Bernstein can consistently and effectively write secure software, and will guarantee that it is secure.
If software was thoroughly designed from the start before any code was written, the same as with normal engineering projects, then perhaps more software would be secure. If you look at his guarantee for qmail, then you'll notice that he followed several principles throughout the design and implementation that allow him to guarantee that it is secure. If software engineers become liable for their work in the same way that traditional engineers are liable, then maybe software engineering will become more like traditional engineering.