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
Sure, let's agree with Prof. Clayton that you should be able to sue developers for malpractice if their code contains security holes.
Then perhaps you should also be able to sue professors, like Richard Clayton for malpractice, if their students are undereducated, or if their papers contain flaws.
You could consider suing developers that intentionally planted backdoors (even if was following NSA or other US government agency orders), but can't target the ones that by weren't aware of them, did by mistake, lack of knowledge or culture, or because things changed (i..e. having/forcing a 8 char password was "good enough" several years ago, not anymore), or even because taken assumptions no longer true by end user choice (how much portals meant for intranets with not specially strong security end being used on internet).
Also, who you sue because a bug in an open source program with a lot of contributes? or against a big corporation that put in legalese that they aren't responsible for any damage or problem that could happen for using it (that is most commercial software licenses)?
As long as you're going to foot the bill for a $500 application that changes your computer's wallpaper.
PEs and PLSs, doctors, psychologists, etc, all carry liability insurance. They're also not cheap. In the 80s, a survey crew cost $100/hr to come out and measure your land with a half-day minimum.
Now apply these costs to software.
--
BMO
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)
It's really time for computer science to grow up and join the rest of the pack. If a mechanical engineer designs a bridge that collapses under normal load, that engineer can be held PERSONALLY responsible for breach of duty. It's long past time for us to stop forgiving shody practices and people making the same old mistakes over and over that cause 90% of security vulnerabilities. Until people are held accountable, there won't be any meaningful change, and we'll keep having a field dominated by hacks and talent-free people without a real understanding of what they are doing.
We NEED this responsibility, and so does the public we serve. They're growing tired of the mess that exists right now. Apple is trying to do better on this front but really it needs to go much futher, and the whole field needs to improve. We've had many decades of ad-hoc cowboy-coders. It's time to start demanding professional behavior.
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?
You realize the most visible open source software projects are built by commercial software vendors? Also, how would you define "sloppy coding" in a law?
-1 overrated isn't the same thing as "I disagree".
If you're going to be adding accountability, be sure of the origin of the security weakness. If it originates in management, in outside requirements or in other ways is part of the contract - the developer shouldn't be held responsible.
Bugs and security vulns are almost unavoidable - but some are due to gross negligence. Gross negligence should always be open to litigation. To follow on from Microsoft's analogy, if a door manufacturer was grossly negligent (let's assume that the door includes the lock and hinges - when this isn't normally teh case), and sold a high security door system, but had accidentally keyed all the doors to a single grand-master key. Then if you were burgled because a burglar happened to find out about this grandmaster key, then potentially you have a claim.
I don't see why it shouldn't be too different in software development. A software vendor needs to bear some responsibilty for good programming practice.
Bad software is everywhere; some is so bad, that it does border on grossly negligent.
As an example, I recently reverse engineered an "electronic patient record" system that was installed at a local hospital. This had a number of interesting design features:
1. Password security was via encryption rather than hashing. The encryption was a home-brew modified Vigenere cipher.
2. The database connection string was stored in the clear in a conf file, stored in the user's home directory. Interesting the database connection used the "sa" user.
3. Presumably for performance reasons, certain database tables (notably "users") would be cached in plaintext to the user's home directory. This way, an SQL join could be avoided, and the joins could be done client side.
4. The software ran an auto-updater that would automatically connect to a specified web site and download and run patches as admin - without any kind of signature verification.
5. All SQL queries were dynamically generated strings - no parameters, prepared statements or stored procedure. Not every user input was properly escaped. Entry of a patient name with an apostrophe in it, would cause very peculiar behavior. In the end, regular memos had to go round to staff telling them under no circumstances to use apostrophes in patient names, and to avoid, wherever possible the use of apostrophes in the plain text entries.
This is by no means all the security problems this software had, never mind the bugs e.g. a race condition when synchronising with a second application which would result in the two components opening different patient's charts.
Amazingly, there weren't any security breaches or significant medical errors as a result of this software - but I can't really conclude that this software production was anything other than grossly negligent.
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
I think the company would be liable, not the individual.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Just because managers hire employees doesn't mean they're in 100% control of who they hire. Managers have supervisors just like everyone else. They have deadlines, too. Besides that, I'm not so sure it's wise to assume that just because you're the one hiring that you somehow control whether you hire talented developers. Last but not least, just because you have a talented pack doesn't mean they either work together well or acclimate to the technologies clientele require servicing with. Same with new hires, too: out of 200 applicants, a manager who hires the one that screened best doesn't imply automatic success because too many moving parts occupy the context. Long story short, it's not all on the manager's shoulders just like it's not all the fault of the developers, clients, etc. All this article is about is some whiny asshole trying to point his fat, stubby finger at someone because he made a bad decision. They're angry, they're pissed, and now someone has to pay their bill. That's all this boils down to.
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.
Even worse is that software is held to a standard that no other engineering field gets held to. That bridge need only function well enough not to completely collapse. Software gets racked over the coals if it has the smallest crack that gets exploited by teams of highly skilled criminals working full time to break the code.
In an up economy, it should be 300.
Did it for a few years. Walking barefoot with your pants rolled up in the middle of winter to locate a stream centerline isn't as cold as it sounds, though.
Hip waders? Bah.
--
BMO
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.
Require liability from closed-source software. Exempt open-source. If you can access the source code, you have the capability to examine the security provided by the software if you so desire to. If you don't have access, you must rely on the assurances made by the company providing the software. If they say "it is secure! trust us..." and provide you no means to verify their claims and it turns out to be false, they should be held liable. You'd need to allow companies to send security fixes though that provide them some sort of protection like "If you don't install this patch within x days, we are not liable for the defects resolved by it"
Developers don't choose when to release software, it's management. Think you need to do more testing but management thinks it looks ready? It's out the door and you cant do anything to stop them. Testing is just as important as coding and the developers dont do all the testing, it's usually outsourced.
Bottom line: if a company doesn't do it's due diligence then yes, they should be responsible for putting out bad software.
Anons need not reply. Questions end with a question mark.
Sure this could be done, Professional Engineers put their asses on the line when they approve designs and Programmers could be held to the same level. This would most likely require devs to go through a similarly rigorous process of training and test taking.
This would also cause a massive drop in the number of available licensed programmers for any work that needs to be done, as well as having Programmers carrying liability insurance. This would cause development costs to get much larger. I seriously doubt half of the programmers in the country are close to prepared to pass any licensing tests.
You seem to have a strange idea about what motivates people to write free software.
I'm a free software developer on my free time. I mostly work on my own projects, but I occasionally contribute random patches to large projects. I write free software for fun, mostly doing things I'm interested at the time. Most software I write have no bad bugs, probably because I write it very slowly, and because stuff I write tend to be very simple. But if I had to go out of my way to ensure that it's impossible for someone to use my program in an unexpected way and crash it, I simply wouldn't do it -- that would take all the fun out of it (of course, I'm more than happy to fix bugs, even when it's a chore, but that's very different than being paranoid about the code you write for fun). Or, more likely, I would keep the stuff I wrote to myself.
Now, one might argue that this applies only to volunteers, and there's a lot of people being paid to write free software. That's true, but there are two problems with discarding all work from volunteers. First, the price of writing certified-bug-free software (if that's even possible) is absolutely ridiculous -- if you don't believe me, you should see how much it costs to write software that controls aircraft, for example. That means that development would be severely affected (less projects, less new stuff, etc.). Secondly, most people being paid to write free software work in a relatively small number of large and well known projects. A typical Linux distribution has hundreds of programs that were completely written by volunteers -- sometimes someone employed by a distribution packages it in a way that plays nice with the organization of the rest of the system. Those contributions would simply vanish, and distributions would be severely affected.
That's why any regulation like what you're proposing would actually lower the quality and quantity of free software, not increase it.
Except the license agreements already say that there's no warranty, express or implied, and that the developer is indemnified against defects. This is usually there in commercial software as well. If you don't agree with that clause, you don't get a license to the software.
BSD license:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
GPL:
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
copy of the Program in return for a fee.
The law would have to be changed to specifically deny that right to the author. If you buy a car, or electronics or something, there may not be an explicit warranty but they usually haven't disclaimed a warranty in advance of your purchase so you can still get the "implied" warranty. The licenses are contracts that are supposed to be entered into after due consideration, so they are allowed to disclaim pretty much anything they want, same as normal contract law. The law would have to be specifically different for software than for most products, and that's a big uphill battle.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
Of course all software is going to have _some_ bugs.
However, if the software is buggy in a particularly egregious way, above and beyond what a rational person would normally expect (like, say, early versions of Outlook), they should have to recall it and offer every single customer their money back. (They could also offer a fix, but the customers should get to decide whether they'd rather have the fix or the money back.)
Obviously, if you take your money back, you are no longer licensed to continue using the software.
Cut that out, or I will ship you to Norilsk in a box.
If you start holding them liable, you can say goodbye to freeware and hobbyist projects.. No one will want the liability that only super corporations can afford to defend.. This will grant microsoft, apple, and the government exactly what they want.
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.
Depends on the manager. It's a myth that managers make more money than developers; usually, the lowest-level manager (the one who directly supervises the developers) doesn't make much more (if any) than the developers. It's the levels above him that get paid exponentially more at each level. The only reason someone goes into management is because either 1) they're not that great a developer, and prefer talking and being in meetings and bossing people around to doing actual work, and/or 2) they want to go higher in management, where the real money is, so this is just a stepping stone.
At the last corporate job I held our managers would frequently push the development staff to put things out before they had been fully tested.
Why punish the people who write the software when often they have an extremely limited amount of control over things?
Businesses selling shitty, insecure software should absolutely be held accountable. Individual developers within those businesses being directly liable? No way.
Why not hold each factory worker who was responsible for a round of ammunition or piece of a missile liable for murder when a drone strike takes out a civilian?
Hold the people responsible for making decisions responsible, not the people who are just putting things together.
Since I can't tell them apart, I treat all ACs as the same person.
You may not be able to just take any program and prove that it works, but you can construct a program of your own in a way that it is possible to prove that it works; actually what you do is the proof and then in best-case scenario extract the machine code from that.
Of course, doing this is still very costly: 7500 lines of C-code can take 200000 lines of Isabelle proof code:
http://ertos.nicta.com.au/research/l4.verified/numbers.pml
So, how does the price of a typical industrial control system compare to the price of typical boxed software for popular platforms?
Why does that make incompetent software developers any less responsible for the bugs in their code?
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
No?
I just want anybody that earns money producing software to be able to demonstrate they were using sound engineering practices. You know, like manufacturers of food, medical goods, building materials, cars, etc. The current state of a lot of software is a disgrace, and the problem is companies earning boatloads of money without any liability if quality sucks. As soon as a company can prove they were not "sloppy", residual bugs become accidents and do not make you liable unless specifically arranged contractually.
Yes, there is a huge gray area here and in particular the US legal system seems to be ill prepared to deal with it. Not any system is this broken though. The standard in the EU is that if you used practices that are not state of the art, you may become liable. But lawyers only get standardized fees and no part of any compensation. And compensation only compensates, absolutely no chances to get rich. That stops gold-diggers in their tracks early on.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
OK, they might have taught you that in college. But they didn't necessarily teach everybody that.
In any case, every there's a post about college on /., most posters come out to say that college isn't about learning the specifics of development (like frameworks, SCM, etc.). It's about learning the theory of computer science. Learning minutiae is for trade school.
If that's the case, then people who studied the science of computing would have no clue about SQL injection. There's really no place you'd be able to learn, except if 1) you happen to get a good mentor at your first job, or 2) you happen to read about it on the Interwebs.
I'm not a lawyer, but I play one on the Internet. Blog
Obviously you shouldn't be using eval() on user input. That should be pretty obvious to everyone with the slightest bit of programming knowledge.
eval() is always risky, everybody who knows about the existence of eval() has to know that you shouldn't be using it recklessly. If there's any PHP framework that does use eval() on user input, then its maker should be banned from ever programming anything in his life ever again.