Slashdot Mirror
Should Developers Be Sued For Security Holes?
An anonymous reader writes "A Cambridge academic is arguing for regulations that allow software users to sue developers when sloppy coding leaves holes for malware infection. European officials have considered introducing such a law but no binding regulations have been passed. Not everyone agrees that it's a good idea — Microsoft has previously argued against such a move by analogy, claiming a burglary victim wouldn't expect to be able to sue the manufacturer of the door or a window in their home."
I think excessively poor software should result in some form of negligence ... but general “can happen to anyone” type bugs.. no.
You can buy software with a (real) warrantee attached. In general this costs a fuck tonne of money because they are accepting a fair amount of liability. Even in a very horizontal market, the price increase for accepting that liability is going to be way more than anyone can afford.
You get what you pay for. Want software that is very secure and unlikely to have serious bugs.. you can get it.. but it’s gonna cost more than you are willing to pay if you don’t really _need_ that level of support.
If it was possible to prevent all security holes, this wouldn't be a bad idea. However, it is provably impossible to do so. This would just create a new inurance industry, profiting from others' mistakes. It would really only serve to cut down on development, especially from small companies and individuals that couldn't afford to make a single security mistake (or insurance against lawsuits).
What we need is more and richer lawyers and frightened software developers with malpractice costs bigger than doctors. Perhaps we can eventually make sure all code is only developed by giant corporations made up primarily of legal defense teams dedicated to patent exploitation and liability control with tiny development arms tagged on the end.
Interesting choice of words there!
There's no -1 for "I don't get it."
You can not sue a door or window manufacturer for failure of your action (leaving the door / window open).
You should be able to successfully able to sue a door / window manufacturer for failing to provide the request product (i.e. seal the opening).
That then hits the ugly question of what is "reasonable". Did the manufacturer provide a reasonable product that provided the expected level of security?
If software development was an official engineering discipline that required P.Eng designation, then maybe this case would have more legs. Even then I'd be in disagreement. Otherwise, hell no, HELL NOOOOOOOOOOOO!!!!!!! That is definitely one way to drive people away from a career in software development. This actually seems like a sneaky way for management to evade culpability if their product harms a customer/user.
Sue the actual developer? How would you propose to do that if they're working for an incorporated company with limited liability?
Drill baby drill - on Mars
It'll have very little impact on actual code quality.
All that will happen is:
- software prices will increase
- a whole insurance industry will spring up around it (think malpractice insurance)..
- people will specifically seek out stuff developed by small shops and try to break it specifically so they can sue..
- producing software will become so expensive and require so much up-front investment that indie devs will be SOL
- the big guys will keep producing shit, and just protect themselves behind lawyers (and feed the cost back to the customer)
Why should FOSS get a bye? What user really has the time to validate the code, line by line, to search for security weaknesses BEFORE using it? No. Users expect the software, free or commercial, to work as advertised. And, given the "superiority" that FOSS pro-ports over commercial software, maybe they should be held to an even higher standard? Didn't think you'd want to go there.
In many ways, FOSS would find itself encountering lawsuits despite the "good samaritan" approach it provides. Loss, whether it be from something you paid for free, is still a loss and, in our litigious society, fair game.
No, leave it to an academic to propose making individual developers liable for each line of code they right. This will destroy the entire IT industry (and, most institutions) in a sweeping blow. Who could afford the "malpractice" insurance given the wide-spread dissemination of most commercial and FOS software?
They aren't talking about suing the individual programmers, they're talking about suing the software companies. Specifically, they want to disallow this kind of language very common in EULAs (this is taken from an actual EULA, name omitted to protect the guilty):
_______ and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this product, including all implied warranties and conditions of merchantibility, fitness for a particular purpose, title and non-infringement. In no event shall _______ and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use of this software.
The translation of this clause out of legalese is "No matter what happens, you can't sue us, we're not responsible. We don't promise that this software is even remotely like what we advertised it to be."
I am officially gone from
OTOH a professional engineer differs from a software developer in one key way: he can't legally be overridden on safety matters. If management orders him to use steel that doesn't meet spec for the bridge's designed load, he can refuse to sign off on the plans and if the company tries to fire him the company is the one who'll end up in legal hot water after he reports them. If you want to make software developers responsible in that same way, you need to give them the same authority and immunity to repercussions for using that authority.
Just like anything else, pay for whatever guarantee you desire. If you want your software created in record time, for a low cost, then the bugs are a part of the equasion. If you want secure coding, then you'll get to pay for it in time and money. It's always been that simple. You don't sue the manufacturer of your house door, but you do sue the manufacturer of your bank vault door. The difference in cost is tremendous.
It's rare that my clients ask for proper security. But for the elements that they do indeed want to protect, they pay for me to do my very best work. And you'd better believe that they hold me responsible and often accountable for significant problems should they result.
But in the end, it's all just insurance anyway. If a client of mine wants a particular e-commerce feature to be super-secure, then they'll ask me to pay for any dollars lost due to bugs. I know that I'm not perfect, and of the thirty possible bugs, there's a small chance that I'll fall into one or two of them, and a partial chance that I won't catch it before it's exploited. So while much of the added price is for me to sit there and check things closely, the rest of the added price is for me to accumulate in the event that I need to pay it back. Over multiple clients and multiple exploits, that's the only way to do it.
The obvious alternative of checking things even closer winds up being far more money, and is only really relevant when physical safety is an issue.
While OSS zealots like to think it is bug free, it isn't. Bugs can and do happen in OSS. Well who the hell is going to contribute to a free project if they know they can be sued for it?
Also it would lead to way less flexibility in software. Vendors would restrict what you could run and how you could run it. That is what you find in real high end systems where problems aren't ok. They are very expensive, they only do what they are designed to do, no installing arbitrary software, and upgrades are very slow in coming.
So long as you want your system to be the wild west where you can install whatever you like, use it in any way you like, and be nice and cheap then you have to accept that problems can and will happen. If you want verified design you can have that, however you need to be prepared to pay the price both in terms of money and in terms of restrictions.
As a professional engineer in a closely related field (industrial control systems), I disagree. What is required is a degree of rigour in design to remove systematic errors as much as is humanly possible. Engineered products still fail, and end-users may sue, but the test is simply whether the engineer, or developer in this case, took all *reasonable* measures to limit errors.
Long overdue in the software development profession, IMO. It's time we grew up.