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."
Simply requiring encryption when handling something sensitive like credit card info is a start. See: Sony and the PSN disaster.
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.
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.
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