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

550 comments

  1. Nah by Anrego · · Score: 5, Insightful

    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.

    1. Re:Nah by Mitreya · · Score: 4, Insightful

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

    2. Re:Nah by mcvos · · Score: 4, Insightful

      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.

    3. Re:Nah by Shikaku · · Score: 4, Interesting

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

    4. Re:Nah by Anrego · · Score: 1

      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 again!".)

    5. Re:Nah by Anrego · · Score: 3, Insightful

      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.

    6. Re:Nah by Anonymous Coward · · Score: 2, Insightful

      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.

    7. Re:Nah by craigminah · · Score: 1

      How bout we sue people who post stupid articles on /.

    8. Re:Nah by DJRumpy · · Score: 1

      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.

    9. Re:Nah by alen · · Score: 1

      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.

    10. Re:Nah by mcvos · · Score: 1

      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.

    11. Re:Nah by Elminster+Aumar · · Score: 1

      What makes you think it's stupid? I mean, after all, your response reeks of empirical rationale and conclusive examples...

    12. Re:Nah by tomhath · · Score: 4, Insightful

      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.

    13. Re:Nah by mcvos · · Score: 1

      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.

    14. Re:Nah by jellomizer · · Score: 2

      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.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    15. Re:Nah by muon-catalyzed · · Score: 2

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

    16. Re:Nah by Javagator · · Score: 1
      You don't define the difference

      Right. How are the lawyers going to make any money if everything is well defined?

    17. Re:Nah by fustakrakich · · Score: 1

      ...Ãoecan happen to anyoneÃ...

      People, please! There is no Unicode in the war room! Use notepad...vi... Slashdot itself...anything but an office program

      --
      “He’s not deformed, he’s just drunk!”
    18. Re:Nah by Sancho · · Score: 1

      no programmer can possibly guarantee a complete absence of bugs

      Programmers from the 70s would laugh at that statement.

    19. Re:Nah by TubeSteak · · Score: 1

      So how do you define "sensitive"?

      I bet if someone poked through the legal code, we could come up with a decent list of information that's already been declared sensitive in one way or another.
      That's probably a good place to start.

      There's no end to it; once you open the door a good lawyer can can convince a jury anything.

      The law defines "sensitive." That's how you prevent lawyers from arguing whatever they want.

      --
      [Fuck Beta]
      o0t!
    20. Re:Nah by Anonymous Coward · · Score: 0

      He provided a specific example in his comment. There's no problem outlining specific things like credit card numbers, social security numbers, and passwords for a start.

    21. Re:Nah by silas_moeckel · · Score: 0

      Same as any other well thought out engineering discipline. You have a standard, a bridge engineer can be liable when they do not follow well established standards or do significant amounts of testing. There are plenty of standards bodies that could deal with making such standards. We already have them for specific applications like control of nuke reactors. Library's would quickly be made to implement a lot of these standards.

      --
      No sir I dont like it.
    22. Re:Nah by Eponymous+Hero · · Score: 1

      you mean PCI compliance. it's not a law, though some states have laws that borrow heavily from this standard.

      http://www.pcicomplianceguide.org/security-tips-20090227-pci-compliance-law.php

      --
      insensitive clod overlords obligatory xkcd car analogy russian reversals whoosh pedant fanbois ftfy in 3...2...1..PROFIT
    23. Re:Nah by Anonymous Coward · · Score: 0

      I think excessively poor software should result in some form of negligence

      That's fine but in an industry obsessed with custom product to deadlines pulled out of some manager's backside or based on business/legal requirements rather than any form of sane estimate, you'll find most good developers quit and move on to something that isn't being outsourced to the lowest bidder.

    24. Re:Nah by ILongForDarkness · · Score: 1

      It is hard to say sometimes what is negligent. For example buffer overflow or SQL injections: most run of the mill developers don't know enough to write code that prevents them, know what causes it etc. They are spending their time solving a real problem in a perfect world where the user interacts with their software in a sane manner. They don't have an interest in learning arcane magic tricks that can be played at the binary level to get things to work badly etc. For large products they probably can afford a security team or an audit but for a small spinoff of a home baked project? Not a chance.

    25. Re:Nah by hey! · · Score: 1

      Well, in custom software a lot of software badness comes from unresponsive clients who force developers to race against the clock to meet deadlines. If the developer drops the ball, sure it's his fault. But sometimes customers hold things up by not answering simple questions or doing the testing they promised to do.

      Coding isn't magic; if you make a coder deliver something in twenty hours when he estimated one hundred, something's going to give. Most likely it'll be non-functional requirements: performance, security, stability, and maintainability.

      It's smart to include customer responsibilities in any development contract and to predicate all delivery dates on customers holding up their end.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    26. Re:Nah by ILongForDarkness · · Score: 1, Interesting

      That would be the best way to go. Have a "native" type in .Net, Java etc that is "credit card" does all the magic to validate the card, communicates encrypted, decrypts when necessary, is understood by things like data entry controls etc. Than it is both easier and secure to use the correct method rather than hacking a plan text box and storing unencrypted data everywhere. As long as it is easier to go the unsafe way people will do it either because they are lazy or just inexperienced and that was the natural way they came up with how to solve their problem.

    27. Re:Nah by Eponymous+Hero · · Score: 1

      prepared statements work great for almost every sql injection attack, but they are not the silver bullet. the structure of your app could allow an xss attack to run a query that doesn't use them, for instance.

      i've also seen some really nasty sql injection attacks using declare, cast and exec to traverse every db, every row, every column and replace every value with an html script tag referencing a foreign-hosted javascript file -- all stemming from a cross-site request forgery that allowed the attacker to run the app as an admin in "debug" mode. almost everything that went wrong with that problem was caused by application architecture.

      the reality is most devs don't get to learn about these things until it happens to them. roll that in your eula and smoke it.

      --
      insensitive clod overlords obligatory xkcd car analogy russian reversals whoosh pedant fanbois ftfy in 3...2...1..PROFIT
    28. Re:Nah by ILongForDarkness · · Score: 1

      Even with strict definitions lawyers will still make money. Just because you're going to lose doesn't mean you can't sue.

    29. Re:Nah by mcvos · · Score: 1

      I don't understand how that could possibly work if you always use parametrized queries. Could you explain a bit more?

    30. Re:Nah by marcello_dl · · Score: 5, Funny

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

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
    31. Re:Nah by Anonymous Coward · · Score: 0

      make it like car design you can sue for outright stupidity but some faults are to be expected

    32. Re:Nah by russotto · · Score: 1

      no programmer can possibly guarantee a complete absence of bugs

      Programmers from the 70s would laugh at that statement

      Lubarsky's law -- "There's always one more bug" -- dates back to at least the 1970s.

    33. Re:Nah by Anonymous Coward · · Score: 2

      I don't see why those things can't be handled contractually instead of with government regulation.

      If a development company is willing to accept liability for security defects that compromise listed information, and the other party is willing to PAY for that kind of quality control... what's the problem?

      If, on the other hand, it's "well I want software companies held liable for this kind of thing by government regulation", except nearly every available option to be unavailable in your country... except for the one that costs 300x's the old options cost, so the company can carry insurance by deployment.

    34. Re:Nah by Anonymous Coward · · Score: 0

      I think this is simple,

      every year various vulnerabilities are identified and reported by different companies, hackers, etc. Now similarly to security standards on houses, cars and so on, software should have a battery of standard tests - updated yearly - that it would have to withstand. Then passing more or less of such tests would determine the software security level

    35. Re:Nah by ColdWetDog · · Score: 5, Insightful

      Are you guys crazy?

      Do you realize how much bridges cost?

      --
      Faster! Faster! Faster would be better!
    36. Re:Nah by Fallingcow · · Score: 1

      Yeah, my understanding was that the main threat from XSS was the ability of an attacker to run arbitrary Javascript on your site and thus masquerade as you to other users... which is unrelated to SQL injection.

      In fact, as described, the "cross-site request forgery" sounds like exactly that sort of thing, with the unauthorized DB access coming as a result of that rather than the other way around. Not SQL injection at all. I too would like more details if it was, because that would be the first I've heard of a SQL injection attack that bypasses prepared statements/bound parameters.

    37. Re:Nah by Anonymous Coward · · Score: 0

      PCI compliance?

    38. Re:Nah by mysidia · · Score: 1

      I think excessively poor software should result in some form of negligence ... but general “can happen to anyone” type bugs.. no.

      How do you define that in a manner that does not result in a slew of lawsuits to let the courts try to sort out the matter?

      How do you feel about your next copy of Windows costing $2000 per seat, instead of $200, due to the premium required to help cover the added legal costs?

    39. Re:Nah by mcvos · · Score: 1

      I don't quite grasp XSS yet, but this sounds like you end up logged in at the site as an admin, so you may have more authority to edit stuff. But that wouldn't give remotely the same power as SQL injection does.

    40. Re:Nah by samjam · · Score: 2

      I think he means a non privileged user inserted some values via a prepared statement which became active web content (maybe unescaped javascript - but not unescaped sql !).

      That content was then viewed by an admin on another machine at which point the java script executed and could submit web pages with actions with admin privileges.

    41. Re:Nah by colinrichardday · · Score: 3

      You might want to start here:

      https://www.pcisecuritystandards.org/

    42. Re:Nah by Anonymous Coward · · Score: 0

      Want software that is very secure and unlikely to have serious bugs

      Use OpenBSD (Only two remote holes in the default install, in a heck of a long time!)

    43. Re:Nah by bsercombe72 · · Score: 1

      Ok, so go negotiate your contract with Micro$oft. Good luck with that.

    44. Re:Nah by Anonymous Coward · · Score: 0

      Anywhere but on your screen, those are just 1s and 0s.

    45. Re:Nah by Anonymous Coward · · Score: 0

      There is no secure system or secure software.

    46. Re:Nah by Anonymous Coward · · Score: 0

      It's like i'm selling doors. And I don't know any one in the world that can not be break. The users should be liable too.

    47. Re:Nah by Eth1csGrad1ent · · Score: 1

      And how do you define the difference?

      Surely this would come down to a determination by the courts as with any form of negligence...

      How do you sue a doctor for negligence after a surgery?
      How do you sue a car maker for negligence due to a design flaw?

      These are all highly specialised and highly subjective - you bring the case, the courts determine where the line is

    48. Re:Nah by yacc143 · · Score: 2

      Or Apple, Google, Samsung, HTC, ...

    49. Re:Nah by Grishnakh · · Score: 2

      What's really lame is that PCI is an interconnect bus on computers, and this PCI group ripped off the name. They should be forced to change it.

    50. Re:Nah by Grishnakh · · Score: 1

      People don't sue nearly as much when things are more rigorously defined. Just look at all the patent wars going on right now: company A thinks that a rectangle with rounded corners is protected IP, another thinks that's bollocks, and off to court they go, spending millions of dollars arguing about it. The lawyers are making tons of money with these cases. If the government changed the IP laws to make this stuff more clear-cut, then there wouldn't be much arguing or so many lawsuits, and that means less money for lawyers.

    51. Re:Nah by Grishnakh · · Score: 1

      There absolutely is an excuse, it's called incompetence and ignorance. The problem is, you can't expect all software developers to be highly competent. In fact, everyone here was incompetent at some point, before they learned enough to be competent. Do they teach about SQL injection attacks in college? I doubt it. A lot of things you learn on the job, with experience, and you only get there by working and making mistakes. In better-run organizations, there's checking and validation and pairing of less-experienced people with more-experienced ones, so you don't have so many problems. In poorly-run or small organizations, there's a lot more "winging it", and mistakes are bound to pop up from people learning as they go.

    52. Re:Nah by Anonymous Coward · · Score: 0

      I think suing developers for poor software is fine, but of course I want to be able to sue lawyers for failing to win a case, and doctors for not curing an ailment on the same basis.

    53. Re:Nah by Anonymous Coward · · Score: 1

      See: Sony and the PSN disaster.

      What credit card info did they not encrypt? People like to claim this but I've yet to see evidence that credit card numbers were not encrypted. Getting hacked does not automatically translate into poor encryption practices. Everyone likes to hate on Sony (and some of that hate is certainly earned) but they were victims and making claims like this just fuels the notion that these hackers were some kind of altruistic vigilante group out to save the world.

    54. Re:Nah by bhlowe · · Score: 1

      Any communication that a user expects should be private should be encrypted--personal info of any kind. Any prompt to enter a password should go through through SSL and not plaintext. Maybe time to get rid of Basic Authentication...

    55. Re:Nah by Anonymous Coward · · Score: 0

      I agree that PCI compliance standards are a good start for defining these things.

      From my own experience, the PCI standards are pretty useful. I work with sensitive user data so I'm pretty familiar with it. We actually pay businesses that specialize in both the legal and technical aspects of security to have them audit us every so often and they advise us on new security exploits and best practices. They do genuinely help us avoid making dumb mistakes that could compromise our customers, at a far cheaper price than messing up and harming our customers. Also, they help us navigate the different laws from state to state and country to country, which makes the cost benefit of serving governments vs serving customers more easy to identify. We have steered clear of some countries based on that legal advice.

      Sometimes compliance is a pain(just recently we added a new batch of production payment servers but they use a new active authentication method which is taking forever to set up), but usually I am convinced that the standard make sense and keeping up to date with it is the most cost effective use of our time. How well it applies in court is complicated, but it is probably the best starting point.

    56. Re:Nah by Anonymous Coward · · Score: 0

      I've taken just about every database & programing class my local community college offers, and if sql injection was even mentioned at all, it was as an "advanced topic" that we should read up on in our spare time, as it wasnt within the scope of these "beginning" courses. Doesnt help that all the "advanced" classes have been axed due to budget cuts and "low enrollment" (which now means less than 80% max)

    57. Re:Nah by Opportunist · · Score: 4, Insightful

      The problem is that the market is by definition asymmetric. The customer usually knows jack about the implications of security concerns. If people had any idea of security, Facebook wouldn't be a success.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    58. Re:Nah by Opportunist · · Score: 1

      You mean like Sony was when they had their CC blunder?

      I guess in this time and age it's more appropriate to hold certification entities liable for the certs they pass out and companies they approve as "certified".

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    59. Re:Nah by silas_moeckel · · Score: 1

      That's a bit of a start, but it needs to go far deeper than that. Right now most passwords over the web are only protect by session encryption but there are multiple methods to have only something that validates that you know the password. Having a standard across the industry that says no passwords shall ever be sent over the line client ot server except to send a new password and gives several methods to so do means that web browsers and a lot of other things can all implement it. This keeps the I pulled it out of my butt rot13 type stuff from happening as the developer could be liable for doing so and it gives them ammo when facing there management that's wants to do something. It also makes it easy for auditors come come in and check for compliance.

      --
      No sir I dont like it.
    60. Re:Nah by Opportunist · · Score: 1

      Yes, they did teach them in my college. Then again, security was the focus of my studies, I bet the "hardcore" database gurus learned more about making databases faster than making them secure...

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    61. Re:Nah by Opportunist · · Score: 1

      Hey, gimme a machine that can only run one job at a time and without networking, and I give you a program you cannot exploit remotely...

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    62. Re:Nah by Anonymous Coward · · Score: 1

      I don't think there have been lawsuits won from anything you say. And courts have said an EULA can prevent class action lawsuits. So no, there are not any mechanisms in place other than what you agree to in the EULA. So if you're using the software you've agreed that the company doesn't have liability for lost data.

      There are a lot of cons by trying to force liability onto companies though. For starters, it's not just companies. Individuals are able to write software. Can you hold a 14 year old liable for buggy software he posts on the Internet? How much liability is assigned to software that is freely distributed? How do you determine what software is actually at fault? In your scenario you could blame the AV software, but you could also blame the OS for not protecting its critical files. Or you could blame the user for giving the AV software permission to change critical files. What mechanisms are in place to handle liability between parties in different countries? How are you going to enforce anything even if you can somehow decide how to handle all of these situations?

      With all of that said. Mark my words. Established software companies will eventually push legislation to regulate software liability. Sooner or later, they will realize that such regulation will raise the barrier to entry in the software industry. With the possibility of adding huge capital costs to pay for insurance they can prevent any new Microsofts, Facebooks, Googles, etc. from starting in a garage or college dorm room. That's when we'll know the industry is mature, stagnant, and closed.

    63. Re:Nah by LiENUS · · Score: 1

      $hnd = ibase_prepare($dbh, "select count(*) from users where user='" . $_GET['user'] . "' and pass='". $_GET['pass'] . "'"; prepared statement so secure right?

    64. Re:Nah by JoeMerchant · · Score: 1

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

      It will also start malpractice insurance as a requirement to sell software, driving up costs, down salaries and putting small businesses and independent operators at a heavy disadvantage.

      I'm a little surprised that Microsoft isn't supporting it.

    65. Re:Nah by JoeMerchant · · Score: 1

      The financial (credit card processing) software industry has some standards along these lines.

    66. Re:Nah by sgunhouse · · Score: 1

      In general, no one forces you to buy bad software. (The exception being bad software updates, where the update may be forced on you.) Hence I don't see an issue if new software is not what you were expecting - only if updates are bad.

      Currently, I'm sure you could sue for either intentional or negligent damages if you can prove that the developer knew or should have known that a bug could lead to monetary loss ,,, but then again, with closed source software how could you prove that?

      In an enterprise setting I could see a demand for a certain degree of liability as part of the reason you buy a certain software - and as the reason you pay hundreds of dollars for said software. If it's some program you bought for $10 (or got free online) to save money then it's partly your fault for choosing to use the no name software over its enterprise competitor. But if you paid for "enterprise" software over a cheaper non-enterprise software then you should expect that it really is suitable for enterprise use and should be able to sue if for some reason - including bugs - it is not (and the company doesn't resolve the issue suitably before you ever get to court, of course).

    67. Re:Nah by cbhacking · · Score: 1

      Given the talk of "application architecture" and the presence of concepts like "debug mode" being a run-time switchable state, or XSS being able to execute code on the server, I'm guessing it probably involves PHP. Atrociously bad configuration, even by the already abysmal standard of "you're using PHP", but possible. Probably also possible in a few other frameworks, but that's the only one I've seen recently used where sufficiently shitty web apps could be persuaded by the client to run arbitrary code on the server.

      --
      There's no place I could be, since I've found Serenity...
    68. Re:Nah by gnapster · · Score: 1

      Next time I go to best buy, I'll try flashing a light at the cashier and see if they let me walk out with a TV.

    69. Re:Nah by Compaqt · · Score: 2

      Translation: You want bespoke (nuclear powerplant-level) security at mass-market prices.

      --
      I'm not a lawyer, but I play one on the Internet. Blog
    70. Re:Nah by Bert64 · · Score: 3, Insightful

      What's wrong with basic auth over ssl? it's still encrypted...
      no worse than form based auth.

      the biggest problem is that users have no idea how their data will be stored or used on the back end... the frontend auth system, wether it uses ssl, basic auth, forms or whatever, is visible to the user, but beyond that your data is going into an unknown black box..
      if you've no idea what is being done at the backend, you cant make an informed decision as to wether you want to trust a given site with your info or not.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    71. Re:Nah by Bert64 · · Score: 1

      What evidence is there that card numbers were encrypted, or that the encryption was adequate and not misused?

      Based on sony, didn't they screw up with the ps3 and give away their private key? That surely demonstrates form for poor use of encryption on the part of sony...

      "encryption" is not a magic bullet, although people often see it that way... i have seen many implementations where "encryption" was used, while providing zero security benefit. lots of places will store their data on an encrypted filesystem for instance, but because its mounted anyone who compromises the box can easily access the data anyway... And to make matters worse, since entering a key on bootup is inconvenient, they have this done automatically, so the key is stored somewhere on the box anyway and all the hacker needs to do is find it.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    72. Re:Nah by Bert64 · · Score: 1

      Big expensive software is rarely bug free, infact it's usually a lot worse... The only difference is that users put up with the bugs and work around them, whereas for smaller suppliers they complain and threaten to move to something else.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    73. Re:Nah by Anonymous Coward · · Score: 0

      And how do you define the difference?

      Industry best practices and accepted baselines. That is how liabilities are judged in every other industry.

    74. Re:Nah by Anonymous Coward · · Score: 0

      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.

      This is what liability insurances are for. The different question is how those terms and conditions develop for the insurances and how long does it take to become a similar burden to the software industry as it is to the medical industry today.
        Engineers and architects have liability insurances as well, so there is some hope that the insurance costs might not go through the roof. On the other hand, it is only matter of time for the marketing departments of the insurance providers to discover the magic of the network effect.

    75. Re:Nah by skovnymfe · · Score: 1

      Are you saying it doesn't already cost far too much to develop software? Here I'm of course referring to the several "Oh look we went $500,000,000 over budget" type software development 'woopsies' that are all too common in this industry. Not open source software that doesn't cost anything to develop, not even man-hours. Especially not man-hours wasted arguing semantics like which way to do something trivial is the better one.

    76. Re:Nah by davester666 · · Score: 2

      > The law defines "sensitive." That's how you prevent lawyers from arguing whatever they want.

      No, lawyers will still argue whatever they want. See the stupid [IMHO] argument some lawyer came up with about 'trepassing' when a guy using Find My iDevice to make his iPad beep in a thief's garage, so he could get the cops to then get a warrant and search the thief's garage [where they found the iPad and a whole bunch of other allegedly stolen items].

      The law seems to be mainly for defined what is roughly legal vs illegal [as it's not exact, and even if it were, there is stuff like jury nullification].

      Basically, it comes down to which lawyer mindfucks either the jury or the judge better.

      --
      Sleep your way to a whiter smile...date a dentist!
    77. Re:Nah by thsths · · Score: 2

      > You want bespoke (nuclear powerplant-level) security

      No, you misunderstand the point completely. This is not so much about functional guarantees of the software than non-functional ones. If you buy a game for $0.99, you do not expect it to be bug free. However, you do (reasonable) expect it not to steal your credit card data or compromise your system.

      It is just as with any other item for sale: a cheap toy made in China may not last very long, but you do expect it not to harm anyone. Every toy sold for $0.99 carries this guarantee, and the manufacturer is liable if anything happens. So why does software not?

      Security is typically a non-functional requirement. And in a lot of software that is actually a reasonably easy problem. Sandboxing, restricting permissions, limiting network communication, and with just a few easy measures you have massively improved safety and security. That is what best practice means: what is known to work and reasonable. There is no need to assume that your code is bug free - power plant level security and testing is not required.

    78. Re:Nah by Neil+Boekend · · Score: 1

      I think it would be easy to distinguish: if you ask money for it it should conform to certain security rules (mentioned by others earlier) depending on the intended use (can't ask for a text editor to automatically encrypt each document because some idiot may save a credit card number with it).
      I do like the Open Source projects however, and this could lay a barrier. If this becomes standard people may choose the payed (often closed) program because it has this security. The Open Source guys could probably remove that barrier with a decent hallmark, which would require the same, or better, security.

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
    79. Re:Nah by Bert64 · · Score: 1

      There is a severe shortage of competent people at all levels, what this means is that:

      Management are not clued up enough in the field to spot someone who is incompetent...
      Even if someone incompetent is identified, they are better than nothing and it is extremely difficult to find replacements, many of whom may even be worse.
      There are lots of people who are incompetent on a technical level, but very good at manipulating non technical management...
      Competent people will generally see through such incompetence and manipulation right away, but most companies don't have anyone sufficiently clued up.

      As the industry matures over time, competent people will gradually start to displace the incompetent and things will start to improve... But this will take a very long time.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    80. Re:Nah by Anonymous Coward · · Score: 0

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

      Was it brought to the attention of the customer before purchase? If a customer walks into a store, is able to buy software and walk out without reading or signing the EULA then the EULA doesn't apply to that customer. (Depending on where you live.)

    81. Re:Nah by Bert64 · · Score: 2

      PHP suffers the same problem as any language thats accessible to novice programmers...

      Novice programmers will use it, and create poor code with it...

      And then non technical management with no understanding of security or technology will decide to start putting such code into production.

      Most decisions are made by people not qualified to make them.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    82. Re:Nah by wvmarle · · Score: 1

      I suppose "sensitive" can be defined in privacy regulations. If not there already.

      So basically any privacy-sensitive data should be encrypted. One could argue that this should apply to all customer data, especially as these days encryption is so well developed.

    83. Re:Nah by Bert64 · · Score: 2

      That's the problem of the lowest bidder system...
      Companies want to reduce costs, and don't really understand much if anything about technology... So the developer who estimates 100 hours is perceived as bad value relative to the developer who estimates he can do the same thing in 20 hours.

      In reality, the 20 hour developer will probably overrun his 20 hours, and will also almost certainly write shoddy code which is full of bugs and difficult to maintain. Although the initial quote is obviously cheaper, once you've factored in overruns, cost of fixing bugs, cost of downtime or other harm caused by bugs, cost of working around bugs, cost of future maintenance, potential cost of a complete rewrite etc it can usually work out a lot more expensive.

      And yet, businesses stumble into the same mistakes over and over again.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    84. Re:Nah by metacell · · Score: 1

      Lawsuits are one of the reasons health care is so expensive. And I think determining who's at fault in the case of software errors will be much harder.

    85. Re:Nah by metacell · · Score: 1

      In the case of business customers, though, they're usually presented with the EULA when they sign the contract for the software license. And it's businesses that suing for security bugs is most relevant for...

    86. Re:Nah by Anonymous Coward · · Score: 0

      Are you saying it doesn't already cost far too much to develop software?

      Thus adding layers of regulation and standards will help reduce the cost ... how? It'll only increase the cost significantly. Nevertheless, a lot of the budget over runs occur because of poor project management and rarely down to poor engineering discipline.

    87. Re:Nah by Anonymous Coward · · Score: 0

      No code bug should be suable... How the hell is making a door and making software the same? You make door after very specific instructions while your making application based on your own design... + Nobody is bugging you (no put intended) to speed up the process when your making doors...

    88. Re:Nah by Anonymous Coward · · Score: 0

      That depends, do you you mind the bridge collapsing under you when you cross?

    89. Re:Nah by Anonymous Coward · · Score: 0

      Even better, you have no control over the circumstances your code will be running under.
      Maybe there is a bad interaction with a driver of an obscure piece of hardware that makes your code do strange things.
      Maybe something injected code into your code.
      Maybe the user decided to copy an older version of a system dll that included some bug that makes your program mess up.
      I think it will be impossible to point fingers with any accuracy in most cases.
      And even then, that would everyone make use the apis even more so they can blame the people who made the api.

    90. Re:Nah by lister+king+of+smeg · · Score: 1

      why they have the most to loose, they after all produce office, and windows, just look at their security track record.

      --
      ---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
    91. Re:Nah by Aryden · · Score: 1

      You actually can, the "Mega-Corp" I work for does it all the time. With that being said, it is a "Mega-Corp" and they have that kind of world-wide buying power so yeah...

    92. Re:Nah by Grishnakh · · Score: 1

      As the industry matures over time, competent people will gradually start to displace the incompetent and things will start to improve... But this will take a very long time.

      Define "very long". The software industry has been around since the 1960s now, it's really not that new any more. It's just gotten a lot bigger, as instead of a few mainframes here and there, we have computers everywhere, and we're using them for so many more things. But we've had the internet in widespread public usage for almost 20 years now, so again it isn't all that new any more.

    93. Re:Nah by Aryden · · Score: 2
      Incorrect, it is one of the great myths of our time:

      One of the principal myths surrounding medical malpractice is its effect on overall health care costs. Medical malpractice is actually a tiny percentage of health care costs, in part because medical malpractice claims are far less frequent than many people believe. In 2004, the CBO calculated malpractice costs amounted to “less than 2 percent of overall health care spending. Thus, even a reduction of 25 percent to 30 percent in malpractice costs would lower health care costs by only about 0.4 percent to 0.5 percent, and the likely effect on health insurance premiums would be comparably small.” i

      src:Justice.org

    94. Re:Nah by Aryden · · Score: 1

      Medical malpractice is effectively 2% or less of the costs in healthcare. If you add that to the cost of Windows 7 Ultimate, you're looking at about a $2 increase...

    95. Re:Nah by Aryden · · Score: 1

      We learned security before we learned set theory.

    96. Re:Nah by mcvos · · Score: 1

      The problem with university classes is that they're all focused on their own little corner instead of how everything is supposed to fit together. So database classes are about transactions and how many database actions you need for something, while software engineering is about datastructures and working in a group. Security is all about encryption algorithms, which you'll never ever actually have to write. But nobody teaches you what the right way is to use one thing with another.

      It's a valuable basis, but often you'll have to learn the real stuff by reading up on real life techniques and best practices, working with experienced programmers who hopefully know this stuff. And reading on programming forums about this.

    97. Re:Nah by Rockoon · · Score: 1

      For example buffer overflow or SQL injections: most run of the mill developers don't know enough to write code that prevents them, know what causes it etc.

      As far as buffer overflows and the similar, I have written plenty of functions that could access random memory if the function is passed bad data. However, the functions arent supposed to be passed bad data and when implemented originally, it was impossible for them to be called with bad data. The problem doesnt appear until the functions are used in an unintended way.

      For instance, function F1(...) produces data D1 from data set D0, function F2(...) produces an array of pointers D2 into D0 that are derived from D1. Function F3(...) blindly uses those pointers but it can be proved correct.

      Then someone comes along and instead of producing D1 via F1(...), decided to throw unconstrained D666 data at it. Now suddenly F3(...) is accessing random memory even though the whole system was once provably correct, and no changes to the consumer F3(...) or the producer F2(...) were made.

      One might say that such things are fragile design, but suppose the whole point of F2(...) was an optimization that allowed the program to run in an acceptable time interval which otherwise was not possible. Surely we arent declaring that optimizations are to be avoided at any cost. The problem is that D1 was not produced by F1(...) .. nothing more, nothing less.

      --
      "His name was James Damore."
    98. Re:Nah by Anonymous Coward · · Score: 0

      That's funny, but you would still get sued: You cannot override local laws like consumer regulations with any EULAs.

    99. Re:Nah by tofarr · · Score: 1

      In most cases, unit testing will do very little to prevent exploitable code - only educating the coder can help with this.

    100. Re:Nah by tofarr · · Score: 1

      and a good security review process

    101. Re:Nah by gweihir · · Score: 1

      I completely agree. For example, falling prey to the OWASP top 10 in an obvious way (you did not try to avoid them) makes you liable. You did try and something not quite obvious failed does not make you liable.

      Of course one problem with all this (and this is likely the source of a lot of the backlash here) is that suddenly you cannot style yourself a "programmer" anymore without having an actual, provable level of skill. But that is just part of the problem of bad software: Most people that write code actually suck at it because of no talent, no education, no training, no insight. Sure, bad management plays a role, but good software engineers walk when faced with untenable conditions. It is only the unqualified coders that stay under these conditions, because they know their skills are not worth much.

      If this were medicine, most current day coders would basically be witch doctors. Not that there are a few good witch doctors, but most are hacks without any real insight into the art they are professing to practice.

      Proof me right, mod me to -1.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    102. Re:Nah by Anonymous Coward · · Score: 0

      Actually they said the opposite. A EULA is non-binding and cannot preclude a lawsuit.

    103. Re:Nah by WarOfTheNerd · · Score: 1

      If a business wants to charge people money for a proprietary product, then there should be liability attached. Why? Because DRM has screwed up too many computers, look at Ubisoft, Sony and any company using StarForce for examples. Also, if a program which is fully patched within 7 days of the latest release causes damage or renders inoperable a computer system due to exploited bugs, the developer/publisher should be held liable. Why? Because they wrote a program which specifically allowed malicious attackers to cause damage.

      To follow the Microsoft analogy: If a burglar manages to kick a door through because the hinges weren't screwed in correctly or if a burglar manages to break the lock easily because the lock was not fitted properly; then the manufacturers are held liable.

      Free Software which is free as in freedom and free as in free beer would naturally be exempt, as it is provided free of charge and the end user is expected to be able to audit the software herself.

    104. Re:Nah by Geeky · · Score: 3, Interesting

      The engineers, possibly, the architects definitely. Not so much the builders as long as they can show they were following the spec.

      If there is any liability, it should lie with the company releasing the software. No individual developer can be held responsible - the software should have gone through testing, QA, user acceptance testing... where do you draw the line? Why the developers and not, say, the testing team for failing to develop a test that shows the bug?

      --
      Sigs are so 1990s. No way would I be seen dead with one.
    105. Re:Nah by rtb61 · · Score: 4, Interesting

      What really needs to be tackled is the insane and deceitful difference between software marketing, software warranties and software EULA's. The worst examples of corporate disinformation and outright lies ever seen by man. It's like the very worst of snake oil con men from the 19th century all joined the software sales business, with all sorts of lies printed on the outside of the label but once to consume it's contents all the disclaimers, once hidden by it's contents appear on the inside of the label and this is insanely and corruptly enough is now accepted as normal practice, led by M$.

      --
      Chaos - everything, everywhere, everywhen
    106. Re:Nah by Geeky · · Score: 1

      Even without prepared statements, it's easy to ward off. Regardless of how the code is going to handle the database query, surely all that's required is validation of the input? If it's a simple field like a name, only accept valid characters. If it's an arbitrary text field, run it through an established sanitiser and make sure it's appropriately quoted.

      The challenge is in finding the right sanitising routine, especially for forms (hey, like this one!) that can take html code. It's almost certainly best to use an established module/package/library than roll your own - chances are you'll miss something that the many eyes looking at existing code will have picked up.

      --
      Sigs are so 1990s. No way would I be seen dead with one.
    107. Re:Nah by Anonymous Coward · · Score: 1

      Microsoft was lead into this practice by the increasingly selfish and litigious nature of US society, rediculous 300 page EULAs are absolutely not their fault. They must disclaim everything, including that the bag the CD came in is not to be used as a toy, or else the lawyers are going to ruin them.

    108. Re:Nah by JoeMerchant · · Score: 1

      Yes, not a problem for Microsoft. For a small business developing software, they might have to post a $100M bond against liability claims - not a problem for Apple or Microsoft, a big problem for the little guy trying to compete with them.

    109. Re:Nah by MadCow-ard · · Score: 1

      They already are penalized: The software gets a bad reputation and is no longer purchased or used.

    110. Re:Nah by luis_a_espinal · · Score: 2

      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 dereferencing; doing "string literal".equals(stringVariable) in java; sanitizing your input at every layer before passing to a lower layer (specially when the input is obtained at the UI); keeping your cyclomatic complexity low, etc.

      Based on the quality of code?

      Yep. Quality of code is pretty much a measurable thing. Looking at the things I identified in B above, if someone's code does not possess any of those violations, or if any such violation is rarely found, then that shows the person has done a best professional effort. However, if the code is riddled with unchecked pointer (or object reference) access, without sanitizing and checking input, with obscene cyclomatic complexity, then it will be obvious that the author has not done his professional duty. He/she has been negligent. Even though we coders are not typically legally bound to pay for our negligence, morally and ethically, we should be held accountable.

      At some point our profession will professionalize itself the way professional engineers do with their profession.

      Based on the amount of unit testing that was (provably) performed?

      Of course. It is one of the ways to show we are not negligent to our clients.

      This will start a slew of software that is only warranted under specific OS/software configurations (and then installing an aggressive anti-virus or

      That doesn't make any sense. If we are talking about device drivers or medical equipment, maybe. But if we are talking about, say, web-based banking applications, I do not see how code/behavior quality assurance will be subject to such things.

      not error-checking your RAM chips regularly would void your warranty).

      This would only apply if you are selling your software packaged with a hardware solution (that is, a totally integrated solution). And in that case, yes, you should be subject to penalties if you do not check the hardware you are selling. This is the case of medical equipment manufacturers whom typically develop the software along with the hardware.

      Now, if all you do is the software part, then, duh, hardware checking is not a requirement for you (not even if you are the person doing a hardware recommendation). It will be for the client who chooses the hardware and/or the hardware provider (typically contigent to some type of SLA.)

    111. Re:Nah by luis_a_espinal · · Score: 1

      So how do you define "sensitive"?

      Depends on the contract between the software supplier and the client. For example (and I work for a defense contractor), the DoD (or similarly, the DoE) will tell you what is not sensitive and what is (and the degree of it), and how to handle it. With medical equipment, the law and industrial organizations estipulate what is sensitive when it comes to data and behavior.

      All developed countries have established rules and regulations for the definition and protection of sensitive data. Using the US as an example, with medical information, credit information, and public companies' information, federal and state legislature clearly defines what is sensitive via legal bodies such as FACTA, HIPAA, SOX, Anti-Phishing Act of 2005, The Privacy Act of 1974, Title 18 of the US Code, 1028d, various legal bodies at the state level, etc.

      We typically do not define the meaning "sensitive". It is already defined by law or by contract in the context of an activity or industry. We can define more stringent definitions than those required by the law or by a contract, but we cannot make our definitions that run counter with the legal/contractual ones.

      There's no end to it; once you open the door a good lawyer can can convince a jury anything.

      You are just hand waving. Stop. I'm sure it makes for a good post to attribute lawyers with magical powers to convince a jury of things counter with what is in the law or in a reasonable contract. But that's not how reality works.

    112. Re:Nah by Compaqt · · Score: 1

      Well, here's a route to that: If you can somehow manage to send messages to the controller as the admin, then:

      1. let's say you're running a PHP CMS, as many/most websites are.
      2. many PHP CMS's allow you to execute arbitrary PHP (if you have appropriate perms).
      3. the DB username/password is normally contained in a PHP file
      4. if you can execute arbitrary PHP, you can probably already execute arbitrary SQL using the CMS APIs. Or you can read the DB username/password and use that, or send it off somewhere.

      --
      I'm not a lawyer, but I play one on the Internet. Blog
    113. Re:Nah by luis_a_espinal · · Score: 1

      The engineers, possibly, the architects definitely. Not so much the builders as long as they can show they were following the spec.

      If there is any liability, it should lie with the company releasing the software. No individual developer can be held responsible - the software should have gone through testing, QA, user acceptance testing... where do you draw the line? Why the developers and not, say, the testing team for failing to develop a test that shows the bug?

      An individual can be held responsible if it is demonstrated that the person was overtly negligent (and worse, lied about it). .ie. claiming that a hard-to-fix bug is unlikely to manifest itself even though he/she know that was not true, or a tester who vouches a component was tested when it was not.

    114. Re:Nah by Anonymous Coward · · Score: 0

      Of course developers should be sued! Just the same way we can sue politicians for creating legal loopholes... Wait, can we do that?

    115. Re:Nah by Anonymous Coward · · Score: 1

      Developers rely on libraries to perform most functions, in general, these are where vulnerabilities come from. An application that uses jpg assets to render some content can hardly be blamed for a failure within the jpeglib. Any coder with more than 10 minutes experience would know that.

    116. Re:Nah by tibit · · Score: 1

      This is a pipe dream right now, but it doesn't have to be so. Software solutions that aid safety-critical development processes cost big bucks, same as training and really any sort of plain-language knowledge (standards aren't plain language). Compare this to the fact that, say, you can read on enterprise development best practices on many blogs, forums and documentation sites and it's free -- it's commodity. Try reading up something actionable on functional safety aspects of software development, ha ha -- at best you need $100 for one of Exida books just to get an overview of what's involved. Tools like Scade cost tens of thousands of USD per seat. Techniques and tools for developing reliable software will eventually become commodities, and as the knowledge hopefully permeates the industry, it will become a non-issue. It's like source revision control systems or parametric CAD systems -- once a big deal, right now they are either free (the former) or affordable (a couple hundred USD for a basic Alibre setup).

      --
      A successful API design takes a mixture of software design and pedagogy.
    117. Re:Nah by Anonymous Coward · · Score: 0

      That is a formatted/concatenated string. Code using prepared statement looks like this (pardon syntax errors):

      $cmd.statement = "select count(*) from users where user='@user' and pass='@pass'"
      $cmd.parameters["user"] = $_GET['user']
      $cmd.parameters["pass"] = $_GET['pass']

    118. Re:Nah by Geeky · · Score: 1

      In my experience, though, that's rarely the case. Bugs happen mainly due to time pressure or just simply not considering a set of possible inputs - sometimes the user will do something that leaves us scratching our heads and wondering where they got that idea from. Not following process should get you fired, not sued.

      Testing of software is usually automated anyway, so it's about having enough people with the right experience to develop test cases - including cases of sending deliberately incorrect or malicious inputs.

      --
      Sigs are so 1990s. No way would I be seen dead with one.
    119. Re:Nah by mcvos · · Score: 1

      Wait, in PHP a user can run arbitrary code on the server that hasn't been installed there? What kind of genius though that could possibly be a good idea?

    120. Re:Nah by Anonymous Coward · · Score: 0

      Was that software development though? I thought it was implementation rather than buggy software.

    121. Re:Nah by Anarchduke · · Score: 1

      HIPAA might be a good place to start.

      --
      who prays for Satan? Who in 18 centuries has had the humanity to pray for the 1 sinner that needed it most? ~Mark Twain
    122. Re:Nah by BVis · · Score: 1

      Who defines how much is "too much"? It seems to me like the prevailing attitude towards software development expressed by non-technical management is that no matter how much the software costs, it's too much. Telling management that a piece of software will take X hours to do and cost Y dollars leads to them stamping their feet and throwing a hissy fit about how high those numbers are, no matter how conservative the estimate is. Instead of trusting their technical folks to know what they're talking about (which is, in fact, why they pay them), they assume since they don't understand it, it must not be important, and therefore shouldn't take that long. They make wildly inaccurate estimates of how long something should take based on the function set they've requested, not how difficult or time-consuming developing those features might be. To them, it's just another place to type something in or another number on the screen. It can be as easy as changing a form (I'm assuming web development here, since that's what I'm most familiar with) to accept an additional input, or it can be massively complicated. To management, adding a field is the same under all circumstances, so if one field takes one man-day to add, then all fields should only take one man-day to add.

      First-hand experience: I used to work for a company that developed a certain kind of security utility. We were approaching a major revision, 1.x to 2.x. We were discussing timelines in an interdepartmental staff meeting, and our QA guy was asked for a time estimate to test the new product. He gave a number. Our VP of marketing (who, in a devastatingly stupid piece of management decision-making, was in charge of development) then said that he could have half that number, and said "QA always wants too much time. If it were up to them, the software would never be released." He didn't ask the QA guy why he thought it would take that long, or what the sub-tasks were, or how it was broken down by feature, or indeed any information that was used to justify the estimate, he just cut it in half because he assumed the QA guy was padding his estimate because he was lazy. To him, it was perfectly OK to sell a poorly tested product, because the testing wasn't a selling point, and selling points were all he was interested in. Who cares if the product is any good, as long as we can use it as a tool to separate people from their money.

      When management makes decisions based on artificial timelines or appearances, space shuttles blow up.

      --
      Never underestimate the power of stupid people in large groups.
    123. Re:Nah by ArsenneLupin · · Score: 1

      Even in a very horizontal market,

      Is this like the "window shopping" district in Amsterdam?

    124. Re:Nah by Anonymous Coward · · Score: 0

      "make hardware resources available to the cloud"

      Ha... hahahah! That's GENIUS.

      The software doesn't 'make your computer part of a botnet', it makes it 'cloud compatible'.

    125. Re:Nah by Anonymous Coward · · Score: 0

      The functionality of this software may be changed at any time...

    126. Re:Nah by ILongForDarkness · · Score: 1

      How exactly do you define trade dress rigorously? A company might think rectangle with rounded corners is their distinct design but it turns out to be having the power button 1cm from centre of the bottom that everyone things is amazing. So to protect themselves companies patent every single part of a design whether it is truly something no one has thought of before or not. The whole point of getting the patent/trademark whatever is it will hopefully stop all the little guys from trying to copy you and provide ammo for mutually insured destruction against your bigger competitors.

      I get your point that when it is clear what qualifies their will be less legal action I'm just not sure that courts/legislator will ever be rigorous enough or should they (because there is the flip side of something truly innovative falling outside of protections because protections didn't take into account their possiblity).

    127. Re:Nah by jedidiah · · Score: 1

      No. He understands the point completely.

      Software is cheap precisely because it is put together with the least possible care that industry can get away with. The moment you alter this, Software will by necessity become much more expensive. It's not trivial and it's not cheap to produce more reliable software.

      Toy manufacturing is the result of about 300 years of manufacturing experience plus about 10,000 more shared expertise in bespoke production before that.

      Plus toys are remarkably simpler.

      --
      A Pirate and a Puritan look the same on a balance sheet.
    128. Re:Nah by ILongForDarkness · · Score: 1

      Good example. D666 data can be a beast :) Seriously though, with any scale of a project not even counting for the fact that you probably won't remember everything when 6months go by, other developers will be trying to call your functions and won't realize that it is a problem. It might work in any testing they do until it hits the real world with large datasets, unusual inputs, or an attacker and then it goes "boom". Than who do you blame? The person that wrote the function thinking no one will use it again and the piece that does use it is throughly tested? The second guy that was just trying to get something done and it seemed to work? The company for not forcing strict architecture/documentation practices?

    129. Re:Nah by Aryden · · Score: 1

      umm no. If that were the case, you wouldn't have small 1-2 doctor practices. Where are you coming up with this insane bond?

    130. Re:Nah by Anonymous Coward · · Score: 0

      The fact that I don't care if my credit card number is used does not imply that I know jack about security. It merely means that I don't care since I'm not responsible for charges that I did not authorize

    131. Re:Nah by JoeMerchant · · Score: 1

      A doctor, first off, invests much more in their education and makes much more money than a programmer (on average, yes there is overlap - I program and I make more than some doctors, not many).

      Secondly, when a doctor gets hit with a malpractice suit, it comes from an individual. If the kid who distributed Napster were found liable for $100 damages to every person who installed his software, what would that total?

    132. Re:Nah by Matheus · · Score: 1

      Not really... here's a programmer from the 70s who would completely agree with him:

      http://en.wikipedia.org/wiki/Halstead_complexity_measures

    133. Re:Nah by eth1 · · Score: 1

      Are you guys crazy?

      Do you realize how much bridges cost?

      Yeah... Windows 7 is probably way more complicated than even something like the Space Shuttle. I can't even imagine how much it would have cost to develop if the same level of engineering, QA, etc. was used.

      And even with all that, don't forget that the shuttles still had a 40% (per unit)/1.5% (per mission) critical failure rate.

    134. Re:Nah by Anonymous Coward · · Score: 0

      "excessively poor software should result in some form of negligence..."

      No, excessively poor software IS the result in some form of negligence.

    135. Re:Nah by Anonymous Coward · · Score: 0

      If you want $50 software, you're not entitled to that kind of liability protection. That's the kind Microsoft sells.

      You want hardened software with guarantees, it's out there. You're just going to have to pay for it.

    136. Re:Nah by Anonymous Coward · · Score: 0

      Come on man. Don't you at least read Slashdot?

    137. Re:Nah by tendrousbeastie · · Score: 1

      The comparison is not entirely fair.

      If the Chinese made toy hurts someone that is either because of the actions of a) the user, or b) the manufacturer.

      With software there is a third party. A bridge builder isn't held liable if someone bombs the bridge. A drinks manufacturer isn't held liable if someone poisons the drink. But this conversation suggests that a software developer should be liable for similar third party attacks.

      I tend to agree with the comments that say that solutions should be contractual - if you want that security then pay for it, and if you don't want the risk then don't buy stuff that doesn't (in a legally binding way) promise it.

    138. Re:Nah by cartman · · Score: 1

      Be careful about the source here. Actually track down the CBO report and verify that the quotation is not being taken out of context.

      Where I live, physicians must pay $20,000-$90,000 per year for malpractice insurance, depending upon specialty (http://www.mymedicalmalpracticeinsurance.com/california-medical-malpractice-insurance.php#2010). Since there are 100,000 physicians in CA, we can guesstimate that $4-5 billion is spent on malpractice insurance just for CA, which is nearly as much as your source claims is spent for all medical malpractice for the entire country.

      Here is another quotation from the dept. of Health and Human Services:

      About 10 percent of the cost of medical services is linked to malpractice lawsuits and more intensive diagnostic testing due to defensive medicine, according to a January 2006 report prepared by PricewaterhouseCoopers LLP for the insurers’ group America’s Health Insurance Plans. The figures were taken from a March 2003 study by the U.S. Department of Health and Human Services that estimated the direct cost of medical malpractice was 2 percent of the nation’s health-care spending and said defensive medical practices accounted for 5 percent to 9 percent of the overall expense.

      ...which I gathered by typing the issue into google and following the link to a wikipedia page (http://en.wikipedia.org/wiki/Medical_malpractice).

    139. Re:Nah by cartman · · Score: 1

      Yep. Quality of code is pretty much a measurable thing. Looking at the things I identified in B above, if someone's code does not possess any of those violations, or if any such violation is rarely found, then that shows the person has done a best professional effort.

      No. Code quality is definitely not a measurable thing, using any simple metric. Many people have tried to come up with some automated way of measuring code quality but nobody has even come close to succeeding. Measuring code quality is a hard problem.

      Even if a programmer has done all the things you spoke of, it does not mean that he has done a "best professional effort". His code could be crap in all other ways. There are a million ways that code can be crappy, and new ones appear over time as languages evolve.

      It would definitely be possible to prove negligence if a programmer committed certain obvious and well-known mistakes like not sanitizing input. This much could be detected using automated tools. Perhaps we could have negligence lawsuits for things like that. But that is not a measure of code quality.

    140. Re:Nah by HornWumpus · · Score: 1

      Backwards. Remember the old joke: 'A building designed by an architect might fall down, but a building designed by an engineer should be torn down.'

      Specifically you need a 'Structural Engineers' license to sign off on the plans. While I'm sure the is an architect somewhere with a S.E. most are just artists who draw pretty pictures and leave it to the engineers to figure out how to actually build the thing.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    141. Re:Nah by Aryden · · Score: 1

      Then add a no class action clause in your eula as well as a release of indemnity. Shit this is not hard people.

    142. Re:Nah by JoeMerchant · · Score: 1

      Sure, works for MDs doesn't it? Have you ever read all the stuff they make you sign before they administer any kind of treatment? EULAs hold water like toilet paper, a drop here and there, but they fall apart quickly if the stakes get high.

    143. Re:Nah by craigminah · · Score: 1

      Just put a STUPID button on every article posted, if it reaches a predetermined thresh hold that poster gets sued. What could go wrong?

    144. Re:Nah by Elminster+Aumar · · Score: 1

      Ah but we're not talking about being sued for personal values or relative constructs. We're talking about being sued for code that simply doesn't work (for whatever reasons). Personally, I think the M$ argument about this is perfect and should be a closed case at this point. I don't, however, believe this article was stupid. Not everything knows about this kind of stuff despite popular (egomaniac) /. mentality.

    145. Re:Nah by Elminster+Aumar · · Score: 1

      *everyone

    146. Re:Nah by sjames · · Score: 1

      You can do that, but only if you are willing to pay the releasing company to vet your particular installation.

      It's only fair, no engineer would be willing to design you a generic bridge and then stand behind the design no matter where you decided to actually build it.

    147. Re:Nah by sjames · · Score: 1

      Actually, no. The $0.99 toy absolutely does not and is not expected to guarantee that it will not harm someone. It is guaranteed to not harm someone when played with properly.

      It is understood that the manufacturer is not responsible if the kid leaves it on the front steps and dad slips and busts his ass. Also they are not responsible if the kid bashes his little brother on the head with it. They are not responsible if big brother douses it with bug spray, sets it on fire, and launches it with his slingshot.

      Attacking software with various and sundry 'hacking' techniques constitutes not playing with it properly.

    148. Re:Nah by LiENUS · · Score: 1

      You're talking about parametrized queries not prepared statements. My example actually is a prepared statement. the query isn't executed until you run ibase_execute($hnd) (although it is quite useless given that I didn't put any parameters in) interestingly enough just in your quick reply you made a few mistakes. You don't need the single quotes around the parameter names and you didn't sanitize your input variables. Maybe writing secure database code isn't quite so easy.

    149. Re:Nah by KingBenny · · Score: 1

      i'll second that Nah of yours. It would spawn a whole lot of trolls looking 24/7 for the slightest of flaws .. o wait? would that be good... nah ... just like the other trolls. I can see why m$ is against it, lol. I didnt bother installing a scanner on the w8 preview tho, not had any problems yet but all i run on it is Steam. I suppose that's more or less self-sustained. Anything else ... linux.
      If they do i hope it includes a clause for lawmakers making laws that turn out to be full of holes as well as cops harassing people on small letters.

      --
      Free speech was meant to be free for all... how can anyone grow up in a nanny state ?
    150. Re:Nah by Eponymous+Hero · · Score: 1

      i referred to a csrf, not xss. although this poor dev's little hand drawn admin mode was also vulnerable to xss. it was a nightmare to look at.

      --
      insensitive clod overlords obligatory xkcd car analogy russian reversals whoosh pedant fanbois ftfy in 3...2...1..PROFIT
    151. Re:Nah by Eponymous+Hero · · Score: 1

      i'm not sure where everyone is getting xss from. i said cross-site request forgery, that's csrf. and yes, this person's app was (very poorly) written in php.

      --
      insensitive clod overlords obligatory xkcd car analogy russian reversals whoosh pedant fanbois ftfy in 3...2...1..PROFIT
    152. Re:Nah by Eponymous+Hero · · Score: 1

      this person owns their own business. he's not an advanced dev by any stretch of the imagination. he doesn't use version control, he's just starting to discover "frameworks" though i don't know if he really understands the concept yet. he taped together some php code that let him set a cookie marking himself as as admin, and a setting variable that allowed him to "debug" his code. this was essentially a form box at the bottom of the page that let him run arbitrary code at certain points -- all for the sake of not swapping back to his code editor, saving, swapping back to the browser, refreshing. the site that got attacked was so small i don't know how he was found. my guess is he posted for help on a bunch of forums and left links to his site. i thought it was funny that there was some pdo code in the site, because he'd outsourced to india for a couple months to handle his workload. i've known him for longer than i've known how to code and he has a pride issue with asking me for help in that area.

      if you have a form input box that lets you update variable values with ajax like as if it were firebug, you can skip prepared statements. the overall point is that with enough ignorance and carelessness you can build an app that lets someone abuse every major vulnerability, while still thinking that you're secure, even using prepared statements for your own queries.

      --
      insensitive clod overlords obligatory xkcd car analogy russian reversals whoosh pedant fanbois ftfy in 3...2...1..PROFIT
    153. Re:Nah by philip.paradis · · Score: 1

      That's not how PCI works at all. Please educate yourself.

      --
      Write failed: Broken pipe
  2. Short answer: No by Anonymous Coward · · Score: 1

    Long answer: Noooooooooooooooooooooooooooo

    1. Re:Short answer: No by Kergan · · Score: 1

      Why not? As an indie dev, it kind of freaks me out, but if it drives as little as half of th crap coders outside of the market, it might be a very good idea...

    2. Re:Short answer: No by Anrego · · Score: 5, Insightful

      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)

    3. Re:Short answer: No by Nethemas+the+Great · · Score: 1

      The "why not" is because all it would result in is more outsourcing to countries outside of jurisdiction.

      Either way, bad software is more of a consequence of bad managers than bad developers. Managers allocate resources to projects--including development talent, managers demand deadlines contrary to software quality. If people should be held accountable it should be the ones running the show not the ones taking orders.

      --
      Two of my imaginary friends reproduced once ... with negative results.
    4. Re:Short answer: No by eddy · · Score: 1

      I'd invoke some form of principle of proportionality. A law where all programmers were liable for their code (no exceptions, straight up same for something that is given away for free as something used in airplanes) would mean the eradication of industries, a set back of science and progress almost unfathomable. Who would have written the first web-browser under such tyrrany? No one. Who'd write a $4 game when the liabilty at the other end of the balance board weighs in at multiple millions, or conversely, who could write a $4 game using methods that guarantee no software errors? No one. Things we take for granted today couldn't exist. Freedoms we have to distribute our code on the web, no strings attached, would have to go away. And to solve what problem?

      At the most basic level, do we really need to give lawyers more tools to fuck us all over with? Really? Because lawyers are the only ones who would profit from this kind of legislation. Everyone else will be losers.

      --
      Belief is the currency of delusion.
    5. Re:Short answer: No by lightknight · · Score: 1

      Exactly. Imagine the insurance premiums -> they will be comparable or larger to what the engineers / doctors pay.

      Software will become to expensive, in reaction, that the field will collapse.

      --
      I am John Hurt.
    6. Re:Short answer: No by lightknight · · Score: 1, Funny

      Yes, and I am sure the managers will be the ones to pay the price.

      --
      I am John Hurt.
    7. Re:Short answer: No by Elminster+Aumar · · Score: 3, Insightful

      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.

    8. Re:Short answer: No by Anonymous Coward · · Score: 0

      It will start to resemble the medical business with developers becoming hyper conservative and progress slowing to a crawl.

    9. Re:Short answer: No by trev.norris · · Score: 1

      Can we all email this a million times to the "Cambridge academic" that believes suing developers is a good? Seriously, how long did it take to figure out this was such a bad idea.

    10. Re:Short answer: No by Anonymous Coward · · Score: 1

      Did you develop the programming language you use? Did you build the IDE and the compiler? Did you design the framework, if applicable? How about the target hardware, did you do that yourself?

      If you can't answer "yes" to every single one of the above questions, then you should already know why laying the blame at your feet for bugs found potentially upstream from you is a really bad idea.

    11. Re:Short answer: No by Anonymous Coward · · Score: 1

      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.

      But I thought that the reason for the manager's high wages was exactly this: because it's all on their shoulders...

    12. Re:Short answer: No by lightknight · · Score: 1

      As long as you don't mind paying a few thousand for a single copy of an office suite, okay.

      --
      I am John Hurt.
    13. Re:Short answer: No by TubeSteak · · Score: 1

      - a whole insurance industry will spring up around it (think malpractice insurance)..

      If insurers get involved, they will set up their own rules and regulations to require good coding practices.
      Why? Because they sure as shit do not want to pay out.

      --
      [Fuck Beta]
      o0t!
    14. Re:Short answer: No by Anonymous Coward · · Score: 0

      Uhm, you're mistaking the insurance payout with some mythical measure of bad practice. There are plenty of bad doctors. Medical malpractice insurance doesn't necessarily stop them from practicing medicine. Plenty of good doctors get sued, too (and plenty of times the insurance has to pay for that). In a system where the amount paid is decided by a jury of peers, this doesn't really work. Malpractice insurance is basically a gigantic bag of money that various people drain from for reasons completely unrelated to the quality of services rendered.

    15. Re:Short answer: No by Anonymous Coward · · Score: 5, Insightful

      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.

    16. Re:Short answer: No by Grishnakh · · Score: 1

      This is frequently (but not always) the case, but it still has bugs. Should users be able to sue open-source developers for bugs then, even though they paid nothing for the product? No? Then why should they be able to sue a for-profit company for any more than they spent on the software?

    17. Re:Short answer: No by Grishnakh · · Score: 2

      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.

    18. Re:Short answer: No by Grishnakh · · Score: 1

      And if you look at the level of technology used in most law offices, the lawyers wouldn't miss out on all the things that would go away. Hell, most law offices are still using faxes!

    19. Re:Short answer: No by Anonymous Coward · · Score: 0

      A fax of a documented signature, by most laws, can be used in most places as if it were an original copy. Most other forms are not, or not widely accepted yet.

    20. Re:Short answer: No by Cute+and+Cuddly · · Score: 0

      You should be able to sue when products you have paid for are faulty. The previous comment states clearly "I use open souorce. It has a much smaller number of bugs", obviously there is no claim about absence of bugs there. Also, the value of a settlement should not be related to what you have paid for the product, but what damage was produced by the negligence of the organization that produced the product in question. Paying for goods or services implies a level of expectation that does not exist when you receive something for free.

    21. Re:Short answer: No by Grishnakh · · Score: 1

      Right, so why can't I do the same with a scanned document sent by email? It's utterly stupid. And don't say the law offices are just bound by the law; who do you think writes the laws?

    22. Re:Short answer: No by Grishnakh · · Score: 1

      The previous comment states clearly "I use open souorce. It has a much smaller number of bugs", obviously there is no claim about absence of bugs there.

      The software makers who sell software have never claimed their wares are free from bugs either.

      Also, the value of a settlement should not be related to what you have paid for the product, but what damage was produced by the negligence of the organization that produced the product in question.

      Open-source software is used in all kinds of mission-critical places: internet servers, stock market exchanges, etc. You think a stock exchange should be able to sue Linus when something goes wrong (though admittedly, it never seems to)?

      Paying for goods or services implies a level of expectation that does not exist when you receive something for free.

      No it doesn't. What if the price is dirt cheap? What if the software is being sold for $0.99? Somehow the maker is suddenly liable for every bug that might be in there? What if they make two versions, one for $1 that has no ads, and one for free which has ads? Are you saying now they should be absolved of liability for the ad-laden version, but made to pay millions if their $1 version deletes all the contacts on some billionaire's smartphone supposedly making him lose millions in business, even though he was too stupid to keep them backed up? Even though both are essentially the same software, and both are producing profit for the software maker?

    23. Re:Short answer: No by shutdown+-p+now · · Score: 3, Insightful

      So, how does the price of a typical industrial control system compare to the price of typical boxed software for popular platforms?

    24. Re:Short answer: No by jeremyp · · Score: 1

      Also, the value of a settlement should not be related to what you have paid for the product, but what damage was produced by the negligence of the organization that produced the product in question

      So, if you pick up a random Linux distribution for free that has a serious security defect, then you should be able to sue for damages. Free is just one end of the scale of payment.

      Paying for goods or services implies a level of expectation that does not exist when you receive something for free.

      If you provide this protection only for paid software, people will stop using open source. To an extent, this already happens in some places. In many cases, management types I have met have refused to authorise the use of open source software because there is no warranty. There's nobody to sue when something goes wrong. Of course, this is based on a fallacious premise: that you can successfully sue a large software company when something goes wrong. If the premise becomes true because of a law, you can guarantee that every article comparing open source software with its proprietary rivals will mention this: "project foobar clearly has the best features of all the products we reviewed, but unfortunately affords you no protection under the Software Negligence Law, being free".

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    25. Re:Short answer: No by jeremyp · · Score: 1

      Because it's the law.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    26. Re:Short answer: No by bloodhawk · · Score: 1

      When it comes to high end professional grade software such as those in industrial control systems this is all well and good as the developers can charge for the cost. This is simply not feasible in complex cheap pieces of software, the amount of rigour performed has to cost less than the amount of money they can get for the software. A complex piece of software can and will have literally thousands of bugs even when well engineered and no matter how hard you try their will always be more. Software is a tradeoff between time, quality and cost, if heavy costs are enforced then you will simply see less products and many products die off completely.

    27. Re:Short answer: No by Bert64 · · Score: 1

      The trouble is the managers are generally not very technical and are unable to differentiate between someone highly competent and a blagger...

      They also judge developers by the wrong standards, someone who turns up in ripped jeans and an old geeky t-shirt is likely to be a much better developer than the guy who turns up in a new suit, but managers will typically hire the latter.

      And finally managers can only hire whoever applies (and isnt pre-screened out by hr in some cases), and the only control they have over who applies is basically the budget their bosses allocate them for hiring... If you are offering low wages, you will get very few applicants and most of them will be incompetent. The odd time you get lucky and hire a good applicant they won't stick around because sooner or later they will realise they can make more elsewhere, and were usually just using you to get some job experience and a reference under their belt.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    28. Re:Short answer: No by WarOfTheNerd · · Score: 1

      Only paid software would be affected by this. So the industry would change to revolve around the support market, so as to shut out the need for insurance. Indie devs will continue to be paid because they can charge a fee for signed download/update access, rather than for the software itself. This type of legislation would only ruin companies charging money for evil proprietary software, companies that already deliver SLAs like Red Hat would be in the clear.

    29. Re:Short answer: No by Anonymous Coward · · Score: 0

      try convincing the manager you need extra development time to make everything according to industry best practices.
      Also remember the rest of your team might not be so scrupulous as you and might say "I can do that in 1/3 of the time".
      Also remember the manager is afflicted by short term vision: "how fast can i get to the next rung of the ladder".
      He doesn't care about industry best practices, he cares about making himself look good to the upper hierachy, which amounts to
      - get the job done with least budget possible.
      - get to the next rung of the ladder before the fallout of poorly written code hits the fan

    30. Re:Short answer: No by Anonymous Coward · · Score: 0

      Typical software (Firefox, OpenOffice, Etherpad, Apache, PostgreSQL): $0
      Typical control system: $10000/unit.

    31. Re:Short answer: No by YttriumOxide · · Score: 1

      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.

      Not much more, but still some... I'm one of those "low level managers" - specifically, my title is Software Development Supervisor. I'm in charge of a small team of developers (and the majority of my time is active development or related activities, with about 25% to 50% spent on managing the team, dealing with other departments, handling spec decisions and other such stuff); but there's three levels above me to reach the company president.

      My income is about 25% more than the highest paid Software Developer (by title) in our group.

      --
      My book about LSD and Self-Discovery
      Also on facebook as: DroppingAcidDaleBewan
    32. Re:Short answer: No by Anonymous Coward · · Score: 0

      The price would necessarily go up, but it wouldn't be that bad. I think you would treat it like any other thing - for example a consumer lamp is designed to a fairly lax set of standards (basic electrical standard for wherever you are), whereas an emergency light to be installed in an explosive area requires a significantly higher degree of engineering and testing, as well as bespoke engineering around selection, installation and maintenance.

      Your average consumer boxed software would undergo a relatively simple design process to ensure no seriously negligent practices were used (more likely people would program it however they do now, but if they got caught out by a bad bug, they'd be liable), and then more critical software would be held to a higher degree of rigour. I wouldn't expect a game to be bug free, but I'd damn sure expect that someone developing e-commerce software to SELL games to have followed a well thought-out design methodology to minimise exploits.

      Agreeing on design methods, levels of rigour, and when they should be applicable, is the next step towards standardisation of software development. I think it's just a question of time before current software practices coalesce around a set of best practices which become the obvious foundation for an engineering approach to software development.

    33. Re:Short answer: No by Hillgiant · · Score: 1

      Nice strawman you got there. We are not talking about game developers.

      --
      -
    34. Re:Short answer: No by Hillgiant · · Score: 1

      Damnit. I misread the article. Nevermind.

      --
      -
    35. Re:Short answer: No by Anonymous Coward · · Score: 0

      What measures and efforts is reasonable? And it's not like industrial control systems are that grown up, if they were, these SCADA APTs wouldn't exist now would they?

    36. Re:Short answer: No by eth1 · · Score: 1

      You forgot one of the most important ones:
      - The software industry will lobby to have any laws regarding this apply also to free software, effectively killing off free/open source software.

  3. Would stop a lot of development by Burdell · · Score: 5, Insightful

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

    1. Re:Would stop a lot of development by Anonymous Coward · · Score: 0

      If it was possible to prevent all security holes, this wouldn't be a bad idea.

      Indeed - there is too many variables involved (OS, memory corruption, etc).
      To go for a car analogy, wouldn't it be something like a car warranty guaranteeing that the car will run under any gravity or in presence of an acid rain?

    2. Re:Would stop a lot of development by proprioceptionZ · · Score: 1, Interesting

      Yes. You can't "prove" that anything but a trivial program works correctly. I think that was the conclusion of the famous paper by Turing in the 1930's.

    3. Re:Would stop a lot of development by ZombieEngineer · · Score: 1

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

    4. Re:Would stop a lot of development by Anonymous Coward · · Score: 0

      My first thought was, "Is this being pushed by the insurance sector?"

    5. Re:Would stop a lot of development by arth1 · · Score: 4, Informative

      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.

    6. Re:Would stop a lot of development by Palinchron · · Score: 1

      However, it is provably impossible to do so.

      Oh? Please prove it, then.

      --
      The lesson here is that a sufficiently large corporation is indistinguishable from government. --ultranova
    7. Re:Would stop a lot of development by Anonymous Coward · · Score: 0

      Or even suing the manufacturer for any repair/work outside of the recommended maintenance.

    8. Re:Would stop a lot of development by Anonymous Coward · · Score: 1

      Turing already did. This reduces to the halting problem.

    9. Re:Would stop a lot of development by Anonymous Coward · · Score: 0

      I always hate the term input validation, especially because this is often named in the same paragraph with SQL Injection.

      Your program should handle all the input that the user can give to you correctly, valid or not, especially on opaque fields that just have to be entered into a database.

      If we are talking about personal fields, the following examples should be treated as completely opaque:
      - Name (never use first name, last name, etc, you will miss something, just use name (and maybe a 'western/nick-name' field). You know how many systems don't accept names like O'Donnel because they are not 'valid'? )
      - Address (don't try to be clever with street names, house numbers, postal codes and countries. You will do it wrong, just let the user enter the address as he knows best).
      - Passwords (Yes, also allow chinese characters).

    10. Re:Would stop a lot of development by SwashbucklingCowboy · · Score: 1

      It would also raise prices significantly to help pay for that insurance, the tools to find the issues and the extra time to run them.

    11. Re:Would stop a lot of development by Palinchron · · Score: 1

      Please explain how. From the undecidability of the halting problem you can derive that there can be no program that reliably decides whether a given program is secure, but this is a very long way from saying that it's impossible to prevent all security holes.

      What keeps me from trying to prove a given program's security by hand? Or how about a program that can prove security IF the input program if sufficiently well-written, giving up on secure but unclear programs for which it can't be sure? Turing's argument doesn't disallow that, and in fact it's perfectly possible.

      --
      The lesson here is that a sufficiently large corporation is indistinguishable from government. --ultranova
    12. Re:Would stop a lot of development by Palinchron · · Score: 1

      No, he proved that you can't decide whether a program works correctly. It does not follow that you can't prove correctness for particular programs.

      --
      The lesson here is that a sufficiently large corporation is indistinguishable from government. --ultranova
    13. Re:Would stop a lot of development by VortexCortex · · Score: 4, Interesting

      Turing already did. This reduces to the halting problem.

      That's incorrect. The halting problem deals with finding a general purpose algorithm that applies to all cases, but we're talking about solutions to specific problem sets, which absolutely can and do exist.

      I've written assembly programs, especially drivers, that were provably free of all bugs: Every series of opcodes did EXACTLY what it was supposed to do under all possible inputs. It's infeasible to develop all software in such a rigorous manner only due to cost, not due to some fault of the hardware or its software (the opcodes).

      I didn't have to test my driver over an infinity of inputs because the hardware had a finite set of possible inputs. The bits are limited -- We don't have Turing's infinitely long tape as a CPU word size.

    14. Re:Would stop a lot of development by ClassicASP · · Score: 1

      I think this would lead to investors actually encouraging, even DEMANDING, that their developers leave a digital paper trail of false claims to stability and features in certain types of software and web development projects. Most likely it would happen to new programmers fresh out of college who haven't learned the ropes out in the real world yet and wouldn't see it coming. They'd be under pressure to send emails making all kinds of claims that they know are false, but, being new to the job market, they're more likely to bend and give in.

    15. Re:Would stop a lot of development by Shoten · · Score: 1

      Actually, it would be like a car warranty guaranteeing that people couldn't crash into you, no matter how hard they tried of how much they tricked out/modified their own vehicles to make it easier to hit you.

      --

      For your security, this post has been encrypted with ROT-13, twice.
    16. Re:Would stop a lot of development by samjam · · Score: 1

      And because you were testing a specific driver not an infinity of drivers.

      Your driver did not get stuck in a loop where it might or might not terminate at any moment.

      Of course it might.... if the hardware it talks to is faulty - but maybe you already tested for that?

    17. Re:Would stop a lot of development by Anonymous Coward · · Score: 0

      Heh. While you're sitting there looking smug, try looking up Godel's incompleteness theorem. There was an article in the Communications of the ACM within the past few months that described the problem in detail.

      Short answer: it is provably impossible to construct an unhackable software system that has to deal with external input, as long as the entirety of the problem exists in the software domain. Now, if your driver never (and I mean never) had to deal with any sort of external inputs, then it's possible for you to have written such a system. However, such systems typically aren't very useful.

    18. Re:Would stop a lot of development by Palinchron · · Score: 1

      it is provably impossible to construct an unhackable software system that has to deal with external input

      Again, prove it. If reducing from the undecidability of the halting problem, of even the incompleteness theorem, show how.

      --
      The lesson here is that a sufficiently large corporation is indistinguishable from government. --ultranova
    19. Re:Would stop a lot of development by Anonymous Coward · · Score: 0

      If it was possible to prevent all security holes, this wouldn't be a bad idea. However, it is provably impossible to do so.

      I'm going to assume that by "provably impossible" you mean "not decidable". It is only provably impossible to make a program that can correctly detect if ANY program has security holes. If you allow it to say "I don't know" on particularly obtuse programs then there is nothing theoretical to prevent such a program from existing. So no, it's not provably impossible to prevent all security holes in the sense that the problem is perfectly decidable once you restrict yourself out of programs that no human who wasn't trying to break the prover would write anyway. In fact non-trivial programs are proven correct all the time, serving as a counterexample to your claim - if you claim is indeed about undecidability.

    20. Re:Would stop a lot of development by roc97007 · · Score: 1

      IANAL but I think there are "reasonable person" legal clauses that would apply. IE a reasonable person would expect that if you set passwords on all your accounts, someone would not be able to log in by hitting escape. Oops, that one actually happened.

      A reasonable person would expect that your ATM would not let the next guy access the account you just accessed after you retrieved your card. And so forth. I think a case could be made that it's about reasonable expectations.

      And of course, it would be up to juries and precedent to decide what was "reasonable".

      --
      Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
    21. Re:Would stop a lot of development by Burdell · · Score: 2

      As soon as it is up to juries to set precedent, the small-time software developer is going to quit. I certainly wouldn't release or contribute to any free software that could cause me to get sued; I wouldn't have time or money to pay a lawyer to eventually hopefully get a decision in my favor.

    22. Re:Would stop a lot of development by Darinbob · · Score: 0

      The subject seems to imply "developers" but in reality it seems to mean the company itself gets sued. Yes, if it's an individual developer that's a problem, but not so much if a large corporation gets sued instead of Bob in cube 357 who let a bug slip past.

      However like most lawsuits what will really matter is not really the security itself but that the company knew there was a security problem and willfully did nothing about it.

    23. Re:Would stop a lot of development by shutdown+-p+now · · Score: 1

      You do realize that there are real world programs today that are verifiably correct, right? As in, there is a strict mathematical proof that for any given set of inputs, they will produce outputs according to the specification.

    24. Re:Would stop a lot of development by jeremyp · · Score: 1

      Provably?

      I'd like to see that proof.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    25. Re:Would stop a lot of development by thsths · · Score: 1

      > You can't "prove" that anything but a trivial program works correctly.

      No, that is not at all what he proved. He proved that unless you limit yourself to trivial programs, there are always going to programs where you cannot reasonably figure out whether they work correctly. It is the mathematical proof that bad (as in difficult to understand) programs exist.

      That is directly relevant to this discussion, but only the incompetent will use it as an excuse for delivering bad programs. All you have to do is avoid writing programs that are difficult to understand, and you are fine. That is one of the key rules of writing secure programs: keep it easy, keep it simple, and do peer reviews.

    26. Re:Would stop a lot of development by Anonymous Coward · · Score: 0

      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.

      How about storing passwords in a plain md5 hash with no salt or stretching? For any serious attacker, plain md5 is pretty much plain text. A lot of people would consider this to be a terrible practice, but should you be sued for negligence? I'm not asking purely rhetorical questions here; the fact is that although there are various security best practices floating around there, there's not much in the way of hard consensus about how things *must* be done. That's exactly why I don't think we should have laws like this without first thinking through proper standards. What constitutes an appropriate level of security depends heavily upon context. Furthermore, at the end of the day, the person making the call about the appropriate level of security is probably not a developer, but rather a project manager whose level of technical understand could either be very deep or very shallow. On my first job out of college, I worked on a project that was using plain md5 hashes for passwords. When I told the managers that we really ought to change this, they pretty much completely blew me off.

      The bottom line is, before we start suing everyone, we need to have some real, actual legal standards like civil engineers or doctors or electricians. Once we have the rules established and companies are aware of them, then we can possibly start seeing lawsuits like this. But doing it before any clear rules are set down is an invitation for disaster.

    27. Re:Would stop a lot of development by jeremyp · · Score: 1

      Actually, what he proved is that there is no general algorithm for deciding whether an arbitrary program terminates or not. But that does not mean that it is impossible to decide that any particular program never terminates. For instance, if I show you a program with no loops in it, you can decide that it terminates. If I show you a program like while (true) printf("Hello \n"); you can decide it doesn't terminate.

      Anyway, that's not what the parent post said, it said:

      If it was possible to prevent all security holes, this wouldn't be a bad idea. However, it is provably impossible to do so

      In the context of this discussion, this is saying that it is provably impossible for me to eliminate all of the security holes in my new online banking application. I will grant that it might be a difficult task, if my application is even moderately complex, but provably impossible? I don't think so.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    28. Re:Would stop a lot of development by Anonymous Coward · · Score: 0

      "Provably"?

      I think you mean "empirically", and that that needs further qualification too.

    29. Re:Would stop a lot of development by jeremyp · · Score: 1

      Gödel's Incompleteness Theorem says that in any consistent formalisation of number theorem there exist true statements that cannot be proved within that formalisation. It does not say that in any consistent formalisation of number theorem all true statements cannot be proved within that formalisation.

      There certainly are formalisations of number theory in which many statements can be proved. For instance, In GEB, EGB Douglas Hofstadter proved that addition is commutative within his TNT formal system.

      The analogous statement to Gödel's Incompleteness in the context of this discussion would be "there exist programs which cannot be proved to be secure". That's a long way from "program X cannot be proved to be secure" where X is, say, my new banking application. It's even further from the statement "program X is secure".

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    30. Re:Would stop a lot of development by jeremyp · · Score: 1

      Sorry, the first paragraph should be

      Gödel's Incompleteness Theorem says that in any consistent formalisation of number theory there exist true statements that cannot be proved within that formalisation. It does not say that in any consistent formalisation of number theory all true statements cannot be proved within that formalisation.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    31. Re:Would stop a lot of development by Anonymous Coward · · Score: 0

      Yes, the manufacturer is liable, you don't go through them and sue the designer themselves.

    32. Re:Would stop a lot of development by Rockoon · · Score: 1

      Exactly this. It is clearly possible to write software that handles all possible inputs in a well defined manner. As a trivial example, consider the simple case of image processing where an image is defined as an array of 8-bit R, G, and B values. All possible inputs are "valid by definition"and because of that its no surprise that the vast majority of image processors never crash while "processing" no matter what the data is.

      It isnt until you get into things like JPEG decoding, where suddenly all inputs are not "valid by definition," that you start finding lots of critical bugs (not just wrong output values) in image processing software. It is certainly non-trivial to verify algorithms that consume data that might be invalid, but its still possible. It is this non-trivialness that is the problem. It takes more effort to handle the invalid inputs correctly than it does the valid ones.

      --
      "His name was James Damore."
    33. Re:Would stop a lot of development by CaptainLard · · Score: 1

      Would it? Just add something to the effect of "User waives right to sue. All grievances must be settled by our in-house arbitration." to the EULA. In fact, its probably in there already!

    34. Re:Would stop a lot of development by Anonymous Coward · · Score: 0

      what your saying is sokethijg like this:
      if you come in my house and a burglar stoles your phone, then it's ok for you to sue me fo leaving the door unlocked.
      it't not ok, because becauese the burglar had no write intering my house. This is the same whit websites, the developer/owner is not responsable for the cracker's actions (for forceing his way in).
      No one is forcing you to use a service. The choice ia your to chose the one's that advertize better security options.

    35. Re:Would stop a lot of development by Anonymous Coward · · Score: 0

      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.

      As a programmer I have had this scenario at my previous employer:

      Me: We need to hash the passwords so they aren't visible in the database when stored
      Manager: Don't spend the time on it, Store it as is

      Should I be blamed because I did as the manager asked me to, just because some managers will get you fired in a flash?

    36. Re:Would stop a lot of development by arth1 · · Score: 1

      Did you get him to sign off on that decision?
      If so, you should be in the clear.

    37. Re:Would stop a lot of development by dkf · · Score: 1

      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 utterly gut-wrenchingly wrong. Do you write PHP for a living? That's a language community which uses faux CS statements to mentally justify delivering insecure crap.

      To prove a program correct, all you have to do is show that it will only ever do correct things, that if given an input that is illegal, it will be guaranteed to be rejected (in a defined fashion). Program correctness is usually either pretty tractable (unless you do something evil like creating a program that is only correct if it is wrong and vice versa; such things are evil but not actually written normally) or coupled to the difficulty of proving some nasty piece of math. Moreover, a very large fraction of programs do not use complex theorems: they are wholly tractable.

      Which isn't to say that they're easy to prove. Making a proven-correct program usually starts from the basis of invariants over operations and a very thorough grasp of what is actually happening and where. A large pile of code spaghetti (or its OO equivalent: code ravioli) is always going to be awfully hard to grasp.

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
  4. Sure by BigSlowTarget · · Score: 5, Insightful

    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.

    1. Re:Sure by Anonymous Coward · · Score: 2, Insightful

      Developers outside of the US would thank us for our malpractice driven suicide.

    2. Re:Sure by Mashiki · · Score: 1

      Well...that sounds like fun. But let's turn it back there on the guy shall we? Should scientists be sued for faulty peer review data, and in turn bad science. I think he'd shutup on the idea very quickly then.

      --
      Om, nomnomnom...
    3. Re:Sure by Yo+Grark · · Score: 1

      Why not, drug companies are continually sued over the failure of their "code"

      - Yo Grark

      --
      Canadian Bred with American Buttering
    4. Re:Sure by wvmarle · · Score: 1

      More likely scenario: software development companies leave the US, and set up elsewhere (e.g. Mexico, Canada, Europe) where they can safely sell their stuff.

      A few short years later the rest of the world completely overtakes the US on all fronts as we have the latest and greatest software while the US is stuck with old, unmaintained software full of known security holes.

  5. Windows by MrEricSir · · Score: 4, Funny

    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!

    --
    There's no -1 for "I don't get it."
    1. Re:Windows by Anonymous Coward · · Score: 0

      But if there was a master key glued into the lock it would be another story, of course I am referring to developers leaving private keys in software/hardware.

    2. Re:Windows by Elminster+Aumar · · Score: 1

      ...in which case, you take the bastard to court who made the freaking key--not the entire industry!

    3. Re:Windows by Anonymous Coward · · Score: 0

      Interestingly, if the window was found to be faulty, the insurance company would indeed sue the manufacturer.

  6. Another Analogy by Anonymous Coward · · Score: 0

    Yes... But could a file cabinet manufacturer be sued if the drawers could be locked but the side of the cabinet fell off with one solid blow?

    1. Re:Another Analogy by Neil+Boekend · · Score: 1

      Just don't hit it that way.

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
  7. For "sloppy coding"? Definitely! by gweihir · · Score: 1, Insightful

    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.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:For "sloppy coding"? Definitely! by DemonGenius · · Score: 1

      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?

    2. Re:For "sloppy coding"? Definitely! by Ronin+Developer · · Score: 4, Insightful

      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?

       

    3. Re:For "sloppy coding"? Definitely! by DeathFromSomewhere · · Score: 2, 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?

      --
      -1 overrated isn't the same thing as "I disagree".
    4. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 0

      Dream on, freetard. The malpractice lawyers and insurance industry smell vast sums of money so FOSS will not be exempt.

    5. Re:For "sloppy coding"? Definitely! by swillden · · Score: 3, Insightful

      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.
    6. Re:For "sloppy coding"? Definitely! by bws111 · · Score: 1

      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 of the stuff they are selling going to be held responsible, no matter who they are?

      And while we're at it, why don't we apply that silly theory to everyday life? If you a cab driver and kill a passenger, you can get sued. But if you just give someone a ride and kill them, too bad? It makes no sense. The law applies equally to everyone, not just some class of people you happen to not like and want to punish.

    7. Re:For "sloppy coding"? Definitely! by turbidostato · · Score: 1

      "I'd say that most developers want to create the best code they can"

      No, they don't.

      Because if they did, they are in a perfect position to enforce their rules: you just don't write down a single semicolon and the software doesn't run at all. It's up to the developer when exactly to write down said semicolon.

    8. Re:For "sloppy coding"? Definitely! by Githaron · · Score: 1

      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.

    9. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 1

      Enter the anonymous coder.

      Nobody to send bug reports to. Software posted on Wikileaks in stead of on SourceForge...

    10. Re:For "sloppy coding"? Definitely! by DemonGenius · · Score: 1

      No, they don't.

      Prove it. I'm basing this assumption on the fact that most people want to ensure they have food on their plates. Not doing your job ensures the opposite.

      Because if they did, they are in a perfect position to enforce their rules: you just don't write down a single semicolon and the software doesn't run at all. It's up to the developer when exactly to write down said semicolon.

      Whether or not you want to do the best you can at your job has no bearing on how much influence one has over the project they work on. It's variables such as tight deadlines, insufficient requirements, feature creep, incompetent management, power outages, sickness, turnover, etc. that can completely derail developers. Come back and argue your point when you figure out a way for developers to completely control all of these variables.

    11. Re:For "sloppy coding"? Definitely! by bws111 · · Score: 1

      Say what? People give other people (friends, carpools, etc) free rides every day. And yes, the drivers (or estates) of vehicles who injure passengers do get sued.

      Why, exactly, should FOSS get a free pass? If FOSS can't survive on it's own merits, that is it's problem. Making special rules just for FOSS is just silly.

    12. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 0

      No, leave it to an academic to propose making individual developers liable for each line of code they right.

      Exactly! Oh wait.... what?

    13. Re:For "sloppy coding"? Definitely! by slimjim8094 · · Score: 2

      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.
    14. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 0

      There's certainly an argument to be made that, were such a law passed, it should not include OSS.

      To extend Microsoft's metaphor, they're more like a condominium, or apartment building. You live there, but you are not permitted to tamper with the doors, the windows, the locks, or the alarms. In fact, you can't even effectively inspect them. You are a renter, with temporary usage rights only. Under those conditions, how can a lapse in security be your own fault? You rely entirely on the competence of the property owners, and you pay them accordingly. Why shouldn't you be able to sue them if, due to their incompetence, you're robbed?

      And on the other hand, with open source software, you have full rights to examine and modify your surroundings (replace the doors, windows, locks, etc). Yeah, it's difficult, and you may or may not have the time and money. If you're serious, you can do it yourself or hire somebody to do it for you--but it's possible to do. It wouldn't make a whole lot of sense to sue the former owners of a house if you were robbed, right?

      It's really got nothing to do with whether you have time to read the code line-by-line. Just because I don't have time to learn to maintain a car does not mean that the manufacturer is liable for all of my mistakes. I shouldn't be doing it if I'm incompetent. If, however, the manufacturer insists on maintaining my car, and refuses to let me touch it, then I think they're fair game. (No, I don't know why I chose cars suddenly...just feels right to have a car metaphor in here somewhere)

      Now, I don't necessarily think that suing developers makes a lot of sense in any case. It seems like insurance against security breaches would be a more reasonable approach. Were such a thing to exist, you'd quickly discover, based on insurance rates, what software was more secure. I agree with you that suddenly making programmers liable for the lines of code they write would absolutely handicap the industry.

    15. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 0

      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.

      In many countries you often cannot disclaim all implied warranties, regardless of what any contract says. The most extreme disclaimers that disclaim any notion that the product is intended to do anything are sometimes ruled out on the basis that because they allow the supplier to effectively deliver nothing, there is a failure of consideration - the supplier could take the money and deliver nothing.

      Less extreme disclaimers can also be avoided, especially where sales to consumers are involved. For example, in the UK the Unfair Contract Terms Act 1977 includes the following:

      (2)As against a person dealing as consumer, liability in respect of the goods’ correspondence with description or sample, or their quality or fitness for any particular purpose, cannot be excluded or restricted by reference to any such term.
      (3)As against a person dealing otherwise than as consumer, that liability can be excluded or restricted by reference to such a term, but only in so far as the term satisfies the requirement of reasonableness.

      The only reason these laws are not often applied against software appears to be that the standard is generally so poor that it would be hard to show that a particular package was less than might have reasonably been expected.

    16. Re:For "sloppy coding"? Definitely! by Trahloc · · Score: 1

      They have access to the data to confirm whether or not its secure. If they choose not to they should sue themselves as everyone associated with a FOSS product, from the original creator, to the dev who writes the code, to the people doing documentation, to the end user actually installing it are part of the project. As the end user installing the program was the last link in the chain before disaster happened the buck starts and stops at them.

      In closed source software we have to take the developers word that they did their job securing it, we have absolutely no access to the source code to confirm whether or not they did. So FOSS already IS the higher standard because of the possibility of review. Whether or not it actually happens by the end user isn't really relevant.

      --
      The Goal: A long simple life filled with many complex toys.
    17. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 0

      No, they don't.

      Prove it. I'm basing this assumption on the fact that most people want to ensure they have food on their plates. Not doing your job ensures the opposite.

      Because if they did, they are in a perfect position to enforce their rules: you just don't write down a single semicolon and the software doesn't run at all. It's up to the developer when exactly to write down said semicolon.

      Whether or not you want to do the best you can at your job has no bearing on how much influence one has over the project they work on. It's variables such as tight deadlines, insufficient requirements, feature creep, incompetent management, power outages, sickness, turnover, etc. that can completely derail developers. Come back and argue your point when you figure out a way for developers to completely control all of these variables.

      Not all developers want to write perfect software. For example, the NSA wants to have good encryption for their communications. However, if they release a public crypto library, they would also like it to be breakable (by them.) Another example is a lot of mobile apps where there is little difference between the free and the paid version except one line in a preference file somewhere. In a way, the developers are purposely breaking the free version.

         

    18. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 0

      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?

      There is a difference between publishing source code and releasing a binary of an application. I don't think anyone should be liable just for writing and releasing source code. Source code is pure speech.

    19. Re:For "sloppy coding"? Definitely! by FranTaylor · · Score: 1

      Limit damage liability to a multiple of the original purchase price.

      FOSS is zero price, zero liability.

    20. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 0

      Apparently you suffer from ding-battery. There was a long series of tests done about 5 years ago sponsored by the United States Government and done by the University of California at Berkeley and Coverity. A summary of the results are here. The lie perpetuated by guessers and those suffering from ding-battery gets killed firmly. Open Source is *BETTER* than closed source proprietary software. It has, in general, about 10x fewer bugs, and the severity of those bugs are 10x less severe or critical than proprietary software. Nincompoops asserting otherwise, are talking through their hats. They can say "open source is bad", but "et suppositio nil ponit in esse" --sayin' it don't make it so--.

    21. Re:For "sloppy coding"? Definitely! by hajus · · Score: 1

      This process would change once companies started to get sued.

    22. Re:For "sloppy coding"? Definitely! by Raenex · · Score: 1

      Why should FOSS get a bye?

      Because in general there's no money changing hands, and hence no contract or sale.

    23. Re:For "sloppy coding"? Definitely! by shutdown+-p+now · · Score: 1

      Exception: FOSS. All commercial software vendors should be liable for any and all damage caused by sloppy coding, including system cleanup, downtimes, etc.

      In practice, that's essentially a roundabout way of saying that you'd like the government to force all software to be FOSS.

    24. Re:For "sloppy coding"? Definitely! by shutdown+-p+now · · Score: 1

      There is a difference between publishing source code and releasing a binary of an application.

      Ah. So Gentoo gets a free pass, while Ubuntu is fucked if there's a bug in any of the binary packages that they ship?

    25. Re:For "sloppy coding"? Definitely! by shutdown+-p+now · · Score: 1

      What about web applications and such?

    26. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 0

      > Why should FOSS get a bye?

      Because it also happens to free as in "free beer". It is unrealistic to expect security guarantees from somebody you don't even pay, and a properly designed law would take that into account.

    27. Re:For "sloppy coding"? Definitely! by wvmarle · · Score: 1

      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?

      There are even less users that have the actual skills to understand what's going on in source. And reading someone else's software and fully understanding what it is all doing, is known to be really hard.

    28. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 0

      No matter what happens, they'll leave FOSS out of it. You're missing the big picture.

      They DON'T care about software quality. They care about MONEY! When you sue somebody you do it for money. Not out of the goodness of your heart. FOSS projects rarely have money for their own servers, let alone to hire lawyers and pay for damages.

    29. Re:For "sloppy coding"? Definitely! by jeremyp · · Score: 1

      So you're saying that, in order to ensure I never fall foul of being sued for defects in the software I use to supply services to my customers I need to audit every line of the open source software in my solution. Nah, I think I'll find a proprietary supplier that is prepared to give me a warranty.

      To an extent, this happens already. This is the main reason why companies like Red Hat can charge people a lot of money for software that can be obtained for free on the Internet.

      This idea that FOSS is "the higher standard" because of the possibility of review is pie in the sky, by the way. In principle it is possible to review FOSS, in practice, it is often impossible due to the complexity of the software. And at least one very serious bug has been caused by downstream people reviewing software and applying an incorrect patch.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    30. Re:For "sloppy coding"? Definitely! by jeremyp · · Score: 1

      I don't think anyone should be liable just for writing and releasing source code.

      Why?

      If I write some software incompetently and release it as source and people subsequently lose lots of money as a result, why should I not be liable to the same extent as if I had released the software as a binary?

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    31. Re:For "sloppy coding"? Definitely! by gweihir · · Score: 1

      So? If you sell a defective product, because you use sub-standard procedures, does it matter whether it is an engineering or management screwup? You may notice that I said the _vendor_ should be liable, and the manager is just as much part of the vendor as the coder is.

      I am not arguing for personal liability. That would indeed often be unfair to the engineers. But if a company ships defective products and then it turns out that is because they were not following the state-of-the-art, they should be liable for any and all damage caused. The solution is easy: Do not do sloppy coding. If a manager forces engineers to be sloppy, arrange things so beforehand that this manager grossly exceeds his/her authority and hence becomes liable to to company.

      The time where you can ship an arbitrarily shoddy product just because it is software has to come to an end. This is a disgrace. Without liability, this will not change in the commercial world, managers (and some engineers) are just too greedy and stupid.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    32. Re:For "sloppy coding"? Definitely! by jeremyp · · Score: 3

      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
    33. Re:For "sloppy coding"? Definitely! by gweihir · · Score: 1

      That is what I wrote. The individual can then become liable towards the company, if they grossly misconducted themselves. Note that if a manager does not give a coder the time to do things properly _and_ if there is a company-wide regulation that code has to be done properly, the manager would be the culprit, not the engineer.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    34. Re:For "sloppy coding"? Definitely! by gweihir · · Score: 1

      Gross negligence always makes you liable. A license does not help. It has to be a commercial "product" though, and FOSS does not qualify as such.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    35. Re:For "sloppy coding"? Definitely! by gweihir · · Score: 1

      BS and you know it. You can download any and all Ubuntu source code.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    36. Re:For "sloppy coding"? Definitely! by gweihir · · Score: 1

      Of course that does NOT include services sold based on FOSS. If, for example, you buy system administration services for FOSS and the admin destroys your installation, of course they become liable. It is just the software itself that is not a commercial product. I do also not see any reason to exempt commercial OSS form liability. You earn money selling it (beyond that "reasonable copying fee"), you become liable if it is sloppily made.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    37. Re:For "sloppy coding"? Definitely! by gweihir · · Score: 1

      I do realize that. If it is FOSS, they are not liable. If they sell it, they are. You make a profit, you have to ensure a reasonable quality level. That does not mean bug-free code. It just means that you use sound engineering practices building it. Accidents can still happen and do not make you liable.

      I do realize the US legal system is broken in this regard. The solution for that is not to prevent liability, but to fix the US legal system.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    38. Re:For "sloppy coding"? Definitely! by gweihir · · Score: 1

      Has reading comprehension suddenly vanished?????

      I wrote "commercial software vendors". If a company writes FOSS, they are not a "vendor" of that software as they are not selling it. Is that so hard to understand?

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    39. Re:For "sloppy coding"? Definitely! by gweihir · · Score: 1

      Untrue. FOSS still has liability, but it requires malicious intent on the side of the developer. For all other cases, I agree. Zero price, source available, no liability.

      Note that for companies FOSS comes with a very real secondary liability: Reputation loss if it is bad. Many companies fear that more than any actual legal liability.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    40. Re:For "sloppy coding"? Definitely! by Bert64 · · Score: 1

      Make the vendor liable, not the individual developer...
      If the vendor wants to decrease their risk, then they can set realistic deadlines and hire competent developers.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    41. Re:For "sloppy coding"? Definitely! by gweihir · · Score: 2

      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.
    42. Re:For "sloppy coding"? Definitely! by Bert64 · · Score: 1

      Prove it. I'm basing this assumption on the fact that most people want to ensure they have food on their plates. Not doing your job ensures the opposite.

      Doing the bare minimum required by the job puts food on their plates... If sloppy buggy code is accepted (which it usually is), then that sets the bar, and if the company sets unrealistic requirements then noone will be able to meet them at all.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    43. Re:For "sloppy coding"? Definitely! by gweihir · · Score: 1

      FOSS has a different mechanism: If you product sucks, people stop using it (or may fork), and you lose all kudos. Happens regularly when projects screw up. The second reason is that there typically is no company to sue in the case of FOSS.

      With some minimal research you would have found this and other arguments.

      You may also notice that _I_ never said anything about individual developers.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    44. Re:For "sloppy coding"? Definitely! by Bert64 · · Score: 1

      FOSS is often held to a higher standard...

      Most security related appliances (eg firewalls) run on open source code.

      Various security standards that companies or government agencies are expected to follow are much tougher for unix like system and often have requirements that windows is unable to meet (eg secure storage of passwords, removal of unnecessary software from the system)... windows basically gets a free pass on several things that a unix system would be marked down for, because windows is incapable of meeting the criteria at all. Unfortunately the resulting standards are considered equal, despite that clearly not being the case.

      Many arguments against open source center around bugs or deficient features, and yet these same people will quite happily continue using proprietary software which has its own different set of bugs and deficiencies.

      And yet it should really be held to a lower standard, because you've not paid so much for it.. You expect a cheaper product to be inferior, and if the savings outweigh the inferiority (ie the product is adequate) then it's acceptable... On the other hand, if the cheaper product is superior then it's exceptional value. Conversely, a product that costs more has to provide a lot more value for money to justify the price differential, otherwise its a rip off.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    45. Re:For "sloppy coding"? Definitely! by Raenex · · Score: 1

      Why does that make incompetent software developers any less responsible for the bugs in their code?

      Because they aren't being paid for it. Commercial transactions are, in general, held to a different standard than something offered for free.

    46. Re:For "sloppy coding"? Definitely! by WarOfTheNerd · · Score: 1

      FOSS is immune if you only provide source code. As source != product. It's only software after it's compiled by a compiler into machine code, which the original developer is not responsible for. Also, yes I believe commercial developers who charge money should be held liable for every mistake they make, after all, a carpenter is held liable for mistakes, as is a builder, plumber and/or electrician. If the workmanship is not up to standard, the client should be compensated for any actual damages as a result of said bad workmanship. This applies to bugs in software too. Commercial software companies have been given a free ride for too long. $5.00 for an update that causes downtime is pittance from Microsoft.

    47. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 0

      I believe the problem is making specific rules that make it extremely expensive to freely share and express ideas, as in FOSS. This could be resolved by publishing Free and Open Source Literature (FOSL) which is provided as is as an artwork, and absolutely should not be compiled.

    48. Re:For "sloppy coding"? Definitely! by bws111 · · Score: 1

      That is not liability, it is a warrantee. Liability does not change based on how much someone paid for something, ever. What you (and the other posters) are attempting to do is make special rules, such that two people engaging in the same activity are held to different laws. If your code can cause damage of a million dollars to some user, and the coder is 'liable' for that damage, it does not matter at all how much was paid for the code. A million dollars damage is a million dollars damage.

    49. Re:For "sloppy coding"? Definitely! by sustik · · Score: 1

      No worry. With FOSS you provide source code. The user can decide to compile and install at their own discretion.
      Of course if a company sells FOSS support they would take on the responsibility. Of course they would be expected to audit
      the code and the burden is on them not the developer.

    50. Re:For "sloppy coding"? Definitely! by DemonGenius · · Score: 1

      It probably wouldn't if developers got sued instead.

    51. Re:For "sloppy coding"? Definitely! by DemonGenius · · Score: 1

      Well then it is those that make the decisions that should be liable, not the people who can't make the decisions. The solution isn't as easy as just not doing sloppy coding. The coding is only part of the mechanism that creates a product.

    52. Re:For "sloppy coding"? Definitely! by DemonGenius · · Score: 1

      Doing the bare minimum when everyone else isn't is not what I'd call job security. If everyone is doing the bare minimum, the company is hiring the wrong people.

    53. Re:For "sloppy coding"? Definitely! by Ash-Fox · · Score: 1

      Not all developers want to write perfect software. For example, the NSA wants to have good encryption for their communications. However, if they release a public crypto library, they would also like it to be breakable (by them.)

      And the developer does by creating the best code they can to make it possible for the NSA to 'break' and not others?

      I think your example is flawed.

      --
      Change is certain; progress is not obligatory.
    54. Re:For "sloppy coding"? Definitely! by Bert64 · · Score: 1

      Depends how the company treats their staff...

      If you treat your staff poorly, they will do only the bare minimum, as they have no incentive to do anything more. Typically almost all of the staff will be behaving the same way.

      Also, in countries with good employee protection legislation, you can't easily be fired unless you do something extremely stupid... If you are complying with the terms of your contract but doing the bare minimum required then they have no legitimate reason to fire you.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    55. Re:For "sloppy coding"? Definitely! by shutdown+-p+now · · Score: 1

      Please re-read the post to which I replied.

    56. Re:For "sloppy coding"? Definitely! by shutdown+-p+now · · Score: 1

      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.

      Wait, but Stallman says that you can write FOSS money producing software, like RedHat! Now what?

      You'd have some point there if you said that any software which user buys (regardless of whether it's FOSS or not) should come with an implicit guarantee of reasonable level of security. But even then, I suspect all that'd do to commercial software is make it move to some kind of online activation scheme, where the software itself is free (and hence liability fully disclaimed), but "activation service" comes with a price tag. Perhaps with some minimal amount of app logic shoved into the service to be able to claim in court that it really is a useful service.

      Speaking of which, how does your scheme deal with client/server software where server side is proprietary? And specifically web apps?

      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.

      It still depends on how you determine what to compensate. If I use someone's software to control, say, a nuclear reactor that goes ka-boom because of a bug in said software and causes several billion dollars in damage, can I sue the software maker?

    57. Re:For "sloppy coding"? Definitely! by turbidostato · · Score: 1

      "No, they don't.
      Prove it. I'm basing this assumption on the fact that most people want to ensure they have food on their plates."

      Therefore, by your own premise, most coders will push more for their food on the plate than for a good work.

      "Not doing your job ensures the opposite."

      For that to be true you first need to define what's "your job". My point is that for most people "their job" is not "to do what has to be done" but "to do whatever my boss tells to do".

      "Whether or not you want to do the best you can at your job has no bearing on how much influence one has over the project they work on."

      Quite on the contrary. All jobs have "doers" and "planners". No matter how persuading the planners are, in the end, the job gets done or doesn't get done by whatever the doers do or don't do.

      "It's variables such as tight deadlines,"

      Just to show the absurd: the deadline is to build from scratch a complete ERP by tomorrow. That's the deadline as told by the planners. Do you think it has the slightest pressure for the doers? The ERP from scratch won't be done by tomorrow no matter how persuading the planners are because the doers won't have it by tomorrow.

      That's, obviously, an extreme case but for each and every case it is the same: the thing will be done when the doers do it, not a minute before.

      "Come back and argue your point when you figure out a way for developers to completely control all of these variables."

      I can do it right now if only by (simple) example:

      Let's take a simple data entry HTML form that introduces data to a DB backend.

      Workflow one:
      1) You produce a simple HTML form.
      2) You link it to the database
      3) You feed the form with the usual data and test that the data gets into the database.
      4) You go after boundary conditions, tests and business-logic constraints.
      5) With all that in place, you refactor your code so it's not all dynamic SQL strings but prepared statements
      6) You add documentation.

      Workflow two:
      0) All the way around you use literate and self-documenting code (say, doxygen).
      1) You implement all the needed business logic at the database layer (say, stored procedures)
      2) You produce a data abstraction layer.
      3) You add boundary tests for such a layer
      4) You add an HTML for to feed the data layer.
      5) You add client-side constraints to the HTML data form (i.e. actionscript code).

      Now, you are completly free to do it one way or another, after all is *you* the one coding it and your manager, by the very definition of manager, can say all he wants but nothing will be done if it's not you the one doing it.

      It's obvious that the workflow two will produce "high quality code" if by nothing else because your code doesn't work *at all* till at leat step 4 is completed, and then, without step five the "user experience" will be so bad that it will be your manager the one pressing you to go after it.

      On the other hand, you and I know that workflow one never will go beyond step 3.

      But the vast majority of coders will go after workflow one... and will cry about how the bad manager didn't allow him to add tests and safewards. And they'll do that way for two reasons:
      1) It's the best they can come to.
      2) The thinking that "if I don't do that way I'll be fired and they'll hire another one that does it this way -therefore giving me the reason: producing "the best code they can" is far, far from the top motivation, call it "the tragedy of the commons" or any way you want, that's the fact.

      The best code they can? My ass.

    58. Re:For "sloppy coding"? Definitely! by Anonymous Coward · · Score: 0

      In some jurisdictions, the implied warranty cannot be disclaimed if the end user is a consumer (ie, not a business).

  8. Bad Analogy by ZombieEngineer · · Score: 4, Informative

    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?

    1. Re:Bad Analogy by kubernet3s · · Score: 1

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

    2. Re:Bad Analogy by Derekloffin · · Score: 2

      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 expect a software maker to ensure their software is secure when people across the whole globe can be attacking it constantly. Security just isn't the kind of thing you can ensure. Now, if the software maker gives you some kind of guarantee, then I can see it as they are making a claim they are now responsible for backing up, but for software in general I just can't see it working.

    3. Re:Bad Analogy by bmo · · Score: 1

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

      --
      BMO

    4. Re:Bad Analogy by amicusNYCL · · Score: 1

      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.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    5. Re:Bad Analogy by lightknight · · Score: 2

      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.

      --
      I am John Hurt.
    6. Re:Bad Analogy by Githaron · · Score: 1

      If you convert this back to software, it would be like if there was a company that shipped out software with known security holes. In which case, I can understand suing them. That said, do you pay-as-you-go type lease or a contracted term? If you have a pay-as-you-go or decide to renew the contract (without putting in that the door must be fixed) and you do not bother to find a new apartment, I say it is your own fault if you get robbed over a open door.

    7. Re:Bad Analogy by VortexCortex · · Score: 2

      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 faulty or not! Say you've got a RAM sim that just randomly flips a bit every now and then? Even though I actually do have a debug mode that purposefully corrupts pointer values to test some of my memory manager code, I simply CAN'T guarantee my software to work on your system unless I've fully certified its operating environment first.

      So, if you would like me to guarantee my code, I have no problem with that; However, I'm going to want to certify your Hardware, OS, Drivers, and all other running processes each time you run my software. I'll bill you for this service once and you'll go back to using someone else's unwarrantied shite again. THAT's why I must explicitly disclaim all warranty.

    8. Re:Bad Analogy by kubernet3s · · Score: 1

      My lease agreement says the landlord is responsible for making all repairs: even if I were permitted to, I am not obligated to. To connect this back to the main point, only FOSS software should be exempt by this logic, since a security hole in a product which cannot be altered is one which the user has no power over

    9. Re:Bad Analogy by shutdown+-p+now · · Score: 1

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

      I doubt you'd be able to sue just any door manufacturer. Pretty much any door "seals the opening", and obviously being able to open it is part of its function.

      It would probably work if you bought, say, a steel door, and the packaging or ads made specific claims, e.g. with respect to the amount of force applied that the door can withstand, and you could then show that the break-in occurred by means of applying less force and thereby disabling the door. In other words, you could sue for a specific fraudulent claim.

      But software manufacturers pretty much don't make any claims about the security of their products. You get some occasional nonsense, like Apple's "immune to all PC malware" stuff, or generic claims like "secure against most common attacks" that are carefully worded to be legally meaningless. And why would they claim it, when customers don't seem to care? If and when it actually becomes a strong enough differentiator in the marker, you'll see "secure by design" software appear for extra $$$. This has already happened in certain narrow niches where it is important to know that software works exactly as intended (say, a nuclear reactor) - where you get things like formal correctness proofs and legally enforceable guarantees - with a hefty price tag attached.

  9. Engineering Discipline by DemonGenius · · Score: 4, Insightful

    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.

    1. Re:Engineering Discipline by Elminster+Aumar · · Score: 1

      1 out of every 3 seasoned veterans of any field or discipline will eventually be viewed upon as a "hack" by his or her peers. So I'm not so sure your idea is very sound...

    2. Re:Engineering Discipline by Anonymous Coward · · Score: 1

      I am an engineer in IT, coming from a polytechnic. To be honest I didn't learn much there.

      You can analyze machines, bridges and electronics pretty well. But most machines are simple, with very few moving parts.

      Every line of code (simplification for this discussion) in a program is a moving part. Simple programs already have thousands of lines, more complex ones easily go near a million or over. That is one reason why you can't really compare software with mechanical or electrical engineering.

      Even better in 1936 it was already proven that it is not possible to completely analyze software; the halting problem. The 'halting problem' has much more consequences than just knowing if a program ends or not. We are trying to get better at analyzing though, engineers are never stopped by current realities.

      - http://en.wikipedia.org/wiki/Halting_problem

    3. Re:Engineering Discipline by lightknight · · Score: 3, Insightful

      He's thinking about the money that could be made if demand were to greatly outpace supply. He also thinks he isn't a hack.

      In the long run, it'd be a huge mistake. Any number of great programmers started off as hacks, then through time and experience, became who they are today. Implementing something like this would only serve to help destroy the technology field faster (and where it goes, others will be sure to follow).

      --
      I am John Hurt.
    4. Re:Engineering Discipline by RobinH · · Score: 1

      In specific cases software *does* require being certified by an engineer as part of a larger system that requires sign-off. For instance, modern safety systems in industrial controls use software components, and those are certified by TUV, or have to be certified by a licensed P.Eng. (at least in this jurisdiction). That means it's a) expensive and b) kept simple. It gets the job done. They don't have to do this because it's software, they have to do it because it's part of a system that needs certification. Now, if you're handling credit card numbers or passwords, it probably shouldn't matter whether you're doing it with software or paper or stone tablets, it's worthwhile requiring certification for systems that perform these tasks.

      --
      "I have never let my schooling interfere with my education." - Mark Twain
    5. Re:Engineering Discipline by russotto · · Score: 1

      We demand professional competence in other fields. It's time for this one to grow up.

      You say "grow up", I say "ossify". Assuming it doesn't simply "vanish".

    6. Re:Engineering Discipline by Anonymous Coward · · Score: 0

      That's why it should be the management that's personally liable for the software's failure; not the developers. I guarantee that once you make this a manager's problem, suddenly it will be worth the company's time to fix it.

  10. Betteridge's law of headlines by fiannaFailMan · · Score: 4, Insightful

    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
    1. Re:Betteridge's law of headlines by Githaron · · Score: 1

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

    2. Re:Betteridge's law of headlines by Anonymous Coward · · Score: 0

      The same way they handle it in all product liability and negligence involving an employee. The employer is liable in both of those, and would be liable in these types of cases as well.

    3. Re:Betteridge's law of headlines by mdielmann · · Score: 1

      Congratulations, you've solved the smallest problem with this proposal.

      --
      Sure I'm paranoid, but am I paranoid enough?
    4. Re:Betteridge's law of headlines by Anonymous Coward · · Score: 0

      That is the only one he asked about.

  11. Fair's fair by Anonymous Coward · · Score: 3, Insightful

    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.

    1. Re:Fair's fair by hajus · · Score: 1

      Perhaps if they they were uneducated in the class and got an A regardless, or the paper containing flaws was given a good grade.

  12. it depends by roc97007 · · Score: 1

    > 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 common ink pen (true story).

    I think it's about reasonable expectations. For instance, if there was an unknown back door in an otherwise reasonably secure OS, and the manufacturer lost the credentials, and didn't 'fess up, and as a result a bad guy nabbed my customer credit card database, yeah, as a person with reasonable expectations, I'd sue.

    --
    Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
  13. Hanlon's by gmuslera · · Score: 3, Interesting

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

    1. Re:Hanlon's by TubeSteak · · Score: 1

      Also, who you sue because a bug in an open source program with a lot of contributes?

      The law could include an exception for OSS/Libre software

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

      I think the idea is that the law would nullify any such clauses in contracts or TOSes.

      --
      [Fuck Beta]
      o0t!
  14. Yes, definitely by Anonymous Coward · · Score: 0

    Especially since purposely coding security vulnerabilities into your product can be a lucrative enterprise:

    The Vulnerabilities Market and the Future of Security

    This is why the new market for vulnerabilities is so dangerous; it results in vulnerabilities remaining secret and unpatched. That it’s even more lucrative than the public vulnerabilities market means that more hackers will choose this path. And unlike the previous reward of notoriety and consulting gigs, it gives software programmers within a company the incentive to deliberately create vulnerabilities in the products they’re working on — and then secretly sell them to some government agency.

    If fact, criminal sanctions maybe needed in order to protect the public.

  15. Sure. it can be done. by bmo · · Score: 2

    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

  16. Should Wall Street be sued for wrecking the world? by Anonymous Coward · · Score: 0

    Hack journalists should just shut up about what should or shouldn't happen. What should happen and what really happens rarely even have a superficial resemblance, s*!theads.

  17. certification by Anonymous Coward · · Score: 0

    I suspect this is another attempt to guildify the field by requiring a certificate in order to be allowed to code.
    I.E. code produced by a coder with a "certificate" from an "accredited" institution will be indemnified.

  18. All code has holes - Read "secrets and lies" by Anonymous Coward · · Score: 0

    All code has such problems.
    A law, would only create incomes for lawyers.
    Lawyers are dreaming that they can create security via the law.
    They fail to understand reality.
    (Again)

    1. Re:All code has holes - Read "secrets and lies" by Anonymous Coward · · Score: 0

      All code has such problems.
      A law, would only create incomes for lawyers.
      Lawyers are dreaming that they can create security via the law.
      They fail to understand reality.
      (Again)

      No, lawyers understand reality well enough. Especially the part from your quote I put in bold.

  19. only if you think you should by nimbius · · Score: 1

    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 knowing that which was unthinkable at the time is wrong-headed.
    its also why you cant sue an engineer for a building that collapses under the shock force of an earthquake that meets or exceeds its structurally rated limit. In russia it was actually fair practice to jail engineers for failing to prevent catastrophic accidents. Hence the recount of senior control room engineers who were incarcerated for failing to safeguard against bureaucratic failures that precipitated the chernobyl disaster.

    --
    Good people go to bed earlier.
    1. Re:only if you think you should by Anonymous Coward · · Score: 0

      People want better roads.
      People don't want to pay for better roads.
      People don't want to deal with construction.
      People are unrealistic.

    2. Re:only if you think you should by Belial6 · · Score: 2

      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.

    3. Re:only if you think you should by RabidReindeer · · Score: 1

      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 knowing that which was unthinkable at the time is wrong-headed.

      its also why you cant sue an engineer for a building that collapses under the shock force of an earthquake that meets or exceeds its structurally rated limit. In russia it was actually fair practice to jail engineers for failing to prevent catastrophic accidents. Hence the recount of senior control room engineers who were incarcerated for failing to safeguard against bureaucratic failures that precipitated the chernobyl disaster.

      People DO sue for 9/11. They'll sue for degraded roads, too, but that one's harder to win, since roads are Wear Items, and degredation is wear, so only failure to wear as expected is likely to win the lottery. People sue for EVERYTHING.

      Although IT is an area where it's virtually impossible to guarantee perfection, there are aspects. Systems of formal correctness exist like the one IBM used to develop CICS, but they're rarely used because it's all "All You Have to Do Is.." and "Git 'R Dun!" and no time to spend on formal proofs or getting customers to actually admit what they really want. Still, certain things like SQL Injection are out-and-out malpractice, and it wouldn't break my heart to see a few people nailed to the wall over it.

      Unfortunately, software development isn't like the medical, legal, or engineering disciplines where there are small groups of people to blame. Much of the software development is done inside larger companies whose primary product isn't IT at all. And to top it off, Corporate Personhood has come to mean "all of the priviliges that people have, but none of the responsbilities".

  20. Even if developers are liable, are they negligent? by CokeJunky · · Score: 1
    From the article:

    “The question is ‘Are they being negligent?’. The usual test is ‘Are they applying contemporary standards to the quality of their work?’,”

    It seems to me that at the moment the contemporary standards are that almost all software has security holes. The "contemporary standards" are that this is acceptable -- very few customers with very specific needs can afford to insist otherwise, and even they have to build in redundancy and monitoring systems to handle the case where something doesn't work as advertised.

    If the authors argument is based on contemporary standards, it's not a very good one.

    --
    More Caffeine. NOW
  21. When did Slashdot... by Anonymous Coward · · Score: 0

    turn into Jezebel blog?

    1. Re:When did Slashdot... by Anonymous Coward · · Score: 0

      ASSAAAAANGE!! (shakes fist)

  22. Re:Should Wall Street be sued for wrecking the wor by Anonymous Coward · · Score: 0

    I'd be satisfied if they were just hung up by their scrotums in Times Square.

  23. "Microsoft has previously argued against" by RocketRabbit · · Score: 0

    Well no shit Microsoft has argued against such a move. There's an entire industry that feeds off of the insecurity of the MS platform, and I am beginning to suspect that MS leaves holes in its software as part of a probable arrangement with the Federal Government, in exchange for being the primary user-facing IT platform there. What better way to spy on friends and enemies, to ruin centrifuges, and so forth, than to have the makers of the standard business / academic / government OS in your pocket?

    I for one would love to see some moves toward making OS companies and application developers liable for their own fuck-ups. If an infants car seat chokes babies to death repeatedly, the product is recalled and the manufacturer is usually sued. People incur real, measurable, personal monetary, business, and emotional damages from poorly-crafted software.

    If such a regulation passed, we'd see a lot more attention given to removing bugs, and a lot less attention given to creating new but probably useless features. Yes, I'm looking at both the Gnome3 and Win8 dev teams here.

    1. Re:"Microsoft has previously argued against" by FrangoAssado · · Score: 1

      If such a regulation passed, we'd see a lot more attention given to removing bugs, and a lot less attention given to creating new but probably useless features. Yes, I'm looking at both the Gnome3 and Win8 dev teams here.

      If such a regulation passed, you wouldn't be able to look at the Gnome3 dev team at all, because it wouldn't exist anymore. As would most free software developers.

      Put yourself in the position of Linus Torvalds when he started developing Linux, for instance. Do you think he would even start distributing it if he could be sued for it?

    2. Re:"Microsoft has previously argued against" by RocketRabbit · · Score: 1

      If such a regulation passed, these developers would simply pay more attention to security. People would still develop Free software, it's just that they would have a new motivation - to make SECURE software, not gee-whizzy stuff.

    3. Re:"Microsoft has previously argued against" by FrangoAssado · · Score: 2

      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.

    4. Re:"Microsoft has previously argued against" by RocketRabbit · · Score: 1

      Less projects, less new stuff. Both great by me. There are over 200 music players on Freshmeat. Why? That's ridiculous.

      The quality of Free software should not be measured by the number of projects. Quite the opposite, in fact - fewer, better projects are what are needed.

      The FSF (and the BSDs) could quite easily release software by developers under their aegis once it was tested and audited. This would reduce the need for individual developers to expose themselves to any risk. It would also, likely, keep the quality of released software very high, and keep the number of available packages from ballooning into insanity.

      I'm not proposing any regulations. I'm not in government and can't afford to bribe / lobby them. What I am in favor of is somebody putting the brakes on this crazy clown car called software before it gets totally out of control. WE DON'T NEED ALL KINDS OF NEW SOFTWARE. We just need better, more refined software.

    5. Re:"Microsoft has previously argued against" by FrangoAssado · · Score: 1

      There are over 200 music players on Freshmeat. Why? That's ridiculous.

      I'd thing my response would have given a hint about that, but: it's because 200 people (or small groups of people) were interested in making a new music player, because it's fun. How is that bad for you? As I said before, forcing them to choose between improving "the one certified music player" and not writing free software at all would accomplish nothing except killing all their fun, and maybe preventing the (very rare, admittedly) creation of a great new software.

      The FSF (and the BSDs) could quite easily release software by developers under their aegis once it was tested and audited.

      The FSF and the BSDs don't make the majority of free software, and have no control over what most free software developers do.

      What I am in favor of is somebody putting the brakes on this crazy clown car called software before it gets totally out of control. WE DON'T NEED ALL KINDS OF NEW SOFTWARE. We just need better, more refined software.

      Again, a lot of people who write free software do it because it's fun, and they distribute it for all kinds of reasons; among them, the hope that it will be useful for someone. But no one has to use them, and if you read most free software licenses (GPL and BSD, for instance), you'll see clearly that they offer NO WARRANTY (yes, it's usually written in all caps, as you can see here, in section 15 and here in all versions listed).

      Since you don't have to use this software, and it's free, and no one is being deceived about it, why is it important to you whether it's being written or not?

    6. Re:"Microsoft has previously argued against" by Anonymous Coward · · Score: 0

      So make software for fun but make a boneheaded mistake and get a class action lawsuit against you? Sounds like great motivation. This should kill the smart phone and tablet market, because obviously none of those app makers take the time to SECURE their software.

  24. Yet again... by Elminster+Aumar · · Score: 1

    ...blame the developer.

    1. Re:Yet again... by lightknight · · Score: 1

      'Tis quite alright. We'll just stop making software for the other sectors. They can go back to doing things on an abacus, while the rest of us have 30 minute work days.

      --
      I am John Hurt.
    2. Re:Yet again... by Anonymous Coward · · Score: 0

      I like this. We can start this cut-off with the the academics.

  25. like other engineering fields by Anonymous Coward · · Score: 2, Insightful

    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.

    1. Re:like other engineering fields by Todd+Knarr · · Score: 5, Insightful

      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.

    2. Re:like other engineering fields by russotto · · Score: 2

      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. So what's being proposed goes beyond even what is required for traditional engineering disciplines.

      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.

      The hacks and talent-free people have built everything in the field. Get rid of us and you've got nothing. You really think you're going to attract actual talent by requiring someone to have a degree plus 16 years of experience before they can work independently (that's a Texas requirement for a professional software engineer; Texas is one of the few states that licenses such)? How many actual talented software developers do you know who would put up with the amount of paperwork required to do work in such a discipline?

      All you'd actually accomplish is to bring the field to a screeching halt.

    3. Re:like other engineering fields by mjr167 · · Score: 1

      And you will end up like the architecture firms- 10 engineers, one PE. The engineers do the work and the PE just signs the forms.

    4. Re:like other engineering fields by Anonymous Coward · · Score: 0

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

      The consequences? You mean, like entire cities full of buildings that aren't falling over at the slightest provocation, aircraft that fly tens of millions of people around the world with an incredible low accident rate, houses that don't catch fire because we license electricians rather than use hacks, and so on? Those consequences?

      Sure, sign me up. Software needs more of those kinds of consequences.

    5. Re:like other engineering fields by Anonymous Coward · · Score: 0

      Your point is insane as you start the comparison and state a bridge under normal load. Well, hacking is not normal use of software, so can a developer be sued for bugs that are not normal usage? Well can a mechanical engineer be sued if the bridge he designs breks whe it is hit by a 1000 ton meteorite ?

    6. Re:like other engineering fields by Anonymous Coward · · Score: 0

      Just THIS. I am sure the majority of security flaws are not the result of ignorance of the programmers or managers, but the result of bad planning or compromises. "We need this done tomorrow, just save the password in clear, we think about something later".

    7. Re:like other engineering fields by Anonymous Coward · · Score: 1

      Except that kind of engineer doesn't innovate and doesn't invent new things, he designs known things. Innovation is about building new untested things, you can't know what will happen when it's unknown. Bridges and steel are known quantities, it's apples and oranges to compare a designer of new things, to an engineer of old things.

    8. Re:like other engineering fields by WaffleMonster · · Score: 1

      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

      Is "Normal load" really the question TFA is posing?

      Unless you are asserting the bridge should be able to withstand attack by any and all living thinking advasaries or the designer is to be held responsible your analogy would seem to fall short.

      We NEED this responsibility, and so does the public we serve.

      Are you sure? Did you ask them? How much more are they willing to pay for code that is guaranteed to repell all human advasaries?

      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.

      Most malware today is installed by tricking users into doing something stupid. Even if all code had no expliotable defects it is foolish and unrealistic to assume this would appreciably change a damn thing. The central problem is not the software it is the USER.

    9. Re:like other engineering fields by havana9 · · Score: 1

      Another key difference is that only some projects in other engineering fields have to be signed by a PE, and are project that only one person could follow reasonably, and that have a set of rules by science or by law that have to be followed. A project for a car or an airplane doesn't require to be signed by a PE, even if requires a lot of engineers, simply because is too big to be followed by a single person and the regulations applicable are only on the whole product and nothing is said for the design phase.

    10. Re:like other engineering fields by vlueboy · · Score: 1

      Understood, when you talk about software engineers we 'trust'. But... good luck giving that override authority to our outsourced minimum wage overlords who have little commitment, and a law system that can't reach overseas.

    11. Re:like other engineering fields by Anonymous Coward · · Score: 0

      That's the way it's supposed to work, but I think we can identify any number of whistleblowers in recent years who lived to regret their decisions professionally.

    12. Re:like other engineering fields by Anonymous Coward · · Score: 0

      How many actual talented software developers do you know who would put up with the amount of paperwork required to do work in such a discipline?

      Well, if I did the paperwork to become a certified developer, I'd be able to charge a lot more for my work. So let's rephrase the question. How many talented software developers do you know who WOULDN'T take a 50% raise in return for doing 40 hours of paperwork?

  26. SONY BMG Rootkit by Anonymous Coward · · Score: 0

    what was the outcome of that?

    1. Re:SONY BMG Rootkit by Anonymous Coward · · Score: 0

      a ridiculously non-punitive class action lawsuit settlement that didn't require Sony to recall the CD's loaded with the rootkit. Still, I believe it set a precedent for suing a company that purposely installed a product that contained a security vulnerability.

  27. If you're going to be adding accountability by Teunis · · Score: 2

    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.

  28. What happens if there is gross negligence? by ChumpusRex2003 · · Score: 3, Interesting

    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.

    1. Re:What happens if there is gross negligence? by DNS-and-BIND · · Score: 1

      In no event shall Microsoft be liable for any damages whatsoever, even in the event of fault (including negligence).
      -- Windows XP Professional license agreement

      --
      Shutting down free speech with violence isn't fighting fascism. It IS fascism!
    2. Re:What happens if there is gross negligence? by Belial6 · · Score: 2

      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 customer for using software that they fully knew was buggy.

      In the door example, there are no doors that are adequate for keeping a determined thief out. The vast majority would not hold up to a firm kick. Even security doors are useless. The last home I had with a steel security door I got locked out of. All it took was grabbing the bar at the middle of the door and pulling hard to get the door to flex enough let the door pop open.

      In the end, no engineering project on the planet is held to the standards that are being suggested. Not building. Not bridges. Not doors.

    3. Re:What happens if there is gross negligence? by TheMathemagician · · Score: 1

      Change your name to ChumpusRex2003'; drop database;'

  29. For those who didn't RTFA by dkleinsc · · Score: 4, Informative

    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 /. Long live http://www.soylentnews.com/
    1. Re:For those who didn't RTFA by msclrhd · · Score: 1

      And what about all open source licenses (BSD, GPL, Apache, ...) that effectively have the same thing? Note that this also includes things like the Boost C++ Libraries that are the basis for libraries going into new versions of C++ (with several Boost libraries making it into TR1 and C++11), Qt and other libraries. If a company releases software that has a security vulnerability in one of these libraries it distributes, is that company liable for that said library? Are they liable if they distribute things like the Microsoft C/C++ runtimes if those include security vulnerabilities?

      The problem is that no software (unless it is very trivial) will be bug free and typical software is large and complex, so the likelyhood it will have security vulnerabilities is exceptionally high (I would say is a given).

      That is not to say that companies/developers cannot employ techniques to reduce these -- things like adequate unit/component/integration tests, fuzz testing, security reviews, static code analysis, etc. -- it is just impossible to not have any.

    2. Re:For those who didn't RTFA by Anonymous Coward · · Score: 0

      There is a very simple reason for this. Most people who are not into hi-tech on the level of at least an average compsci BS cannot form an informed opinion as to what they can reasonably expect from a particular piece of software. Practical exercise to illustrate: you work at Microsoft, and you have to explain to a person whose IQ is at tenth percentile of the population what Windows is and does for them to the level where you're idemnified from a "bad advertising" lawsuit? The term "operating system" is so abstract to a technically illiterate person that you could be just as well talking about something in the neighboring galaxy.

    3. Re:For those who didn't RTFA by Anonymous Coward · · Score: 0

      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,

      This line is explicitly void in many countries (outside the US I assume), and you are entitled to a refund if your product is not fit for purpose.
      Most countries pass laws that say these sort of rights cannot be relinquished through a contract.

    4. Re:For those who didn't RTFA by Anonymous Coward · · Score: 0

      No see that would be OK, somehow magically all the nice open source people that give away their stuff wouldn't get sued because hey wouldn't have any bugs. After all, it's clear possible to do that, but all the mean for profit people why they on the hand dont care and as we know hey love bugs! Making money makes you bad, unless youre a lawyer suing developers, then making money is good, otherwise you shouldn't be allowed to wrote software with bugs, and no nice person would do that! So FOSS has nothing to worry about! Why this wouldnt unfairly favor big companies with deep pockets, or lead to highly restrictive licenses where you cant use a product in any way other than what he manufacturer has carefully tested it, and by god you cant modify it or the source code,

      I mean, come on, everyone could produce perfectly bug free code if they really cared, if they werent such evil assholes. We all know its absolutely possible, because an academic said so!

    5. Re:For those who didn't RTFA by mdielmann · · Score: 1

      Agreed. Ultimately, software is like a house of cards. The nice thing is, you can set it up again reasonably quickly. If you want code as reliable as that on Voyager, expect the same cost per functionality ratio, inflated to current value.

      --
      Sure I'm paranoid, but am I paranoid enough?
    6. Re:For those who didn't RTFA by Anonymous Coward · · Score: 0

      I've seen this sentiment quite a few times in the comments - that allowing companies selling software to be sued for negligence necessarily implies that open source authors can also be sued.

      I don't think this is true. There are two reasons for it - first, open source software is generally provided free of cost. Rather like picking up a free mattress someone left outside, you can't sue them if you get bed bugs. Second, because the source code is released, I would argue, that moves the security liability to the user, not the author. If you choose to use the code without understanding it, you take that risk. If you choose to, you can also understand the code yourself. There's the difference.

      Now, whether a government can/would make a law that respects that difference is another question entirely.

    7. Re:For those who didn't RTFA by itsdapead · · Score: 1

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

      This is a symptom - not a problem. What the law needs to do is to disallow all such one-sided terms in contracts unless they have been negotiated between equal parties and impose penalties on anybody trying to impose them (because those terms are already void in many juristdictions, but they still have bullshit value if the victim can't afford - or if the transactiion is too triivial to justify - legal advice).

      Don't get me wrong: My lawyer should be able to thrash out a contract with your lawyer without interference (beyond the usual rules on unconscianable terms) . The problem is EULAS and "Terms and conditions" that aren't subject to negotiation, or other situations where one side has a team of crack stunt lawyers and the other side has Wikipedia.

      If you use computers then you probably click "I have read and accept the terms and conditions" or something similar on an almost daily basis. Even some GPL software does this (we all know it's mostly harmless, but how is someone who doesn't know about GPL meant to make a judgement - especially if it's the legalese-ridden GPLv3?) . The T&Cs for a well-known brand of online media/applications store run to 30 pages and you're expected to accept them every time the software auto-updates.

      More and more consumer items are coming with "services" attached that have T&Cs that only a lawyer could love. If I'm buying a house, I'll hire a lawyer. If I'm buying a pint of milk and a frozen pizza on my debit card and the card terminal flashes up "Refer to Terms" (yes, this used to happen in my local store) - not so much. This needs to be stopped.

      --
      In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
  30. Microsoft will change their mind by Anonymous Coward · · Score: 0

    Microsoft will change their mind once they realize they can afford the insurance, and the open source developers can't.

  31. First define 'security hole' by Mister+Liberty · · Score: 1

    Then answer the question.

  32. No by Anonymous Coward · · Score: 0

    Academics should be -- for not doing a good of teaching.

  33. No way by Anonymous Coward · · Score: 0

    Can I sue my government for their corruption?

  34. If they did it on purpose by Cockatrice_hunter · · Score: 1

    If they left a hole in the fence on purpose or knew about a hole and didn't patch it I'd say sure go ahead and sue. Would you sue a fence builder if someone dug under your fence? Not all security holes are immediately apparent and most software has holes of some kind you can't just sue everybody.

  35. No more lawsuits by craigminah · · Score: 1

    I'm so sick of the legal situation in the USA where people sue for everything. If we allow software developers to be sued for security holes we might as well ban software development. Like the medical field, a large majority of the cost would be in insurance and mitigation. Let developers develop, so long as their code isn't negligent then security holes are to be expected. What today is "secure code" will tomorrow be "vulnerable code" due to a clever haxor so don't complicate development any more and burden those who buy software with extra costs and don't burden our legal system with more stupid cases.

  36. NO by PostPhil · · Score: 1

    No, developers should NOT be sued. I'm quite frankly tired of hearing this drivel. COMPANIES or their UPPER MANAGEMENT should be sued (depending on the type of company) because THEY are the ones truly responsible and accountable. "They get paid the big bucks for a reason." Unless the person is a very crappy developer, most devs I know actually WANT quality control and the time required to write software properly. It's almost always management that tells them no, that "time to market" with something that vaguely resembles a product is most important, no matter how angry at the result the customers will be. Until the people with the actual power to change company decisions are held accountable for their decisions, nothing changes. So why are we wasting time persecuting the people with little power and who actually agrees with us?

  37. Depends on the intention by vchoy · · Score: 1

    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.

  38. Only an academic would think this is a good idea. by Barlo_Mung_42 · · Score: 1

    That is all.

  39. Oh, there are ways around this. by Bill,+Shooter+of+Bul · · Score: 1

    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.

    --
    Well.. maybe. Or Maybe not. But Definitely not sort of.
  40. si by shentino · · Score: 1

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

    1. Re:si by Anonymous Coward · · Score: 0

      Microsoft is not stupid. They realize there is problem exists between user and keyboard and they want to avoid frivolous lawsuits.

  41. Doors vs Vault Doors by holophrastic · · Score: 4, Interesting

    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.

    1. Re:Doors vs Vault Doors by Anonymous Coward · · Score: 0

      You only sue the manufacturer of the vault door if said door withstood attack for less than x minutes, where x is the number of minutes the manufacturer claims the door can withstand attack for.

      If the door is rated for 30 minutes, and you allow it to be attacked for 35 minutes, sorry, you are shit outta luck.

  42. What is so hard about this? by Anonymous Coward · · Score: 0

    Just adopt the PCI-DSS model:

    • Define a reasonable set of standards for what is "sloppy"
    • Have tiered requirements that scale based on the types of information the application can/will expose
    • ???
    • Profit!
    • ???
    • Security auditors / scanners Profit!
    1. Re:What is so hard about this? by Anonymous Coward · · Score: 0

      Just adopt the PCI-DSS model:

      Have tiered requirements that scale based on the types of information the application can/will expose

      The tiering you are referring to only effects out of pocket cost for paying an extortion racket enough to periodically bless you. Technical requirements are hardly differentiated in the PCI DSS.

      Security auditors / scanners Profit!

      God you know what I purchased something from a web site that checked me out in the clear and it ticked me off.

      That web site had a secure logo certification from a "security" firm called "securitymetrics" to regularly check their site for PCI compliance.

      I tried over a series of two months sending a half dozen emails to that security firm telling them the site was accepting CC PAN in the clear and they sat on their ass and did nothing but tell me it was not their problem and they could not change the site... yet they continued to vouch for the site and renew their assertion of compliance even though they knew it was broke.

      Perhaps this level of manifest stupidity is an outlier uet I know first hand most PCI scanning firms exist to extract as much money as possible while doing as little as possible. Their auditing consists of running a glorified nessus scan and calling it a day. There is no intelligence analyzing anything. If you think this has any effect on outcomes I would suggest you are wrong.

  43. Sounds like a good idea... by multicoregeneral · · Score: 1

    until you realize that there's no such thing as "safe" software. All software is potentially exploitable, and potentially dangerous. As developers, we can do our best to make sure that we get the obvious defects, but given enough time and motivation, any piece of software can be cracked. It's just the way computers work. To assume negligence by default is dangerous for everyone, and could have the opposite effect that they are intending (think gun laws). It will lead to less innovation, and more software companies shielding themselves from these kinds of suits. Not a good scenario.

    --
    This signature intentionally left blank.
  44. Re:Sure. it can be done. by Anonymous Coward · · Score: 0

    We're $200/hr now

  45. Re:Sure. it can be done. by bmo · · Score: 2

    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

  46. Hardware Vulnerabilities? by Anonymous Coward · · Score: 0

    Many vulnerabilities originate in hardware, not software. General-purpose computers are full of hardware vulnerabilities because they are general-purpose. For instance, a general-purpose computer will interpret the value stored in the PC as the address of an instruction, regardless of what is actually stored in the PC or how it got there... it must do this because it is designed to be general-purpose. We circumvent this in commodity computers by using software to make sure that the hardware doesn't execute "invalid" software. This is the job of your antivirus software.

    Are we proposing to punish software folk for hardware vulnerabilities? Should Intel be explaining why ANYTHING in the PC of the i7 will be interpreted as the address of an instruction?

  47. Define "Sloppy Coding" by SwashbucklingCowboy · · Score: 1

    How do you define "sloppy coding" and do you really want a jury of likely mostly non-technical people determining what is and is not sloppy?

    adding that known flaws can be exposed by running code through commonly available security tools and validation suites.

    Which will drive lots of small developers out of business because they can't afford the tools. Tools such as Coverity and Fortify are fairly expensive.

  48. Sounds like a dumb idea... by Anonymous Coward · · Score: 0

    Suing a developer for security related bugs is ridiculous. What if a security bug is discovered but there is no available exploit? Will a fee be imposed on the level of effort (subjective) required to exploit it? As you can see this is just stupid.

    Can I sue a door/window manufacturer because they can be easily broken into (ie physical security weakness)? What about all manual lock vehicle doors that can we opened with a coat hanger?

    Also, how would this impact new innovations for fear of being sued over a race condition or improper input validation? The world seems to be loosing its mind..maybe we have another magnetic pole forming...

  49. It would be the end of OSS by Sycraft-fu · · Score: 4, Insightful

    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.

    1. Re:It would be the end of OSS by vlueboy · · Score: 2

      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 expensive) companies and everyone less powerful to have those stupid "trust" warnings because signing the code cost so much. Instead of actually getting stuff signed, I remember that drivers just added one little page in their install how to asking the user to disregard and click OK. I am sure a super-secure developer world of doom would contain quite a few of these new cheapskate hurdles that limit usability and get passed on to the installation and daily usage side of things.

      Imagine all those disclaimers for using JQuery and Node.js and tons of other nifty things on gray and black sites... Anyway, regulation is not really going to happen. App markets are the wind that is pushing cellphone sales up, which is pushing other tech in the USA forward as a side effect of Apple and other giants doing well.

    2. Re:It would be the end of OSS by Bert64 · · Score: 1

      Or you could limit the liability to the price paid for the software that failed...
      Of course this is open to abuse, "yes the software only costs $1, but the mandatory support contract is $1,000,000" or "Each file is a separate product and costs $1, there are 1,000,000 files so if you find a bug in one file we're only liable for $1"

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    3. Re:It would be the end of OSS by WarOfTheNerd · · Score: 1

      You can indemnify yourself if you're providing free software, completely free products/services can never have a mandatory contractual agreement provided under law; that's why in some countries Apple had to charge people a penny for some products/services. Also, if you don't provide binaries, you're not liable for those binaries. No-one can be held liable for the source code itself. Software people pay for should come with a contract whereby the company is liable if disruption to business, loss of profits and other harms are caused due to bugs.

    4. Re:It would be the end of OSS by WarOfTheNerd · · Score: 1

      or the software is free and you pay for download access, like indie developers do to avoid needing to pay lawyers to write contracts/licenses which indemnify the developer.

  50. Simple compromise by viperidaenz · · Score: 2

    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"

    1. Re:Simple compromise by Anonymous Coward · · Score: 0

      If you have the executable file, you have the capacity to examine the security provided by the software if you so desire to. This isn't infeasible, some people do this.

  51. Absolutely! by Anonymous Coward · · Score: 0

    I believe that there aren't enough law suits out there already. Why not add a new category?
    Also, more automatic weapons for everyone in case the lawsuit does not yield the desired results.
    The NRA approves. God bless America.

  52. Developers, no. Companies, yes. by Gravis+Zero · · Score: 2

    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.
  53. Requires total change of industry by Algae_94 · · Score: 3, Insightful

    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.

    1. Re:Requires total change of industry by Anonymous Coward · · Score: 0

      Half? You're very generous, my dear. People who can actually pass this sort of certification and know what they are doing are the elite.

    2. Re:Requires total change of industry by Anonymous Coward · · Score: 0

      And you know this because of all the flawless engineers that exist? Or are you just talking out of your ass?

    3. Re:Requires total change of industry by Ash-Fox · · Score: 1

      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.

      To be fair, this already exists when a software publishing company certifies it's systems are compliant with various standards like PCI DSS, HIPAA, ISO 27001, SAS 70 etc.

      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.

      I don't know really. Usually projects comparable to the work of "professional engineers" you mention look for 'certified' developers in specific technologies and fields, I can't really imagine this making a significant change with regards to available people when it's unlikely the 'license' is going to be that much different from existing certification requirements.

      I suspect though it will be a very profitable area of work for those giving the training and licensing.

      Personally, I'd rather endorse the approval of working on the types of projects based on certifications a person holds after it's been 'approved' as a good certificate. This would avoid the stagnation that government have regarding developing new certifications and international standard bodies being far more capable in making 'universal' certifications that can be accepted in most countries.

      --
      Change is certain; progress is not obligatory.
  54. maybe share some liability? by rjr162 · · Score: 1

    I mean if a hole or flaw in the software allows someone to steal PII or CC #s etc, I don't think the company who had the data stolen should be souly at fault.. it should be split (unless it can be proven the company failed to take basic "standard" steps to try to prevent such attacks)

  55. computer security is a process, not a product by Anonymous Coward · · Score: 0

    Bugs in code will always exist...
    If it were possible to write completely secure code,
    it would be done already.

    This type of law only makes money for lawyers, and puts coders out of work.

  56. I don't think you can justify this by aklinux · · Score: 1

    We are constantly finding ways around things thought to be secure, but then somebody thinks of an attack vector that nobody thought of before. We find this in the world in general.

    Look at padlocks for instance. We all thought Master Locks were pretty secure at one time. Now we find that someone thought of mounting a lock-pick to an electric file or toothbrush and now anyone can open one in seconds. Kryptonite bicycle locks have suffered a similar fate. I think both companies honestly believed they had reasonably secure products, so did the rest of the world.

    I think the only way we can reasonably justify holding software developers to this is if the developer of a particular piece of software is willing to put forth this type of guarantee.

  57. As always, within reason by gman003 · · Score: 1

    If it is a security hole that was either place deliberately, was known to the developers but not fixed within a reasonable time frame, or was caused by severe negligence, then yes, liability would be logical. But if it is a security hole that could have slipped through a *reasonable* QA process (ie. IBM's coders, not NASA's), then no.

    Examples:
    Program has a deliberate backdoor that allows for complete root access from any remote computer, protected only by a simple password that is the same for all installations and version. As this was deliberate, they are liable.
    Program has a bug where the usernames and passwords are compared only on the first three characters. As this required both massively incompetent coding, and would have been caught by any reasonable testing, they are liable.
    Program has one field in an obscure form that is vulnerable to SQL injection (the rest is properly secured against it). This was discovered during testing, but went unfixed for months until a major security breach was made public. As they had a reasonable amount of time to fix it but failed to do so, they are liable.
    Program is accidentally distributed with a test account in the defaults that grants full read-only access to the system, resulting in numerous leaks of private information. As soon as it is discovered, a notice goes out to disable this account and it is removed in the next month's updates. As it was a bug that could have slipped through a reasonable QA process, and was remedied reasonably, they are not liable.

  58. Re:Sure. it can be done. by Algae_94 · · Score: 1

    depends on where you are in the middle of winter. In my neck of the woods that stream would be frozen and covered in a thick blanket of snow.

  59. Only under the following circumstances by istartedi · · Score: 1

    1. He used a standard function or class as cited in the Catalog of Standard Functions and Classes for Professional Software Engineers.

    2. He used the standard function or class in a manner inconsistant with proper use as defined in the reference entry for the standard function or class.

    3. He used a non-standard function, class, or an implementation that wasn't certified.

    4. He represented himself as a licensed, certified professional software engineer.

    5. The fault was in his code, and not in the implementation of the standard functions and classes or the language, in which case the implementors would be liable.

    Now. Seeing as how the aforementioned publication doesn't exist, the aforementioned license doesn't exist, and no respectable body publishes such a text or administers such a licensing program, we must conclude: No.

    Alternatively, the increasingly annoying Betteridge could have brought us to the same conclusion.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
  60. Betteridge's Law by mug+funky · · Score: 1

    editors:

    before posting your troll article, look up Betteridge's Law, and realize that most of us here are aware of it.

  61. Not with government regulations. by roman_mir · · Score: 1

    Here is the pertinent part of this article:

    Clayton is arguing for regulations that remove the developerâ(TM)s right to waive any responsibility for security flaws in their software. Itâ(TM)s an argument that has already won support from officials across Europe, with a House of Lords committee recommending such a measure be implemented in 2007 and European Commissioners arguing for the requirement in 2009 - however agreements to this effect have not been passed.

    âoeItâ(TM)s remarkable that of all the things that you could buy as a consumer, software is the one where youâ(TM)re expected to make up your mind whether itâ(TM)s dangerous,â Clayton says.

    This person wants to create what he understands and works with - more laws. It's more work for himself, he wants to create environment where he would be given more power over other people, that's all.

    All people who are for any type of legislation over other people are really looking for power over other people, you have to understand it. The guy says: "it's amazing, you have to make your own mind about something and there is no law!" Wow, amazing.

    How about doing the exact opposite of what he proposes, namely removing the EXISTING regulations from the books that regulate businesses out of existence already?

    Here is an audio interview, starts at 19:19 and ends at around 40:00 (with VLC I listen at 1.5 times the speed, it's a time saver)

    This interview is about a couple of entrepreneurs from California that are shutting down their business because they couldn't make it there, but if you listen to the interview you'll find out why they couldn't make it there, the government prevented them from doing business as they wanted. They basically had something like cycle rickshaws driving people around for tips and the city (in this case) prevented them from having electronic advertising on their bicycles.

    The drivers (10 to 17 people or so) made up to 20 bucks per hour doing this work for tips. The two people running the company couldn't go around a few city rules, like that with the advertising and also something about being unable to cross a bridge where people on bicycles are allowed to cross, but with passengers people aren't allowed. It's amazing to listen and find out that they had to pay thousands of dollars to the government just to start a business like that, with all the licenses and compliance costs! It's ridiculous obviously (should be obviously). People clearly like their services, but the gov't prevents them from operating in a way that would allow them to continue.

    But all business regulations are about shutting down the business, all of it. It's about creating monopolies for some businesses and it's about creating worthless, economy damaging government jobs. It's about creating more work for lawyers of-course, it's about all the parasites riding on the backs of the real economy, and it all ends up destroying jobs, destroying the economy in the process.

    Regulating software creation? Good way to shut down free/open source software and hand over the monopolies to a few large enterprises that have the necessary lobbyists and economies of scale to comply with these regulations. Will the clients, customers, consumers be better served by these few monopolists?

    Pffffft.

  62. What about rushed QA / 80 hour work weeks / overse by Joe_Dragon · · Score: 1

    What about rushed QA (that can pass over issues) / 80 hour work weeks (that just lead to more errors) / overseas programmers (that sometimes code to specification)

    Poor user experience testing that can lead to errors from a poor UI.

  63. The company should be sued by bbroerman · · Score: 1

    The company should be sued, not the developers. Its usually company management that tells the developers what to code, gives them too tight a deadline, changes requirements mid-stream, and prioritizes fixes and defects based on the percieve d cost vs. benefits. (i.e. how much a lawsuit costs vs. the cost of fixing it) Usually the poor developers are struggling to keep up, and most aren't trained in security... Most are barely trained, as the companies want to get people cheap. Its really the companies fault.. This coming from a developer with 20 years of professional experience in companies large and small...

    --
    Logic is the beginning of reason, not the end of it.
  64. Agreed w/ your subject-line, 110%... apk by Anonymous Coward · · Score: 0

    Nothing more needs to be said than what I did, & what Burdell stated.

    APK

    P.S.=> It'd make getting into the business one thing, but getting out of it alive & solvent, possibly QUITE another, & not worth it!

    Well - put it THIS way: They had electricity pretty much "debugged & figured out", in around a decade - that's STILL going on in software engineering, & the "malware makers in general" even make it tougher (but I've said this before - that the 1 GOOD THING that type does, it point out holes to shore up)...

    ... apk

  65. E&O by Anonymous Coward · · Score: 0

    If enacted, I would think that the market for errors & omissions insurance would grow exponentially overnight.

  66. Not until we have an association to limit supply! by Anonymous Coward · · Score: 0

    And make as much as doctors and lawyers.

  67. Great Idea by fluxburn · · Score: 0

    It might be a better start to, in the open source space, patch security holes as a theme for a new era of computing. Starting to force programming to change so rapidly is one avenue, yet presenting the information alone addresses the issues of software and computing bugs.

  68. Re:Engineering Discipline (clarification) by Anonymous Coward · · Score: 0

    So the P.Eng person responsible for a project would have to sign off before a product is released. In the event that the software did something "bad" (TM), then the person who signed off is responsible for it. The P.Eng would use everything that is within "established" best practice - code review, peer reviews, test bench, QC etc. So if the product is not ready, the person's head is on the line for not releasing. Simple as that.

  69. FASCINATING issue by Kimomaru · · Score: 1

    It's surprising how long this point has been discussed in the comminity and still things really haven't changed. Both sides have compelling points. I remember listening to a radio interview with Simpson Garfinkel over ten years ago in which he stated that he was mystified that EULAs had stipulations that if software wiped out your system the manufacturer wouldn't be liable for damages. It makes total sense for the developer to be on the hook - if you buy a car and it has a defect, it's recalled. Same logic, right? EXCEPT that the indie developer who is learning to code may also be on the same hook if something goes wrong. Slippery slope - what about misconfigurations, situations where people THINK it's a software issue but it's really the tech's fault? If you set up an email server that's configured by default as an open relay (although, frankly, I can't remember if that's been the case in the past 12 years), who's on the hook for the mistake? I very much doubt this will change, not sure if it should.

  70. can roman_mir answer a simple question? by Anonymous Coward · · Score: 0

    how many sock puppets do you have? you know the answer. the rest of us know it is at least one though we doubt that is it. we suspect one or more of your sock puppets managed to get moderator points recently, and are using them to suppress posts that oppose your world view.

  71. It's called "Warranty of Fitness"... by trims · · Score: 1

    And, EVERYONE else has to do it, so why should software get a free pass?

    Software has gotten completely away from this, to its detriment. I'm not talking about being bug-free. I'm not even talking about being able to prevent "evil exploits", though programs which fail basic standards of secuity should be held to the same standards that any other product should. What I am talking about is that the program (let's say a word processor) doesn't crash repeatedly when run on OSes it is sold as "compatible" with, doesn't randomly delete your data, or doesn't read your on-line cookies and insert your name, SSN, and credit card number into the file format when you save the document. That is, software should have to do EXACTLY what it says it does, and nothing more. Any deviation from that should require a FREE FIX from the manufacturer, in a short amount of time, and manufacturers should be liable for unreasonable (in the legal sense) damage that it causes (e.g. in the case of a word processor, if it decided to erase your system drive, that's unreasonable, and the mfg owes you damages, but deleting a saved file, while requiring a fix, shouldn't trigger damages).

    It's time we quite treating software as something so horribly unique and different than any other possible thing that humankind has ever developed that NONE of the prior rules on warranties, fitness of purpose, or consumer protection should ever apply.

    All other manufacturers manage to deal quite well with product liability, so why is software supposed to be so different? Remember, product liability is about things that are unreasonably broken, or that the manufacturer knew about, and refused to fix and still cause damage. It's not about being able to hunt down all the heisenbugs ever possible.

    -Erik

    --
    There are always four sides to every story: your side, their side, the truth, and what really happened.
    1. Re:It's called "Warranty of Fitness"... by epyT-R · · Score: 2

      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.

    2. Re:It's called "Warranty of Fitness"... by u38cg · · Score: 1

      Then why does Microsoft, er, not want it?

      --
      [FUCK BETA]
  72. Contract by epyT-R · · Score: 1

    If it's in the contract that they are liable for failures, then they are.. Obviously the contract should specify what constitutes failure.. Otherwise no liability outside of gross misrepresentation (ie the software is NOT what the vendor says it is).

  73. One word: refund. by jonadab · · Score: 2

    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.
  74. What about the managers? by downhole · · Score: 1

    The summary at least seems to be focusing on individual developers, but how often is it really the developer's fault? Imagine that your boss asked you to write a program to do A. You say, well, I can use algorithm X, which will be a fast project, but not secure, or algorithm Y, which is more secure, but will take twice as long and twice as many developers to create. What do you think they're going to pick? What about just plain not having enough time to actually finish something and fully test it before having to move on to something else? What about stuff like no budget for software testers, pen testing, proper security audits, etc? Probably 80% of it isn't really the fault of the individual developer, so it makes no sense to focus on holding them accountable.

    If you wanted to do something like the PE program, like certified developers, then you'd have to have some sort of legal requirement for what programs require what kinds of sign-offs from who. The State can easily enforce that, say, plans for an actual physical building must be signed off, and inspect the building to make sure it's actually built to the plan, etc. How do you do that for software? Is there supposed to be some organization that monitors publicly accessible servers or something and fines anybody operating one that doesn't have the right licensing? Sounds like a mess.

    --
    I don't reply to ACs
  75. If it's poorly written, then yes by Anonymous Coward · · Score: 0

    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.

    If the door, or the lock on the door, was defective or poorly constructed then I think the burglary victim would have a pretty good case in court. Case in point - http://hardware.slashdot.org/story/12/07/25/1326225/open-millions-of-hotel-rooms-with-arduino

  76. Re:Developers, no. Companies, yes. by Anonymous Coward · · Score: 0

    Developers don't make reliable software, engineers do. There is a difference. A company that wants to release reliable software on predictable schedule hires engineers, not developers.

  77. Americans. Always discussing who to sue next... by hotfireball · · Score: 1

    Of course they can sue. It is the same as suing car manufacturer for being a victim of somebody's wrong driving...

  78. lol by Anonymous Coward · · Score: 0

    I'm pretty sure that if this happens, Windows will cost $4000, and Linux will actually be outright illegal to run.

  79. I'd support by Anonymous Coward · · Score: 0

    suing the company that sells the Point Of Sale software, but not the developer(s).

  80. In other industries ... by TheGavster · · Score: 1

    In the "bricks and mortar" engineering world, you have to pass your PE exam to be able to sign off on designs and whatnot. Big projects that could conceivably cause a liability if they went awry thus employ one or more PEs to at least inspect and certify the design and implementation, and liability falls on those professionals should the engineering turn out to hurt people or destroy property. With computer code forming more and more of the "can blow the whole thing up" part of engineering, it might be time to pull computer engineers into the PE fold, and bring a similar legal structure to mission-critical code.

    --
    "Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
    1. Re:In other industries ... by Voogru · · Score: 1

      Except in reality this won't actually increase any safety, what it will become is a rent seeking entity and regulatory capture nightmare, as what happens with most situations

      It will also drive prices of everything though the roof, because one can always argue for more safety regulations (whether they increase safety or not), and then claim anyone who's against it wants people to die in horrible ways.

  81. Microsoft isn't sued - why should developers be? by Anonymous Coward · · Score: 0

    Sue MS for it's crappy OS... Sue Oracle for a DB that is riddled with holes that you pay thousands for... Don't try to sue the poor guy trying to code in those hellish environments... Sounds like and Obama plan - stick it to the little guy...

  82. well then.... by slashmydots · · Score: 1

    Then they'd have to let banks sue their customers for their complete stupidity causing their money to be stolen. Fall for some bullshit phishing scam promising to make you rich instantly? You're liable. So I'm all for it, lol.

    1. Re:well then.... by SecurityGuy · · Score: 1

      Actually, banks don't have to sue for this, they can (and sometimes do) simply say that the customer is responsible for the loss, and then you're out the money. If you disagree, you can sue them.

  83. Really? by Voogru · · Score: 1

    "A Cambridge academic is arguing for regulations"

    You don't say. An academic arguing for regulations.

  84. Well stated by zkiwi34 · · Score: 1

    I agree, it is long overdue in software development.

    For those who say it's "too hard" etc, bollocks.

    1. Re:Well stated by Man+On+Pink+Corner · · Score: 1

      It's not "too hard." NASA can write bug-free code, right?

      But do you want to pay for it, as a user? I sure don't.

    2. Re:Well stated by El_Muerte_TDS · · Score: 1

      It's not "too hard." NASA can write bug-free code, right?

      No: http://en.wikipedia.org/wiki/List_of_software_bugs
      It lists 4 software bugs for NASA in the "Space exploration" section.

  85. This is just software plus an insurance policy by SecurityGuy · · Score: 1

    Look, this sort of thing is already done in other industries. I have absolutely no intention of working for $XX/hour writing software for X million users, each of which might conceivably sue me for some nontrivial loss. No way, ain't gonna happen. It's simply financially stupid to do so. What I'd end up doing is exactly what doctors do. Write software that might end up getting me sued for $millions, and have a giant malpractice policy standing by. You'll get your more secure software, but you'll also pay for it because I'm absolutely transferring that cost to you. If the market won't bear what I have to charge, I'll find other work.

  86. Civil vs Criminal by Wolfling1 · · Score: 1

    In Australia (and most western countries I imagine), there is a distinction between Criminal matters (eg breaking the law), and Civil matters (eg breaking a contract). Generally speaking, Civil matters won't see you landed in jail, but could bankrupt you.

    Anyway, the point is, anybody who sells anything (including software) is open to be sued in a Civil court. If you are negligent, and it can be proved that you are negligent, then you can be held accountable for it.

    Interestingly, in Australia, the burden of proof is different for Civil matters. There is no 'beyond reasonable doubt' clause for Civil matters. It is generally decided by a judge (not a jury) on the basis of 'the balance of evidence'. But I digress...

    The point is: We are already liable. Its not a criminal matter - and nor should it be, unless there are lives at stake. Admittedly, some software is life-critical, but there are already laws covering professional negligence in these cases.

    IMHO, this academic has an axe to grind that has not yet come to light. Scratch and sniff, and something probably stinks...

  87. You get what you pay for by FranTaylor · · Score: 1

    Limit maximum liability to a multiple of the product's price.

    If you pay $50 for software, the liability is limited to (say) $500.

    If you pay $0 for software, the liability is zero.

    No special exceptions needed for FOSS

    RHEL is not selling software, they sell a service, so they would not be liable, except for the software that they wrote, but see above.

  88. You can already sue developers.. by Phasedshift · · Score: 1

    The following is my non-professional opinion:

    You can already sue developers.

    Any development contract should have language indicating what is desired and minimum standards compliance (example: PCI compliance if you're handling credit card data.) If it is later found that the developer did not adhere to the terms of the contract, they can be sued for breach of contract.

    Further, if the flaws in the software are extremely severe, even if the contract didn't explicitly call out the problems observed, they could be covered under gross negligence and the developer can be sued for that as well.

    As with many other things, a new law isn't needed for this, the ones on the books are perfectly suitable. The money/time it takes to get a remedy to the issue via our court system is another matter entirely, but would be similar regardless of a new law.

    1. Re:You can already sue developers.. by Phasedshift · · Score: 1

      I should have clarified in the previous comment that if you don't have the ability to dictate the terms of the contract (such as if you buy the product in the store), it is my belief that you can likely recover damages already if it is due to gross negligence of the developer in question in most jurisdictions. As mentioned in the previous comment, proving that can be another issue entirely.

  89. Language! by Anonymous Coward · · Score: 0

    If this became law everyone would simply learn Haskell, thus eliminating all bugs overnight!

  90. But the burglar was the one that broke the law by Anonymous Coward · · Score: 0

    Why on earth would you want to sue the door manufacturer? Shouldn't the effort go into tracking down and prosecuting the burglar? After all, he was the one that did all the law breaking.

  91. SQL operator IN by tepples · · Score: 1

    There are things that an application that always uses MySQLi prepared statements cannot do. One of them is anything involving SQL operator IN. But in such cases (hopefully rare), there are still ways to reduce the attack surface.

    1. Re:SQL operator IN by shutdown+-p+now · · Score: 1

      Is that a limitation of that PHP library, or a limitation of MySQL?

      Whichever one it is, don't use it.

    2. Re:SQL operator IN by tepples · · Score: 1

      It's a limitation of "that PHP library". But it's also a limitation of shared web hosting, which is often limited to "that PHP library" because not all companies that offer shared LAMP hosting have PDO in their PHP configuration. Just not using MySQLi, as you suggest, would require everyone who operates a web site as a hobby to put down several times more per month for a virtual private server.

    3. Re:SQL operator IN by shutdown+-p+now · · Score: 1

      Just not using MySQLi, as you suggest, would require everyone who operates a web site as a hobby to put down several times more per month for a virtual private server.

      Admittedly I haven't looked at the state of the Unix-based web hosting market in a while, sticking to what I know best (which is .NET). But there are definitely hosting solutions offering ASP.NET etc without a full-fledged virtual private server. I'd be surprised if there were no such for PHP (or, better yet, Python or Ruby) + Postgres.

    4. Re:SQL operator IN by icebraining · · Score: 1

      One of my VPSs costs $3.2 / month and runs a PHP based blog engine just fine, plus my mail server. I doubt you can find any decent web host for several times less per month.

  92. Need more than encryption by Walt+Sellers · · Score: 1

    Plenty of examples have been made of programs that had encryption, but did not use the encryption correctly. This resulted in security that was defeated in a few steps by skilled people.

  93. Particular by tepples · · Score: 1

    What difference do you see between particular and trivial in this case?

    1. Re:Particular by flux · · Score: 2

      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

    2. Re:Particular by metacell · · Score: 1

      Turing proved that it's not possible to write a program (or algorithm) that can examine *any* program and decide if it works correctly.

      It's still possible to prove that individual program work correctly, but you may have to use a different method each time.

      Much like proving mathematical theorems; there's no general algorithm for deciding if a theorem is true or false, so mathematicians will always have to use their own creativity.

  94. Password storage by tepples · · Score: 1

    If an application needs to store a password to interact with a remote system, it can't just store a hash. And if it encrypts the password, it still needs to store the key to decrypt the password to use it. So how should an application store this key, especially a server or something else that must run without user interaction (which rules out PBKDF type key generation)?

    1. Re:Password storage by metacell · · Score: 1

      The password is entered once to authenticate the local machine with the remote server. At that point, the remote server gives the local machine an identification token. The local machine then forgets the password the user entered.

      The identification token can have limitations on what IP address it can be used from (if the local machine has a fixed IP address), what operations can be done using it, what times of day it can be used, and so on. For example, the user can enter their social network password on their phone to authenticate it to fetch incoming messages for them, but not for anything else, like changing settings.

  95. Why not managers and owners? by thesandtiger · · Score: 2

    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.
    1. Re:Why not managers and owners? by Anonymous Coward · · Score: 0

      Exactly. If you want to hold me accountable then I get final say on every single requirement.

      Sales told you that we could implement X for you and it is the cornerstone of your business?
      Nope. Sorry. It's a security risk.

      You forgot that one requirement that's key to your business and want to push it in now, after a lot of the system has been developed?
      Nope. Sorry. It's a security risk.

      You want to integrate with that 3rd party tool?
      Nope. Sorry. It's a security risk.

      You need to keep communicate with your legacy system?
      Nope. Sorry It's a security risk.

      -BSWEFH

  96. Speech and beer too by tepples · · Score: 1

    the supplier could take the money and deliver nothing

    What money? I thought we were talking about free software.

  97. Now usefully define source code by tepples · · Score: 1

    Is a JavaScript program source code or an executable?

  98. Yet They Should by Anonymous Coward · · Score: 0

    I see no reason why car companies can not be sued when cars or so easy to steal and it is well known over decades. Exterior doors should be tested for burglary issues just as they are rated for fire or other known hazards. Code is completely different as new ways seem to come along to break into computers and other devices that people who are diligent simply would not be able to foresee. That is completely different than a home owner being killed by flying glass from an errant golf ball striking a window. There are technologies that stop that sort of thing and why should various industries be allowed to skate on safety issues?

  99. Costs of Security by Anonymous Coward · · Score: 0

    This is one of the dumbest ideas I have seen in a long time. I'm a professional software developer like many people here. As background, I have around 20 years experience, and I have worked on web, desktop, mobile, and console software.

    In theory, this sounds like a good idea, but the costs are just too high. Who will pay the company or dev? What devs want this responsibility? What's the selection criteria? So many more questions.

    Security bugs are typically caused by the following:

    1. Stupid people, with low skills. This is actually the majority of the industry, sorry.

    2. Introduction of third-party libraries that bring sometimes undocumented problems. If they are not open source, it becomes even harder to find these bugs. If they are, who is paying us to scan through them ourselves line by line?

    3. Lack of time. Maybe the #1 or #2 cause. Crazy deadlines force us to release things, ready or not, and of course take short-cuts. These deadlines are often arbitrary because of stupid manager. If anyone should be accountable then, it should be them. Never a dev directly.

    4. Complexity of systems. Involved with #1 in this list. The more moving parts there are, the more likely there is going to be an issue. Especially if those moving parts introduce communication layers and other systems.

    5. Languages. Yes, some languages actually don't protect things very well at a low-level. And certainly using an unmanaged language, one could argue makes it easier to make mistakes that relate to memory exploits and buffer tricks for instance.

    6. Deployment infrastructure. Who knows if it is the OS, the physical setup, or the software always that opened the exploit? Forensics are not always clear for sophisticated attacks. Then it becomes a blame game between vendors and personnel.

    The results of such a law would be:

    1. A lot of businesses couldn't afford the costs and wouldn't be able to continue.

    2. Because of #1, or lack of desire to protect themselves legally from a cost perspective, a lot of businesses would simply find a country where these laws didn't apply. If it's an internet company, it becomes much more of a gray area.

    3. Less people want to be a software developer to take on the risks. The pay would at least have to increase to compensate developers and their companies for taking on added risk. As developers are often underpaid already, I don't see this as realistic.

    4. Enforcement bodies would have to be created at a huge cost to the public. I don't see this as a priority compared to other issues and can hardly see who wants to fund this. Even if it did, I can't see the most qualified software professionals working for a government usually. Not a good situation when you have inept people performing the evaluations.

    I could go on, but it's obvious implementing something like this would be a debacle. It's as if someone had a grand idea over a roast beef sandwich and decided to declare it to the world without thinking it through for 5 seconds. Frankly, the naive nature of this whole thing makes me scared for whoever thought of it.

  100. Companies should be held liable by Anonymous Coward · · Score: 0

    One of the best ways to improve our industry is to allow individuals and companies to sue software makers (companies, not individuals) for negligent behavior resulting in harm. You'd have to prove that said company was aware of a problem that could cause serious harm, they had sufficient time to fix it but did not, and said harm did occur.

    Yes, it would drive software prices up, but it would have the affect of finally converting our industry from an art to a science. We need some "tough love".

    If a company builds an overpass that collapses on people a few years after it was built (this actually happened in my city) whereas normally overpasses last over 30 years then the company rightfully gets sued for negligence leading to bodily harm and death. Similarly, if a company produces software that causes, say, cars to cease functioning while you're driving on the highway, leading to serious bodily harm, then they deserve to get sued into bankruptcy as well.

    A bank whose websites exposes your bank account to a known security flaw (for an extended period of time) that gets exploited to steal your funds would:

    1. Require the bank to refund the stolen amount.
    2. Enable you should sue them for their negligent behavior.

  101. He Who Pays the Piper by Walt+Sellers · · Score: 1

    Too many people forget the liability is about the possible consequences. The consequences in your analogy just don't compare.
    - If a bridge collapses, there are real damages such as deaths, injuries needing long-term care, injuries needing short-term care.
    - If software fails, information gets copied.
    These are not the same.

    You say its time to demand professional behavior. Then do it. Buy your software from the better behaved company even if it costs more.

  102. Clients want software fast and cheap... by Anonymous Coward · · Score: 0

    You can't have it both ways, finding bugs costs money and takes time, when one of my customers wants an app developing they usually need/want it yesterday.

    Hence I include the following in all my licences and I get them to sign off on it;

    "The Software is experimental in nature and is being licensed as is."

    I usually include a maintenance agreement so if there are bugs they get them fixed under maintenance but I am not going to find all the bugs in the time available and any cracker worth his salt will eventually find ways to get into my systems although nothing I have written has been cracked yet.

    It's interesting that it's an academic coming up with this idea - "Those who can do, those who can't teach", perhaps he should stick to teaching...

  103. No. by Anonymous Coward · · Score: 0

    Nobody is more fed up with the sloppiness and general incompetence that is all too widespread in the software world. But suing people over this will lead to a circus that will make the current patent thing look sane. That will kill innovation.

  104. Medical and sports professions offer clues by Tablizer · · Score: 1

    If you compare it to the medical profession, then it most likely it would greatly drive up software costs.

    For one, programmers would probably have to buy malpractice insurance, and expect an increase in wages in order to pay for such insurance and also compensate for the added risk to one's career in general.

    It would also be more like sports in that after a few "injuries" your career is done because nobody will want to hire you. Thus, programmers would expect higher salaries earlier in their career before lawsuits kill it all. (One doesn't know up front how often they'll have difficulties in this area.)

    The training and "intern" stages would also be longer to learn how to avoid bugs and work with "anal" languages, which would also likely be reflected in salary.

    If people balk at such higher USA salaries, then good luck trying to sue a poor programmer in a wood hut in Timbuktu. If you can ever win the lawsuit, you get an old camel with a bad back and a hole-filled blanket.

    It may make more sense to sue the software vendor for breaches, not the programmers. Still, insurance costs would play into the price.

    Test this all in a smaller country first.

  105. Could be a good idea, if and only if .... by DerPflanz · · Score: 1

    there are also laws governing the quality of code.

    The analogy of Microsoft is not so bad, considering that a door-maker, or a house builder actually has laws governing the *construction* of their products. Same thing goes with safety standards in the industry. This leads to provable checks on the design, *before* something bad happens. Then, if something bad happens, you can request the reports and if everything is OK there, the designer/engineer is not responsible, but it is an 'accident'.

    If the computer industry can come up with design standards, the law can make these standards obligatory. Without these standards, this whole thing is bound to become yet-another-stupid-IT-legal-battle with lawyers and judges without a clue.

    --
    -- The Internet is a too slow way of doing things, you'd never do without it.
  106. Full disclosure debate by Anonymous Coward · · Score: 0

    Is very close to this debate and wasn't mentioned so far. As others have said, this proposition is fine as long as free software (think freedom, not price) is exempt.

    The idea that the big shops will just be moving the costs onto the customer is valid and of course what will happen. All costs are always moved onto the customer... And it does mean more competition and healthier practices throughout the industry.

    http://en.wikipedia.org/wiki/Full_disclosure

  107. "Confidence Insurance" by iiiears · · Score: 1

    Your customer pays 5% to be held in escrow. A portion of this money can be claimed by a company in the 5 years following initial sale.

    If the customer is happy they split the money. If the customer isn't they can petition for and fund a class action lawsuit.

     

    --
    15TW = 15,000 Nuclear Reactors. (Approx. one accident a month.)
  108. Why not sue by Anonymous Coward · · Score: 0

    the professors who teach computer science graduates who eventually develop the software...

  109. Meanwhile Adobe by jbov · · Score: 1

    Meanwhile, Adobe's lobbyists are preparing a formal application to have their Adobe Reader and other software excluded from such litigation.

  110. sure by Anonymous Coward · · Score: 0

    Sure you can sue the developer for security bugs, just put it in the contract.
    And pay the software 50x. After all, you're asking a *lot* more work.
    And wait for the software 2-3 times the times. After all, you're asking a *lot* more work.

    Is it really worth the trouble? with all this spending, why don't you build the software on your own?

  111. Yes... by Anonymous Coward · · Score: 0

    ...If they pay programmers like lawyers, doctors, engineers and accountant, of course to become a programmer an induction to a Society of Programmers would be required, just like lawyers, doctors, engineers and accountants. The society would monitor for malpractice. We would also require practice insurance like lawyers, doctors, engineers and accountants.

    But to tell you the truth it will never happen, nobody wants to pay for software that much.

  112. WYGIWYP by itsdapead · · Score: 1

    Even the legal system ought to be smart enough to apply "you get what you pay for" to this situation and make a distinction between the liabilities of someone giving away their software and a big company charging industrial grade annual licensing fees.

    If you want guarantees on open source software, get a support contract.

    --
    In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
  113. Bad Analogy Guy says - by JosKarith · · Score: 1

    "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"
    If it's sold as a security door/window and the burglar gained access through said portal then I'd say the defence starts looking a lot more shaky...

    --
    'Don't worry' said the trees when they saw the axe coming, 'The handle is one of us.'
  114. There should be official standards in place. by Qbertino · · Score: 1

    There should be official standards in place to cover for crappy coding and bad security and professional developers should be held accountable.

    This is tough for me to say, because I coulldn't say that I'm particularly solid at web security.
    But, and here's the big *but*: I and nobody else would want to cross a bridge with which some engineer might have thought about all the neccesities. We would want to be damn near sure that he *did* think about everything.

    Online payment procedures are becoming an everyday thing, it's time we get public standards enforced by legal authorities into place. It is then that we developers can finally ask the same salareis that engineers get.

    That's just my opinion though.

    --
    We suffer more in our imagination than in reality. - Seneca
  115. ofcourse not.. by SuperDre · · Score: 1

    The problem with security bugs is that it's hard to decide what a securitybug is.. SQL-injection for instance is now a wel know securitybug, but it wasn't when it was first used. Also there is the problem of not being up to date what can cause a securitybug (that's almost a special trade by itself), I personally still frown at the concept of bufferoverflows to start malicious code and still can't grasp how it's done even after more than 25 years of coding, so I would never be able to detect a securitybug like that.
    Then ofcourse there's the problem of using a framework/external component which might have a securitybug which you as a developer are not aware of. Also what about old software, which might be full of securitybugs but not known bugs at the time of writing..
    Securitybugs are a bug problem to classify, to an expert who makes money of finding those bugs, it's a given, but to a day-to-day developer it might not be known, and it just isn't feasible to be up to date on EVERYTHING, because there's a lot more then only securitybugs..

  116. Sue for money? Increase rates. by Vernes · · Score: 1

    If they accept this, we just increase the rates.

  117. Whilst there are bugs, support the software by Anonymous Coward · · Score: 0

    Whilst there are bugs, support the software. The only one allowed to make the derived work of a bugfixed patched system is the closed source copyright owner themselves.

    Until there are no bugs, support the software.

    Or allow anyone to create a bugfix.

  118. Because they can see your code is incompetent by Anonymous Coward · · Score: 0

    and can do so without running it if you give the source code. They can also change your code so it isn't incompetent. They can also get it for free if you gave it FOSS, so they're not even out of money.

    But if you give a binary, they have to TRUST you are competent. They cannot tell until after the fact that it is destructive.

    You HAD to *LIE* to them to get them to run your code.

    Of course, if you gave out binary saying "this code will trash your system and cost you money" then you wouldn't be lying but then again, why are people using it?

  119. College != ready to program by Compaqt · · Score: 2

    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
  120. Should teachers be sued for stupid pupils? by Anonymous Coward · · Score: 0

    You can't be serious. You obviosly dont understand the concept of a company as a legal entity to minimize private risk. Minimizing the risk for private liability is one of the key elements of modern economies. In this sense who ever receves the profits, bares the risk and is liable for defects.

  121. No, just let the market do its job by Bigfield · · Score: 1

    How about letting the customers decide if the product is good or not. You don't need to sue, just don't buy it. Choose the alternative which is better and buy that one instead. Or in case of free SW, select the product which gets patched/maintained/is good in the first place.

  122. Sounds familiar... by Menkhaf · · Score: 1

    We had this same discussion last year, after PHK had an article on acm.org arguing for software liability laws: http://yro.slashdot.org/story/11/09/29/2045232/outlining-a-world-where-software-makers-are-liable-for-flaws .
    The article is to be found at http://cacm.acm.org/magazines/2011/11/138202-the-software-industry-is-the-problem/fulltext

    --
    A proud member of the Onion-in-Hand alliance
  123. Flat out NO, it wil have the same effect as... by Anonymous Coward · · Score: 0

    Malpractice insurance on the health care industry. The commercial software industry will fail. Most people will embrace open source and accept the security disclaimers that I'll force my users to accept to use the software. Not accepting the security disclaimer will be a violation and the company and/or people involved with the product will not be held liable.

    Computer users should be educated enough to conduct their own security audits. If not too bad. I tell you if I was to write and sell an application with the
    knowledge I 'll be sued if the code was hackable I will be forced to add costs to the software. I'm not going to give the added security away. Next I'll never support Microsoft Operating Systems. Why? That platform is extremely insecure. I am surprised that any Government uses it. They are much better off with a hardened version of Linux.

    Maybe all of us who contribute to OpenSource or sell code should always release a security disclaimer, that way we can nip this in the bud. My clause would say "Every step was taken on our part to ensure that this code is secure, however system security is up to the system administrator and end users of this product."

    An application can be tested to be extremely secure in a test environment, but when installed and deployed by a layman or inept systems administrator the application be be a total security hole.

    This should be a lesson to all CIOs. Do not trust system adminstration to a remote team. Employ someone knowledgeable. Your Company's IT security depends on it.

  124. Sue the police for every crime by Anonymous Coward · · Score: 0

    Let me sue the police every time there is a crime - afterall, I pay taxes to make sure I'm "secure". Its the police's job to ensure my security. Ergo, if there is a crime, its a security flaw - so sue the police.

    Its fucking preposterous! I'm not surprised that most lawmakers in the "civilized world" are lawyers - they just want more work for their kind. Before anyone jumps on this, I realize that this was proposed by an "academic" (not sure he/she is a lawyer or not), but all the same.

  125. Its all about the risk by njko · · Score: 1

    The activities that the developers make who introduce a real and considerable risk to the society should be done by certified professionals and using the standarts for that activity. Developing software its a common name for a diverse group of activities in diferent kind of industries.

    --
    \n.\n
  126. Dynamic PHP by Compaqt · · Score: 1

    It seems you're not really familiar with how this works in PHP, so I'll explain it:

    If you're on the server as shell user, you can both 1) create a PHP file in your home directory (or wherever you have perms) and execute it via the command line. 2) Execute dynamic PHP (i.e., code that you make up on the spot) via the exec("php code goes here") function. That goes without saying.

    Additionally, the mod_php Apache module allows the webserver to execute PHP files. Also, many PHP-based CMS's allow you to enter PHP to be executed at specified time or events. This PHP is saved in the database, retrieved, and then executed (via exec).

    But that doesn't mean anybody who signs up as a user on the website can execute PHP.

    If, somehow, you could impersonate the admin, then anything is fair game.

    However, of course, anything would be fair game in a Java-based setup, too, since DB passwords are stored in plain text there, too. Also, you can run dynamic Groovy (Java scripting language).

    In addition, CMSs such as Drupal which allow you to execute dynamic PHP also warn you not to do so. You can turn off the facility, as well. I would say that all your PHP should be in files. And you should turn off perms for "other". The files should be owned by you, and the webserver should run as you (meaning your user), not as "www-data" or whatever. That prevents nice and easy updates, but it's better.

    --
    I'm not a lawyer, but I play one on the Internet. Blog
    1. Re:Dynamic PHP by mcvos · · Score: 1

      You're still skipping the vital step here. Are you talking about impersonating the admin on the website, or on the server? That's a vital difference. Impersonating the admin on the website shouldn't matter for SQL injection. And admin has more permissions, but still can't run arbitrary code. As an admin on the server, you can of course change the code in any way you like, but there's no way a website should be able to give you that kind of access.

    2. Re:Dynamic PHP by Compaqt · · Score: 1

      1. First, yes, we agree that if you're root, you can do anything.

      2. But, again, yes I was talking about admin on the website software, whatever it is. And that would be "guy with all permissions". Of course normally, you should set up and use lower privilege accounts, which contain the bare minimum of stuff you need to do your daily tasks. Only log in as admin once in a while.

      3. However, let's say you are logged in as site admin. And you go to badsite.example.com, and they manage through some combination of bugs in your browser, CMS, and non-secure possibly wifi connection to execute commands as site admin.

      4. Assuming #3, yes, an attacker should be able to execute arbitrary PHP.

      a. First of all, he can probably upload a PHP file and navigate to that.

      b. Or, run dynamic PHP with eval(). Example in Drupal. Like it says "While this is a powerful and flexible feature if used by a trusted user with PHP experience, it is a significant and dangerous security risk in the hands of a malicious user." But, it's enabled on many sites anyway for the flexibility it offers. ("You go to war with the PHP site you have, not the one you want.")

      My recommendation: log in with the least privilege necessary. And turn dynamic PHP in your CMS.

      Note: You can turn off the eval() function in php.ini with disable_functions. However, many PHP CMSs and frameworks make use of it for some of their dynamic magic/polymorphism/etc.

      --
      I'm not a lawyer, but I play one on the Internet. Blog
    3. Re:Dynamic PHP by Compaqt · · Score: 1

      Just to be sure you understand what I'm saying, forget the CMS, and let's just take the simplest case:

      You've got a single PHP file, say test.php .

      test.php has a text box in which you can enter some PHP code, and a Submit button.

      Once you submit, in test.php, you've got the PHP code in, say $phpcode.

      Now, to execute it, just do:
      eval( $phpcode);

      That's it.

      Of course, you wouldn't want a file like that anywhere on your website, but that's how dynamic PHP works. Also, it's not meant for the purpose of executing code you type into a text box. It's just some level of flexibility included in PHP (and most other scripting languages).

      --
      I'm not a lawyer, but I play one on the Internet. Blog
    4. Re:Dynamic PHP by mcvos · · Score: 2

      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.

    5. Re:Dynamic PHP by Compaqt · · Score: 1

      Obviously, no CMS or CMF is asking you for code and then executing it.

      Normally, people use it like this:

      Example 1: Access permission on a certain page. The CMS lets you a) show the page to all users, b) show only to users with a given role, or c) show only if you return "true" from a PHP function, which you enter into the CMS and it's saved in the DB.

      Example 2: In a given content block, you can enter (on the backend) plain text, filtered HTML, full HTML, or PHP.

      As I said above, it's better not to use this functionality. But there you go.

      The potential for harm exists in that you could have a PHP injection problem if you reuse something from the environment (GET or POST or whatever).

      --
      I'm not a lawyer, but I play one on the Internet. Blog
  127. Increased Costs & Happy Lawyers by Scin · · Score: 1

    I can see some logic with the developers having some liability when grossly negligent.

    The problem is that this will likely have very limited impact on the number of bugs and software quality. It will however increase costs and we will end up with ridiculous class action law suits that primarily benefit the lawyers.

  128. Identification token storage by tepples · · Score: 1

    At that point, the remote server gives the local machine an identification token.

    By "password" I was referring to long-lived identification tokens in general. If an application needs to store an identification token to interact with a remote system, how should it store this identification token?

    1. Re:Identification token storage by metacell · · Score: 1

      In plaintext -- encrypting it would be pointless. But the token could be limited to a specific IP address, specific requests to the remote server, and a specific time period, making it much harder for an attacker.

      For example, Facebook uses this method when the user authenticates third-party web sites to act on their behalf.

    2. Re:Identification token storage by tepples · · Score: 1

      Tokens limited to a specific time period are fine for the client side of an interactive application where the user can be expected to reauthenticate daily. But I was referring to the token that, for example, PayPal's payment processing service issues to the operator of an online store. Those tokens have to last longer because the operator of the store doesn't want to end up turning away customers if he fails to key in the password at the same time each day. And I don't see anything within PayPal to give a different "API signature" to each IP address associated with a particular merchant; each merchant is allowed only one token.

  129. Developers are not insurance companies. by coldsalmon · · Score: 1

    The liability for a loss should fall on the party who is best able to protect against that loss. In the case of data security, the user is best able to secure her data. A software developer cannot control what type of data a user chooses to interface with its products. In this way, developers are similar to landlords. A landlord is not responsible for the property you bring into its building, because it cannot control what that property is. Instead, tenants are expected to get insurance on their own property based on its value. Similarly, data security liability will vary based on the type and amount of a user's data, not based on the type of software they are using. Insurance should be provided by insurance companies, not by software developers.

  130. depends on the level of "stupid" by RobertLTux · · Score: 1

    You should not be able to sue for a bug that only happens with data out of normal range between 22:00 and 23:45 during a full moon with Venus in ascension when the system is set to Cherokee Language with german numbering (or something similar).

    But if somebody codes something so that it falls over with Normal Data (or in a way that a first year programming student wouldn't try to turn in STONED) then that should be sueable.

    in the window case if the window was sold with a flaw that you could just push on the window to pop it out especially if it was SOLD AS A SECURE WINDOW then yes you should be able to sue.

    --
    Any person using FTFY or editing my postings agrees to a US$50.00 charge
  131. Hypercomputation by tepples · · Score: 1

    there's no general algorithm for deciding if a theorem is true or false, so mathematicians will always have to use their own creativity

    Are you claiming that a mathematician's creativity is a form of hypercomputation? If the digital physics hypothesis is true, hypercomputation is impossible.

    1. Re:Hypercomputation by metacell · · Score: 1

      No, a mathematician's creativity is not a computation (in the mathematical sense) at all, since it may give incorrect answers, and yield different outputs when presented with the same input on different occasions.

  132. Scumbag User by Anonymous Coward · · Score: 0

    Insists that software development follow rigorous engineering principles and that developers maintain full liability for all flaws.

    Refuses to pay anything more than $10 for the result.

  133. No. In one word. by Alkonaut · · Score: 1

    No, someone else (management) is always responsible for the company's products and services. An employee risks being fired for not doing their job, but that's all. We are only talking incompetence here, not deliberate error. To put it another way: if I'm going to take some of the economic/legal risk that he company should be taking, then this company better pay me extra (say, about twice what it would cost me to insure against this) or they can look for other developers, and presumably finding those they will have to sue a lot.

  134. Simple minded by Anonymous Coward · · Score: 0

    The politicians solution to any problem: more laws and law suits. How's that working out?

  135. Errors and Omissions by Anonymous Coward · · Score: 0

    There is an errors and omissions requirement with some government contracts that one or a company must have to protect the developer from serious software errors.

  136. It's not always the developers by Anonymous Coward · · Score: 0

    Posting Anonymously for obvious reasons.

    The company where I work stores passwords as plain text in the database, and transmits them unencrypted (even sends them over E-mail), because it is more important to cram MOAR FEATURES into the product and hit arbitrary deadlines than to secure the system. The developers are not calling for this stupidity, so why should the developers be sued?

  137. obvious test by Anonymous Coward · · Score: 0

    Ok, but the security hole should be obvious.

    Things like:
    1) failing the monkey test.
    2) allowing for insecure login methods while a secure login method is an obvious requirement.
    3) not applying encryption when it's obvious it should be used.
    4) Not applying obscurity (it's a very weak layer, but nonetheless it is one).
    5) programs not cleaning up the mess they created (not only insecure but also sloppy).
    should be punishable. The obvious things.

    Somebody should not gain admin rights when an unexpected value is entered. Things like that.

  138. Tit for tat by Anonymous Coward · · Score: 0

    Seems fair; as long as we also get the death penalty for stupid users.

  139. Progression by Anonymous Coward · · Score: 0

    Every programmer, regardless of how brilliant or how much of a prodigy they may be, starts out as a novice. With each new project that they complete, they hopefully become a little better than they were before, which is usually the case. As a programmer is exposed to more and more things, their world of possibilities and solutions grow as well. This being the case with all programmers, each have been the newbie, the overly cocky screw up, the adequate completer, the designer and architect, and finally the polished expert.

    Placing liability on a programmer has more to do with timing than ability I believe. How many companies do you know of that hired an under qualified engineer and tasked with a project beyond their capabilities. For the programmer, it's a great learning experience, but let's make no illusions of where the liability lies. A company almost always gets exactly what they pay for, like most things in life. Under experienced programmers are going to make mistakes, it's a fact of life. Cheap companies not willing to fork out what it takes to build a project, and now wants a fall guy (that they setup) to point a finger at?

    Personally I stand behind any code I've written, but is it perfect? No. Perfection is an illusion, but I still strive for it with each project I do. Each project is also usually given a tight time line for completion, where I explain what is compromised in order to reach that point in that time frame. So where does the liability fall then and who can guage or say the level of any of this. This sounds like just another in an endless string, of ways people come up with to defer blame and make money from someone else's work. Coffee lap spilling is almost a profession these days.

    -Davey

  140. Code is a form of communication by fa2k · · Score: 1

    Code is not just meant to be run, it also communicates an idea. I just posted a script for benchmarking responsiveness. That may not have been a success, but it's an example of using code for communication. If I could be sued by someone if that created a security problem, I wouldn't post it. The analogy with food doesn't hold, because food doesn't convey any information (except for fortune cookies)

    1. Re:Code is a form of communication by fa2k · · Score: 1

      Sorry to change my mind again, but there's not even a need to invoke the "communication" argument. Plenty good reasons above. If you as the customer want the developer to have some kind of liability, write a contract.

  141. Sure, but... by juancn · · Score: 1

    if that happens, we'll become a LOT more expensive.

  142. Programmers... but not management? by whitroth · · Score: 1

    How many of those systems are as buggy as they are because
          a) upper management this program would make them a lot of money
          b) upper management decided that it *had* to be out by x date
          c) working its way down to the developers' manager, who didn't look for buy in, but told them when it would be done by
          d) management didn't want to "waste" money by hiring testers

    Then there's the developers' defense:
          a) what was turnover?
          b) what percentage of the development team had extensive experience?
          c) see b and d, above.

    Think all the very well paid lawyers would tell management that you can't use a EULA?

                    mark

  143. Should Developers Be Sued For Security Holes? by lsatenstein · · Score: 1

    I think that we forgot how things in software engineering should be done. Are there not steps that we have learned?

    a) Business Spec
    b) Functional Spec
    c) Technical Spec
    d) Risk Analysis
    e) Coding and testing
    f) Quality Control (of pre-production code)
    g) Legal (CYA)
    h) Marketing (somewhere around a.1)

    Code walkthoughs and testing must be done-- right?

    --
    Leslie Satenstein Montreal Quebec Canada
  144. How to fire an engineer by davidwr · · Score: 1

    Offices of Cheapskate Products, Incorporated:

    Boss: We need to cut costs or we'll have to cancel the project. Use cheaper steel.
    Engineer: I'll see what I can do.

    [Next day]
    Engineer: I looked for ways to reduce the cost of the project and still make it safe. Unless you can find a cheaper source for this grade of steel or a very cheap source for high-tech materials, we can't do the project on budget.
    Boss: Thank you.

    [The following day, at a team project meeting]:
    Boss: I'm sorry to tell you all this, but our budget got cut and despite our best engineering efforts we are unable to continue on this project. Unfortunately, this will mean layoffs.

    [One week later, in the unemployment office]
    Engineer: I'm here to apply for unemployment.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  145. should home-builders be sued for break ins? by Anonymous Coward · · Score: 0

    should home-builders be sued for break ins?

  146. Make them fix it. by Anonymous Coward · · Score: 0

    Removing all bugs is asking too much, but making the software company responsible for fixing the bug -- for free ---
    I think is reasonable.

  147. Yes! by Anonymous Coward · · Score: 0

    New insurance for software developers at a low, low rate of $100K per year!

  148. Let's treat the disease, not the symptom by Anonymous Coward · · Score: 0

    Alternately -- and my personal favorite variation on this -- let's make the managers individually liable for security holes rather than the developers. Then, suddenly, it's in the manager's best interest to extend the deadlines to allow thorough testing. It's now in the manager's best interest to select good developers and weed out the ones who code swiss cheese and spaghetti. Unlike today, when it's in the manager's best interest to get a barely-functional product shipped in the smallest amount of time so that they collect their end-of-year bonus before moving on to another project and washing their hands.

  149. Developers, no. Companies, no. MANAGERS, yes! by Anonymous Coward · · Score: 0

    The key line in your response is "Management thinks it looks ready? It's out the door and [developers] can't do anything to stop them." It's the managers who should be liable for the security holes, not the developers. It's the managers who made the decision to NOT test the code and thereby put their customers at risk, so it's the managers who should get raked over the coals for it.

    If you make the company liable, then what will happen is that companies will just assume settling such lawsuits as a cost of doing business, much like they do today. There will be some Department of Legal Muckery which sends an attorney to court and offers a few hundred grand to settle and the few hundred grand will get taken out of the development team's year-end bonus pool. Meanwhile the manager who decided to ship will be moved to another division as a reward for how quickly he got that product out the door, just as soon as he gets back from his two-week vacation in Bermuda. Nothing will get solved, developers will still get overruled on security (and other quality-related) matters, and the lawyers and insurance companies will reap all the profits.

    On the other hand, if you make the managers liable, then that manager is sure as hell not going to ship that product until he's damn sure it's secure. His ears will prick up when a developer says "but I think we need to test this more thoroughly," because his livelihood now depends on his developers' expertise. He's going to have a huge incentive to not just ship quality code, but understand code quality, because without understanding what makes code good or bad he can't make accurate management judgments. His boss isn't going to come to him and say "we need to ship by the end of the year," his boss will be saying "we need to test this code six ways from Sunday so I don't lose my yacht in court." (Or at least, if his boss does ask him to ship by the end of the year, he'll have the best possible reason to push back -- that boss's own liability.)

    TL;DR: If you want change, apply pressure to the people with the authority to make change, not to a faceless legal structure.

  150. A lot of overhead by HaZardman27 · · Score: 1

    From TFA, the analogy is made of a hamburger vendor being able to be sued for causing damages. There is a big difference here between a hamburger vendor on the corner and a software developer. For one, at least in the US there are some pretty specific regulations about how that hamburger vendor can prepare and serve food. If a hamburger makes you sick and the vendor was not following those regulations properly, that's when you can sue. To open up the ability to sue software developers for insecure software, we first would need specific regulations showing minimum security requirements of software.

    --
    Apparently wizard is not a legitimate career path, so I chose programmer instead.
  151. In the case of Microsoft... by Anonymous Coward · · Score: 0

    I think they should be forced to send out, via post (not just online), updates to everyone who has registered with them...

    Critical issues should be posted out immediately, but more benign tweaks could be included in a six monthly patch (along with the other accumulated patches, just in case).

    There'd be an instantaneous sharp uptake in their quality control procedures

  152. Which VPS provider? by tepples · · Score: 1

    Which VPS provider are you talking about, so that I can try it out and recommend it to others with the same problem? You don't give me a lot of keywords to go on.

    1. Re:Which VPS provider? by icebraining · · Score: 1

      Inception Hosting, but they only show the plan on this page: https://clients.inceptionhosting.com/cart.php?gid=9

      These are the US based ones, I got one based on the Netherlands since I'm in Europe.

  153. Should Developers Be Sued For Security Holes? by Anonymous Coward · · Score: 0

    Yes!

    Security is almost always an afterthought. It is time to professionalize programming. Require at least a BS along with real certifications(not the lame money makers we currently get from Oracle, MS, etc) from both individuals and companies.

    AKA jettison the self-trained and those that got C's in college.

  154. Side channel attacks by gay358 · · Score: 1

    In some small cases this is possible, but with large and complex programs it is typically infeasible to prove them verifiably correct.

    And even verifiably correct programs might be insecure. For example, program might leak sensitive information which can be measured with timing attacks, even if the computation itself is verifiably correct, can handle incorrect input etc. In some cases, timing attacks can absolutely destroy the security of the system.

  155. We have bugs by tepples · · Score: 1

    No, a mathematician's creativity is not a computation (in the mathematical sense) at all, since it may give incorrect answers

    All that means is the algorithm is flawed, not that it isn't computation.

    and yield different outputs when presented with the same input on different occasions

    The input to this algorithm includes all of the mathematician's life experiences prior to attempting the proof.

    Here's where I'm confused: Are you claiming or not claiming that the brain is capable of doing things that a computer cannot, that a computer inherently cannot simulate a brain? If so, on what basis do you make this claim?

    1. Re:We have bugs by metacell · · Score: 1

      Here's where I'm confused: Are you claiming or not claiming that the brain is capable of doing things that a computer cannot, that a computer inherently cannot simulate a brain? If so, on what basis do you make this claim?

      I'm not claiming that, since I have no idea if the brain is capable of doing things that computers can't.

      But both electronic computers and human brains can do things which aren't computable, such as generate output with an element of randomness. Lots of electronic computers have physical sources of randomness built-in, such as temperature and sound sensors.

      Now, you could argue that even apparently random physical phenomena are fundamentally computable, but this has little practical importance, since you'd need to simulate a large portion of the universe down to subatomic scales to include these phenomena. (It also implies non-locality in physics, per Bell's theorem).

      No, a mathematician's creativity is not a computation (in the mathematical sense) at all, since it may give incorrect answers

      All that means is the algorithm is flawed, not that it isn't computation.

      But then you're talking about the (hypothetical) algorithm which describes how a mind functions, right?

      I wasn't addressing the question of whether the human mind can be *described* by computations, only whether it *performs* computations. And it seems clear to me that it doesn't. A device needs to live up to some minimum requirements to be able to perform computations in the mathematical sense, such as unlimited storage, unlimited running time, and being able to perform a few basic operations flawlessly, such as choices and skips. Humans fail to meet these requirements, since their life span is limited, they make mistakes, and could even have limited memory capacity.

      If we allow some computations to yield errors, than arguments such as Gödel's incompleteness theorem and Turing's halting argument aren't applicable, and even ordinary mathematical algorithms can compute what's normally incomputable. But that's normally not allowed, since a device which computes X with errors, strictly speaking doesn't compute X at all.

  156. The linear bounded automaton by tepples · · Score: 1

    But both electronic computers and human brains can do things which aren't computable, such as generate output with an element of randomness.

    One way to model such randomness is that the random events are a function of the time at which a computation begins. It's commonly approximated by including a measurement of this time as part of the input and using that to seed a pseudorandom number generator.

    I wasn't addressing the question of whether the human mind can be *described* by computations, only whether it *performs* computations. And it seems clear to me that it doesn't.

    Any process that can be described by computations is incapable of performing anything more powerful than computation. Therefore, if the human mind can be described by computations, creativity is no more powerful than computation.

    A device needs to live up to some minimum requirements to be able to perform computations in the mathematical sense, such as unlimited storage

    Not necessarily. There exist models of computation that assume limited space and time, such as the linear bounded automaton. If you've ever seen me describe something as "LBA complete", I'm doing that to anticipate certain pedantic arguments and ward them off.

    1. Re:The linear bounded automaton by metacell · · Score: 1

      One way to model such randomness is that the random events are a function of the time at which a computation begins. It's commonly approximated by including a measurement of this time as part of the input and using that to seed a pseudorandom number generator.

      That means we've introduced an external source of randomness, since the time at which the computation begins is dependent on external physical processes. This means the model is not computable in the Turing sense.

      Any process that can be described by computations is incapable of performing anything more powerful than computation. Therefore, if the human mind can be described by computations, creativity is no more powerful than computation.

      Not more computationally powerful, no. But it's still more powerful at solving mathematical problems. To compute a solution to a mathematical problem, an algorithm is needed, but the creative mind can solve them without algorithms. Which is what happens every time someone solves a mathematical problem for the first time.

      In fact, ALL problem-solving using computation is dependent on a creative mind to first devise an algorithm for the solution.

      Simulating a human mind using computations doesn't help us either, because then we get the same risk for errors as with a real human, while taking much, much longer.

  157. you can already be sued for not delivering by gl4ss · · Score: 1

    since it's a breach of contract.

    it's just too bad that governments around the world usually never do it even if they get shafted paying 100 million dollars for something that was in the original contract a 10 million gig.

    --
    world was created 5 seconds before this post as it is.
  158. Effort tradeoff by tepples · · Score: 1

    There still exist problems that have, as of August 2012, resisted human creativity to solve. Even P=NP isn't solved yet. But to what extent is society willing to train mathematicians to prove individual theorems rather than developing techniques to expand the set of "particular programs" amenable to a computer-assisted proof?

  159. No by Anonymous Coward · · Score: 0

    Lets use Windows as an example -- it already has a terms of service saying basically that it's not suitable for anything, don't use it for anything important (and another specifically saying it cannot be used in nuclear control systems.) These types of clauses are fairly common. READ YOUR TERMS OF SERVICE if you are that concerned about it. Otherwise, you are literally getting what you paid for -- you did not pay for exceptional stability or security. It's far too expensive.

              There already ARE companies that produce certified reliable code, including liability if it turns out there are flaws. Those who hire them end up paying like 100s of dollars PER LINE OF CODE, and these guys DO NOT rush their code. (Flight control systems to name one.) There ARE companies that produce certified secure code, also including the liability (as far as I know). This software also is quite expensive.

              Of course, there's some very good open source software; nobody in their right mind is going to bring themselves liability for software they write for free. Again, in this case, you can pay a company such as Redhat if you want some company to have your back in case of problems.