Slashdot Mirror
Cure For Bad Software? Legal Liability
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."
if we have software liabilities then we also open "Open Source" software to liabilities....
It would be crazy to say that "Open Source" have no liability while "Closed Source" do...
-- Note: These Comments are Generated by ME! Not You! ME!
Should such a situation come to pass, the fallout would include:
1) Higher development costs
2) Far fewer small companies in consulting
3) Shrinking job market for new grad coders
4) Larger legal costs on both sides on the fence
On the brightr side, it would also include:
1) Lessening of age discrimination - experience outweighs youth
2) Alteration of programming education to focus on security
3) Higher standard of programming excellence
4) Self-policing. Companies who fail to adhere will run themselves right out of business in short order.
Finally, legal liability for Open Source projects is not a bad idea at all.
Any liability law should offer an exemption for software that is distributed along with buildable, commented source code.
The reason is simple. The end-users of open source software are in a position to verify the integrity and correctness of the software. Even if such an end-user is not a programmer, they could, if they were concerned, pay someone else to inspect the code. They have been provided with the ability to protect themselves, because the source code accurately describes the actual operation of the product.
The end-users of proprietary software are in no such position. They are absolutely dependant on the software vendor to verify the integrity and correctness of the software. They are powerless to protect themselves, and without the source code, they are only left with a representation of the operation of the product. This is far less information then the source code, which specifies the actual operation of the software.
Therefore, only proprietary software vendors should be held liable for bugs in their software.
Comment removed based on user account deletion
For example, If I buy a car tire from firestone, but instead use it on some home-build dune-buggy that I use to drive over lava fields in Hawaii and the tire blows (flipping me into the lava) should Firestone pay? I wasn't using the tire according to the specs that they call for the tire.
Imposing liability on software will only force software manufacturers to list hardware/software configurations on which they are willing to accept liability. If you use the software outside of that configuration, then you're on your own. My guess is that this would disqualify just about everybody, as they'll only be able to certify a limited amount of equipment (as it will entail actually owning that equipment to test).
I mean, would you accept liability on a product that can be used on a multi-use computer that may have god-knows-what software/hardware config?
So this will lead to something like:
Which then just gives software companies even more reason to offer less support, as they'll then only need to offer support on their specific hardware, or risk the liability of condoning the use of their software on unsafe/untested environments.
Think about it.
As a programmer, I have often given a simple explanation of why I can't write reliable software. On most vendors' computers (Microsoft obviously, but also Sun, HP, IBM and most of the rest), the inner workings are totally hidden from me. I can't even in principle know what a lot of my code will do in all cases, because I much make calls to the underlying system and its libraries, and the code for these things is a proprietary secret.
What I usually use as a parallel is: Imagine that the people who built buildings or bridges were required to use commercial steen and concrete, but the specs for these materials were trade secrets. Imagine that construction firms had to use whatever material was delivered, and were not permitted to see its specs. There would be no way that anyone could calculate the effect of loads and stresses, and things would fall down under load.
This is how software is built.
On Open Source systems, it's somewhat different, because the source is available. But even there, you can only understand the system "in principle". You usually don't have the time it would take to thoroughly investigate all the components that you use. Open Source software does generally work better, true, but it's not because every programmer has examined every piece of the source. It's because a lot of them have examined a few pieces, and they can tell each other about problems (and fix them).
This probably has significant legal impact. Consider the construction parallel again. If I design a structure and specify materials of a certain quality, those materials are used, and the structure collapses, I am probably liable. But if the material vendors substitute material with different properties (usually for cost reasons), all I need to do is show in court that the material didn't meet my specs. I'm not liable, and the vendors end up facing some serious fraud charges.
With software, this sort of fraud happens routinely, with all sorts of system components that are delivered knowing that they don't do what the manuals says they do. Or the vendors don't even bother checking that things work right, because they know they can't be held liable. Then people hire programmers like me to write software using such shoddy systems, and expect us to write reliable software on top of it. Then it turns out that some parts of the system have "undocumented features", and the code doesn't work right.
Until we find a way to force reliability on the Microsofts and Suns and IBMs of the world, the way we have with companies that sell steel and concrete, there's no way whatsoever that programmers can ever write reliable software.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Second of all, the RFC really has no force given the RFC language. The two key provisions, that companies SHOULD fix holes within 30 days, and that customers SHOULD apply patches in a timely manner, can both be ignored since "SHOULD" in RFC-speak is different from "MUST".
Thirdly, this RFC is a bit too targeted at Microsoft:
1) The Vendor SHOULD ensure that programmers, designers, and testers are knowledgeable about common flaws in the design and implementation of products.
2) Customers SHOULD configure their products and systems in ways that eliminate latent flaws or reduce the impact of latent flaws, including (1) removing default services that are not necessary for the operation of the affected systems, (2) limiting necessary services only to networks or systems that require access, (3) using the minimal amount of access and privileges necessary for proper functioning of the products...
This is too "ripped from today's Microsoft headlines". This stuff about removing default services is bogus. Something like UPNP in Windows (designed to makes things easy for novice users) is useful only if it is turned on by default. Anyway what does "not necessary for the operation of the affected systems" mean. You can run Linux without a GUI...so if an exploit is found in KDE or Gnome will someone jump up and say, "You enable the GUI by default and it wasn't necessary and you violated the RFC"? The solution to flaws in UPNP to not ship with them, not to disable everything in the box.
Fourth, what the heck is this supposed to mean:
7) The Customer SHOULD give preference to products whose Vendors follow responsible disclosure practices.
Can we please keep the social engineering out of the RFC -- this is an absurd requirement to put in there. Why not just say "Customers SHOULD give preference to open source software because we think it's k3wL"?
- adam