Slashdot Mirror
Insecure Code - Vendors or Developers To Blame?
Annto Dev writes "Computer security expert, Bruce Schneier feels that vendors are to blame for 'lousy software'. From the article: 'They try to balance the costs of more-secure software--extra developers, fewer features, longer time to market--against the costs of insecure software: expense to patch, occasional bad press, potential loss of sales. The end result is that insecure software is common...' he said. Last week Howard Schmidt, the former White House cybersecurity adviser, argued at a seminar in London that programmers should be held responsible for flaws in code they write."
Great news for the E&O insurance industry! When programmers become liable for the mistakes (read: human nature) of their creations then everyone who codes for a living will have to consider buying insurance to hedge their risk, or find another form of work.
E&O is incredibly expensive. I looked into buying a policy when I started doing environmental work due to the possibility that I could be named a 'potentially responsible party' in an environmental enforcement action by the government. I side-stepped that need when I went to work for a large firm that could afford the E&O insurance. You can bet that cost was included in my chargeout rate.
That is what this effort will lead to for independent programmers. You will have the choice of buying E&O insurance, provided you qualify, and jacking your prices up to cover your costs, or you will have to work for a company that already has it. Hobby/free software enthusiasts are screwed.
I prefer the policy of 'caveat emptor'. If you install free software on your production machine without properly vetting it you are not only a fool but should bear all of the costs yourself.
"Rocky Rococo, at your cervix!"
Almost all other professions have to take responsibility for their work and constructs - why are programmers an exception?!
In my experience, its always time to market + cost that wins out. When a consumer buys a product, they don't [usually] choose a "Secure" product, they buy the cheapest one thats on the shelf.
I predict that Slashdot will have a headline next week that proclaims "Security flaws totally the fault of the end-user."
Vendors (more specifically, the product managers, sales types, etc.) are under pressure to get proudcts out the door to get sales and keep sharholders happy. That forces developers to limit the amount of time they spend writing quality software so that they can keep the PHB's happy. Net result, crappy insecure software.
BTW, this topic seems vaugely familiar. Is this a dupe?
This is my opinion. To make sure you don't steal it, it's covered by the DMCA.
"the former White House cybersecurity adviser, argued at a seminar in London that programmers should be held responsible for flaws in code they write."
OK. And to make it fair, let's let lawmakers be responsible for all the unintended consequences their legislation brings about.
The more you regulate a company, the worse its products become.
Let's see: do we hold employees at an auto factory responsible when unrealistic timetables means shoddy workmanship, or do we hold the employer who chooses speed to market over quality responsible? If that failure means the death of someone, do we sue the manufacturer or the guy who made the poor weld?
Large software companies have more in common with factories than they do with law firms or medical practices, two places where the liability *is* on the individual. The employees don't get to choose how much time is spent designing quality and security into the product, nor do they get to choose how much quality assurance is done on the back end (although that is a lesser solution to quality code, it is still necessary).
The day that every programmer is licensed the way that doctors and lawyers are is the day I will reassess this position, but for now programmers are *not* in the position to make the decisions that lead to quality code. I'm not convinced that licensing would ensure that, but without licensing coders are nothing more that code churners cranking to the beat of the employers drum.
Sig under construction since 1998.
Having been involved in software development I can confirm that most companies are more concerned about cost than the security of their code.
They would rather get the product out there quickly in order to produce revenue rather than hire more and better developers
to secure the code.
It is very sad....
I'd be glad to take responsibilty for any code I write just as soon as they're willling to pay my new, updated fees. If it's really *that* important shouldn't the client be equally if not more concerned with cost as getting it done right?
"...we dont care about the economics; we just want to be able to hack great stuff."
Too bad you have to click through the EULA before you can test it, suckers!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Howard Schimidt has probably never written a single line of code in his life. Fixing software does not require attorneys. It requires better education for developers.
What do you want Mr. Schmidt? A team of attorneys in each cubicle? Do you want programmers afraid to write new features for fear of being named in a a lawsuit if the code is buggy? Do you think trial attorneys do not have enough money as it is suing people over slip-and-fall cases in grocery stores.
Please stop your complaining until you show you actually know what you're talking about.
Last week Howard Schmidt, the former White House cybersecurity adviser, argued at a seminar in London that programmers should be held responsible for flaws in code they write."
And why not make the folks in Homeland Security responsible for the flaws in the infrastructure? At a recent congressional hearing for the FEMA folks, a congresswoman asked whether the folks at FEMA should be prosecuted for negligent homicide. She pointed out that a bus driver was being prosecuted. Perhaps it made sense to go farther up the chain.
Seriously, it's hard to hang individual coders for the same reason it's hard to hang cybersecurity advisors. Most coders work in teams and failures are often systemic. They're literally no one's fault. Well, perhaps the fault of the person who designed the system. But I can tell you that it's very hard if not impossible to anticipate everything that can go wrong.
Vendors should love open source in this case, nice and cheap (usually) well developed. There's a case for making propriatory software developers liable - we trust they have checked the code - but you can check the code of OSS so if you want to sue the developer you should have checked the code. How can you be sure a product's ok if you can only see the results it produces.
Any grammatical or spelling errors above are for comic effect, and do not signify imperfection in the writer.
Users are to blame for putting up with crap and buying insecure software.
- "White House cybersecurity adviser, argued at a seminar in London that programmers should be held responsible for flaws in code they write
"The problem with that is when an employee writes code for a company, it becomes the companies' code, so it would follow that any litigation should fall on the company, and not the programmer. I would also argue that the programmer doesn't release the software, that's up to the company which *should* have testing and QA measures in place to find bugs and insecurity.fak3r.com
Next you'll be claiming that bad movies are the fault of the people making them, or that it's Britney Spears' fault she sounds like a howler monkey being run over by a bus.
Sheesh. Scientologists...
I'm sick and tired of hearing talk about holding vendors or developers legally responsible for writing insecure code. It's impossible to write any complex application and not have security problems.
The software industry operates more like the automobile industry: they know their cars will have problems, so they freely fix those problems for the warranty period. Software's warranty period is as long as the vendor or developer say they'll support that software.
The major difference is with closed source software, after the "warrany" period is up you can't usually pay someone to fix the problems. Open source provides a great car analogy, because after, say, Red Hat stops supporting your OS you can still fix it yourself or hire a developer to fix it for you.
This is why nobody would buy a car with the hood welded shut. For the life of me I can't figure out why anybody would buy software with the "hood" welded shut.
The global economy is a great thing until you feel it locally.
I always try to reassure my code that it matters and that people love it in spite of its flaws. That usually helps to reduce my insecurities. So I try to show the same kindess to my code. ...as far as unsecure code.... ...uuuuh...
Is that developers are looking to make a profit because that is what it comes down to when you do cost vs. benefit analysis... Its like when factories were required to put giant filters in place to help cut down on pollution and if they didnt they were find $1000 dollars... Well if it costs a million dollars to implement the pollution solution (yes that rhymes) then cost vs. benefit for a profit margin was simple for them (although the environment suffered...) Should there be penalties for bad security practices when developing code... IMO yes, but even with those penalties it still might not make a difference depending on what those penalties are...
News Reporters Make Tasty Polar Bear Treats!
I don't know anything about what causes buggy software, but years of training by the press, television, and movies have meticulously prepared my brain to accept the oversimplifying fiction that it must be one of them and not the other.
Shop as usual. And avoid panic buying.
In case you want to give their fight song a listen, here it is - I Go Chop Your Dollar: http://www.tlcafrica.com/I_go_chop_your_dollar1.mo v
Stephanie says / she wants to know / why she's given half her life to / people she hates now.
reminds me of an article about making politcal candidates responsible for any illegal action their constituents perform (eg a supporter makes ballots, you get in trouble), kinda makes running for office less appealing
That can only increase the move to outsourcing software. If the companies who put out shoddy software because refuse to implement any kind of internal controls aren't held accountable and US programmers become even more expensive, guess who gets the work and then who ya gonna sue? Somebody in china who makes $37 a day? right...
Put the burden of liability on the real reason buggy software gets shipped. Hint, it's not the developers 9 times out of 10.
Using the best knowledge of today to create the problems of tomorrow.
So I think everyone is financially to blame, other than my client of course.
If someone says he and his monkey have nothing to hide, they almost certainly do.
We've long recognised that different computer systems need different levels of security and stability: real-time systems running Boeing auto-pilots don't need firewalls (at least, I assume they're not networked!) but do need high reliability and stability. Headlines like Nuclear power station brought down by Slammer worm shouldn't happen - and when it does someone needs to take responsibility.
However, the cost of developing a super-stable system is massive; whilst absolving all risk (as most EULAs do) is akin to passing the buck, liability for flaws needs to be allocated reasonably.
This all seems to be a rehash of the "worse is better" meme ... that those damn software programers/companies aren't doing what we want. The only problem is, it's all crack. Almost no customers, even now, are willing to pay more for "quality".
Yes, I think all other things being equal, people will go towards quality/security ... but it just isn't high on anyones list. Cheap, features, usable ... and maybe quality comes in fourth, maybe.
And, yes, there are exceptions ... NASA JPL obviously spend huge amounts of money to get quality at the expense of everything else, and I say this having written my own webserver because apache-httpd had too many bugs (which comes with a security guarantee against remote attacks) ... but I'm not expecting people to migrate in droves from apache-httpd, it's got more features. The 90%+ market share have spoken, consistently, and they just don't care about the same things Bruce and I do.
I have a lot of respect for Bruce, but the companies really are just producing what most people want ... so stop blaming them.
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
Howard Schmidt can suck my left nut while I take a shit!
So you think making level 5 DFD's and showing the clients is good for business? Did it help in securing the network enabled parts to be any safer? NOPE!
.NET here, MSSQL there, J2EE over there...
People are now coming UP from security by obscurity. This means that they're becoming security conscious. 2002-2005 witnessed the rise of spyware and spyware awareness together. Even MS, Symantec and McAfee call it a legitimate threat.
With the customers and users becoming more security conscious and aware, both developers and vendors turn a blind eye. So you think making level 5 DFD's and showing the clients is good for business? Did it help in securing the network enabled parts to be any safer? NOPE!
People are now coming UP from security by obscurity. This means that they're becoming security conscious. 2002-2005 witnessed the rise of spyware and spyware awareness together. Even MS, Symantec and McAfee call it a legitimate threat.
With the cusSo you think making level 5 DFD's and showing the clients is good for business? Did it help in securing the network enabled parts to be any safer? NOPE!
People are now coming UP from security by obscurity. This means that they're becoming security conscious. 2002-2005 witnessed the rise of spyware and spyware awareness together. Even MS, Symantec and McAfee call it a legitimate threat.
With the cus what was the last time someone actually TRIED to foolproof his code? Even if it was a bittorrent client...
NO developers pay ANY attention to this aspect, whether while coding, or while designing, or even when learning. (I can crash 100% of all programs created inside my univ. by first to third year students, within an hour... TC++ on DOS)
Vendors on the other hand, it has been correctly mentioned, that pay no attention to code security, stability, testing...
Result? Crappy code that dies on you.
Let's get Micro$oft bashing on..
It's partly the fault of compiler vendors like MS and borland too... NO tools are popularised to enhance stability, efficiency or security... It's ALWAYS new features this, connectivity that,
I predict that Slashdot will have a headline next week that proclaims "Security flaws totally the fault of the end-user."
/sarcasm
Why re-state the obvious?
The theory of relativity doesn't work right in Arkansas.
Security flaws and bugs are the same thing from different angles. Both are functionality that was not intended, both come from the same cause (programming error/oversight), and both can be reduced through the same means: intelligent modularization, testing, and review.
The problem is that security has been far less modular than general design. Why is it a running application has the entire rights of the logged in user? Why can it access the internet (without software firewall), read/write any file, or do anything I as a user can do?
It shouldn't. It's as simple as that. It's like running a bank with a big thick wall to get in, with strict credential checks and armed guards, and meanwhile you expect the customer to conduct all of his business as he pleases and honestly once he's inside. (ooohh.. I'll just take a few thousand dollars and write down that I withdrew that much!)
Then you hold the customer responsible when he accidently screws up? That's insane. The problem when a particular server has a security flaw in it is that it can expose the entire machine: instead, it ought to expose _only_ the functionality the server needs to run.
But this also applies to -all- applications. A security hole in your webbrowser? Well, why the hell can your webbrowser run random commands on your machine without your permission?
As far as I'm concerned, the entire running model for OSes is going to be dramatically different in another few decades. When a program wants to open a new file, up will pop an -operating-system- file open -- requesting whether you, the user, would like to the application to read (or maybe write?) a file. When it wants to communicate over the IO, the OS will prompt you to allow it or not.
Mark
There are laws that say that the employer assumes the liability for the employees -- unless the employee is acting so bad (e.g. going out of his way to kill someone) that you then say the employee is acting badly. This is why, for example, Domino's contracts with drivers to provide pizza delivery services: Domino's doesn't want the liability for auto accidents. I guess the law could be changed, but that's basically how it goes now. I don't see how it could go any other way: e.g. Billy Gates tells you to ship, or you are fired. You then say, "But Billy, there's 10,000 bugs in windows -- people will suffer damages if we ship now?" Or do you say, "yes master, slink away and ship what you know is a bunch of crap?"
http://www.thebricktestament.com/the_law/when_to_
I agree and dis-agree on this. If a software creator is working on his/her own with no one else making the decisions, then that person is responsible for the code that is generated. On the other hand, a programmer in a cubicle farm is not responsible be he/she is doing what they are told, and they have people doing code reviews so the ultimate responsibly falls on the shoulders of the project manager.
In other words, it's always the boss's fault.
This is just my $0.02 worth...
The real article by Bruce Schnier is in Wired:
. html
http://www.wired.com/news/privacy/0,1848,69247,00
Its more interesting than the sound-bite-full ZD-Net summary.
-dZ.
Carol vs. Ghost
I'm a developer and errors/holes in my code are my fault. Some, could in theory be the fault of the framework I use, but typically, its mine.
People really over complicate this topic. Nobody is perfect, and people make mistakes. It really doesn't matter what excuse I use (deadlines, bad company decisions, whatever) if its code I wrote, its my fault. Even if I identified the hole and my boss told me to skip it, I still published flawed code. If I was perfect, it would be bullet proof from the get go, and if my team was perfect the same would apply. My boss would never have to tell me to ignore the error/hole, because my UML model was flawless, and my execution of it was flawless.
I think this topic comes up because of one of two things; developers passing the buck, or blogger/writers trying to get some press. The fault is obvious, the solution however is far more difficult, and since humans will create the solutions, chances are it will be flawed too, and the cycle repeats...
The link in the post goes to a LA Times summary of the article. The real article is at Wired.
Media that can be recorded and distributed can be recorded and distributed.
-kfg
For most applications, it should be "caveat emptor" unless the vendor DELIBERATELY "put in" a back door or knowingly or recklessly made promises that weren't true. If you pay $99 for a multi-MLOC piece of code and someone finds a security bug after it's shipped, my first inclination is to say "too bad, let the market punish the vendor not the courts."
In almost all remaining cases, it should be the vendor who is responsible, not the developer.
The only time a developer should be responsible is if he's a corporate officer or licensed by the state. Licenses should be required only for "life and death" software like flight-control software, MRI machines, and other things that can kill someone if there is a bug. In those cases, the entire unit - the entire MRI machine - should be "approved" by a licensed professional.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
damnit
:(
stupid clipboard... sticky keys.
I'm really sorry...
WHY can't we edit our own comments, BTW?
Sorry: I screwed up my formatting and punctuation. Here it is again, this time with feeling.
There are laws that say that the employer assumes the liability for the employees -- unless the employee is acting so bad (e.g. going out of his way to kill someone) that you then say the employee is acting badly.
This is why, for example, Domino's contracts with drivers to provide pizza delivery services: Domino's doesn't want the liability for auto accidents.
I guess the law could be changed, but that's basically how it goes now. I don't see how it could go any other way: e.g. Billy Gates tells you to ship Windows Clusterfuck Edition now, or you are fired.
You then say, "But Billy, there's 10,000 bugs in Windows CFE -- people will suffer damages if we ship now?" Or do you say, "Yes master," slink away and ship what you know is a bunch of crap.
http://www.thebricktestament.com/the_law/when_to_
I have a minor child who is too young to enter into a contract install all my software for me. I click no EULAs.
Clickthrough EULAs aren't worth diddlyshit. There is no way of proving WHO clicked through.
A real EULA is a signed document like they used to have in the cave man days when a "computer" was a three story tall pocket calculator and its programs cost hundreds of thousands of dollars.
The only thing dumber than a EULA is anybody thinking they can ever be enforced. Which is why one has never been in court - the prople who write them know they'd be laughed out of court if they ever tried to sue.
(mind reading capcha="paranoid"... good work guys)
For some reason I remember reading this on a different site a few weeks ago. Bad Slashdot repeating repeated news! Bad!
It's never just a game when you're winning. - George Carlin
I don't code, but I don't think making developers responsible for faulty code is a good solution.
If I develop X for a company that then takes X to market, and X turns out to be faulty, company should be at fault. I am at fault for writing shoddy code, the effect of which will be that I get fewer future contracts or employment to do the same. Company is at fault for taking X to market, and as such should be resonsible for any liability due to X's shortcomings.
GM is responsible for a shoddy part on one of its vehicles, not the engineer that developed the part.
Sole proprietors who take their code to market should be responsible, but in that instance, the sole proprietor is both developer and vendor.
un burrito me trampeó.
A good start to our current security problem would be to stop writing internet based software in languages that allow buffer overflows to occur (e.g. C, C++). 90% of security exploits are caused by buffer overflows. I've seen a figure like this in research papers, but it should be obvious to anyone from reading patch descriptions and current security alters. Writing computer programs in these types of languages and patching the errors as they are found is simply not a scalable solution. It essentially means that if you write a program to be used on a network, you have to maintain and patch it forever because you'll never catch all the buffer overflows it contains (e.g. the zlib bug, not a particular large library and it has been around for a long time). Picking a tool that doesn't even allow these types of errors is the obvious solution. In addition, we need to start using more granular security permissions for our programs. Blaming security problems solely on users is ridiculous. Could you explain to me why a program downloaded from the internet has read and write access to every file on my computer? Why it can open up network connections? Having root users is a start, but we need to be able to sandbox all the applications we download so they just aren't allowed to do anything bad. I see no reason why a user shouldn't be able to download and run any program they find, as they should all be sandboxed appropriately that they cannot cause damage.
If people really cared about security, MS would have been driven out of business a long time ago, and other vendors would have taken note of that and made sure the same thing didn't happen to them. We would have more secure, less featureful, less convenient, more expensive software. But people don't care that much, so that didn't happen.
Don't drop the soap, Tommy!
Now why didn't I see that one coming?
"Rocky Rococo, at your cervix!"
As a programmer, I'll accept liability for bugs in the code... the day I get the same protection that a professional engineer gets: if I say I need X for the program to be properly designed/written/tested, any manager or executive or marketer who says otherwise can be thrown in jail. No mere job protection, no civil remedies, jail time for anyone who tries to overrule me, same as would happen to a manager who overruled the structural engineer's specification of the grades of concrete and steel to be used in a building.
Responsibility and authority go hand in hand. If they want to hand the the responsibility, they give me the authority to go with it. If, OTOH, they don't want to give me the authority, then they can shoulder the responsibility.
You can make a case for this without worrying about impinging on the right to make free software. Peopleware really isn't worth the thousands of dollars it runs you. Solomon Accounting isn't worth the $100K it costs for a companywide install, Great Plains and larger packages like Deltek's Costpoint (actual install cost: $450K) are no better.
They have weak or no APIs, the built-in tools aren't able to perform the most basic tasks the users want, and the customized workaround take as much work as rewriting the software.
I think the guy from the article has a point, as there are many businesses that spend many times any of our salaries running commercial software, and the people involved in the purchase have no idea they're throwing bad money at subpar products. I'm not sure he's talking about something relevant to most slashdotters: even those of us who work in IT don't really get to pick the accounting software people use, the CFOs pretty much run what they know and we have to build accounting their own network around that package.
-jpowers
Who do you trust more?
... noted security expert or political hack, ... noted security expert of political hack?
Noted security expert or political hack,
It's not even close. On the credibility front Schneier has hundreds - no, thousands - of times more credibility on this issue than a political appoiontee out of the White House. Actually it's infinitely more credibility because anything times zero is zero where the White House is concerned.
So you think making level 5 DFD's and showing the clients is good for business? Did it help in securing the network enabled parts to be any safer? NOPE!
.NET here, MSSQL there, J2EE over there...
People are now coming UP from security by obscurity. This means that they're becoming security conscious. 2002-2005 witnessed the rise of spyware and spyware awareness together. Even MS, Symantec and McAfee call it a legitimate threat.
With the customers and users becoming more security conscious and aware, both developers and vendors turn a blind eye.
what was the last time someone actually TRIED to foolproof his code? Even if it was a bittorrent client...
NO developers pay ANY attention to this aspect, whether while coding, or while designing, or even when learning. (I can crash 100% of all programs created inside my univ. by first to third year students, within an hour... TC++ on DOS)
Vendors on the other hand, it has been correctly mentioned, that pay no attention to code security, stability, testing...
Result? Crappy code that dies on you.
Let's get Micro$oft bashing on..
It's partly the fault of compiler vendors like MS and borland too... NO tools are popularised to enhance stability, efficiency or security... It's ALWAYS new features this, connectivity that,
Modern software development relies on an ever-expanding list of external factors. Case in point, our application ran perfectly fine until one day, it started crashing. The errors gave us no clue to the problem. As far as we could tell, the software was fine. Our software ran on top of a J2EE server, which runs on top of a JVM, which runs on top of an OS, which runs on top of hardware. It relies on database drivers, which connect over a network, which run against a database, which itself relies on the os, which runs on hardware. The J2EE server, of course, relies on the web server, and the driver to make the two work together. They all rely on the firewall for security, and the crypto flavor-of-the-year for HTTPS security.
All of these pieces can be culprits in the issue, but only one of those is in your direct control, that being your source code.
In the end, a MS patch against the OS caused issues in the JVM which caused issues in the J2EE server, causing our JDBC connections to lock up and fail. To find that we had to check every piece mentioned above. Swapping out to another JVM fixed the issue, but was risky because the source, which we purchased from a third party, was not qualified to run on the newer JVM.
Now imagine unwinding all of that in court. Who's fault is it? MS is just patching their OS. Sun can't be held liable for a bug in a JVM that's no longer being maintained, and was not certified to run on the newer OS patches, the J2EE server can't be upgraded because the app isn't built to run on it.
The fact of the matter is that you can't hold the engineer who designed the break pads responsible for a crash if the driver can switch out the engine, transmission, wheels, tires, diffs, etc., and can drive past the limits of the design of the automobile.
Ideas like holding software developers or development companies accountable will lead to far less software development, more expensive software, with very hard vendor-imposed limitations, like "by agreeing to this EULA you agree to run this software on a dedicated, vendor-approved machine, with the os of our choosing, and you may not patch the os or hardware drivers unless it is cleared by us."
No way. I'll take what we have.
I am still in college for CS, so I'm not really in the loop enough to know about the real-world application of programming, but I am split on this subject. Is it the developers fault bugs are in code? Yeah. But could it be helped? Probably not. The nature of programming alone makes it seem that almost everyone probably misses a few bugs (that are probably caught during testing before the product goes gold), since people do not work like computers. And from what I've heard, the time constraints for many projects probably don't allow for debugging and testing as much as they should. Hard set deadlines in large projects seem like a rough thing to work with since you never know how programming is going to go, and in crunch time, proper debugging seems like it would be the easiest part to skimp on to meet the deadline.
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
While security should be a focus and currently is not, it is not the programmers fault for the screw ups.
I saw one post mention that everyone else is responsible for their actions...Try making a computer run with lines of text...Programming is a bit different that lines of
[code]
Computer: go to internet
Computer: go to slashdot.com
[/code]
People don't understand what programming is like. While some people like it, have a knack for it, etc it is difficult to catch every possible problem.
Take an application, a mid-large sized application, that is like 50+/- thousand lines of code and really tell me that you can debug the entire thing in a timely way? It does become very cost-inefficient.
Now, I do agree that security should be a focus of software development companies but look from all sides. Security should be a huge concern of companies and it should be the companies responsibility to provide the resources for security efforts. NOT the programmer.
As the first post mentioned, if you start requiring programmers to hedge liabilities you will see many programmers drop from the field due to the cost alone and you will find that your rants about security will escalate due to the lack of good programmers...
Most contracts result in the company owning all of the intellectual property. If the programmer can't own their work, then the owner should be responsible for it.
Besides, it is a company's responsibility to sell good products. If they sell a product that is defective, it is often because they didn't do sufficient Q&A on the product, or rushed it to market.
Bottom line is that if a car maker sells a car with a defective part (the tires lugs were defective), and it passes shoddy Q&A, it is the maker's fault, not the assembly line guy. If it doesn't pass Q&A, you can be sure Ford won't sell it -- but the same doesn't seem true of software.
I see no reason why a user shouldn't be able to download and run any program they find, as they should all be sandboxed appropriately that they cannot cause damage.
Sure, it may be a good start to remove some of the bugs, but who writes the sandbox? In what language? Is the sandbox itself sandboxed, to prevent being comprimised? If so, who writes that sandbox? In what language? Is that sandbox itself sandboxed, to prevent being comprimised? If so...
It's not an "obvious solution." It's an "obvious time-saver" when it comes to having to check for bugs.
Could you explain to me why a program downloaded from the internet has read and write access to every file on my computer?
I think that has more to say about your choice of operating system rather than the program itself.
It essentially means that if you write a program to be used on a network, you have to maintain and patch it forever because you'll never catch all the buffer overflows it contains.
I think you mean:
It essentially means that if you write a program to be used on a network, you have to maintain and patch it forever because you'll never catch all the programming errors, incorrect assumptions, and random unexpected behaviour introduced through unforseen run-time activity it contains.
Not only is this exactly the correct solution to this problem, it also illustrates why anyone who calls themself a "Software Engineer" is full of it!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Although it may vary from shop to shop, where I am currently follows a pretty standard model:
There is a major misconception that a Developer is the "one stop" source for software, where that is rarely the case. Even when some of the first steps are handled by a single person (usually when the Developer is a Lead or a Programmer Analyst, in title) the process entails more than just a single person.
It is only a matter of time, if it hasn't happened already, that insurance companies start selling liability insurance to Developers, just like they sell Malpractice insurance to Doctors. There are companies out there that will claim the "collective effort" when the profits roll in, but will hang a developer out to dry when something goes wrong. Thankfully, I left that job for the one I am at now. ;-)
You are in a maze of little twisting passages, all different.
Although you're right about the nature of the problem, the welded hood analogy doesn't fit.
... but they can with leasing. (take the EV1)
Automobiles typically need 'preventive maintenance' (PM) performed on them, such as changing filters, belts, and other mechanical systems that need to be replaced due to use and wear. The closest analogy to this in computers is defragging the hard drive, and maybe the occassional disk replacement or vaccuming out the dust.
Automobile manufacturers have done the closest thing they can to allow you to do the PM, without being able to diagnose the big problems on your own, through the use of computerized transmissions. ODB-II scanners have come down in price, but it's still not something that the average car owner might have.
Software warrenties are also not like the automotive warrenties, in that the EULA states that you can't sue them, whereas automotive companies can't pull that crap. Although they occassionally do recalls where they don't notify customers (just if you drop it off at a dealer for something else, they'll fix it), they occassionally have things so bad, that they know they'll get sued, and it's cheaper to fix everything, than to deal with the losses in court.
Software licenses, however, can be written in such a way, that if the customer complains too much, the vendor might have reason to revoke the license. (although, that would be bad press, and might result in a lawsuit, but a good EULA will ensure that the vendor wins the lawsuit). Automobile vendors can't do that will sales
Build it, and they will come^Hplain.
well put,
Howard Schmidt is a guy who has worked in the software industry, but it not really a geek, he is a BIG SUIT or a PHB. I highly doubt he has ever programmed in his life. Unfortunately, ppl in the big seats would think , hey this guy has worked in the software industry, he knows what he is talking about. I hope ppl ignore this dumbass and just move on.
Doing something like this will also hinder the Open Source process. Software will get more expensive and we can see a whole bunch of crap going on.
If you're an engineer practicing on behalf of a single company, you're entitled to an "industrial exemption," at least in the state laws I've read. EEs working for Motorola don't need to be a PE. The company takes the liability, not the engineer. Businesses actively make a decision to place time to market over correctness, over "security." Forcing liability on people engaged in development is stupid and causes inevitable friction between the developer and the business who's hired him and ten others. If you don't agree that the software is secure... well, if you're lucky you'll be transferred to another department. The only thing that personal liability solves is how to enact liability without killing off companies immediately. This way, they'll last for five years before nobody wants to work in the field.
Furthermore, what happens when a company simply decides to ship a product against your will? Without the power to approve or disapprove a product, liability is a win-lose situation that never flips.
I Browse at +4 Flamebait
Open Source Sysadmin
in differnt ways.
If a developer produces shotty code, then they can be reprimanded and ultimately fired f their is a clear sign of shotty work and an inability on the part of the developer to improve.
If the vendor deploys shotty code, then they can be sued if it causes some sort of damages to the customer. It's the vendors responsibility to ensure the software works fine before it goes out to the customer, and that involves having the right processes in place for quality testing, that are usually dedicated to a group of workers that specifically do testing. If they fail on this, then they can only blame the developer for creating the bug, but not for the fact that it wasn't properly tested and that it was deployed.
Developers do not have the time to fully stress test software to a variety of tests. If developers are held to full liability, then they will spend 50% of their time coding, and 50% of their time testing and finding bugs, ultimately causing production to drop by half (this is an estimate).
Lousy code is caused by several factors:
1. unrealistic promises of dates by managers eager to please their superiors
2. uninformed or untrained programmers
3. constant interruption of programmers due to constantly shifting priorities
Good code takes knowledge, concentration, and careful, methodical, uninterrupted work. If the work is hurried or the programmer sucks, or they get constantly interrupted, the work is not done carefully. This leads to security issues.
2 of these 3 factors are outside the control of the programmer. He is an employee that does what he is told, if he wants to keep his job. If the people telling him what to do, don't understand that you can't do a 3 month job in 2 weeks, but the programmer is forced to do it anyway, bugs be damned, the result is less than optimal 100% of the time.
Business people and their childish demanding attitudes are the ones that are most often responsible for bad code, not the programmer. He's just doing what he's told, and getting it done in the time allotted. Usually, whether or not it's perfect, is irrelevant as long he delivers *something*.
I know this because I get subjected to it daily. We have a 6 month project due on Jan 1st, and the business still hasn't signed off on the requirements, well actually they just did yesterday. Now the coding can begin. We now have 2.5 months to get the 6 month job done, "or else".
Typical... If this "programmers are held legally responsible" crap kicks in, I am finding a new line of work, unless people let me do my freaking job, the right way.
l8,
AC
Yeah, cynical don't even begin to cover it...
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Yes, software has bugs and mistakes and errors, and in a large project it can become infeasible to guarantee that there aren't issues somewhere. That doesn't mean, however, that software should simply ignore the issue. It's a matter of contracts and assurance: It is possible to make certain assurances about a piece of software and spend the time making sure it fulfills those properties. For instance, while you might not go to the trouble of ensuring a word processor is completely bug free, it may be worth providing assurances, for instance, that files cannot be corrupted when the program crashes, and that the print preview is exactly what will be printed. There are methods for proving and verifying such properties, and if you restrict it to key properties that the client wants formal assurance on then it is not significant extra work to use those methods.
The same principle applies to security. While you may not be able to say your system in completely invulnerable without expending enourmous amounts of time and money, you can make certain formal assurances like "no buffer overflow exploits exist in this software" or "the software will always fully and correctly carry security protocol X, or abort with an error and deny access". Such things don't ensure 100% security, but being able to formally make such assurances does significantly improve the expected security of the software.
For some reason software has gotten stuck in an "all or nothing" mentality, claiming that obviously you can't ensure perfection, therefore you should assume nothing, and make no assurances at all. That is neither necessary, nor productive. Being able to formally guarantee certain properties of software is both possible, and only as much extra work as the amount of assurance you choose to provide.
Jedidiah.
Craft Beer Programming T-shirts
The parent poster is correct in that this would destroy hobbyist programming, at least in the US.
I'm wondering if the GPL 3 should include a clause to protect against this kind of lawsuit as well as patent lawsuits.
-- Knowledge shared is power lost. -- Aleister Crowley
Liability isn't viable in uncontrolled environments which means any normal desktop.
The mistake everyone seems to be making is that liability doesn't exist in the industry. It most certainly does and always comes with strict terms for approved usage that defines the operating enviroment and prohibits any installation without vendor approval.
If Dominoes tells them to drive a certain route or to get there in a certain time, OR GIVES THEM INCENTIVES TO DO EITHER then if there's a wreck Dominoes WILL be dragged into the lawsuit.
Back in the old days, Dominoes had a 30-minute-or-free guarentee. I don't know if their drivers were contractors or employees at the time but there was a wreck, someone sued, and Dominoes canned their guarentee.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I'm sick and tired of hearing talk about holding vendors or developers legally responsible for writing insecure code. It's impossible to write any complex application and not have security problems.
Software is unreliable because we have been doing it essentially the same way for 150 years without stopping to think that there might be a better way. We've been writing algorithms ever since Lady Ada Lovelace penned down the first table of intructions for a digital computer. It's time we reevaluate the algorithmic model. Switch to a non-algorithmic, signal-based, synchronous software model and the problem will disappear. Until then, we can't hold either vendors or programmers liable. Didn't Fred Brooks show that algorithmic code is essentially unreliable? See link below for more info on non-algorithmic programming.
If liability is passed on to the individual developer, then it remains an externality -- and therefore a non-issue -- as far as the company is concerned. The company doesn't give a damn about your liability: management and marketing will continue to insist on ridiculous schedules and feature sets, because it doesn't effect them. The only way that might change is for the liability to rest with the company (or, as another poster mentioned, for software engineers to be given the same legal protections as other professional engineers, including jail time for managers who overrule their engineering decisions).
Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?
They have TIME to do the tests and have made a conscious decision on what constitutes acceptable failure tolerances.
NOBODY expects a car tire to perform acceptably under the load of a 747 suddenly going down on it so it suddenly accelerates to 120 miles per hour.
No industry is subjected to performing perfectly each and every time with untested configurations of their components. Testing COSTS.
Basically, its the attitude that permitted the rise of Microsoft that is at fault here, and this attitude came from the same people who demand 99.9999% up time, and a recovery plan, from their mainframes.
Get real people.
PCs and anything hooked up to them, are NOT designed to deal with the loads they are often subjected to. We design systems to fail gracefully under known tolerances.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
If an individual or a company produces software, and they are liable for any damages the software causes, what do you think is going to happen?
End users may end up in a situation where they either...
a) sign an agreement whereby they accept liability themselves, getting the product at a reasonable price - or free of charge.
or
b) pay the vendor an exhorbitant fee for some form of software insurance - which would be necessary to cover costs should the company have to recompense for damages.
Linux/Open Source/Anti Microsoft News
There are 2 kinds of issues:
1) Designed Issues. These are just plain sloppy design. But is there a way to mitigate this? Yes, with more extenstive and proven frameworks. Still designer lack-of-talent can still doom and app. These can generally be easily fixed because they are at a high enough level.
2) The harder problems come from the toolkits. This could be due to GLIBC or other"low level" libraries(LLL). I define a LLL as any toolkit which requires and permits you to manage memory implementation directly on a byte-basis. (C, C++, ASM.) Where as the high level libraries (HLL) are object oriented like Java, Python, PHP and not allow someone to mange memory directly.
PROPOSAL:
Ideally, we should be able to substitude out a library with one of a completely different internal operation (i.e. vector strings rather than byte arrays, python dictionaries (or C implementations thereof) instead of C structs) recompile and test. Only when it works under all possible libriaries do we know that the only issues that remain are design errors.
The added advantage to replacing the underlying toolkits is that when an application is distributed, you can ensure that not all instances will have the same vulerabilities. If you have 3 string classes, and each download sent is not the same as the previous, then you will have a exploit that will only pertain to a subset of the downloads sent out. The inherint advantage of this is that you the developer get to write and distribute your application code, in a very architecture free manner, while limiting the feasibility of explotations on your customer base.
The simplification that I am making is that you can assure the toolkits are 100% error free. It is easier to assess (audit) the error-freeness of a toolkit from which your application can be constructed than it is to audit both eh application and any trickiness in the interface between your app and the toolkit. Having a changable toolkit prevents one from purposefully or unintentionally expliting the toolkit in known and unknown ways. (I belive the as-yet-unknown ways are the most dangerous and harest to track down)
So I think we can address these issues, and that as software becomes less coupled from the underlying implementation we will see only design errors. And even then the toolkits/frameworks will prevent a good many from seeing the light of day.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
If you are opposed to paying, say $100 for totally insecure software, then you agree with this premise.
It probably makes most sense for software publisher to assume responsibility. Thus would eliminate the need to license every corporate VB jockey and merely ensure that someone competent reviews the code before release.
(This is customary in many licensed professions. E.g: House remodeling projects are usually done by an unlicensed architectural designer and then just reviewed and stamped by a licensed architect.)
Since you can't make something 100% perfectly secure, we shouldn't bother trying right? Just produce complete and utter crap like IE, IIS, Mozilla, etc?
I work at a company that has only 1 programmer. Guess who that one person is? I am pretty good at clean code, but I am human... I have written so many tools and applications for this company, and there are bugs everyday everywhere. The management pushes me in so many directions that realistically its impossible to create great code in a timely manner. Now that I have so many programs to continue fixing, I don't have much time for further development. Of course I get the blame for how lousy applications are. I suppose you could compare this situation to a house maid. She makes you dinner with the chicken that your wife bought at wal-mart. The meat is bad, you get sick. Sue your maid? A little far fetched.... I tried
If you are a civil engineer designing a bridge, and the manager disagrees with you about needing a certain feature, he's free to find another engineer who will do things his way, and fire you.
Of course, when the bridge collapses, the other engineer may go to jail, and when you testify to what went on behind the scenes, your former client may join him.
If you have a PHB client like that, much more likely is that your client will either cancel the project or do it your way this time, but find a yes-man for the next job. That way he won't go to jail when the next bridge collapses.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Most other free software licenses also have something similar:
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
DNA is a programm and it has a lot of flaws, but it works well for all of us. Be happy and have some fun!
Just make it legal to crack other people's computers and use their resources.
Evolution is the only thing that will work!
3000 Microsoft programmers have been given the boot.
As a result of post-Enron corporate officer accountability, it's harder to find people willing to be corporate officers.
Beware the law of unintended consequence.
Most parent up - it may be offtopic but it's interesting.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Just because something's in a EULA (or even a contract) it doesn't make it legally binding.
Let's say the EULA states that I can come round your house and rape your wife.
thank God the internet isn't a human right.
You imply that authority and responsibility go hand in hand.
Rather, IMO, responsibility consists of equal parts accountability and authority. If you are responsible for X, then you have authority over X, and are held accountable for it.
If you agree to be held accountable for X without having authority to influence it, you've signed a recipe for disaster, regardless of what it's called. I guess "responsiblity for X" is a something nice for a boss to say, but it's a false premise unless you have accountability and authority both.
I wonder if they can get around it by claiming the code as the documentation as to what the program does. That way if it does something wrong it is perfectly documented that that is what it is suppose to do. If you don't want it to do that let me know and I (the programmer) can change it. This would be kind of like the Microsoft argument of "it's not a bug it's a feature" except with OS it is a documented feature that is subject to change appon request.
Closed source applications wouldn't be able to use this loophole.
Paying taxes to buy civilization is like paying a hooker to buy love.
In the end everything comes to requirements, validation and verification at each level of implementing an application.
Say i'm a coder and there is a flaw in the OS? or in the API? or in the hardware? can I pass the buck onto the Redhat, Java, or HP after the damge is done? of course not. Its my responsability to make sure that the app is valid and verified given the requirements.
Just like its the responsibility of the requirements gatherer to properly describe the problem to the developers, weather or not that entity is a vendor, client, or part of the development organization.
And what if there is err on the part of the end user? like if the hardware does not meet the minimum requirements of the app and something goes wrong.
this is Software Engineering 101, not capital punishment, gay rights or abortion.
Blame the user for buying Microsoft products!
What, do I need a sig now?
I'm certain it is a problem of the company. The company should A) have a qualified application designer who accounts for security related issues, B) have the QA plan to test security issues, and C) have the ability to respond to security issues with rapid patch deployment. Unless a developer maliciously includes security holes or deviates from a standardized development policy (and in this scenario, it's the company still, but they can take it out on the developer) I believe it's like anything else, where the employee (developer) is doing what the company asks of them. If the company does not have a standardized development policy that includes security related strategies, then the company is at fault for failed responsibilities. Cheers. Oh, and I don't know if this has anything to do with the topic.
Would something like this apply to open-source projects as well? Or would open-source fall into "Use at your own risk".
"Sure, it may be a good start to remove some of the bugs, but who writes the sandbox? In what language? Is the sandbox itself sandboxed, to prevent being comprimised? If so, who writes that sandbox? In what language? Is that sandbox itself sandboxed, to prevent being comprimised? If so...
It's not an "obvious solution." It's an "obvious time-saver" when it comes to having to check for bugs."
To use Java as an example (I'm not advocating Java, just the idea), somebody writes a secure Java virtual machine once and everyone uses that as their platform. If a buffer overflow is found in the virtual machine (a single program), it is fixed once and all programs that use it are now more secure. The virtual machine code can also be heavily audited and over time it is unlikely to contain any easily exploitable security issues. With the current approach, buffer overflows need to be found and corrected in every single, for example, C program written. The amount of code here is gigantic compared to auditing one virtual machine and it will never be as secure. I'm not sure what your point is, but the former approach is obviously more secure and scalable. Why would you want to write program in a language that allows buffer overflows when you're concerned about security? It seems an obvious solution to me.
"I think you mean:
It essentially means that if you write a program to be used on a network, you have to maintain and patch it forever because you'll never catch all the programming errors, incorrect assumptions, and random unexpected behaviour introduced through unforseen run-time activity it contains."
The fact is, the vast majority of security issues are caused by buffer overflow bugs. If you eliminate these types of bugs (which many languages do), you save a massive amount of maintenence time and effort.
Quality code CAN happen... but first things must change...
Right now the environment in the business world today prevents truly bug-free programming. A lot needs to change:
1 - Fire all the programmers and developers that can't program. We all know which ones in the group fit into this category. Unfortunately our bosses don't know. They're the ones that cause the majority of the bugs. They came into the industry just for money (pre-2000 bust) and they have no real feel for programming yet they know how to email the boss. Keep the ones that are naturals. The real code warriors. The good ones know when to code new source, when to copy old source, and how to clean up old source when they copy it into their new modules.
2 - Get rid of the bosses that don't know tech people. (i.e. the ones that don't know the difference from #1 above) The boss doesn't need to know tech (it does help) but they do need to know their people. They also need to know how to keep office politics and beauracracy away from their people.
3 - Get rid of separate New Development and Maintenance groups. People will code better when they know they will have to fix their own code when it goes into production. They will care more about stability instead of features. Also, a programmer learns the difference between good and bad coding techniques when they are forced to maintain both. When you are maintaining programs you learn how to right code that is easier to fix or modify later; if all you do is new development you will never learn this key concept.
4 - After the requirements are requested and the specs/design is created don't let users change them. I can't change everything just because a user changes their mind. If I have to change, the release date is pushed back as if I just started the design today. I can't complete a program until you are done knowing what you want it to do.
5 - Procedural vs. Object Orientated programming. The huge developement debate. I admit I am biased toward Procedural programming. However, you should use whatever works better for your project. A GUI works better when you design using OOP, but when you need to crunch numbers on 10 million records procedural will work a lot better. I know a lot has been said about the poor code quality of OOP in particular, but if you get rid of the idiots in #1, the logic should be easy to follow.
6 - KISS - Keep It Simple Stupid - I used to work with someone very intelligent, but his code was terrible. He would program elaborate functions just to add two numbers together. My honest belief is that he tried to impress us with his "coding ability." If someone needs a simple program give them a simple program, don't redesign the wheel.
7 - Shoot and KILL everyone that sponsors or participates in a unreadable source code competition. (sorry personal peeve) We need to promote legible code with indenting and good, clear, and relevant variable naming.
8 - Quality. CMM, ISO, TQI. These are nothing more than BULLSH!T. While there some occasional insights coming from these "Quality" initiatives I disagree with most of the methods. Unfortunately, most of this initiatives are nothing more than feelgood bs for clueless management. Commenting and documenting your code is a good thing. However, these "quality" processes can also cause over-documentation. If you spend more time documenting your code than it will take to rewrite your system, you have documented too much. No one will sit through reading 50 hours of documentation to fix a small bug. When your documentaion helps explains why your code is doing obscure things to save the time of the person after you (or even remind yourself months later) you have the proper level of documentation/comments. I honestly believe that some of these initiatives create tons of documents so consulting/contracting companies can increase billable hours.
9 - Admins and Tech Writers. Hire all the good ones back. The improve our ability to code by letting us
Looking for a job?
Want your resume written professionally?
DON'T USE TUNAREZ!!!
However, if $Corporation knows it could be taken to court, and its insurance rates would then rise, it would be motivated to, at least, have proper testing.
Best Slashdot Co
Let's not forget the old saying... "It's always easier to ask for forgiveness than to ask for permission."
I think vendors just need to make things reasonably secure. :)
This sig used to be really funny...
Most coders will fall back on dirty C routine to get the job done, when coding in a more secure routine in a higher language is just too time consuming. Of course the habit of ignoring compiler warnings is one of the biggest issues. Unfortunately if all else fails a quick and dirty C routine sometimes is the only answer.
What we really need is a way to create a sandbox for subs that can run them and accurately and quickly report the buffer status stepping through the code. Most compilers and debuggers are very weak at this function, though the gdb is getting much better. In business the Visual C++6 is still the one most widely used, and abused, the end result is tonnes of insecure MS exes that can be hacked on the net. Alot of it still coming from Microsoft and their unlimited supply of cheap and crappy hardware vendors!
Why do people still write in those grotesque languages?!?!?!
They're not faster. Not better written. They have huge learning curve.
Both make COBOL look cool.
But the real source of the problem here isn't with the programmers or vendors of software. The real problem is the protected nature of the insurance industry. The insurance industry is structured to prevent competition from technically savvy upstarts that would be capable of underwriting warranties. Consumers aren't averse to signing end user license agreements with strong warranties. Nor are vendors averse to consulting contracts where the consultant's code quality is underwritten and guaranteed. The problem is basically the way capital is concentrated by the laws of the society. Those laws determine what kind of people have decision-making authority. Right now those laws are biased toward subsidizing wealth concentration which means we're systematically taking wealth out of the hands of the technically savvy and giving it to those who are wealthy.
The result is all manner of market failures impacting the high tech industry, including a failure of insurance underwriting for software.
Seastead this.
Proposals like these are stupid and idiotic because half the time it simply ISN'T CLEAR what a piece of software should be doing. We simply don't have formally rigorous and perfect descriptions to meet real-world demands, and for the most part we CAN'T have them. If we had, we could use those instead of writing computer programs. For the time being, however, computer programs are the best descriptions we have.
Assume people that can't play, can't play due to bugs.
... never.
Which is better?
A game that 9,998 people can play today, but two people couldn't.
A game that 9,999 people can play a year from now, but one person cannot.
A game that no one will ever play.
How bout with an OS...
An OS that 99.98% of the features are usable by 99.98% of the users today.
An OS that 99.99% of the features are usable by 99.99% of the users in a year.
An OS that 100.00% of the features are usable by 100.00% of the users in
It really is the same balance question for security as well.
Who is going spend a million dollars on a nearly flawless security system for their home's Welcome mat that they have on the front porch?
IMO, a good software company would take both options one and two then continue the trend as they approach option three as long as revenues permit.
Let the buyer decided if the current level of reliability is good enough for them. Maybe its not, they can take their business elsewhere, not buy it, or if absolutely necessary build it themselves.
I would push for the Vendor to have a reasonable return policy. How bout 30-90 days?
At the end of the day, are you threating to not buy the vendor's software or are you threating to continue to complain about the vendor's software?
From the high-modded posts above:
With that kind of idiotic thinking, do you think programmers today are even trying? What's the matter guys, no confidence in your abilities as a programmer?
I would *love* to see some more responsibility from vendors. The state of security today is *completely inexcusable*. Yes, perfection is difficult, but most of the stuff I have on my computer isn't even *adequate* let alone perfect. I seriously believe programmers today don't even bother, because of the attitudes represented above.
How about this: let's hold vendors (or whoever "signs off" on a piece of software) responsible for all *undisclosed* security flaws. That way we don't have to expect perfection, but we should expect at least a basic audit before the product is delivered.
I don't know what the solution is, but we are headed on a collision course. Phones, PDAs, computers, ATMs, home entertainment, homeland security, banks, medical records, all this stuff is built on a foundation of crappy, insecure software, and the best the programmers can say is "it's impossible" to make it secure. Great.
...libraries or open source (like MySQL) that my application uses?
we sue the inventors and implementors of the programming languages that are used to write insecure software!
or better yet, we could sue the hardware manufactures for allowing their hardware to run insecure software!
In my post from the last article, I already stated the many reasons why blaming the developer is simply ridiculous.
But the fact that software, in general, has so many flaws is a simple matter of economics. As I said, in a different way, in my last post, people are willing to pay the current price for software with the types of flaws they have now. People simply wouldn't be willing to pay what software WOULD cost if it had few or no flaws.
Left to its own devices, an economy can generally regulate such things on its own. When you start trying to legislate this kind of stuff, it generally screws with the economy and everyone loses.
The simple question for a business to ask is, "Are we better off with the flawed software we have or would we be better off without any software?" That's really what it comes down to, because again, the economics of it would take make the cost of software beyond reach for most businesses, if it were flawless or close to it.
With time, all of this stuff will impove. I suspect at some point (quite a bit in the future), software will become self-correcting or programming languages will arrive at a point where code can be mathematically prove to be correct or not (though I suspect the latter will be more difficult). Regardless, I suspect that over the years, code quality will improve, not because developers will improve, but the underlying technologies will improve in finding and correcting code problems.
After all, we developers are merely human and what we're often asked to do is stretch our abilities and the technologies to their limits. We'd lose our jobs if we refused, so how could we possibly be held responsible?
It's a ridiculous idea, but if it were to happen, it has the following implications:
- Cost of software would have to go WAY up. Time to produce would increase significantly as well. Developers would take longer to produce software so more developers were needed or less software would be produced. MORE DEVELOPER JOBS. Better job security.
- Increase in cost of software would cause more in-house development in order to save money, where there is no external liability as the software is not sold in the independent marketplace, only used internally. Thus, the security constraints would be less as a company isn't going to sue itself for the insecure software it chose to use. More in-house development projects. MORE DEVELOPER JOBS. Better job security.
People that participate in obfuscated source competitions are the ones that most likely:
#1 - can read and understand other people's source code, no matter how obfuscated it seems to be; and
#2 - give the proper value to clear and consistent code, naming and indentation, because they know how hard can be to read improperly-written code.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
If you want to be an Engineer, talk to the governing body. Tell them that software that works and works well is Engineering, and that you think that some responsibility and accountability would be great for your profession. Bring up how much more money they could bring in from the extra 1000 or so Software Programmers who could be Engineers.
In Canada, you can be a Software Engineer - you get the ring, the B.Eng, EIT restrictions, and P.Eng potential. You're an Engineer in the real sense of the word, not some mail-order alphabet soup "engineering" certificate from nortel or microsoft. (I'm an EE, but some of my friends are SE.)
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
The blame is on the "developers" in this case: http://developers.slashdot.org/article.pl?sid=05/1 0/21/1240258&from=rss
* Si hoc legere scis numium eruditionis habes *
1) Just as long as legistlators are held responsible for loopholes in the law. "It's not illegal to steal candy from a baby? Who'da thought?"
2) Security consultants are held responsible for when their 'advice' is totally wrong.
I'm sure I can think of a few more. As long as we're spreading the blame around, lets spread it around 'bout everything equally.
A type-safe C program can contain buffer overflows. A type-safe Java, ML, OCaml, Haskell, Python, Cyclone etc. program cannot. Buffer overflows constitute 90% of the security problems found in todays software. Blaming the programmer for buffer overflows doesn't make sense, especially when expert users have these bugs in their code. You shouldn't be writing secure programs in a programming language that is fundamentally insecure.
All you need is one exploitable buffer overflow bug in an internet based program on your computer and your computer could get hacked, get a virus, get spyware etc. Expecting every programmer in the world to be good enough to not create buffer overflow bugs is not a realistic or scalable approach to this security problem.
This is the real article by Bruce Schneier: Sue Companies, Not Coders
An excerpt at Bruce Schneier's web site is titled Liabilities and Software Vulnerabilities. (Scroll down to see it.)
Bruce Schneier is a very smart guy. This statement from his web log is foolish, and not typical: "Somewhere in the middle there is a reasonable amount of liablity, and that's what I want the courts to figure out."
If Bruce Schneier doesn't have a detailed plan, that shows how difficult it is to resolve the matter. "The courts" have very little knowledge or willingness to think carefully about this. In the U.S., court judges are often backed by those who want a weak judicial system, and other people, like U.S. President George W. Bush, who are corrupt and incompetent. For a list of books discussing the corruption, see: Unprecedented Corruption: A guide to conflict of interest in the U.S. government.
Insecure Code - Vendors or Developers To Blame?
Obvious answer: blame the users!
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
I have worked with variety of programmers, some VERY good, and some VERY bad.
The cases where the good programmers wrote insecure code, was generally due to poor project management, eager sales practices, or just plain bad IT management.
The cases where the bad programmers were even touching code, was due to a poor HR screening policy and hiring process.
All in all, the company should be held accountable, not the individual who wrote the code.
The company is by all means responsible for the staff they hire, as well as the manor in which they conduct business.
If the company hires a bad programmer, then it is their fault for hiring underskilled staff in the 1st place.
If the company has over-eager sales practices, poor project management, or an inaddequite QA process, then again, the company is to blame, not the individual who wrote the code.
the only permanence in existence, is the impermanence of existence.
If you work for the IRS and you make a mistake on an Audit. Are you as an IRS agent responsible for making up the money in the mistake or do you get to take home the extra money (depending on which way the error was made)?
If you want this type of policy for one type of employee you must make sure it applies to all others.
I am pretty sure your employer is 100% responsible for the employee's actions while they are working. Mind you the Employer has the right to fire the employee.
Just like a friend of mine who was traveling in a company car for work and hit a deer. The employer wanted him to pay 100% of the cost to fix the nearly totaled car. After a bit he refused to pay - which was with in his legal right his lawyers told him. Shortly after his was fired. Which the company was legally allowed to do. Sadly in the province in which he worked there is relatively no protection from wrong full dismissal and it is virtually impossible to prove.
If you try to make programer legally responsible (like doctors) you need to increase the wages so they can afford insurance (like doctors). I am sure companies would love to pay programmers $300,000 - $500,000+ a year.
My Sig indicates the end of the comment I posted.
Bugs in the code are not repeat NOT the fault of the guy (or girl) who put them there in the first place.
The fault lies with the company that didn't test the software correctly. You can't test your own code to failure. If you think you can, then you're either wrong or sloppy. By definition, you can't think of something you haven't thought of. You will find bugs in my code and I will find bugs in yours. That is because we think differently. If you didn't account for possibilities that you could think of, then you're being sloppy.
You have to have someone else test your code to FAIL. Anything less is going to have bugs and leaks. You can not get around this.
As for the proposal, you get what you pay for. If you want a bug-free operating system and software, then pay the extra cash for a military-grade version. Otherwise, pay the $200 (or $0) and live with the crashes. Don't buy the cheapest power supply you can get your hands on and pair it with the cheapest hard drive money can buy.
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
Second, companies usually have liablility for the actions of their employees under respondeat superior.
Third, the proposal is a bad idea. Companies gain tremendous benefits from their employees. Making employees individually liable for their mistakes while profiting from their efforts is obviously imbalanced.
Read the EFF's Fair Use FAQ
The mistakes programmers were making 40 years ago are being repeated today on an even grander scale.
This liability approach is all wrong. All we need is an unbiased standard of security. If you want to tout your product as "secure", it has to pass some sort of audit. This wouldn't be trivial to implement, but it would be highly effective if done right.
There is a place in the market for inexpensive software, so you shouldn't try to legislate it out of existence. Any legislation should have more of a "Truth in Advertising" approach.
Did any engineers at Firestone get prison time for causing hundreds of deaths? Is a security leak of information going to cause someone to spontaneously combust in a large ball of fire? How could software developers be expected to be more responsible than engineers or scientists or accountants or janitors?
Be sure to remember the Programmers Prayer
Can I sue the carpenters that built my house, since some thieves broke in? They should have reasonbly forseen the use of a crowbar on the front door. I mean houses have been built for a lot longer than software. Why can't someone build me a house that is impossible to break into? Some of you call yourselves "Professional Engineers", and you can't solve this problem.
I can't be held accountable, I never make misteaks.
Click here or here.
This is a huge over reaction, although tends to be happening anyway ... for other reasons (mainly because it's cheaper). I'll repeat what I've said before writing with a real string type in C, is not hard ... and provides all the same benifits. The problem is convincing people that it can be fast enough (and even now, speed outweighs security for most customers).
Of course I'm also backing up my retoric with a $500 security guarantee, on my webserver that's written using only a real string type ... in C. Also AFAIK the only software in the OSS community that have offered such guarantees have all been written in C (and all with real string types).
This may have been true but is now false, and has been for years. Even if you take into account integer overflows etc. that can be mitigated by real string types, it maxes out around 60%. I do have some stats. I did myself, from 2003 ... and I've seen other more recent ones which say the same thing (I don't own them though, and I'm not sure they are public).
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
The software projects that make it to market are the ones that win. Asking why software isn't more secure is like asking why peacocks have bright feathers--plainly a liability when running from predators or fighting, but they get the attention of the peahens. And the software peahens just don't care enough about security. Whoever gets to market fastest, and with the prettiest colors, wins.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
One path for input, one for output. Buffer overflows are easily avoidable with a little discipline or an i/o library that does filtering/truncating for you.
Instead of char[100] you have cBuf buffer; with associated read/write methods. Or even use std::String and append as needed.
Anyway looking at LWN security alerts, there are more temporary file vulnerabilities these days than buffer overflows (and out of 59 or so listings, 7 were overflows, if I counted correctly, which is a bit less than "90%"). Race condition DDOSes are there for sophisticated software (e.g. the kernel). Cross-site scripting is another one. Basically, straight buffer overflows are one of the easiest to eliminate but there are many problems that remain which can be quite tricky (race conditions are one; XSS) and occur with a variety of languages.
because its impossible to write 100% secure code. Even if it was possible to write an app that was 100% sure today, but whose to say 1-2 years from now a more advanced technology arives and makes it possible to 'unsecure' that once secure code.
Supposing I ran a small company that develops and sells(i.e. 'vends') software.
Would you be willing to buy my software, as opposed to a competitors, if said software had a few less features but I could garauntee that said software would work correctly all the time, and my competitor could not?
What if that garauntee carried a money back promise with it?
Just curious. I've been considering developing low cost end user applications with an eye towards quality as opposed to a major featureset.
Not anymore. Many security holes on websites are due to SQL injection, where a user is able to type bits of SQL directly into a form. In addition, some web sites give too much information when an error occurs, thus giving a hacker a clue as to the database's schema.
No, I will not work for your startup
" I'll repeat what I've said before writing with a real string type in C, is not hard ... and provides all the same benifits. The problem is convincing people that it can be fast enough (and even now, speed outweighs security for most customers)."
A C program which meets the C language specification can contain buffer overflows so it simply does not have the same benefits as languages that do not allow buffer overflows. It doesn't matter if you can spend a lot of time writing a very secure C string type; you can easily create exploitable, difficult to find buffer overflows in the rest of the C code you write. It is insane that not using a buffer properly can allow a third party to take control of your computer. Why is using a language that lets this happen acceptable for writing secure programs?
I wonder if they can get around it by claiming the code as the documentation as to what the program does. That way if it does something wrong it is perfectly documented that that is what it is suppose to do.
And this is exactly why specification is actually important. Unless you have a specification (preferrably a formal one) on what the intended behaviour is, then it is impossible to have incorrect behaviour: by definition anything the software does is the correct thing for the software to do.
It's also worth noting that your specification doesn't need to cover all possible behaviours for the software, it might be as simple as saying "in the particular case of X, then Y will occur", for which you can then provide formal verification.
Software doesn't need to behave perfectly, but it would be nice if software came with formal assurances that, while not everything will necessarily work perfectly, X, Y and Z are guaranteed.
Jedidiah.
Craft Beer Programming T-shirts
What happens when a coder uses a pre-defined function in a language that turns out later to have say a buffer overflow? Is the software coder responsible for it, since he used? Is the language coder that wrote the language responsbile for it?
As an additional question - why not apply the standard legal definition of "negligence"? The test for negligence is 1) was this a forseeable consequence of a given action? and 2) what would a prudent man do?
Thirdly, we have this nifty piece of legistation already in place called the Uniform Commercial Code, which stipulates that a product must be fit for the purpose for which it is intended. All that needs to happen is that the EULA's need to be disregarded and the UCC enforced against software makers. It's completely ridiculous that we have software that can completely wreck your computer/server/network being sold to people who are completely unaccountable for their actions. Once they cash your check, they have no incentive to fix anything.
2 cents,
Queen B
HDGary secures my bank
Yes, I'm aware of this clause, and I think most software, even proprietary software has a clause like this in the EULA. What I'm talking about is giving it teeth. The anti-patent clause I believe they are proposing for GPL 3, if I understand it correctly, says that if you sue the copyright owner for patent infringement by GPLv3 software, you then lose your right to use all GPLv3 software. Essentially the current clause says, "You can't hit me under any circumstances." Maybe what we should be saying is, "You can't hit me under any circumstances, and if you do, me and all my buddies are gonna hit you back."
-- Knowledge shared is power lost. -- Aleister Crowley
The end users agree to a EULA, that's an End User License Agreement, which states very clearly that the vendors and developers are NOT liable for any damages caused by the software.
If the end users cannot accept responsibility for their own security then they should be held accountable or not allowed to purchase it.
If you hold developers accountable nobody will develope software, or the average developer salery will increase to include the insurance they would need to protect themselves. All software has bugs, bugs can be security vulnerabilities, so can poor design and loopholes, etc, etc, etc. So the price of the software will increase drasticly to pay the developers.
If you hold vendors accountable the price of the software will increase drasticly to include the cost of the addtional software they would need to automatically update and/or disable any exploitable software. So yeah, if you'd rather pay more for the product than patch your OS, go right ahead and require vendors to manage your personal security for you. No matter what happens here it won't affect F/OSS, as there is no known vulnerabilities in source code and anyone who compiles it is accepting responsibility for any damages, etc.
This whole debate is just retarded. And so is anyone who agrees with either side of it.
How about demand more quality from your vendors or put your money where your mouth is and switch vendors, if you're not a spinless prick who expects everyone else to take care of this hard computer stuff for you cuz you're too important to be bothered with clicking "Windows Update" once a month. I hate the technical illiterate. They shouldn't be allowed to touch a PC. They create more real-world problems for those of us with a clue than they will ever be capable of solving.
I did a bit of a perfunctory search, and from what I see, it will apply to the particular GPL3'd piece of software that the patent suit is being applied to. Otherwise, I would think that this could give third-party developers an open license to violate patents of any company with risk sunk into GPLed code.
Information wants to be free.
Entertainment wants to be paid.
You just want to be cheap.
Notice "the *former* White House cybersecurity adviser"....
Development costs skyrocket; everyone moves their company to India. The current slapshod kick-it-out-the-door environment exists because it's an economic optimum. If people need bullet-proof software, they can grab a consultant, add contract stipulations, and pay out the nose for it.
And God forbid you write something general purpose like an OS. People always use the engineer building a bridge analogy. The problem with that is that the bridge is built for the span that it crosses. You cannot buy shrinkwrap bridges and arbitrarily place them between things. That would be silly.
Holding software devs to the same level of accountability as doctors and civil engineers, a level where the failure coditions result death and dismemberment, is just ignorant. How would you even begin to deal with library stuff like the zlib double-free? Can I sue a doctor for misdiagnosing me because a prevailing medical opinion at the time was wrong? Blargh.
So, because of this... Last week Howard Schmidt, the former White House cybersecurity adviser, argued at a seminar in London that programmers should be held responsible for flaws in code they write.
Unless and until the programmers are responsible for technical decisions instead of marketing 'droids and bean counters then holding programmers responsible will do nothing!
No, the correct response to this problem is to make the companies who rush such POS software to market (for every other reason EXCEPT technical) responsible. Car manufacturers are held responsible for faulty car designs that lead to dangerous cars, not the designers they hire to design them.
Howard Schmidt used to be chief security officer at Microsoft. Draw your own conclusions about what that means for his credibility, but he's certainly no Harriet Miers.
Obviously you are one of those people that I kindly refer to as sh!theads.
Why? Well, to be perfectly blunt because as clueless as you seem to be about
the origins of computer language and the most used languages history, you
sound off as a result of subscribing to some artifact of information that
disseminates crapulence as sound science, much like intelligent design
punditry.
All languages have components that are subject to sublimation and exploitation by
discerning individuals. Look at english speaking humans and the derivative varieties
of intercourse that are described as brands of interaction and consequent result
by critics. Politics, religion,etc..are all brands of language communicated vulnerability
when viewed in a social sense.
Fortunately the corporate personality has attached itself to property, motive and right.
Let those who profit pay for the decisions they make. The workers will make their wage and
their masters will pay their keep. Their keep is determined by those who direct, these selfsame
managers and directors that would move stupidity,motive and blame to an individual rather than
to those who are paid to make sure that these situations don't exist for an end user.
The majority of security problems by overflows? Not by far.
SQL Injections, not closing sessions on time, cross site scripting, etc.
Those are the problems that you've to face most often.
--
Two witches watched two watches.
Which witch watched which watch?
But arguing a point by merely appealing to an authority is still a fallacy.
Also wrapped up in your argument is an ad hominem attack on said "hack".
Schmidt's status as a hack does not affect the truth or falsity of his arguments about whom should be considered responsible for security flaws in software.
Now reread the last sentence, replacing "Schmidt" with "Schneier" and "hack" with "security expert".
A C program which meets the C language specification can contain buffer overflows so it simply does not have the same benefits as languages that do not allow buffer overflows.
Every non-trivial language allows buffer overflows. Prehaps you just don't know what "buffer overflow" actually means, and think the common example of stack return-pointer corruption actually encompasses all the possibilities.
There are other kinds of buffer overflows besides call stack overwrites!
The correct answer is "Both, you idiot".
The person who wrote it is guity of writting bad code and the person who distributed it is guilty of distributing bad code. Doesn't matter if it's via incompetance or greed, the end result is the same: bad code.
Of course, it's much easier to write bad code, any man and his dog can do it. And does. Fuckwits.
Is programmers are held liable, then it stands to reason that programmers still own the rights to thier work... Which mean you can take the insurance payments out of my ROYALTIES on every copy of software that gets sold that I have contributed to.