It's about BLOODY time!! I think this is great!
http://www.techrepublic.com/blog/european-technology/should-developers-be-sued-for-security-holes/1109?tag=nl.e224 (http://www.techrepublic.com/blog/european-technology/should-developers-be-sued-for-security-holes/1109?tag=nl.e224)
Interesting article. I can't see it ever happening though. If a precedent was set then where would it end?
I think if it did there would be a lot less software as a result.
Well Dan, that's one theory. I think it's a great idea. Something should be done, can anyone deny that?
It would be like holding road builders accountable for drunk drivers killing someone. The person that should be sued is the person that commits the crime, not the creator of the product.
Even the first line of the article paints the picture wrong. If you eat a poisoned burger you sue the restaurant that sold it. You aren't suing the butcher, the baker, or the farmer. You're suing the place where you bought it. If we were to follow that example, we'd have to sue the store where we brought it ( seller) or the prepare-er (us for putting it on our systems).
I disagree. I think that if someone creates something with the intent of selling that thing, they are responsible to make sure they've taken precautions that ensures that thing is safe and viable. I'm not saying that the article exactly what we need, it is flawed. But it's a launching point.
And X, to your point, if I eat a poisoned burger, I will hold accountable everyone who had anything to do with that burger, as would you and everyone else. Perhaps a better example would be, if you ate a burger and it was undercooked, then you got very ill, then you sue the restaurant because they WERE directly responsible for your illness. Right? They were sold the raw meat. They know how to cook it, in fact, they have the tools to ensure that the meat is cooked to the proper temp. But they neglected to do so. Maybe the instruments to measure the temp were faulty, but does that matter? Nope. Because they have a duty to ensure that product they sell is safe. I think the same should apply to developers. If you develop software for mass consumer purchase, it's your duty to perform all the tests that are reasonable to ensure there are no safety holes in that software that could allow a malicious person take advantage of.
I would propose that certain standards be put into place. If you create software that I buy and someone can break into and steal my info, YOU are responsible to defend your creation. I have the right to challenge you in a court of law to see if you did your due-dilligence according to the guidelines (whatever those may be).
I could only agree if the developers were proven to be malicious, sloppy or lazy with their coding and left security holes wide open for anyone to get into. How your going to prove that, I haven't the foggiest clue and that's troubling. This could lead to a lot of problems for developers and I think expecting developers to see all possible holes and leaks in their software is asking way too much. Someone will always find a way. Their jobs are stressful enough as it is.
Also, comparing software development to making food is hardly fair. We have standards of food and safety practice and they are relatively easy to follow. Because food and what causes food to go bad doesn't really change. I don't think we could have the same for software development because the world is constantly changing and advancing.
I guess the question becomes how would you decide when a security hole is caused by "sloppy coding"? Many security holes take very convoluted and complex exploit paths which are frankly never even fathomed of by developers.
If a software company purposefully inserts a back door which is exploited then sure, prosecute them but where does that end? I know when I build something my intention is to make it as secure as possible. I go to great lengths to accomplish that. Do I still put out code that has errors and potential holes? Sure I do.
All I'm saying is that no matter who you are or what company you work for, you will never put out software that is error or security-hole free. It's like running a factory and saying you will never have an accident. It's a nice goal to have, but it's not realistically possible.
""The question is 'Are they being negligent?'. The usual test is 'Are they applying contemporary standards to the quality of their work?'," he says, adding that known flaws can be exposed by running code through commonly available security tools and validation suites."
This quote is kind of where the rubber meets the road on this. We also need to consider caveat emptor, we as consumers assume responsibility for fair use of a product. Assuming we are not forced to use a software application there need to be shared responsibility between buyer and provider.
Quote from: KingIsaacLinksr on August 30, 2012, 09:44:43 AM
I could only agree if the developers were proven to be malicious, sloppy or lazy with their coding and left security holes wide open for anyone to get into. How your going to prove that, I haven't the foggiest clue and that's troubling. This could lead to a lot of problems for developers and I think expecting developers to see all possible holes and leaks in their software is asking way too much. Someone will always find a way. Their jobs are stressful enough as it is.
Well, how do you prove the restaurant who served you the undercooked burger was at fault, and Tim why would a developer need to be proven malicious? That's not the question here. The question is negligence.
Quote from: KingIsaacLinksr on August 30, 2012, 09:52:52 AM
Also, comparing software development to making food is hardly fair. We have standards of food and safety practice and they are relatively easy to follow. Because food and what causes food to go bad doesn't really change. I don't think we could have the same for software development because the world is constantly changing and advancing.
Yeah but Tim, do you think that was ALWAYS the case? It's probably hard to imagine for any of us, since we've been enjoying the "fruits" of other's labors for generations, but once upon a time, the food industry had no standard practices in place. They had to be developed, as I'm suggestion this needs development.
Quote from: billybob476 on August 30, 2012, 09:53:16 AM
I guess the question becomes how would you decide when a security hole is caused by "sloppy coding"? Many security holes take very convoluted and complex exploit paths which are frankly never even fathomed of by developers.
If a software company purposefully inserts a back door which is exploited then sure, prosecute them but where does that end? I know when I build something my intention is to make it as secure as possible. I go to great lengths to accomplish that. Do I still put out code that has errors and potential holes? Sure I do.
All I'm saying is that no matter who you are or what company you work for, you will never put out software that is error or security-hole free. It's like running a factory and saying you will never have an accident. It's a nice goal to have, but it's not realistically possible.
Right, but (and this is as I feared), those in favor of "free tech for everybody" is taking this WAY out of context. What I'm proposing, and I'm sure the subject in the original article is, is to produce a (for lack of a better term) standard checklist for developers to heed to. Whatever that list may be, developers must follow it and "CYOA". IF, they can prove they've adhered to the safety list (or whatever it would be called), then they could have a successful defence.
Quote from: Bryancd on August 30, 2012, 10:20:40 AM
"“The question is ‘Are they being negligent?’. The usual test is ‘Are they applying contemporary standards to the quality of their work?’,” he says, adding that known flaws can be exposed by running code through commonly available security tools and validation suites."
This quote is kind of where the rubber meets the road on this. We also need to consider caveat emptor, we as consumers assume responsibility for fair use of a product. Assuming we are not forced to use a software application there need to be shared responsibility between buyer and provider.
That goes without saying. I'm not suggesting that the person who takes a program and uses it for purposes other than it was intended should have a legal leg to stand on. I'm talking about the person who uses a program as it was intended, who suffers from "possible negligence" would have recourse. Bryan, one is not forced to drink a cup of steaming hot McDonald's coffee and spill it on themselves, yet, and we've seen this, it is possible and quite probable that that person could sue the pants off of McDonald's because they were scalded.
Everyone is looking at this as me (and the subject in the article) attacking the poor honest defenseless computer programmers but it's not. I think that we've entered into such a new age that the old rules need to be redesigned. Creating standards like this for software would also protect the developers in the long run. If they're adhereing to the standards, they're protected. Some of you view this as the catalyst in dampening the computer programmers spirit which will result in less and less software development but why? Why would it do that? Why would it foster anything negative at all?
Off topic, but weren't all those scalding law suits dismissed?
There are certain standards in existence, such as PCI for storage of credit card and other personal info. It is best practice to code for PCI compliance, but not a requirement.
Quote from: QuadShot on August 30, 2012, 10:24:32 AM
Quote from: KingIsaacLinksr on August 30, 2012, 09:52:52 AM
Also, comparing software development to making food is hardly fair. We have standards of food and safety practice and they are relatively easy to follow. Because food and what causes food to go bad doesn't really change. I don't think we could have the same for software development because the world is constantly changing and advancing.
Yeah but Tim, do you think that was ALWAYS the case? It's probably hard to imagine for any of us, since we've been enjoying the "fruits" of other's labors for generations, but once upon a time, the food industry had no standard practices in place. They had to be developed, as I'm suggestion this needs development.
Your still missing my point. Food creation and how it all works changes slowly, if at all. So creating standards for it is far easier than creating standards for a software world that changes rapidly within a year. We went from the Atari to our Windows 7 systems with mobile systems in about a decade. How do you create standards that work for such rapid development when they will likely be obsolete within a year or two?
Bryan, no. In at least one, jury found McDonald's 80% at fault and the plaintiff was awarded $640,000 (Liebeck v. McDonald's Restaurants)
Joe, I get what you're saying, but don't you agree that since the tech and industry is growing and advancing so much, we need to keep pace with standards and regulation?
Quote from: KingIsaacLinksr on August 30, 2012, 11:06:16 AM
Quote from: QuadShot on August 30, 2012, 10:24:32 AM
Quote from: KingIsaacLinksr on August 30, 2012, 09:52:52 AM
Also, comparing software development to making food is hardly fair. We have standards of food and safety practice and they are relatively easy to follow. Because food and what causes food to go bad doesn't really change. I don't think we could have the same for software development because the world is constantly changing and advancing.
Yeah but Tim, do you think that was ALWAYS the case? It's probably hard to imagine for any of us, since we've been enjoying the "fruits" of other's labors for generations, but once upon a time, the food industry had no standard practices in place. They had to be developed, as I'm suggestion this needs development.
Your still missing my point. Food creation and how it all works changes slowly, if at all. So creating standards for it is far easier than creating standards for a software world that changes rapidly within a year. We went from the Atari to our Windows 7 systems with mobile systems in about a decade. How do you create standards that work for such rapid development when they will likely be obsolete within a year or two?
No, I'm not missing your point. I never said I was the one to develop this stuff, nor are you. That should be in the hands of people far more intelligent than we, and I never said it would be easy. And you're confusing food creation with regulation. If we create a STANDARD set of regulations, and honestly, although tech advances rapidly the basic CONCEPT and SCIENCE of it remains the same, those standards and regulations would remain viable for a while.
Quote from: QuadShot on August 30, 2012, 11:11:59 AM
Quote from: KingIsaacLinksr on August 30, 2012, 11:06:16 AM
Quote from: QuadShot on August 30, 2012, 10:24:32 AM
Quote from: KingIsaacLinksr on August 30, 2012, 09:52:52 AM
Also, comparing software development to making food is hardly fair. We have standards of food and safety practice and they are relatively easy to follow. Because food and what causes food to go bad doesn't really change. I don't think we could have the same for software development because the world is constantly changing and advancing.
Yeah but Tim, do you think that was ALWAYS the case? It's probably hard to imagine for any of us, since we've been enjoying the "fruits" of other's labors for generations, but once upon a time, the food industry had no standard practices in place. They had to be developed, as I'm suggestion this needs development.
Your still missing my point. Food creation and how it all works changes slowly, if at all. So creating standards for it is far easier than creating standards for a software world that changes rapidly within a year. We went from the Atari to our Windows 7 systems with mobile systems in about a decade. How do you create standards that work for such rapid development when they will likely be obsolete within a year or two?
No, I'm not missing your point. I never said I was the one to develop this stuff, nor are you. That should be in the hands of people far more intelligent than we, and I never said it would be easy. And you're confusing food creation with regulation. If we create a STANDARD set of regulations, and honestly, although tech advances rapidly the basic CONCEPT and SCIENCE of it remains the same, those standards and regulations would remain viable for a while.
Well, I hope your not referring to our government making these standards, because they don't have a clue of how our Internet works, much less coding. (See SOPA & PIPA if you dont believe me here). So if not the government, then who?
I guess that's the problem. I do believe in standards, but I don't feel like the government should be the one defining them. Further to that, if the US government did create standards, that's all well and good for software developed in the US, but what about the rest of the world?
Quote from: billybob476 on August 30, 2012, 11:44:12 AM
I guess that's the problem. I do believe in standards, but I don't feel like the government should be the one defining them. Further to that, if the US government did create standards, that's all well and good for software developed in the US, but what about the rest of the world?
(and for Tim) That's what the article is stating: that this cannot be effectively created by any one country alone, it must be a global thing. Like I said, it's not cut and dry. I don't know the answer to this. I'm just throwing out something I read and I believe in. That shouldn't mean I must be able to have a complete plan :) It's just a starting point, like I said.
We have software where I work with just HUGE security holes. The bozo's we bought it from still don't have a clue.
Can you imagine the latency inherent in a process like this? The entire industry sits on its hands while some beaurocrats try and come up with a set of standards to work too?
OK, I understand the principal but I really can't see it working. The main issue would actually be that security would probably be made worse as a result. Everyone would faithfully (and deliberately) design to the standards as laid down but standards bodies are generally so slow that the srtandards in force at any one time would be woefully short of what was really required.
Maybe someone could come up with a process that would work but I'm in the highly cynical camp on this at the moment.
When I write code I do my best to stand by it, but as a developer I respectfully disagree with general software being held accountable like that. I imagine it would hurt individuals, companies and open source projects... who would want to give up their own free time to contribute something and then possibly get sued over it?
If something is specifically in a contract and that contract is violated then okay - but I cannot even begin to imagine what litigating software like that in general would mean - apart from more money for lawyers.
Personally I think it is up to the service provider to do the best it can to secure your data and keep up to date with security patches etc.
HOLY FRAK! Is there a flipping way to delete this post? I offered up my thoughts and opinions and all I get is "this is stupid, how could this work? you're idea is nonsense". Dudes, I NEVER flipping said I had the answer to this PROBLEM, and YES it IS a problem. You deny that. Deny there's a problem with crap software being sold that is more damanging than not. I never said I had a plan, only an idea that SOMETHING must be done. Period. So, If there is a way to delete this entire thread, that would be fan-freaking-taskic.
Wow! This is a new side to debates on this forum!
You offer a view with which others disagree and this is the result????
I don't see anyone being called anything here, just a friendly discussion from opposing viewpoints. Is this really something you feel that strongly about?
Perhaps deleting the thread IS a good idea!
No need to remove the thread IMO. No one has accused anyone of anything or shot down anyone's ideas as far as I can see. Some of us here (myself included) are software developers and certainly have some insight into various parts of the industry.
The biggest challenge to the original post I've seen is asking how it would be enforced. If I've missed something then definitely send me a PM.
It's an interesting topic, but something that I'm obviously on the against side of. I don't see a way to enforce something like this or a need to enforce something like this.
I hate to go all free market economy, but if you consistently produce a poor product and refuse to address the flaws, you won't be in business long. This seems to me like a self correcting problem more than anything else. If some company is producing buggy crap I just can't see consumers sitting around waiting to buy the next iteration of it.
Yeah, I'm pretty close to Chris on this. Products in general stick around because people buy them and they work. Much software can be trialed too. I trial out a lot of stuff on my PC before I buy it. Also, I find a of companies are pretty responsive to emails or a phone call. If you don't like something, let them know. You might even be able to get a refund. They do want their customers to be happy or they won't come back or suggest their product to others.