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."
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?
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)?
Especially since purposely coding security vulnerabilities into your product can be a lucrative enterprise:
The Vulnerabilities Market and the Future of Security
If fact, criminal sanctions maybe needed in order to protect the public.
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
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.
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.
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)
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
turn into Jezebel blog?
I'd be satisfied if they were just hung up by their scrotums in Times Square.
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.
...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.
what was the outcome of that?
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
Microsoft will change their mind once they realize they can afford the insurance, and the open source developers can't.
Then answer the question.
Academics should be -- for not doing a good of teaching.
Can I sue my government for their corruption?
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.
Just adopt the PCI-DSS model:
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.
We're $200/hr now
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
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?
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.
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...
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"
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.
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)
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.
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.
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.
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
If enacted, I would think that the market for errors & omissions insurance would grow exponentially overnight.
And make as much as doctors and lawyers.
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.
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.
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.
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.
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.
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
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
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.
Of course they can sue. It is the same as suing car manufacturer for being a victim of somebody's wrong driving...
I'm pretty sure that if this happens, Windows will cost $4000, and Linux will actually be outright illegal to run.
suing the company that sells the Point Of Sale software, but not the developer(s).
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".
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...
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.
If this became law everyone would simply learn Haskell, thus eliminating all bugs overnight!
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.
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?
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?
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.
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.
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.
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...
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.
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.
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
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.)
the professors who teach computer science graduates who eventually develop the software...
Meanwhile, Adobe's lobbyists are preparing a formal application to have their Adobe Reader and other software excluded from such litigation.
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?
...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.
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.
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.
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?
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
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.
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
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.
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.
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.
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.
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.
The politicians solution to any problem: more laws and law suits. How's that working out?
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.
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?
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.
Seems fair; as long as we also get the death penalty for stupid users.
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
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.
should home-builders be sued for break ins?
Removing all bugs is asking too much, but making the software company responsible for fixing the bug -- for free ---
I think is reasonable.
New insurance for software developers at a low, low rate of $100K per year!
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.
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.
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.
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
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.
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.
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?
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.