Difference between revisions of "Andrew"

From CSEP590TU
Jump to: navigation, search
(Burden reconsidered...free software and license enforceability)
Line 1: Line 1:
Santtu: Discussion on threatened targets will cover the threats posed by integration of computer systems into an ever increasing number of devices and areas where the effect of attacks may extend from disruption of service and to life threatening. such as health and financial record management, everyday appliances, and military equipment.
+
  Thurrott, Paul. “SuperSite for Windows.” 20 Nov. 2004 <http://www.winsupersite.com/reviews/winserver2k3_gold2.asp>
 
+
  Intel Corporation. “Intel Unviels World’s Most Advanced Chip-Making Process.” 20 Nov. 2004 <http://www.intel.com/pressroom/archive/releases/20020813tech.htm>
Andrew proposed: This chapter examines who is ultimately responsible for the costs incurred through security flaws and exploitations? How does this differ when the software is produced by corporations, individuals or an open sourced project? What kind of incentives are there for companies/open source groups to produce more reliable software? Can these incentives be improved?
+
  Collins, Robert R. “Intel Errata.” Dr. Dobb’s Journal. 20 Nov. 2004 <http://x86.ddj.com/errata/errataseries.htm>
 
+
  Microsoft Corporation. “Computer Hangs after 49.7 Days.” 20 Nov. 2004 <http://support.microsoft.com/kb/q216641>
Responsibility should scale with the importance of usage. Does a click-wrap license or a disclaimer in an OSS license indemnify the creator of the software of all responsiblity? Do corporate products incur more liability than OSS projects? What responsibility does a software vendor have to society? If a single vendor holds a significant portion of the market is there a greater responsibility to protect the users of this network? Software which controls critical societal infrastructure (such as an automobile, a power plant or a voting machine) is at the far end of this scale. Are governments choosing software responsibly?
+
  Dallman, John. “49.7 day ‘overloaded with data’ in Los Angeles.” Risks Digest 23.54. 20 Nov. 2004 <http://catless.ncl.ac.uk/Risks/23.54.html#subj10.1>
 
+
  Microsoft Corporation. “WM_TIMER Messages May Stop Being Delivered to Programs in Windows 2000.” 20 Nov. 2004 <http://support.microsoft.com/kb/q322913>
What incentives exist to produce secure software? Would legal liability be a greater incentive or a disincentive to innovate? Would anyone produce important but risky software if their company were potentially liable for all damages resulting from usage of that software?
+
  Norman, Donald A. The Psychology of Everyday Things. New York: Basic Books (Harper Collins), 1988. pp. 34-36.
 
+
  Poulsen, Kenneth L. “Software bug contributed to blackout.” Risks Digest 23.18. 20 Nov. 2004 <http://catless.ncl.ac.uk/Risks/23.18.html#subj1>
=== Top ===
+
  Schauble, Paul. “Software developer’s liability.” Risks Digest 3.4. 20 Nov. 2004 <http://catless.ncl.ac.uk/Risks/3.04.html#subj2.1>
 
+
  Internal Revenue Service. Handbook for Authorized IRS e-file Providers of Individual Income Tax Returns. 20 Nov. 2004 <http://www.irs.gov/pub/irs-pdf/p1345.pdf>
