Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Software The Courts Technology

Outlining a World Where Software Makers Are Liable For Flaws 508

CowboyRobot writes with this piece at the ACM Queue, in which "Poul-Henning Kamp makes the argument for software liability laws. 'We have to do something that actually works, as opposed to accepting a security circus in the form of virus or malware scanners and other mathematically proven insufficient and inefficient efforts. We are approaching the point where people and organizations are falling back to pen and paper for keeping important secrets, because they no longer trust their computers to keep them safe.'"
This discussion has been archived. No new comments can be posted.

Outlining a World Where Software Makers Are Liable For Flaws

Comments Filter:
  • Sure (Score:5, Insightful)

    by recoiledsnake ( 879048 ) on Thursday September 29, 2011 @04:41PM (#37560048)

    It will just cost 100x more, just like healthcare with the torts. Time to take out software developer insurance, similar to the healthcare insurance of approximately 1 million dollars a year paid by doctors these days.

    • Re: (Score:3, Insightful)

      by maliqua ( 1316471 )
      and software development grinds to a halt. opensource vanishes who's going to donate time to a liability.
      • Re:Sure (Score:5, Informative)

        by sqlrob ( 173498 ) on Thursday September 29, 2011 @04:48PM (#37560144)

        What liability?

        Clause 1. If you deliver software with complete and buildable source code and a license that allows disabling any functionality or code by the licensee, then your liability is limited to a refund.

        • Re:Sure (Score:4, Insightful)

          by Amouth ( 879122 ) on Thursday September 29, 2011 @04:58PM (#37560268)

          so a PE can get out of being liable for a badly designed bridge by putting the blueprints and the bill of materials on a sign before you get on the bridge?

          there is a point where i agree that the programmers should be liable for their code - to the extent that it shows negligence. the fact that software for so long has gotten away with "good luck, thanks for the cash" mentality is kinda sad.

          I am a programmer - and i would be willing to stand behind my code used in the environment for which it was intended.. but at the same time i would want to be compensated for the risk.. same way a PE gets compensated based on the scope of work they have to sign off on.

          • Re:Sure (Score:4, Insightful)

            by slippyblade ( 962288 ) on Thursday September 29, 2011 @05:19PM (#37560498) Homepage

            am a programmer - and i would be willing to stand behind my code used in the environment for which it was intended..

            ROFL! Wow, you actually expect liability to be limited to the scope the product was INTENDED? That ranks up there with lawsuits against toys because little jimmy choked on a Lego brick or Peggy Sue shoved a jet fighter figure up her nose and shot the plastic missile into her sinus. There is no limit to the stupid and out of intended uses people will put things. There is NO SUCH THING AS IDIOT PROOF. The world keeps making better idiots. If this becomes law, at some point you WILL be sued. No ifs, ands, or buts about it.

            • Re:Sure (Score:4, Informative)

              by publiclurker ( 952615 ) on Thursday September 29, 2011 @06:37PM (#37561264)
              Or even the cost of defending things that are not your fault. I worked for a company once where a contractor provided module required 3rd party drivers. The installer for these drivers would occasionally do strange things, making the module act funny causing problem in our program. The customer does not care about any of this, all they know is that they bought your program and every so often the screen goes blank. they are going to sue you, and then you'll have to go through the chain of ownership to get things straightened out.
          • Re:Sure (Score:4, Insightful)

            by Anonymous Coward on Thursday September 29, 2011 @05:22PM (#37560532)

            the fact that software for so long has gotten away with "good luck, thanks for the cash" mentality is kinda sad

            Genuinely critical software isn't usually handled like this.

            The whole premise is retarded. You want guarantees? Great, we already have a handy tool of commerce for that. They're called contracts. Just a heads-up... it's going to cost more.

            • I could perhaps, see the logic behind having a 'standard' contract(where software buyers share the cost of writing an airtight and toothy contract), which could then be used by anybody in a critical situation,but the idea of making that the default is insane. Goodbye OSS, goodbye any software that isn't mission-critical and priced to match. Worse, depending on the level of vendor influence, you might see the worst of both worlds. Some sort of perverse situation where having a clueless support drone close yo
          • there is a point where i agree that the programmers should be liable for their code - to the extent that it shows negligence.

            This has good and bad points. A few things of note:

            1) One major function of tort-liability is cost-shifting--the programmer's negligent behavior causes an actual cost to the business owner who uses his software, and maybe the programmer should have to reimburse him. If the programmer does, then this means that a part of the total cost of making that particular software--the part otherwise paid by the loss the business owner suffers--gets built into the expected costs of making the software on the part of

            • by Amouth ( 879122 )

              Obviously, that is an extreme case, and most software is not designed with the expectation of having lives depend on it. Just like you have different standards for military grade hardware and consumer hardware. There are a lot of options we have as a society in deciding how to treat risk.

              You should see the amount of code that goes into a modern car, elevator, or the summation of code in plc's in plants. There is plenty of code now days that have an expectation not to kill a user.

          • Re:Sure (Score:5, Interesting)

            by ScrewMaster ( 602015 ) on Thursday September 29, 2011 @09:19PM (#37562314)

            so a PE can get out of being liable for a badly designed bridge by putting the blueprints and the bill of materials on a sign before you get on the bridge?

            there is a point where i agree that the programmers should be liable for their code - to the extent that it shows negligence. the fact that software for so long has gotten away with "good luck, thanks for the cash" mentality is kinda sad.

            I am a programmer - and i would be willing to stand behind my code used in the environment for which it was intended.. but at the same time i would want to be compensated for the risk.. same way a PE gets compensated based on the scope of work they have to sign off on.

            What truly irks me about discussions such as this is that everyone wants to lay the blame on the programmer. It is the organization that is at fault. Matter of fact, the responsibility for a defective software product lies squarely with upper management. Frankly, I just don't get this perceived need to roast programmers and software engineers alive, when defective designs in every other industry cause harm, and nobody talks about throwing those engineers under a bus.

            Standing by your code is one thing: taking the legal responsibility for a finished, shipping application that has problems that you would certainly have fixed if you knew about them is something else again. Management decides who works on what project, how much (if any) quality control time is assigned to that project, management decides what bugs are minor enough to fix in an update (and sometimes they're wrong about that.) Management decides who to hire in the first place.

            I work in an industry where my codebase, if it were to malfunction in any serious way, would be a major problem for some rather large plants worldwide. But here's the thing: if the responsibility (and legal penalties) for such problems were mine, and mine alone ... well, guess what. I wouldn't be a software engineer anymore. Why should I go to jail, or be bankrupted with legal fees, when I did a perfectly competent job, but a bug still managed to get by QC? Might as well put the QC team on the hot seat too: they're the ones that missed it. Fact is, the corporate veil is there for a reason.

            In any organization it's the people at the top (the people who get the big salaries and golden parachutes) who ultimately maintain responsibility for such failures. And that is how it should be: they make the big decisions, they're the ones who allocate resources. Your average code monkey is no more at fault for a product failure than the janitor. That's why, unless there's gross mismanagement, it's the company that is penalized, not the individual employees. There are supposed to be checks and balances. Face it people: we know how to do code right, but most vendors simply don't want to spend the money.

            That bridge you were talking about is a perfect example: the reason bridges don't fail very often because of design flaws is because those designs are reviewed and cross-checked and signed-off upon by slew of other engineers and designers who make sure the design is solid. It's that way because nobody is perfect. Again, who decides how much code review and design assurance is necessary? Yeah, you got it: management.

            All the disclaimers in the world don't mean squat in court if your software causes significant economic or physical harm. The company that produced it (not the individual developers) certainly can be sued and redress granted. But penalizing individuals for systemic problems within a given organization? Even discussing that is patently ridiculous.

            There's no good reason to burn engineers at the stake. Plenty of reason to boil a lot of CEOs and managers in oil though.

            • No. As a Software Engineer myself I see this 'blame the management not the engineer' mindset as an unacceptable abdication of responsibility. Management isn't the technical expertise, the engineer is. If your a Civil Engineer PE and your MBA boss asks you to sign off on a design, that's great and all, but you don't sign off unless you're sure that the designs are sound and acceptable according to your trained, professional opinion. The company is paying you to make that call honestly, they did not and can

          • a broken word document does not. If your software runs a device that people's lives depend on, then existing negligence laws cover the device just fine (e.g. pacemakers and whatnot).

            Software Liability is just the big companies trying to take control. Nothing else (well, there's a healthy dose of fearful stupidity there, but those people are silly, so I don't count 'em).
        • Re:Sure (Score:4, Insightful)

          by Daniel Dvorkin ( 106857 ) on Thursday September 29, 2011 @05:04PM (#37560332) Homepage Journal

          Ah, idealism! The proposed law, with Clause 1 in place, and enforced, doesn't sound too bad. Do you really think that's the way it would work? In the real world, any software liability law would be written by lobbyists working for Microsoft, Oracle, Adobe, EA, et al., and there is no way in hell it would make life easier for open source developers than for the big commercial developers.

          • by migla ( 1099771 )

            Dang. Stupid reality. Maybe stones and bombs could help. Where should we put them? ;) Just kidding. I don't wish to stone and/or bomb anybody. We must forgive them, for they don't know what they're doing. Or so I'm told.

          • Re:Sure (Score:5, Insightful)

            by Microlith ( 54737 ) on Thursday September 29, 2011 @07:48PM (#37561778)

            They already have the beginnings in place.

            It's called "patent indemnification," which they insist that vendors must have. Yes, effectively "patent violation insurance" to keep other companies off your back. Granted it's not entirely "liability insurance" but it's a step towards the state where you cannot develop software independently, but instead must be under the thumb of some larger corporation (or somehow have millions in insurance) to write and distribute software.

      • and software development grinds to a halt. opensource vanishes who's going to donate time to a liability.

        From TFA:

        Clause 1. If you deliver software with complete and buildable source code and a license that allows disabling any functionality or code by the licensee, then your liability is limited to a refund.

        So if you're distributing the source code (and license it correctly) the most you'll be out (aside from malicious intent) is a refund.

    • Re:Sure (Score:4, Insightful)

      by Anonymous Coward on Thursday September 29, 2011 @04:43PM (#37560072)

      It's very important we decimate the last industry the US has that's still mostly functional, profitable, and productive

    • by h4rr4r ( 612664 )

      1. That is medical industry bullshit. They just want tort reform to improve their profit margins.
      2. When you make 250k+/year a million worth of insurance is not something too surprising. People routinely insure homes that cost more than 4 times their yearly income.

      • by tmosley ( 996283 )
        80 years ago doctors were members of the middle class. Doesn't that strike you as odd?
        • by h4rr4r ( 612664 )

          Define middle class.

          It used to mean all the wealth of aristocracy and none of the privilege. So then there has not been much change by that metric.

          If you mean they were considered middle income and paid like other white collar workers. Then we can be pretty sure this is the result of the regulations they have protecting them.

          • by ackthpt ( 218170 )

            Define middle class.

            It used to mean all the wealth of aristocracy and none of the privilege. So then there has not been much change by that metric.

            If you mean they were considered middle income and paid like other white collar workers. Then we can be pretty sure this is the result of the regulations they have protecting them.

            40 years ago I went to public schools with children of Dow Chemical CEOs.

    • If Console game developers can put in the added effort to make a product that is reasonably bug free, or is otherwise unplayable, back before consoles could update the software then I'm sure MS can debug Office a little bit better before shipping.
    • just like healthcare with the torts.

      What statistics do you have to demonstrate the cost savings "tort reform" would bring to healthcare?

      Or, did you just lazily accept what you were spoon fed by people who don't want to be responsible for their actions?

      • by h4rr4r ( 612664 )

        If the medical industry was serious about this it would already be the case. You could get your surgery X% off if you sign some tort limitation form. That would however go counter to what they want, which is to limit tort and pocket the cash.

      • by tsotha ( 720379 )

        What statistics do you have to demonstrate the cost savings "tort reform" would bring to healthcare?

        How could there be evidence for something like that? The closest you get is opinions from economists, practitioners barely one step above Voodoo priests, and you can always find one that supports your position. Clearly what we have isn't working very well, and many of us who've been around long enough to see the way the system has changed over the years don't find it hard to imagine torts as a cause.

        Or, did

    • Re:Sure (Score:4, Interesting)

      by digitig ( 1056110 ) on Thursday September 29, 2011 @06:22PM (#37561142)
      No, you just find that all software production is shifted offshore outside the jurisdiction of such a law, and you will find in the small print of your license that by purchasing the software you are acting as the importer and so accepting legal liability for any defects.
  • by PhxBlue ( 562201 ) on Thursday September 29, 2011 @04:43PM (#37560086) Homepage Journal

    "There should be a law!"

    No. No, there shouldn't. There also shouldn't be disclaimers that "this coffee can burn your ass," "don't point this gun at your face" or "don't use this curling iron to stir your bathwater while it's plugged in."

    If organizations see pen and paper as the only alternative, then they're probably getting the quality of IT support that they're paying for.

  • Great idea (Score:2, Insightful)

    Yeah, let's drive the cost of software through the roof. That will solve everything! Companies will employ a lot more people to do testing but will still have to invest in huge insurance policies just in case they miss something. Your next copy of Windows will cost more than a well equipped car.

    • Actually, in a world where software can be a liability, testing isn't the answer -- the answer is formal methods. It's still under active research (as it's not immediately applicable to certain types of programs) but when used correctly, formality not only reduces errors, but reduces costs as well.
  • Software is complex enough that even the most diligent programmers produce bugs. It's nigh impossible to create 100% bug free code. I think this would pretty much kill the industry as well as be detrimental to hobbyists.
    • If you read the proposal, it isn't likely to harm hobbyists much -- it basically exempts open source from the requirements. The likely result will be for proprietary software companies to either go out of business and become service companies, and for software to be developed in the future as open source by hardware and service companies.

      Which I suppose wouldn't be the end of the world.

  • by LordNimon ( 85072 ) on Thursday September 29, 2011 @04:48PM (#37560146)

    "You can't trust code that you did not totally create yourself."

    I can't trust the code that I did totally create myself, either.

    • A-Freaking-men.

      You know, it just occurred to me that there really isn't a secular alternative to 'Amen' that gets the point across quite as well (at least not one I know of).
      • by Tynin ( 634655 )

        A-Freaking-men. You know, it just occurred to me that there really isn't a secular alternative to 'Amen' that gets the point across quite as well (at least not one I know of).

        I think that is what the new batch of kids are using the word, "This!" for... even though it doesn't quite jive with the cut of my jib. :-)

        • Well, the old-school Parliamentary call of "Hear, hear!" is kinda cool, although it's somewhat laden with political overtones.
    • by amicusNYCL ( 1538833 ) on Thursday September 29, 2011 @05:01PM (#37560298)

      That reminds me of an anecdote one of my CS professors mentioned. When fly-by-wire technology for passenger planes was starting to get rolled out, they polled some people about their willingness to fly on a plane that was controlled by a computer. The group that had one of the largest negative response was programmers. For everyone else the software is just magic.

    • Some quote (approximate) from Knuth or some other guru:

      "Be careful: I've only proven the code to work; I haven't actually run it or anything."

    • by dohnut ( 189348 ) on Thursday September 29, 2011 @05:57PM (#37560904)

      I can't trust the code that I did totally create myself, either.

      When was the last time any of us totally created code? I've been coding to various operating system APIs for a long, long time. Even back in the DOS days I made quite a few DOS and BIOS calls. We use(d) lots of 3rd party libraries for various things. Not to mention the libraries that come with your compiler/IDE.

      I'm pretty sure I've never totally created any runtime code. Maybe some useless crap I did back in an assembler class would count?

      I did have a radio-shack 8-bit processor kit when I was a kid though. That was all machine language (there was no ROM or non-volatile storage). However, I still had to trust that the opcodes did what they were supposed to do. Intel (and others) have shown us you can't even count on that all of the time.

      • When was the last time any of us totally created code?

        Probably never - because the only way to totally create code is to directly generate machine code (not assembler) directly on the bare iron. Even at the assembler level, lat alone at higher levels, you're dependent on the guy who wrote the compiler.

      • Trust an assembler? Who wrote it? The closest I've come to creating software of my own hand has been on a PDP-11 test station, and the embedded processor it tested... writing hex values directly into memory. But even while massaging words by "hand", I was still relying on someone else's tools to get my intention from the keyboard to the flip-flops, and thus still suffering from more levels of abstraction than any civil or mechanical engineering effort.

  • by Anonymous Coward

    I need you to design a bridge. We've already promised the customer that it'll be light and strong, but we only have budget for paper (so we're ok on 'light', just make sure that it's strong), and the deadline is next Monday.

    If you think it can't be done, I have the "outsourcing provider" on the phone telling me that there are 500 engineers who would do it. I need an answer in two hours. I know that you've just bought a house and have a new baby on the way, so think again before you protest.

    By the way, we've

  • by Derekloffin ( 741455 ) on Thursday September 29, 2011 @04:52PM (#37560202)
    You can overbuild a house, it generally makes it stronger. You over code a piece of software it just adds to the number of possible points of failure. The two really aren't good analogies for each other. That doesn't even consider things like how maintenance of both is handled, interactions of hardware, varying setups, and just simple complexity.
    • You can overbuild a house, it generally makes it stronger. You over code a piece of software it just adds to the number of possible points of failure.

      In this context, "over coding" software refers to, for starters, defensive programming techniques (i.e. checking the return values of all the functions you call, fully validating external inputs, etc). It does not reduce the number of points of failure, but it does require the programmer to consider them and the gracefully handle them or transparently report

      • No, he had it right. Adding defensive programming techniques is ANOTHER layer, with MORE potential for failure. When it comes to software, less is more.
  • by Talennor ( 612270 ) on Thursday September 29, 2011 @04:53PM (#37560208) Journal

    Hey, engineering in general is a profession. Bridges and skyscrapers get built. And if the engineers mess up people can die. And there's liability for flaws.

    Should all software hold to this standard? No. I didn't involve a civil engineer building a clubhouse as a kid. But there are places where correctness does matter and is worth the extra discipline and professionalism.

    • No because 90% of coding is working with pre-existing frameworks in code.

      70% of the job is working around bugs in IE 6/7, MFC, and Win32 for all software development in the real world. Believe it or not people need to memorize race conditions in IE 6 as sometimes code will work in a test release but in real life it wont work randomly etc.

      Sure, this is slashdot and someone may may reply they code in C, but that is niche 3% of all programmers. No one designs things from scratch all by themselves from the grou

    • by Xugumad ( 39311 )

      Sure; but this is not about a few corners being cut, this is about an order of magnitude difference in costs. The design requirements, implementation, and QA are all massively increased.

      That's fine if you're building a nuclear power plant's control systems, or an autopilot, but to be blunt, people are happy with Windows because it makes the right compromises for them.

    • by CAIMLAS ( 41445 )

      "For everything else, there are poorly paid, incompetent Indian programmers"? Because that's what it comes down to.

  • All that would happen is vendors lock down the system totally and only allow signed, vetted code. Approved websites only. Pre-scanned emails only.

    I'll take my chances.

  • In effect we are building machines, albiet virtual ones. You don't get to drive cars on the road, that haven't gone through an engineering design and approval process.

    Unfortunately, that costs both time and money. It requires that you have a formal systems engineering approach; Independent Verification & Validation; Testing and first of all; Formal Requirements that are traced to the implementation.

    You can't get away with doing it "On the cheap". I don't know many countries that allow Rail Traffic

    • Spoken like a true engineer. Measure a thousand times, have a thousand meetings, and still screw up anyway. Somehow I don't think that your average corporate intranet application needs anywhere near this much effort, nor the software engineering team that you think you need to throw at it. I guess when you're an engineer everything looks like an engineering problem.
  • All we need is Love (Score:4, Interesting)

    by migla ( 1099771 ) on Thursday September 29, 2011 @05:01PM (#37560300)

    ... All we need is love and Free Software. And even the love is not strictly a requisite.

    Let's say everyone owns Free software, so nobody (i.e. everybody) is liable for faulty Free software. Everybody (i.e. nobody) pays.

    In other words, sure, let the proprietors of proprietary software pay for software behaving badly.

    If the software is free it's everybody's and nobody's responsibility. It's like culture and language in general. We do it together.

    Who's with me?

  • The solution seems a little too simplistic. Just look at any very large software project, like an operating system. Even a simple operating system like an iPod has a huge set of sub-licenses (go check out the Legal menu item, at least twenty on my nano). Large commercial projects often have code contributed from other sources; some open source, some not. If the problem comes from one of those contributions or sub-licenses, what happens?

    I could definitely see Microsoft setup a fully owned subsidiary tha

  • There are already far too many lawyers sucking overhead out of software development companies. Increasing liability for code will drive up how much it costs; software is only cheap because it's relatively low risk to release.

    I make my living working on open-source projects. Given how many imperfect components I work with, in a world with liability issues my full time job would become contract paranoia instead. It's already extremely dangerous to try and make a living from open-source work due to the huge patent minefields you're exposed to. If something like this happened, the only companies who would still be able to afford the risk of coding would be corporations with large legal departments. I'd have to move to a country that doesn't have these laws instead, which is exactly where all the software jobs will migrate to (even faster than they are already migrating now).

    • have things set so that REASONABLE EFFORTS are required. Now the lawyers can sort out the meaning of the term but if you have done everything possible (input checking and not using known unsafe code ect) then you should be safe from being sued.

      Also if something is later found to be "unsafe" then the required patch/update should be given out free to existing customers (no fair bundling an error fix with a program feature update just to be able to sell the update). Now yes this should have a reasonable limit

  • by ka9dgx ( 72702 ) on Thursday September 29, 2011 @05:07PM (#37560366) Homepage Journal

    The responsibility for preventing security problems with PCs should strictly fall into 2 places, the User, and the OS.... however... not the way 99.99% of you are thinking about it.

    The user should decide what resources a program NEEDS in order to do a task, such as which folder it can access, what network connections, etc. This allows the user to decide ahead of time what they are willing to risk. Once that determination is made, the user then would give that list, along with a pointer to the program, to the operating system.

    The OS should then enforce the users choices.... if it's not in the list, the application shouldn't even be able to find it, let alone access it. If the OS fails to enforce the users will, then the OS is at fault.... if the User gave away the store, well... they gave away the store.

    This requires a simple change to the base design of operating systems, instead of permitting everything, and limiting actions of a running program to that of the user's account... the OS should limit the actions of the program to a short list of resources supplied by the user... and nothing else. Of course, the refactoring of everything to add this additional layer of logic is a massive undertaking.

      There would still be the traditional user rights, access control lists, etc.... but there would also be a level of control where the user decides which of the resources they have should be given to the application. This is called "capability based security", or cabsec for short.

    It's going to take somewhere between 10 and 15 years before people are fed up enough to make the switch.... but it will happen eventually.

    Security isn't an application issue... it never was, and never will be.

    • by h4rr4r ( 612664 )

      This is called SElinux. It already exists and is in wide use.

      • by ka9dgx ( 72702 )

        No... it's not... SE Linux and App Armour enforce static rules.... not dynamic ones decided by users. However... it is a step in the right direction.

        • by h4rr4r ( 612664 )

          You can make your own SELinux policy all you want. I fail to see how that does not fulfill this.

          • by 0123456 ( 636235 )

            You can make your own SELinux policy all you want.

            Good luck with that.

            Apparmor is hard enough for a typical user to configure, SELinux seems to be pretty much impossible unless you're an expert.

  • So who is held libel when the user gets an email that says they've won millions of dollars if they click this link, ignore the security warning telling them they probably shouldn't click the link, and proceed to install some malware from god knows where?

    If you're telling me that I am... well that's fine, becuase you're no longer allowed to click links. Or install stuff. Or do anything other then what I've whitelisted. Congratulations, you no longer have a PC.

  • The advantage for paper is that you need physical access to break its security. Paper in a safe is even better. And every educated person understands the characteristics of pen and paper, while understanding IT security requires an expert (I am one). I personally have some things on paper that I would not put on my computer.

    So, yes, this is an indication of failure on the part of rolled-out IT security, but it is not a problem. At least I do not see one here.

  • If you do not want to accept the information sharing in Clause 1, you would fall under Clause 2 and have to live with normal product liability, just as manufacturers of cars, blenders, chainsaws, and hot coffee do. How dire the consequences and what constitutes "used normally" are for the legislature and courts to decide.

    An example: A salesperson from one of your longtime vendors visits and delivers new product documentation on a USB key. You plug the USB key into your computer and copy the files onto the c

  • If the consequences of the poorly written code are negligible, who cares.

    If the user can take well known preventative measures to avoid damages, and don't, then they are liable.

    If a software fault causes damage to life or property, then the liability of the developer is a serious consideration.

    A lot of research has been done to improve software engineering practices to make software more reliable. A lot of research has been done in computer science to prove algorithms. If you're writing mission critical s

  • There's nothing wrong with pen and paper. Computers don't "replace" pen and paper, they "add" to pen and paper. That's always been the case. Just look at data storage. Pen and paper, subject to fire and flood, but otherwise reliable for ages. Computer storage can die for any number of reasons, but you can duplicate it thousands of times easily. That's the safety net.

    Today, welcome to the internet, your computer is accessible -- by the way, you didn't need to plug it in -- so it's accessible to all. B

  • In contracts for software projects, rules to guarantee certain safety and security levels are already present. In embedded systems and trading platforms, there are even laws in place which define how safe something has to be. For example the Safety Integrity Levels are used to define how many failures may occur before violating the law. Similar stuff exists for security. The real problem is, that no one in low risk areas is willing to pay for higher safety and security levels. Present end user software is t

  • by Animats ( 122034 ) on Thursday September 29, 2011 @10:10PM (#37562528) Homepage

    I proposed, back in 2000, that Microsoft be required to provide a full warranty on their products [animats.com] as part of their antitrust remedy. "Full warranty" has specific meaning in US law; see the article. A few vendors have provided full warranties and not found it too expensive. Notably, GTech, which builds gambling systems, is held financially responsible for errors made by those systems. This costs GTech less than half of one percent of their revenue.

    It's time for the computer industry to grow up and take on warranty responsibilities. The auto industry had that forced on them by Congress in the 1960, over the screams of the auto industry. Cars rapidly became safer and more reliable.

Enzymes are things invented by biologists that explain things which otherwise require harder thinking. -- Jerome Lettvin

Working...