Slashdot Mirror
Should Developers Be Sued For Security Holes?
An anonymous reader writes "A Cambridge academic is arguing for regulations that allow software users to sue developers when sloppy coding leaves holes for malware infection. European officials have considered introducing such a law but no binding regulations have been passed. Not everyone agrees that it's a good idea — Microsoft has previously argued against such a move by analogy, claiming a burglary victim wouldn't expect to be able to sue the manufacturer of the door or a window in their home."
I think excessively poor software should result in some form of negligence ... but general “can happen to anyone” type bugs.. no.
You can buy software with a (real) warrantee attached. In general this costs a fuck tonne of money because they are accepting a fair amount of liability. Even in a very horizontal market, the price increase for accepting that liability is going to be way more than anyone can afford.
You get what you pay for. Want software that is very secure and unlikely to have serious bugs.. you can get it.. but it’s gonna cost more than you are willing to pay if you don’t really _need_ that level of support.
Long answer: Noooooooooooooooooooooooooooo
If it was possible to prevent all security holes, this wouldn't be a bad idea. However, it is provably impossible to do so. This would just create a new inurance industry, profiting from others' mistakes. It would really only serve to cut down on development, especially from small companies and individuals that couldn't afford to make a single security mistake (or insurance against lawsuits).
What we need is more and richer lawyers and frightened software developers with malpractice costs bigger than doctors. Perhaps we can eventually make sure all code is only developed by giant corporations made up primarily of legal defense teams dedicated to patent exploitation and liability control with tiny development arms tagged on the end.
Interesting choice of words there!
There's no -1 for "I don't get it."
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.
You can not sue a door or window manufacturer for failure of your action (leaving the door / window open).
You should be able to successfully able to sue a door / window manufacturer for failing to provide the request product (i.e. seal the opening).
That then hits the ugly question of what is "reasonable". Did the manufacturer provide a reasonable product that provided the expected level of security?
If software development was an official engineering discipline that required P.Eng designation, then maybe this case would have more legs. Even then I'd be in disagreement. Otherwise, hell no, HELL NOOOOOOOOOOOO!!!!!!! That is definitely one way to drive people away from a career in software development. This actually seems like a sneaky way for management to evade culpability if their product harms a customer/user.
Sue the actual developer? How would you propose to do that if they're working for an incorporated company with limited liability?
Drill baby drill - on Mars
Sure, let's agree with Prof. Clayton that you should be able to sue developers for malpractice if their code contains security holes.
Then perhaps you should also be able to sue professors, like Richard Clayton for malpractice, if their students are undereducated, or if their papers contain flaws.
> 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.
You could consider suing developers that intentionally planted backdoors (even if was following NSA or other US government agency orders), but can't target the ones that by weren't aware of them, did by mistake, lack of knowledge or culture, or because things changed (i..e. having/forcing a 8 char password was "good enough" several years ago, not anymore), or even because taken assumptions no longer true by end user choice (how much portals meant for intranets with not specially strong security end being used on internet).
Also, who you sue because a bug in an open source program with a lot of contributes? or against a big corporation that put in legalese that they aren't responsible for any damage or problem that could happen for using it (that is most commercial software licenses)?
As long as you're going to foot the bill for a $500 application that changes your computer's wallpaper.
PEs and PLSs, doctors, psychologists, etc, all carry liability insurance. They're also not cheap. In the 80s, a survey crew cost $100/hr to come out and measure your land with a half-day minimum.
Now apply these costs to software.
--
BMO
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.
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
...blame the developer.
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.
If you're going to be adding accountability, be sure of the origin of the security weakness. If it originates in management, in outside requirements or in other ways is part of the contract - the developer shouldn't be held responsible.
Bugs and security vulns are almost unavoidable - but some are due to gross negligence. Gross negligence should always be open to litigation. To follow on from Microsoft's analogy, if a door manufacturer was grossly negligent (let's assume that the door includes the lock and hinges - when this isn't normally teh case), and sold a high security door system, but had accidentally keyed all the doors to a single grand-master key. Then if you were burgled because a burglar happened to find out about this grandmaster key, then potentially you have a claim.
I don't see why it shouldn't be too different in software development. A software vendor needs to bear some responsibilty for good programming practice.
Bad software is everywhere; some is so bad, that it does border on grossly negligent.
As an example, I recently reverse engineered an "electronic patient record" system that was installed at a local hospital. This had a number of interesting design features:
1. Password security was via encryption rather than hashing. The encryption was a home-brew modified Vigenere cipher.
2. The database connection string was stored in the clear in a conf file, stored in the user's home directory. Interesting the database connection used the "sa" user.
3. Presumably for performance reasons, certain database tables (notably "users") would be cached in plaintext to the user's home directory. This way, an SQL join could be avoided, and the joins could be done client side.
4. The software ran an auto-updater that would automatically connect to a specified web site and download and run patches as admin - without any kind of signature verification.
5. All SQL queries were dynamically generated strings - no parameters, prepared statements or stored procedure. Not every user input was properly escaped. Entry of a patient name with an apostrophe in it, would cause very peculiar behavior. In the end, regular memos had to go round to staff telling them under no circumstances to use apostrophes in patient names, and to avoid, wherever possible the use of apostrophes in the plain text entries.
This is by no means all the security problems this software had, never mind the bugs e.g. a race condition when synchronising with a second application which would result in the two components opening different patient's charts.
Amazingly, there weren't any security breaches or significant medical errors as a result of this software - but I can't really conclude that this software production was anything other than grossly negligent.
They aren't talking about suing the individual programmers, they're talking about suing the software companies. Specifically, they want to disallow this kind of language very common in EULAs (this is taken from an actual EULA, name omitted to protect the guilty):
_______ and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this product, including all implied warranties and conditions of merchantibility, fitness for a particular purpose, title and non-infringement. In no event shall _______ and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use of this software.
The translation of this clause out of legalese is "No matter what happens, you can't sue us, we're not responsible. We don't promise that this software is even remotely like what we advertised it to be."
I am officially gone from
Then answer the question.
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.
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.
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?
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.
That is all.
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.
Gee, I wonder why a company like Microsoft that writes perfect code would ever lobby against this...
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.
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?
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.
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.
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
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.
While OSS zealots like to think it is bug free, it isn't. Bugs can and do happen in OSS. Well who the hell is going to contribute to a free project if they know they can be sued for it?
Also it would lead to way less flexibility in software. Vendors would restrict what you could run and how you could run it. That is what you find in real high end systems where problems aren't ok. They are very expensive, they only do what they are designed to do, no installing arbitrary software, and upgrades are very slow in coming.
So long as you want your system to be the wild west where you can install whatever you like, use it in any way you like, and be nice and cheap then you have to accept that problems can and will happen. If you want verified design you can have that, however you need to be prepared to pay the price both in terms of money and in terms of restrictions.
Require liability from closed-source software. Exempt open-source. If you can access the source code, you have the capability to examine the security provided by the software if you so desire to. If you don't have access, you must rely on the assurances made by the company providing the software. If they say "it is secure! trust us..." and provide you no means to verify their claims and it turns out to be false, they should be held liable. You'd need to allow companies to send security fixes though that provide them some sort of protection like "If you don't install this patch within x days, we are not liable for the defects resolved by it"
Developers don't choose when to release software, it's management. Think you need to do more testing but management thinks it looks ready? It's out the door and you cant do anything to stop them. Testing is just as important as coding and the developers dont do all the testing, it's usually outsourced.
Bottom line: if a company doesn't do it's due diligence then yes, they should be responsible for putting out bad software.
Anons need not reply. Questions end with a question mark.
Sure this could be done, Professional Engineers put their asses on the line when they approve designs and Programmers could be held to the same level. This would most likely require devs to go through a similarly rigorous process of training and test taking.
This would also cause a massive drop in the number of available licensed programmers for any work that needs to be done, as well as having Programmers carrying liability insurance. This would cause development costs to get much larger. I seriously doubt half of the programmers in the country are close to prepared to pass any licensing tests.
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)
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.
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.
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.
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"?
editors:
before posting your troll article, look up Betteridge's Law, and realize that most of us here are aware of it.
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.
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.
You can't handle the truth.
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.
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.
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.
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.
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).
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.
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.
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
Of course they can sue. It is the same as suing car manufacturer for being a victim of somebody's wrong driving...
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?
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".
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.
"A Cambridge academic is arguing for regulations"
You don't say. An academic arguing for regulations.
I agree, it is long overdue in software development.
For those who say it's "too hard" etc, bollocks.
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.
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...
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.
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.
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.
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.
What difference do you see between particular and trivial in this case?
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)?
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.
the supplier could take the money and deliver nothing
What money? I thought we were talking about free software.
Is a JavaScript program source code or an executable?
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.
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.
Table-ized A.I.
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.
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.)
Meanwhile, Adobe's lobbyists are preparing a formal application to have their Adobe Reader and other software excluded from such litigation.
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.
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.
"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.'
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
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..
If they accept this, we just increase the rates.
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
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.
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
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
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
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.
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?
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.
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
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.
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.
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)
if that happens, we'll become a LOT more expensive.
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
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
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.
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.
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.
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.
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?
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.
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.
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?