Computers and software are immensely complex engineering feats. Windows Server 2003 was written by about 5000 developers working on over 50 million lines of code (interview with Microsoft Distinguished Engineer Mark Lucovsky at http://www.winsupersite.com/reviews/winserver2k3_gold2.asp .) Intel's "Prescott" microprocessor contains 330 million transistors in an area the size of a fingernail.( http://www.intel.com/pressroom/archive/releases/20020813tech.htm .)
+
  Block Financial Corporation. TaxCut End-User License Agreement. 20 Nov. 2004 <http://www.taxcut.com/license/TCB2003.pdf>
 
+
  Kaner, Cem. Bad Software: What to do when Software Fails. New York: Wiley Computer Publishing, 1998. 178-181.
Given their complexity it's not surprising that we've had the kind of problems we've had with computers. While popular awareness of hardware bugs is limited, Intel (for one) has had a number of issues with their microprocessors. Two of the most famous were the FDIV bug of 1994 and the F00F bug of 1997. ( http://x86.ddj.com/errata/errataseries.htm .) The former returns incorrect results for a particular class of floating-point division operations. The latter freezes the microprocessor, halting the system and, on a network server, any systems relying upon that system. Software problems, though often less serious, are more well known. One issue which had serious repurcussions is that Windows 95 and Windows 98 can cause the computer to hang after 49.7 days of continuous operation. The LAX air traffic radio communications system relies on a monthly manual reboot of the system as a workaround to this bug. ( http://catless.ncl.ac.uk/Risks/23.54.html#subj10.1, http://support.microsoft.com/kb/q216641/ .) A similar bug exists in Windows 2000 wherein parts of programs can stop working after the computer has been running for 497 days (http://support.microsoft.com/default.aspx?scid=kb;en-us;322913 .)
+
  IDG.net. “UTICA: Summary Information.” 20 Nov 2004 <http://cgi.infoworld.com/cgi-bin/displayStory.pl?/features/990531ucita_home.htm>
 
+
  Landau, Philip J. “Comment: Products Liability in the New Millenium: Products Liability and the Y2K Crisis.” The Richmond Journal of Law and Technology VI:2. 20 Nov. 2004. <http://law.richmond.edu/jolt/v6i2/note4.html>
We have come to expect that computers are naturally prone to failure. ''DOET--making excuses.'' Rina Piccolo drew a cartoon for King Features' comic strip "Six Chix" which depicts two secretaries playing solitaire with cards on their desks. One is speaking on the phone saying "Our computers are down so we have to do everything manually." The cartoon is funny because its subject--that computers sap productivity through both diversion and failure--is universal amongst computer users. But one of the main reasons we are willing to accept low quality in software is that a large number of the functions performed by computers are essentially unimportant. But what happens when we employ this increasingly complex process to perform what should be a simple task?
+
  Interestingly, Dr. Knuth pays a small bounty to every person who finds a bug in his software, documentation or books. Kinch, Richard K. “An example of Donald Knuth’s Reward Check” 20 Nov. 2004 <http://truetex.com/knuthchk.htm>
 
+
  Heckman, Corey. “Two Views on Security Software Liability: Using the Right Legal Tools”. IEEE Security & Privacy. 1:1 (2003): pp. 73-75.
=== Consumer-grade software ===
+
  Raymond, Eric. The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. Sebastapol, CA: O’Reilly, 1999. p. 32.
 
+
  The secondary effect of getting contributions to make the program better without extra effort is often not seen in open-source software. Usually the number of contributors is extremely small compared to the number of users.
In 1986, when the tax preparation software industry was barely in existence, the IRS ruled that authors of tax software may be liable for advice given to taxpayers ( http://catless.ncl.ac.uk/Risks/3.04.html#subj2.1 .) To treat software providers as one treats a tax advisor is a reasonable decision at first blush--after all, the software at some level gives advice to a taxpayer. Now that tax software is big business the liability of the software industry seems diminished. The license of one popular program, TaxCut 2003, clearly specifies that "While Block (the vendor of TaxCut 2003) is providing the Software as a general tool to assist you in preparing and/or filing your tax returns, the software does not replace your obligation to exercise your independent judgement in using the software. Your use of the Software does not make Block your tax preparer... Block does not warrant any particular results that you may obtain in using the Software." ( (emphasis removed) http://www.taxcut.com/license/TCB2003.pdf .) The IRS's current guidelines for e-File providers specify that the software used to file tax returns must pass a test which verifies, in part, that "returns have few validation or math errors." ( http://www.irs.gov/pub/irs-pdf/p1345.pdf .) Who should be liable when a consumer trusts software to do the math on his tax return correctly? What should be the extent of the liability given that punishment for tax fraud can include large monetary penalties and even jail time?
+
  Office of the Secretary, Department of Homeland Security. Federal Register 68:200. (2003).
 
+
  Office of Regulatory Affairs, Department of Health and Human Services. “Guidance for Industry: Computerized Systems Used in Clinical Trials” 20 Nov. 2004 <http://www.fda.gov/ora/compliance_ref/bimo/ffinalcct.htm>
One argument goes along with the 1986 IRS ruling in making the software vendor liable for errors in tax preparation software. The Uniform Commercial Code provides an implied warranty of merchantability: essentially, that the product will do what it is sold to do. One would expect that tax software would perform mathematical calculations correctly. Errors in the software could be construed as negligence if it were shown that the vendor should have tested that their product was suitable for sale before selling it. In the case of ''United States vs. Carroll Towing Co.'' Judge Learned Hand stated a formula to test a company's duty to see that their product does not cause harm. This formula was a function of three variables: ''P'', the probability of failure, ''L'', the gravity of resulting injury given a failure, and ''B'', the burden of adequate precautions. If B is smaller than the product of P and L (B < PL) then the software vendor is negligent. ( http://law.richmond.edu/jolt/v6i2/note4.html .)
+
  Assistant Secretary for Legislation, Department of Health and Human Services. “Statement on Medical Devices and the Year 2000 Computer Problem by William K. Hubbard” 20 Nov. 2004 <http://www.hhs.gov/asl/testify/t990525a.html>
 
+
  The XA/21 system had a bug due to a race condition which is a well-documented problem in the Linux kernel’s swapping of pages in memory. Bovet, Daniel and Cesati, Marco. Understanding the Linux Kernel. Sebastapol, CA: O’Reilly, 2001. pp. 474-474.
Given the combinatorial complexity of a software program what is the burden of "adequate" testing for bugs? While the software vendor can be expected to test that their software performs some calculations properly it cannot test all combinations of input parameters. Just a single IRS tax form, the 2003 Form 1040, has 74 lines, about 90% of which are inputs. Even testing all of the possible mathematical inputs to the program (which has the ability to prepare many different forms) would be impossible given the available time between when tax forms are made published and the date that the program must make it to market to be valuable for tax filers. And the testing of routine mathematical inputs would be trivial compared to testing logical decisions made on "corner cases" which are not commonly exercised in the program's operation.
 
 
 
What is the probability of there being a bug in the program? Few programmers would claim to have written a program free of bugs. One of these bold few was Dr. Donald Knuth author of (amongst other things) the ''TeX'' typesetting software. Dr. Knuth said in the preface to his book ''TeX: The Program'' that he "believe[s] that the final bug in TeX was discovered and removed on November 27, 1985." ( http://truetex.com/knuthchk.htm ) And yet bugs were still being uncovered--if infrequently--ten years later.
 
 
 
What is the gravity of injury resultant from a failure? In the example of tax software, no one dies when an error is made. And it is likely that a demonstration of software failure would help to demonstrate that intention to defraud did not exist in an erroneous income tax filing. The biggest threat posed to an individual consumer by a non-networked computer and consumer grade software may well be the risk of musculoskeletal disorders from use of keyboards and mice. But as computers are embedded into new areas of our life the potential for serious injury increases.
 
 
 
''examples of this? or different direction?''
 
 
 
=== Burden reconsidered...free software and license enforceability ===
 
 
 
The opposite argument takes the position that the burden of complete testing is too high compared to the reward of producing software. An extreme example is the case of the open source free software project. What would be the consequences if the principle author of "Open Tax Solver" (an actual open-source tax software project) were held liable in the same way as a professional tax advisor?
 
 
 
Software developers generally create software because they have identified a problem they want to solve. As Eric Raymond wrote, "Every good work of software starts by scratching a developer's personal itch." ( http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html ) This is as true of open-source developers working in their free time on a "labor of love" as it is of salaried programmers at giant software companies such as Microsoft. The difference is, of course, that programmers at Microsoft will continue to develop programs in which they may have lost personal interest because responsibility for the work comes with the reward of a paycheck. The reward for the open source programmer may have been limited to intellectual curiousity and might have disappeared as soon as the program was released to its users.  
 
 
 
Open-source licenses, while varied, have a common theme of providing no warranty to the user. As open-source software is often free (of cost) software (''footnote'' "free" referring to "software gratis", not "software libre" or, as it Richard Stallman says, "free as in beer, not free as in speech) there is no warranty of merchantability implied becasue there may have been no sale. The open source developer is seen as a "good samaritan": by freely providing aid without reward to someone in need (someone with the same itch, perhaps, but not the ability to scratch it) one is not held liabile for negligence which may have caused an injury in the giving of that aid. Put bluntly, I wrote this software because I found it useful. Because you may find it useful I make it freely available to you. If it breaks, you get to keep both halves.  
 
 
 
''Introducing a cost to the software doesn't change things much...this is a continuum. The cost of fully testing software is infinite. The rewards to innovate are limited. Who would make voting software if a world war were at stake? Who would make nuclear plant management software if there were a possiblity of such blame?
 
 
 
Medical software...FDA certification. Absolution?
 
 
 
'''stuff'''
 
The implied warrant of merchantability can be waived if notification is provided to the buyer in "conspicuous writing...prior to the sale" ( Cem Kaner's ''Bad Software'', 1998, and at http://www.badsoftware.com/support1.htm .) Generally accepted that license exemptions are unenforceable.
 
 
 
=== Bottom ===
 

Revision as of 23:39, 20 November 2004

 Thurrott, Paul. “SuperSite for Windows.” 20 Nov. 2004 <http://www.winsupersite.com/reviews/winserver2k3_gold2.asp>
 Intel Corporation. “Intel Unviels World’s Most Advanced Chip-Making Process.” 20 Nov. 2004 <http://www.intel.com/pressroom/archive/releases/20020813tech.htm>
 Collins, Robert R. “Intel Errata.” Dr. Dobb’s Journal. 20 Nov. 2004 <http://x86.ddj.com/errata/errataseries.htm>
 Microsoft Corporation. “Computer Hangs after 49.7 Days.” 20 Nov. 2004 <http://support.microsoft.com/kb/q216641>
 Dallman, John. “49.7 day ‘overloaded with data’ in Los Angeles.” Risks Digest 23.54. 20 Nov. 2004 <http://catless.ncl.ac.uk/Risks/23.54.html#subj10.1>
 Microsoft Corporation. “WM_TIMER Messages May Stop Being Delivered to Programs in Windows 2000.” 20 Nov. 2004 <http://support.microsoft.com/kb/q322913>
 Norman, Donald A. The Psychology of Everyday Things. New York: Basic Books (Harper Collins), 1988. pp. 34-36.
 Poulsen, Kenneth L. “Software bug contributed to blackout.” Risks Digest 23.18. 20 Nov. 2004 <http://catless.ncl.ac.uk/Risks/23.18.html#subj1>
 Schauble, Paul. “Software developer’s liability.” Risks Digest 3.4. 20 Nov. 2004 <http://catless.ncl.ac.uk/Risks/3.04.html#subj2.1>
 Internal Revenue Service. Handbook for Authorized IRS e-file Providers of Individual Income Tax Returns. 20 Nov. 2004 <http://www.irs.gov/pub/irs-pdf/p1345.pdf>
 Block Financial Corporation. TaxCut End-User License Agreement. 20 Nov. 2004 <http://www.taxcut.com/license/TCB2003.pdf>
 Kaner, Cem. Bad Software: What to do when Software Fails. New York: Wiley Computer Publishing, 1998. 178-181.
 IDG.net. “UTICA: Summary Information.” 20 Nov 2004 <http://cgi.infoworld.com/cgi-bin/displayStory.pl?/features/990531ucita_home.htm>
 Landau, Philip J. “Comment: Products Liability in the New Millenium: Products Liability and the Y2K Crisis.” The Richmond Journal of Law and Technology VI:2. 20 Nov. 2004. <http://law.richmond.edu/jolt/v6i2/note4.html>
 Interestingly, Dr. Knuth pays a small bounty to every person who finds a bug in his software, documentation or books. Kinch, Richard K. “An example of Donald Knuth’s Reward Check” 20 Nov. 2004 <http://truetex.com/knuthchk.htm>
 Heckman, Corey. “Two Views on Security Software Liability: Using the Right Legal Tools”. IEEE Security & Privacy. 1:1 (2003): pp. 73-75.
 Raymond, Eric. The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. Sebastapol, CA: O’Reilly, 1999. p. 32.
 The secondary effect of getting contributions to make the program better without extra effort is often not seen in open-source software. Usually the number of contributors is extremely small compared to the number of users.
 Office of the Secretary, Department of Homeland Security. Federal Register 68:200. (2003).
 Office of Regulatory Affairs, Department of Health and Human Services. “Guidance for Industry: Computerized Systems Used in Clinical Trials” 20 Nov. 2004 <http://www.fda.gov/ora/compliance_ref/bimo/ffinalcct.htm>
 Assistant Secretary for Legislation, Department of Health and Human Services. “Statement on Medical Devices and the Year 2000 Computer Problem by William K. Hubbard” 20 Nov. 2004 <http://www.hhs.gov/asl/testify/t990525a.html>
 The XA/21 system had a bug due to a race condition which is a well-documented problem in the Linux kernel’s swapping of pages in memory. Bovet, Daniel and Cesati, Marco. Understanding the Linux Kernel. Sebastapol, CA: O’Reilly, 2001. pp. 474-474.