Forgot your password?
typodupeerror
Crime Programming The Courts

Should Developers Be Sued For Security Holes? 550

Posted by samzenpus
from the who's-to-blame dept.
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."
This discussion has been archived. No new comments can be posted.

Should Developers Be Sued For Security Holes?

Comments Filter:
  • Nah (Score:5, Insightful)

    by Anrego (830717) * on Thursday August 23, 2012 @06:41PM (#41102783)

    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.

    • Re:Nah (Score:5, Insightful)

      by Mitreya (579078) <mitreyaNO@SPAMgmail.com> on Thursday August 23, 2012 @06:52PM (#41102925)

      excessively poor software should result in some form of negligence ... but general âoecan happen to anyoneâ type bugs.. no.

      And how do you define the difference?
      Based on the quality of code?
      Based on the amount of unit testing that was (provably) performed?

      This will start a slew of software that is only warranted under specific OS/software configurations (and then installing an aggressive anti-virus or not error-checking your RAM chips regularly would void your warranty).

      • Re:Nah (Score:5, Interesting)

        by Shikaku (1129753) on Thursday August 23, 2012 @06:58PM (#41103029)

        Simply requiring encryption when handling something sensitive like credit card info is a start. See: Sony and the PSN disaster.

        • Re:Nah (Score:4, Insightful)

          by tomhath (637240) on Thursday August 23, 2012 @07:18PM (#41103261)
          So how do you define "sensitive"? There's no end to it; once you open the door a good lawyer can can convince a jury anything.
      • by Anrego (830717) *

        That of course is a huge issue.

        Realistically you would need a standard (or set of standards) defining what "secure software" is... and good luck with that!

        I would venture that in the case of a huge vulnerability, the company would be required to show "what they did" to secure the software (what kind of testing they did, review, etc..) and a jury would decide if they were negligent (excessively negligent would be the lead dev cracking on the stand about how the boss kept shouting "ship it or you get the cane

      • by DJRumpy (1345787)

        You don't define the difference. We already have mechanisms under law to handle such as this.A good example would be cases where someone's computer was damaged by a virus scanner that quarantined a key system file and caused a failed boot condition. Those consumers could sue the company for losses associated with getting their computers fixed. It could also escalate into a class action lawsuit. I would think the same recourse is available to an enterprise.

      • excessively poor software should result in some form of negligence ... but general âoecan happen to anyoneâ type bugs.. no.

        And how do you define the difference?

        A.Some things can simply happen (using < when you meant to use <=). Or obscure bugs that manifest themselves as corner cases between many components. Those are the "general, can happen" types.

        B. There are others that are simply not acceptable given how much knowledge we have acquired in the last 40 years. Things that are simply erradicated by using widely accepted coding techniques .ie. putting consts/rvals on the right side of the equality operator in C/C++; always checking pointers before derefer

    • Re:Nah (Score:5, Insightful)

      by mcvos (645701) on Thursday August 23, 2012 @06:55PM (#41102981)

      Some things, like allowing SQL injection, might be considered negligence. But no programmer can possibly guarantee a complete absence of bugs, and any bug can be a security hole. It takes time and money to track them down. If you don't give them that time and money, you can't expect perfect security.

      • Re:Nah (Score:4, Insightful)

        by Anrego (830717) * on Thursday August 23, 2012 @07:01PM (#41103065)

        Perfect, no... but I suspect there are companies where if required to justify what they did to protect the end users (was the thought of security even a consideration at any point..) would pretty much give a blank stare.

        It's not about having perfect security imo, but rather about at least making an effort proportional to the risk you are putting users in.

        • by mcvos (645701)

          That last line is the big one: think about what's at stake. If there's any sensitive data involved (credit cards, medical, whatever), security is a very real concern. Of course that also needs to be included in the price. You get what you pay for.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Allowing SQL injection attacks is negligence. And if you allow an SQL Injection attack, you need to find another line of work.

        SQLinjection is the easiest attack vector to ward off, all you have to do is use prepared statements.

        Done.

        • by mcvos (645701)

          Absolutely. It amazes me how many sites, important ones, even, are vulnerable to it. It's trivial to prevent, and doing so makes your code prettier and faster. There's no excuse.

          • >Absolutely. There's no excuse
            Oh, there is "an excuse", happy camping on the line 50231 in the EULA. That's why we love the software industry.
    • by alen (225700)

      no, the developer will just have a very constrained usage scenario for the no security hole policy. the NSA has proved that you can make Windows and Linux secure, its just going to be a pain in the a$$ to use and annoying to do the simplest things.

    • Blame the organization not the developer.
      Week one we need a working prototype.
      Week two we need to put the prototype into production.

      We want it to do all these features... 6 months down the line we need to put in production with half the features.

      Yes this products will be only used internally.

      As developers we are often not given the full picture and the organization changes the mind. Often good developers in bad organizations write bad code.

    • Re:Nah (Score:5, Funny)

      by marcello_dl (667940) on Thursday August 23, 2012 @08:08PM (#41103765) Homepage Journal

      I dunno, as an indie dev you can change the warranty in the license of your software, stating that
      "This software will occasionally test your hardware by deadlocking it, perform random functions regardless the user inputs, and make hardware resources available to the cloud, specifically to the latest botnet makers."

      So it always performs as planned :)

  • by Burdell (228580) on Thursday August 23, 2012 @06:43PM (#41102809)

    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).

    • Not really - you would need professional indemnity insurance.

      The insurance is based on risk of a claim (more copies sold / bigger the premium, could be priced on a fixed price per copy), the impact of damage (just make sure that the license terms exclude indirect consequental damages).

      The risk side of the equation can be reduced by using appropriate development structures (code reviews, etc).

      This could improve the quality of the industry long term but there will be some pain getting there...

    • by arth1 (260657) on Thursday August 23, 2012 @07:06PM (#41103131) Homepage Journal

      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 is true. However, I still think it should be possible to sue for gross negligence. Like lack of input validation, or storing passwords in plain text, or installing everything world writable.

      That's like a bike lock manufacturer whose locks open if hit with a shoe, or a car manufacturer whose cars start if you roll them dowhill and put them in gear, even without an ignition key. Both existed, but would be considered gross negligence today.

      I don't expect software to be perfect, but I do expect it to not be outright stupid.

    • by Sycraft-fu (314770) on Thursday August 23, 2012 @07:49PM (#41103539)

      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.

      • by vlueboy (1799360)

        It would be the end of plugins --think of the liabilities Mozilla opens itself to by letting you extend it in unexpected ways. It would be the end of App stores, given that they extend android and allow personal information to be collected in ways that are hidden and unexpected to most. Hmm, but then it would be the end of ALL Flash support and its vulnerabilities. You'd probably have a fresh start to code signing and trust / authentication system. Personally I hate that MS forced EVEN legitimate (read expe

  • Sure (Score:5, Insightful)

    by BigSlowTarget (325940) on Thursday August 23, 2012 @06:44PM (#41102819) Journal

    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.

  • Windows (Score:5, Funny)

    by MrEricSir (398214) on Thursday August 23, 2012 @06:45PM (#41102843) Homepage

    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.

    Interesting choice of words there!

  • Exception: FOSS. All commercial software vendors should be liable for any and all damage caused by sloppy coding, including system cleanup, downtimes, etc. In most European countries this would just require classifying sloppy coding as "gross negligence". I am all for it.

    • Except you fail to consider the fact that many managers expect unrealistic deadlines from developers, leaving them no choice but to take the quick and easy way out. I'd say that most developers want to create the best code they can, but contraints on timelines, requirements, and feature creep often work against this ideal situation. Do you really want to be sued because of an incompetent manager?
    • by Ronin Developer (67677) on Thursday August 23, 2012 @06:57PM (#41103019)

      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?

       

      • 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

    • Re: (Score:3, Informative)

      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?
    • by bws111 (1216812)

      That makes no sense at all.

      First, that puts FOSS at a huge disadvantage. If a customer uses 'commercial software' (whatever that is), they can sue if something goes wrong. If they use FOSS - too bad?

      Second, define 'commercial software', and more importantly 'commercial developers'. What about the large amount of FOSS that is developed by 'commercial' developers (IBM, Red Hat, etc)? What about FOSS that is 'sold' (RHEL, SuSE)? Do those companies get a free pass on selling crap, or are the developers o

      • by Githaron (2462596)
        Keep in mind that no one is going to give you a free ride if they think there is any chance of you suing them. FOSS would completely disappear if there was a fairly decent chance that the developers were going to get sued.
  • Bad Analogy (Score:5, Informative)

    by ZombieEngineer (738752) on Thursday August 23, 2012 @06:46PM (#41102861)

    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?

    • The door to my apartment is in the habit of blowing open during strong winds even when "locked" unless we carefully move the bolt in when the door is positioned correctly. My landlord will not fix it: he doesn't claim a reason, just never gets around to it. If the door blows open, and someone steals our stuff, I should be able to sue the landlord by arguing that his negligence lead to the conditions under which I was burgled: the door would have remained shut if he furnished the apartment with a working doo
      • by bmo (77928)

        Many rental laws give you the right to self-fix and deduct from the next rent payment. Look into them wherever you live.

        --
        BMO

    • Well, it isn't the greatest analogy, sure, but it does have a point. It is like the faulty 'If you can build a bridge that doesn't fail, why not a program', where the easy counter is 'Bridges generally don't have people trying 24/7 to destroy them through every imaginable means available to them, and when they do, they generally don't last long.' If you can't hold a door maker responsible for the failure of a door and lock to stop an determined intruder who has to be physically present, how do you really e
    • 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).

      They provided the product, it's not their fault how the product was actually used or installed. It's not the manufacturer's fault that the person responsible for the actual installation was on his first day on the job after reading several tutorials online. It's the responsibility of whoever sets up a computer to secure that computer, you can't sue the manufacturer of your CPU because it executed malicious code that deleted your files.

    • Yeah, no. Software programs juggle so many variables that it's virtually impossible to prove the program is bug-free. And add in the computer illiterate, who will find a way to generate giant lawsuits because of "the computer didn't preserve the placement of the file icons I dragged around the folder, after I copied it to a new driver; therefore it's a design flaw" crowd, and you know as well as I do that tech will be sacrificed for the greater human stupidity.

    • That then hits the ugly question of what is "reasonable". Did the manufacturer provide a reasonable product that provided the expected level of security?

      Well, since my software explicitly states that it disclaims all warranty, and I make no claim as to its fitness for any particular use, then what is your expected level of security? I basically say, Here's the bits I configured. Hope you find them useful! I use input fuzzing, unit testing, stress testing, stateful malloc & free replacements, etc, and do my best to create good secure software. However, I don't know what else you have running in your machine -- I don't even know if your hardware is fa

  • by DemonGenius (2247652) on Thursday August 23, 2012 @06:47PM (#41102867)
    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.
  • by fiannaFailMan (702447) on Thursday August 23, 2012 @06:47PM (#41102877) Journal

    Sue the actual developer? How would you propose to do that if they're working for an incorporated company with limited liability?

    • by Githaron (2462596)
      That is what I was thinking. If a developer is being paid a standard wage rather than a major percentage of sales, why should said developer have to assume the responsibility of the product rather than the company that is actually reaping the profits of the product..
  • Fair's fair (Score:3, Insightful)

    by Anonymous Coward on Thursday August 23, 2012 @06:48PM (#41102881)

    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.

  • > Microsoft has previously argued against such a move

    Well, of course (/snark)

    > claiming a burglary victim wouldn't expect to be able to sue the manufacturer of the door or a window in their home.

    Maybe one could expect that, if the advertisement for the door or window led one to believe a level of security that the door or window was not designed to supply. Or if a reasonable person would assume, for instance, that a door with a security-type cylindrical-key lock on it could not be opened with a commo

  • Hanlon's (Score:4, Interesting)

    by gmuslera (3436) on Thursday August 23, 2012 @06:50PM (#41102901) Homepage Journal

    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)?

  • by bmo (77928) on Thursday August 23, 2012 @06:53PM (#41102933)

    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

  • sue engineers for degraded roads or 9/11. As time passes, holes emerge and the code shows age. things that were once determined safe and sound like blowfish are no longer the norm, much as roads from the sixties can no longer handle multi-ton SUV traffic. maybe its a problem with the roads, or a problem that can be addressed by changing the environmental factors contributing to its degradation. Security, much as road construction, continues to improve but to retroactively fault an engineer for not knowi
    • by Belial6 (794905)
      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.
  • by Anonymous Coward

    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

    • by Todd Knarr (15451) on Thursday August 23, 2012 @07:07PM (#41103141) Homepage

      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.

    • by russotto (537200)

      It's really time for computer science to grow up and join the rest of the pack.

      It's really time for lovers of over-regulation (including regulation through overbroad liability) to consider the consequences of their actions.

      If a mechanical engineer designs a bridge that collapses under normal load, that engineer can be held PERSONALLY responsible for breach of duty.

      He's not, however, responsible if someone dynamites the bridge, deliberately overloads it, or commits other malicious acts designed to destroy it

  • 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.
  • by ChumpusRex2003 (726306) on Thursday August 23, 2012 @06:59PM (#41103039)

    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.

    • by Belial6 (794905)
      Your example shows how the management was at least partially to blame. The memo that said not to use apostrophes in patient names shows that they were completely aware that there was a problem. Even someone who does not code would know that trimming out the apostrophes would not be a major undertaking. If they asked for this, and were willing to pay for it, it most certainly could have been fixed. The customer WANTED the cost/quality that they were buying. Negligence would be at least as much with the
  • by dkleinsc (563838) on Thursday August 23, 2012 @07:00PM (#41103057) Homepage

    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."

  • If the security hole introduced intentionally with malice, or nothing is done about a known security bug, then getting sued maybe on the cards...
    It depends on the impact the security hole...eg privacy or information breach.

    If the security hole was introduced without malice or fixed in time, or does not have major impact (ie affects only test data, or performance...), then you're unlikely to have a case for litigation.

  • Add a EULA that forbids anyone suing me.

    Short of that, no longer license software, but provide it for free, but tivo'd. The binary blob inside is what I'll license for a cost. And guess what, its just a trivial piece of software that cannot contain any bugs.

  • by shentino (1139071)

    Gee, I wonder why a company like Microsoft that writes perfect code would ever lobby against this...

  • Doors vs Vault Doors (Score:5, Interesting)

    by holophrastic (221104) on Thursday August 23, 2012 @07:15PM (#41103227)

    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.

  • by viperidaenz (2515578) on Thursday August 23, 2012 @07:49PM (#41103541)
    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"
  • by Gravis Zero (934156) on Thursday August 23, 2012 @07:51PM (#41103557)

    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.

  • by Algae_94 (2017070) on Thursday August 23, 2012 @07:53PM (#41103579) Journal
    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.
  • by thesandtiger (819476) on Friday August 24, 2012 @12:21AM (#41105489)

    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.

"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken

Working...