All of the material below was gleaned from "Risks to the Public" by Peter G. Nuemann and contributors. The archives are most easily reached at http://www.risks.org ------------------------------------------------------------------------------- Using the technology: England's NHS loses patient data: bad news, good news, bad news > Sun, 25 Jan 2009 03:33:10 -0500 Bad news: A National Health Service employee lost a flash drive containing personal information of up to 6,360 patients. Good news: The data on the flash drive was encrypted. Bad news: The password was written on a sticky-note attached to the drive. Paraphrased from the *Lancashire Evening Post* http://www.lep.co.uk/news/Apology-after-prisoners39-health-info.4862265.jp =============================================================================== TSA Loses Hard Drive With Personal Info <"Peter G. Neumann" > Tue, 8 May 2007 16:48:46 PDT The U.S. Department of Homeland Security's Transportation Security Administration reported that it had lost a portable computer hard drive containing Social Security numbers, bank data, and payroll information for about 100,000 employees from Jan 2002 to Aug 2005. [Source: AP item in *The New York Times*, 5 May 2007] http://topics.nytimes.com/top/reference/timestopics/organizations/t/transportation_security_administration/index.html?inline=nyt-org =============================================================================== Digital road sign in Austin, TX was altered to read, "Zombies Ahead." > Thu, 29 Jan 2009 15:23:13 +0000 Excerpts from http://www.foxnews.com/story/0,2933,484326,00.html : Transportation officials in Texas are scrambling to prevent hackers from changing messages on digital road signs after one sign in Austin was altered to read, "Zombies Ahead."* ...The sign was reverted back to its original message within hours... the signs are tamper-resistant and equipped with external locks. According to the blog i-hacked.com, some commercial road signs, including those manufactured by IMAGO's ADDCO division, can be easily altered because their instrument panels are frequently left unlocked and their default passwords are not changed. "Programming is as simple as scrolling down the menu selection," i-hacked.com reports. "Type whatever you want to display -- In all likelihood, the crew will not have changed [the password]." =============================================================================== Political risks of poorly configured email advocacy > Sat, 31 Jan 2009 10:59:04 -0500 In the UK last week, Greenpeace asked its supporters to email their MP on the issue of runway expansion at Heathrow. Apparently, the email system in question was set up to send the supporter's email to their own MP -- and to copy the email to all the other targeted MPs on the system. As a result, 57 MPs each got thousands of emails in three or four hours. Hilarity ensued. What makes this interesting: the 57 targeted MPs are all *supporters* of Greenpeace's position, who were being asked in the emails to hold firm in their support. =============================================================================== Canadian do-not-call list becomes valuable telemarketing database > Sat, 24 Jan 2009 10:22:15 -0500 The Consumers' Association of Canada says it has been inundated with complaints from people who have been called by scam artists after placing their telephone numbers on the registry, which went into effect last September. The do-not-call list was created to prevent telemarketers from contacting people who do not want to be pestered with uninvited sales pitches. For companies to find out who they are not permitted to call, the Canadian Radio-television and Telecommunications Commission sells the list online for a fee. "You can buy any list you want of people who subscribe to the do-not-call registry online. The whole of Toronto costs you 50 bucks for 600,000 names," Bruce Cran, president of the CAC, said in a telephone interview yesterday. "That's just perfect for any telemarketer, because these are good names which they would otherwise have to pay money for to verify. In addition to that, there's no index list of cell phone numbers that you can get. However, people were encouraged to put their cell phone numbers on there as well." Source: Fraudsters abusing do-not-call list, *The Globe and Mail*, 23 Jan 2 009 http://www.theglobeandmail.com/servlet/story/RTGAM.20090123.wdonotcall23/BNStory/National/home The article makes it sound like names are also included in the lists, but the DNCL website seems to indicate otherwise (unless, of course, reverse-lookup is used with other public listings): http://www.crtc.gc.ca/ENG/INFO_SHT/t1028.htm =============================================================================== =============================================================================== American Express, a model of good corporate practice? Amex goes phishing <"James J. O'Donnell" > January 22, 2009 5:36:54 PM EST [From Dave Farber's IP] Got messages on various accounts over the weekend from American Express to tell cardholders that their 2008 year-end statement is online. Just click on this address, it said, giving an address. If you mouse-overed the address, a different address appeared in the status bar, and if you clicked on the address, you went to a third uniquely different address. I did so, on a machine that could be cleaned if it were compromised, twice. What I found when I got there is that after you clicked on the nonconforming link, you went to a page that asked you to input credit card information: either your existing login/password for the amex site *or*, if you didn't have login/pwd yet, to input your actual credit card information including card number, expiry date, and 4-digit "security code". Now I believe that the message was in fact legit: came from Amex and led you to a site that was what it said it was. What gobsmacked me was that Amex was using classic phishing technique to get you to their site, and asked you once there to engage in *exactly* the behavior that we tell everybody not to behave in. So what happened? Today we got two messages that obviously responded to the incomplete logins yesterday -- alerts to tell us that there was a problem with that account due to multiple attempted logins and asking us to login to the site to check and confirm information there. The "security messages" took exactly the same form: please click on this inconsistent URL and when you get to the page referenced, go ahead and input confidential information. I phoned Amex and nobody on their standard phone lines understood the issue, but they got me eventually to corporate in NYC and I spoke to someone in "investigations" who got what I was saying instantly and I could hear him shaking his head. He said he'd get on it. Archives: https://www.listbox.com/member/archive/247/=now =============================================================================== American Express Kept a *Very* Watchful Eye on Charges (Ron Lieber) > Sat, 31 Jan 2009 00:11:59 -0500 YOUR MONEY Ron Lieber, American Express Kept a (Very) Watchful Eye on Charges, *The New York Times*, 31 Jan 2009 You probably know that credit card companies have been scrutinizing every charge on your account in recent years, searching for purchases that thieves may have made. Turns out, though, that some of the companies have been suspicious of your own spending, too. In recent months, American Express has gone far beyond simply checking your credit score and making sure you pay on time. The company has been looking at home prices in your area, the type of mortgage lender you're using and whether small-business card customers work in an industry under siege. It has also been looking at how you spend your money, searching for patterns or similarities to other customers who have trouble paying their bills. In some instances, if it didn't like what it was seeing, the company has cut customer credit lines. It laid out this logic in letters that infuriated many of the cardholders who received them. "Other customers who have used their card at establishments where you recently shopped," one of those letters said, "have a poor repayment history with American Express." It sure sounded as if American Express had developed a blacklist of merchants patronized by troubled cardholders. But late this week, American Express told me that wasn't the case. The company said it had also decided to stop using what it has called "spending patterns" as a criteria in its credit line reductions. ... http://www.nytimes.com/2009/01/31/your-money/credit-and-debit-cards/31money.html =============================================================================== =============================================================================== Is there something you don't know ?? Reported impending asteroid was actually Rosetta > Wed, 14 Nov 2007 14:37:21 -0800 [Incoming stone was actually Rosetta stone? PGN] To make a long story short, The Minor Planet Center, the world clearinghouse for information about newly discovered asteroids, raised the alarm last week to track a threatening celestial body. This would be one of the closest approaches ever by a sizable asteroid -- its distance away being less than half the diameter of the Earth. They announced that a previously unknown asteroid would miss the Earth by just 5,600 kilometers. Then Denis Denisenko, of Moscow's Space Research Institute (IKI), made an interesting discovery. He noticed that the incoming asteroid's track matched that of the European space probe Rosetta on a scheduled flyby of Earth. The Rosetta craft was launched from Europe's Guiana Space Center in early March of 2004; the purpose of the space probe is to place itself in low orbit around the comet Churyumov-Gerasimenko at a distance of 675 million kilometers from the sun. To get there, the billion-dollar craft will spend ten years boosting its velocity (using the gravity assist technique) with no fewer than three flybys of Earth and one of Mars. [Source: Bill Christensen, Near-Miss Asteroid Found to be Artificial, 12 Nov 2007; PGN-ed. Bill was reminded of Arthur C. Clarke's Rendezvous with Rama.] http://www.space.com/businesstechnology/071112-technov-asteroid-mistake.html [Mark Brader noted a BBC item: http://news.bbc.co.uk/1/hi/sci/tech/7093402.stm and *The Register* did an amusing take: "Muscovite skywatcher Denis Denisenko revealed that the menacing meteor was in fact [STRUCK THROUGH: a European Union space battleship bent on world domination] the European Space Agency Rosetta probe, passing close to Earth for a long-planned gravity-assist "slingshot" manoeuvre.] http://www.theregister.co.uk/2007/11/13/rosetta_asteroid_spacecraft_patrick_moore_cockup/ =============================================================================== =============================================================================== Why is this so hard? Touch typing > Wed, 25 Apr 2007 11:50:10 -0700 I have long been a fluent touch typist. I consider Typing to have been the high-school course that has been most useful during my professional career. Early this year I started noticing increasing problems with my typing. Sometimes characters would be dropped. As many as half of them. When things got bad, even if I slowed down and typed a single character at a time, I lost quite a few. I was sometimes reduced to a mode of typing a character, seeing if it appeared on the screen, and then either typing it again or proceeding to the next character. I found this quite distressing. Initially, I thought it might be my keyboard, since I'd fairly recently acquired a new ergonomic keyboard. However, swapping the old keyboard back in didn't help. I thought maybe I'd done something to mess up my software configuration, but checking all the settings I could think of that might be relevant didn't turn up anything out of the ordinary, and none of the changes I tried seemed to help. (Deleting Temporary Internet Files did sometimes seem to help a little bit, as did exiting Internet Explorer and restarting it.) I found that I had the same problem on both my home and office computers, which made it seem unlikely that it was a problem with my hardware. The problem seemed most acute when using Blogger, but checking the Help and searching the Web turned up no indication that anyone else was seeing this problem with Blogger. And it didn't only happen when I was using Blogger. By this time I had to consider the possibility that the common factor was me. My neurologist ran some tests, and concluded that this was NOT peripheral neuropathy affecting my fingers (although I did have a mild case of Carpal Tunnel Syndrome that cleared up very quickly wearing wrist splints at night). The penny dropped yesterday during a frustrating session creating a new blog post: I realized that the typing problem had started when I converted to Internet Explorer version 7, with its feature of "tabbed browsing," which I rather like. I typically have four to ten tabs open at any given time, more when I'm looking for information and links to put into my blog posts. The troublesome combination was typing into an IE form (e.g., the Blogger editor) while having a large number of tabs open. I quickly tested this by opening a second IE window with only a single tab for Blogger, leaving the other window on the screen with all its tabs still open. Glory be! I could touch-type at my old speed once again! It appears that IE 7's input de-multiplexing routine is so inefficient that it can't reliably keep up with a couple of characters per second when there are more than about six tabs open, even on a dual-core Pentium D 3.40 GHz processor with a 1 GB memory! This seems so preposterous to me that I'm asking for other IE 7 users to do the experiment and let me know if they see the same thing; alternatively, perhaps someone else can offer me a better explanation. [We have nothing to fear but Blogosphere. FDR-PGN] =============================================================================== =============================================================================== Software can mess up your hardware Browns Ferry 3 nuclear power site scrammed <"Peter G. Neumann" > Tue, 8 May 2007 10:58:28 PDT This is another example of a system environment in which components that were supposedly not safety related could compromise safety. The case is of considerable interest to RISKS. On 19 Aug 2006, operators manually scrammed Browns Ferry, Unit 3, following a loss of both the 3A and 3B reactor recirculation pumps, as required after the loss of recirculation flow -- which placed the plant in a high-power, low-flow condition where core thermal hydraulic stability problems may exist at boiling-water reactors (BWRs). Generally, intentional operation is not permitted under this condition. Although some BWRs are authorized for single loop operation, sudden loss of even one pump could present the plant with the same stability problems and could result in the reactor protection system initiating a shutdown of the plant. [Source: Effects of Ethernet-based, Non-safety Related Controls on the Safe and Continued Operation of Nuclear Power Stations, United States Nuclear Regulatory Commission, Office of Nuclear Reactor Regulation, Washington, DC 20555-0001, 17 Apr 2007; PGN-ed, although the following text is abridged but unedited.] http://www.nrc.gov/reading-rm/doc-collections/gen-comm/info-notices/2007/in20075.pdf The initial investigation into the dual pump trip found that the recirculation pump variable frequency drive (VFD) controllers were nonresponsive. The operators cycled the control power off and on, reset the controllers, and restarted the VFDs. The licensee also determined that the Unit 3 condensate demineralizer controller had failed simultaneously with the Unit 3 VFD controllers. The condensate demineralizer primary controller is a dual redundant programmable logic control (PLC) system connected to the ethernet-based plant integrated computer system (ICS) network. The VFD controllers are also connected to this same plant ICS network. Both the VFD and condensate demineralizer controllers are microprocessor-based utilizing proprietary software. The licensee determined that the root cause of the event was the malfunction of the VFD controller because of excessive traffic on the plant ICS network. Testing by site personnel performed on the VFD controllers confirmed that the VFD control system is susceptible to failures induced by excessive network traffic. The threshold levels for failure of the VFD controllers due to excessive network traffic, as determined by the on-site testing, can be achieved on the existing 10-megabit/second network. The NRC staff's review of industry literature and test reports on network device sensitivity, and the threshold levels for such failures, confirmed these testing results. The licensee could not conclusively establish whether the failure of the PLC caused the VFD controllers to become nonresponsive, or the excessive network traffic, originating from a different source, caused the PLC and the VFD controllers to fail. However, information received from the PLC vendor indicated that the PLC failure was a likely symptom of the excessive network traffic. To ensure that excessive network traffic will not cause future Unit 3 VFD controller malfunctions, the licensee disconnected these devices from the plant ICS network before restart. The licensee also disconnected the Unit 2 VFD controllers from the plant ICS network. Licensee corrective actions included (1) developing a network firewall device that limits the connections and traffic to any potentially susceptible devices on the plant ICS network and (2) installing a network firewall device on each unit -- VFD controller and condensate demineralizer controller. The Browns Ferry Unit 3 event is discussed in Licensee Event Report 05000296/2006-002, dated October 17, 2006, Agencywide Documents Access and Management System, Accession No. ML062900106. The reason the licensee at Browns Ferry investigated whether the failure of one device, the condensate demineralizer PLC, may have been a factor in causing the malfunction of the VFD controllers is that there is documentation of such failures in commercial process control. For instance, a memory malfunction of one device has been shown to cause a data storm by continually transmitting data that disrupts normal network operations resulting in other network devices becoming locked up or nonresponsive. A network found to be operating outside of normal performance parameters with a device malfunctioning can effect devices on that network, the network as a whole, or interfacing components and systems. The effects could range from a slightly degraded performance to complete failure of the component or system. Major contributors to these network failures can be the addition of devices that are not compatible, network expansion without a procedure and a overall network plan in place, or the failure to maintain the operating environment for legacy devices already on the network. While only non-safety related network devices became nonresponsive at Browns Ferry Unit 3, it is important to protect both safety-related and non-safety related devices on the plant network to ensure the safe operation of the plant. The 19 Aug 2006, transient unnecessarily challenged the plant safety systems and placed the plant in a potentially unstable high-power, low-flow condition. The potential safety implications for future similar events would depend on the type of devices that are connected to the plant ethernet. Careful design and control of the network architecture can mitigate the risks to plant networks from malfunctioning devices, and improper network performance, and ultimately result in safer plant operations. =============================================================================== Washington DC Metro replacing software that causes fires > Sat, 14 Apr 2007 07:35:47 -0400 This is certainly not the only case of software causing a physical problem, but it's one of the more unusual ones I've run across. Metro (Washington DC's subway system) is one of the more automated subway systems around. The key to the problem seems to be as follows: "The fire [on Easter Sunday] started after a sensor underneath the rail car failed, causing the voltage in the car to rise. At the same time, the software designed to monitor the flow of electricity also failed, causing overheating in the resistor grid, an electrical component under the car that absorbs excess energy, officials said. A Metro official said the software was not designed to take into account the failure of the voltage sensor. A check of all affected rail cars found no other bad sensors, officials said." As I've been spending a lot of time working on electronic voting issues, I thought about how a few simple word changes might explain some of the voting system failures we've seen - perhaps failures of sensors on touch screens are causing unexpected interactions. This is just an hypothesis - but shows that just as Metro undoubtedly spent millions of dollars testing the rail cars without finding this problem (until a serious fire brought it to their attention), so too might similar problems occur in voting systems. The difference is that in today's paperless voting systems, the fire is smoldering quietly and unseen - but still doing damage. =============================================================================== =============================================================================== Do you trust your GPS? Another sat-nav accident: car destroyed, driver escapes Sat, 12 May 2007 01:05:30 -0400 (EDT) Accepting satellite-navigation directions without sufficient thought has caused another accident. A young woman in Great Britain followed its directions onto a country lane which was blocked by a gate. At first she thought it was a dead end, she said, but "the sat nav insisted it was the correct way so I opened it and drove through." After the first gate there was a second one, so she got out to close the first gate and open the second one, apparently not thinking about why there might be two gates across a road, or why there was a sign saying to proceed "if the light is green". (None of the news reports I found says any more about that light than that the sign existed.) And while she was out of her car, a train came along the tracks and demolished it. http://news.bbc.co.uk/2/hi/uk_news/wales/south_west/6646331.stm http://icwales.icnetwork.co.uk/0100news/0200wales/tm_headline=sat-nav-guides-driver-into-path-of-train&method=full&objectid=19083438&siteid=50082-name_page.html http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2007/05/11/nsatnav11.xml http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=453991&in_page_id=1770 =============================================================================== When banking real time isn't really real time > Thu, 05 Apr 2007 01:07:42 -0700 A friend of mine had an interesting banking experience with Citibank this weekend. She wrote a check for $990 on Friday expecting it to take at least two days to clear. On Saturday she was surprised to see a negative $300 balance. No problem, she transfered $1500 from another account at the same bank via an ATM. A subsequent check on line later that day showed the new money in her account, a positive balance and the universe back in harmony. Then things got weird. On Monday Citibank credited back the $990 check as a returned check and debited a $30 fee for doing it. The end of day balance for Monday was over $2200. We both went into the branch today, and the manager couldn't give a rational explanation as to how a check that appeared to have cleared in real time and caused an overdraft (for which they charged interest) had in fact not cleared and how a $1500 transfer that was available in real time (she took some of it out at an ATM which also showed the check as cleared) was now only showing as credited on Monday. As best I can figure out the system only appears to effect transfers and clear checks in real time when, in fact it's still happening on an end of business day basis. The result is what you see on the screen is not really what you get. The manager credited the $30 and my friend smoothed things over with the recipient of the bounced check but I will now be much more skeptical of what Citibank's computer is saying to me. John Pettitt (who in another life wrote credit card processing software) =============================================================================== <"A.E. Siegman" > Sun, 22 Apr 2007 12:07:30 -0700 While waiting to board a different flight in the United Terminal at JFK Friday evening, April 20, I was bemused to hear an announcement repeated perhaps 20 times in a two-hour period: "Attention passengers on British Airways flight 1502 to Manchester: Due to system problems on this aircraft, there will be no inflight entertainment and no overhead lighting during the flight. We apologize for this inconvenience; passengers who have questions may come to Gate xxx." I guess my own question would have been: Do I want to head out over the Atlantic in an aircraft that's having "system problems" and especially electrical ones? (Maybe it would depend on whether I'd gotten an upgrade or not . . .) A. E. Siegman, McMurtry Professor of Engineering Emeritus, Stanford University (650) 326-4360 siegman@stanford.edu [This seems to be a not uncommon failure mode, which I presume the repair folks believe is unrelated to the flight controls. On the other hand, RISKS readers are generally suspicious of such beliefs. I suppose that if this particular problem cannot be fixed quickly enough, the airline might prefer not to delay the flight, which of course can have propagational effects on international schedules. PGN] =============================================================================== =============================================================================== Various: Ed Felten: You Can Own an Integer Too - Get Yours Here > Tue, 8 May 2007 09:09:03 -0400 Ed Felten, 7 May 2007, http://www.freedom-to-tinker.com/?p=1155 Remember last week's kerfuffle over whether the movie industry could own random 128-bit numbers? (If not, here's some background: 1, 2, 3) Now, thanks to our newly developed VirtualLandGrab technology, you can own a 128-bit integer of your very own. Here's how we do it. First, we generate a fresh pseudorandom integer, just for you. Then we use your integer to encrypt a copyrighted haiku, thereby transforming your integer into a circumvention device capable of decrypting the haiku without your permission. We then give you all of our rights to decrypt the haiku using your integer. The DMCA does the rest. ... =============================================================================== Automatic translation leads to ethnic slur > Fri, 20 Apr 2007 10:24:33 -0400 The automated translation of a color description by a Chinese manufacturer into English resulted in an ethnic slur (which I'm not repeating here due both to its being offensive and to avoid tripping inappropriate word filters). While there are periodic lists circulated around of mistranslations, this one wasn't funny but rather quite offensive. There's the usual level of finger-pointing between the retailer, wholesaler, and manufacturer of who is responsible. Some lessons learned: - Translations should be checked by a native speaker to ensure both accuracy and appropriateness. - Relying on automated translations as a cost saving measure isn't a good idea, for anything other than getting the gist of an idea. http://www.cnn.com/2007/WORLD/americas/04/19/canada.couch.ap/index.html [Also noted by several others. PGN] =============================================================================== Prisoner freed by fax <"Bob Morrell/Cancer Center" > Mon, 23 Apr 2007 12:13:38 -0400 A prisoner was wrongly released after a fax was received from a grocery store stating that the Kentucky Supreme Court had demanded his release: http://www.cnn.com/2007/US/04/21/wrongly.freed.ap/index.html I have always complained that network security is held to a standard that other technologies do not have to meet. Apparently others are noticing this as well... =============================================================================== US Daylight Saving Issues, System Libraries vs Program Libraries > Sun, 15 Apr 2007 12:33:25 -0700 I have a Windows program written in C++ using Microsoft Foundation Class structures. It gathers data and stores it in XML format. I store associated time stamps for the data using ISO8601 date format, and store the dates in UCT. (I use the ATL classs ATL::CTime for most of my time manipulation stuff, including the FormatGmt() method.) I do not run my own date arithmetic. I only use the library calls for switching between local time and UCT. I use standard library calls for getting the time. In running log files from the past few weeks I've noticed that the times seem to be an hour off from what I remember the time would have been when the data was taken. Things are more complicated, because I'm teleworking from a location that is two hours away from where the data was originally taken. (The office is in Dallas TX, I'm in Seattle WA.) I have no idea if the various patches I've applied to the systems I've been using have been applied only to the operating system, the C Run time libraries, or only half, and making sure that they are only applied once and not multiple times. I think that this US DST switch is going to continually bite us in small ways for several years. The only solution I see is to operate computers on UCT without any time zone translation enabled, which isn't really a viable solution. =============================================================================== Insured car wrongly crushed? > Sat, 24 Feb 2007 22:25:30 +0000 Background: In the UK, motor vehicle details have been stored on the Driver & Vehicle Licensing Agency (DVLA) computer for decades. This includes a record that the annual Vehicle Excise Duty ("tax disc") is current. For the last year or two, the annual vehicle inspection ("MoT test") is captured on-line as it's done, and insurance companies provide details for a database of insured vehicles. These allow the police to do real-time road-side checks on passing traffic. Drivers are not required to carry documents with them, but the police can require them to be produced ("a producer") at a police station nominated by the driver within 7 days. In one case, a car was allegedly towed by police and crushed for having no insurance, despite having a valid policy. There are questions about this case, but here are some general comments on the matter from people at the company where I work: >> A police statement said: "It is the responsibility of insurance >> companies, not police forces, to ensure that insurance policy details >> are updated on the national motor insurance database. When deciding if a >> car should be towed for insurance or licence violations, officers must >> show `reasonable belief' that an offence has taken place. "Due to >> inaccuracies on the motor insurance database officers should not only >> rely on details held there to constitute `reasonable belief'". > > Having been involved in our attempts to keep the motor insurers database > up to date with details of the company fleet, I can't say I'm surprised > that it's sometimes out of date. It seems totally ridiculous that the > police use this as the sole evidence that a vehicle should be towed away. > >> Gives you great confidence in the ability of the `authorities' to use >> databases in he pursuit of their version of justice. Imagine them using a >> database covering ID cards, they'd be hauling us off instead of cars >> then.... > > Can't help wondering why the police impounded the car instead of simply > issuing a producer. Was there something else dodgy about the car or the > driver that we weren't told about? The idea is the computer says no, the journey ends there. The police will not allow you to continue in an uninsured car. There was something on one of those `fly on the wall' police programs that made me wonder. They stopped someone because the computer said the car was untaxed and uninsured and the driver tried to show them an insurance certificate. The officers were singularly unimpressed saying anyone with a computer can knock up a `valid' certificate of insurance preferring to believe what the database told them. At the end of the program we were updated and the driver was insured but his tax was 6 weeks out of date. Looks like the (rather familiar) RISKs here are (a) ambiguity as to what is regarded as the definitive record -- in this case, computer database or paper insurance certificate? -- and (b) how individuals can find themselves in trouble for others' errors and omissions, e.g. if your insurance company makes a mistake in updating the database. Presumably you could prove in court that you have a valid policy, but that's not much good if you're detained by police at the side of the road a long way from home. =============================================================================== =============================================================================== Tragic consequences Michigan man freezes to death after electric company cuts power <"Mark E. Smith" > Tue, 27 Jan 2009 04:06:40 -0800 In this case the risk appears to be the assumption that anyone who wishes to pay their electric bill can do so easily. The 93-year-old WWII veteran may not have had a checking account, a computer, or online bill paying, and the weather was too severe for him to leave home to pay his electric bill in person. After his death, a large amount of cash was found clipped to his utility bill on his kitchen table. =============================================================================== Unit confusion caused fatal chemotherapy overdose Thu, 10 May 2007 18:38:01 -0400 (EDT) The Alberta Cancer Board has released a report into the death of patient Denise Melanson last August due to an accidental overdose of the chemotherapy drug fluorouracil. The prescription gave the dosage as "5,250 mg (at 4,000 mg/m2) intravenous once continuous over 4 days" and then as "baseline regimen 1,000 mg/m2/day = 4,000 mg/m2/4 days". The m2 here apparently refers to the total area of the patient's skin and explained how the dose in mg had been calculated rather than how it was to be administered. To administer the drug, a nurse loaded it into a portable infusion pump. The drug label would have read "Final Concentration: 45.57 mg/mL; Dose: 5250 mg/4 days (1312.5 mg/24h); Rate: 28.8mL/24h (1.2mL/h)". The pump had several options to program the rate of flow, but none of them involved a rate per day. The nurse selected milliliters per hour, and recalculated the rate herself, but forgot to convert days to hours, and typed in the number for mL/day, which she saw on the label. For some other drugs 28.8 mL/h would have been a plausible amount, but with fluorouracil it was fatal. Another nurse checked the arithmetic, partly mentally, and did not spot the error. The problem was only realized when the drug supply ran out, and then it was too late. The fact that the pump's user interface said "mL" when it meant "mL/h" cannot have helped. The report summarizes the causes as: "miscalculation; opportunity for false confirmation on label; information required to program pump not part of medication administration record; double check process failed; complex workload and multitasking; no feedback from pump; and low knowledge of hazard." This is not the first time this sort of thing has happened, and the report details some of the other ones as well as making recommendations for improved procedures. News media reports: http://www.cbc.ca/cp/health/070508/x050819A.html http://www.theglobeandmail.com/servlet/story/LAC.20070509.OVERDOSE09/TPStory/National Cancer Board report (PDF, and curiously marked "Privileged and Confidential" on every page): http://www.cancerboard.ab.ca/NR/rdonlyres/D92D86F9-9880-4D8A-819C-281231CA2A38/0/Incident_Report_UE.pdf