RISKS-LIST: Risks-Forum Digest Weds 17 November 2010 Volume 26 : Issue 22 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <http://www.risks.org> as <http://catless.ncl.ac.uk/Risks/26.22.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: New study on adverse events in hospitals (Rita Rubin via PGN) Computer crash affects Chicago-area hospitals (Gerry Smith via PGN) Re: Trust the Vote, Rebecca Mercuri on DC (E. John Sebes, Rebecca Mercuri) Ariane 501: Not that Kind of Bug (Dennis E. Hamilton) Make left turn into swamp, wait on roof for an hour (Mark Brader) Massive Chinese Net Reroute Exposes Web's Achilles' Heel (Steven Cherry) It's Time to Stop ICANN's Top-Level Domain Lunacy! (Lauren Weinstein) Should You Be Snuggling With Your Cellphone? (Randall Stross via Monty Solomon) Re: Something has been going right in the fight against spam (Jonathan Kamens) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 16 Nov 2010 08:21:39 -0500 From: Peter Neumann <neumann_at_private> Subject: New study on adverse events in hospitals (Rita Rubin) [Thanks to Nancy Leveson for spotting this one. PGN] Rita Rubin, Hospital care fatal for some patients, *USA TODAY* <http://content.usatoday.com/topics/reporter/Rita+Rubin> An estimated 15,000 Medicare patients die each month in part because of care they receive in the hospital, says a government study released today. The study is the first of its kind aimed at understanding "adverse events" in hospitals -- essentially, any medical care that causes harm to a patient, according to the Department of Health and Human Services' Office of Inspector General. <http://content.usatoday.com/topics/topic/Organizations/Companies/Health+and+Medicine/United+States+Department+of+Health+and+Human+Services> Patients in the study, a nationally representative sample that focused on 780 Medicare patients discharged from hospitals in October 2008, suffered such problems as bed sores, infections and excessive bleeding from blood-thinning drugs, the report found. The federal Agency for Healthcare Research and Quality called the results "alarming." "Reducing the incidence of adverse events in hospitals is a critical component of efforts to improve patient safety and quality care" in the U.S., the inspector general wrote. The findings "tell us exactly what some of us have been afraid of, that we have not made much progress," said Arthur Levin, director of the independent Center for Medical Consumers and a member of an Institute of Medicine committee that wrote a landmark 1999 report on medical errors. "What more do we have to do to make sure that sick people can rest assured that they're not going to be harmed by the care they're getting?" <http://content.usatoday.com/topics/topic/Organizations/Non-profits,+Activist+Groups/Institute+of+Medicine> Among the findings in the report obtained by *USA TODAY*: * Of the 780 cases, 12 patients died as a result of hospital care. Five were related to blood-thinning medication. * Two other medication-related deaths involved inadequate insulin management resulting in hypoglycemic coma and respiratory failure resulting from oversedation. * About one in seven Medicare hospital patients -- or about 134,000 of the estimated 1 million discharged in October 2008 -- were harmed from medical care. * Another one in seven experienced temporary harm because the problem was caught in time and reversed. * About 47 million Americans are enrolled in Medicare, a government health insurance program for people 65 and older and those of any age with kidney failure. The adverse events found in the study weren't necessarily due to medical mistakes, said Lee Adler, a University of Central Florida medical professor who was involved in the study. For example, he said, an allergic reaction to a penicillin injection is an adverse event, but it's a medical error only if the patient's allergy was known prior to the shot. Among the problems identified in the report were Medicare patients who had excessive bleeding following surgery or a procedure. For example, one patient had excessive bleeding after his kidney dialysis needle was inadvertently removed, which resulted in circulatory shock and an emergency insertion of a tube to allow breathing. When the tube was removed the next day, the patient inhaled foreign material into his lungs and needed lifesaving medical help, the report said. Peter Pronovost of Johns Hopkins University, co-author of the book *Safe Patients, Smart Hospitals*, said medical mistakes are "an enormous public- health problem." "We spend two pennies trying to deliver safe health care for every dollar we spent trying to develop new genes and new drugs," Pronovost said. "We have to invest in the science of health care delivery." <http://content.usatoday.com/topics/topic/Organizations/Schools/Johns+Hopkins+University> ------------------------------ Date: Tue, 16 Nov 2010 14:38:53 PST From: "Peter G. Neumann" <neumann_at_private> Subject: Computer crash affects Chicago-area hospitals (Gerry Smith) Source: Gerry Smith, Computer crash affects Chicago-area hospitals, *The Tribune* (Chicago), 13 Nov 2010 [PGN-ed. Thanks to Dr. Richard Cook, who had lots of questions on this item, about how a day-long outage would not affect patient care, the qualifications of the spokeswoman, etc., the oversight, etc.] A computer system housing patient data at Advocate Health Care hospitals crashed this morning, but was back up and running this afternoon, a hospital spokeswoman said. Advocate patients experienced "little to no interruption" in receiving care after the system went down about 5 a.m., said Stephanie Johnson, an Advocate spokeswoman. The crash required employees temporarily to take patient orders on paper instead of entering them into the computer, she said. Employees still were able to access patient information by using backup computer systems, she said. The system's manufacturer, Cerner, had the system up and running around 4 p.m., Johnson said. The hospitals in the Advocate system are Christ Medical Center, Trinity Hospital, Good Samaritan Hospital, Good Shepherd Hospital, Lutheran General Hospital, South Suburban Hospital, BroMenn Medical Center, Eureka Hospital and Condell Medical Center and Hope Children's Hospital. ------------------------------ Date: Thu, 11 Nov 2010 15:52:31 -0800 From: "E. John Sebes" <jsebes_at_private> Subject: Re: Trust the Vote, Rebecca Mercuri on DC (RISKS-26.20) I'm writing to correct an important misconception that was reported in RiSKS-26.20 (8 Nov 2010) by Rebecca Mercuri. Rebecca said that she was shocked that DC BOEE election officials had used an experimental voting system to collect Internet ballots in the 2 Nov 2010 general election, despite demonstrated security flaws. She would be right to be shocked if that were the case, but in fact it's not so. Instead, let me list all the Internet-related and ballot-related activities in DC in Oct/Nov 2010 that I know of: * The digital ballot return system was only used in the public test, and was not used for the real election. * In the real election, only the digital blank ballot distribution system was used. * This blank ballot distribution system is similar in nature to the over 20 similar "FVAP Wizard" systems * Digital return of marked ballots was not part of the "Digital Vote By Mail" system used in the election. * However, digital return may have occurred by e-mail; DC election law, like that in other states, permits overseas voters to return digitally via email. * Email return was neither part of the Digital VBM system used in the election, nor the recommended method or return. In addition to the above corrections about what did *not* occur, I thought it might be useful to also say a few words about the system that *was* used. I can speak to details with confidence because I was leader of the TrustTheVote project team that assisted the DC BOEE in the Digital VBM project. This system has 3 main functions: 1. Identify a voter, confirm their identity, and provide the particular blank ballot for the voter's precinct, together with the vote-by-mail attestation document that must accompany the marked ballot. 2. Provide two options for marking the ballot: online marking and then printing for ballot return; or printing the blank and then marking by hand. 3. Provide assistance and information about returning VBM materials by post or express. In addition, there are some significant differences between the DC system and some of the FVAP wizard systems: * Digital marking of the ballot is performed purely locally to the user's PC, without exposing voter choices to the application server in a way that could risk ballot anonymity. * Both paper and digital marking methods use the exactly the same ballot representation, for equal access and protection regardless of the voter's choice of marking method. * The ballots are pre-rendered as PDF files (rather than dynamic HTML) so that they can be proofed for legal correctness the same as non-VBM ballots. I'd also like to respectfully agree with several of Rebecca's other points, especially her invocation of Ken Thompson, coupled with transparency != trust. I couldn't agree more, having been on record that: * Technology transparency, including published source code, is not an inherent solution to any problem. * For any form of election technology, such open-ness is a pre-requisite for trust which must be earned in many other ways. * There is no solution to the security/privacy/anonymity problems of voting. * This applies whether voting in-person, or remote voting via postal mail, or remote voting in any of the Internet-based schemes. * This applies whether voting technology is open or closed - the fundamentals of imperfect software and "Reflections on Trusting Trust" are universal. Instead seeking a solution to insoluble problems, technologists can help election officials make sensible choices about the responsible use of technology to assess and manage risks inherent in voting. And I believe that some consensus among technologists and election officials can be reached on these thorny issues -- but only by civil and respectful engagement, not by repeated insistence that the technologists know better, and election officials are ignorant and irresponsible. John Sebes, CTO, Open Source Digital Voting Foundation ------------------------------ Date: Wed, 17 Nov 2010 00:05:44 -0500 From: Rebecca T Mercuri <notable_at_private> Subject: Re: Trust the Vote, Rebecca Mercuri on DC (Sebes, RISKS-26.22) What Mr. Sebes claims is not made clear by the BOEE's website. Even so, the OSDV digital ballot distribution system was not been proven to be safe and should have been assumed not to be. There have been plenty of examples of absentee ballots mucked up so that certain races or candidates are left off, such as even John Glenn in an Ohio Senate race as a notable example a number of years back, and that was without the assistance of computers and the Internet in the mix. As far as the main functions for the Digital VBM project are concerned: 1) There is no way to differentiate between a spoofed voter and a legitimate voter in a remote Internet voting setting. Anyone who has access to the voter database can pretend to be a voter and obtain ballots. My understanding is that the system hack demonstrated the possibility of this. 2) Online marking and printing doesn't ensure correctness of the ballot. As well, hand marking doesn't prevent overvotes (as required by HAVA). Basically the OSDV system did not provide the voter with any assurance that they correctly prepared a correctly supplied ballot. 3) Assistance and information about how to cast votes is a requirement of any election and not a special accomplishment by OSDV. The above items did not merit a $300,000 grant. These could have been accomplished by a small team of undergraduates for under $10,000 (especially considering the paltry number of remote voting participants). OSDV should immediately return the excess $290,000 to the DCBOEE. Until they do so, their efforts can hardly be considered altruistic, or in the best interest of either the election officials or the public. Those folks who handed over a quarter-million in tax dollars without a refund clause if the system failed to perform as promised certainly deserve to be considered ignorant and irresponsible, at least until they demand the citizens' money back. ------------------------------ Date: Wed, 17 Nov 2010 07:45:43 -0800 From: "Dennis E. Hamilton" <dennis.hamilton_at_private> Subject: Ariane 501: Not that Kind of Bug (Re: RISKS-26.16) I find it distressing that the loss of flight Ariane flight 501 is repeatedly taken as demonstration of a software bug, as in the risk of (now 11) software bugs cited in RISKS-26.16. I think this covers over a far more important lesson and trivializes the incident. See <http://orcmid.com/blog/2005/12/ariane-501-historys-worst-software-bug.asp>. Here's another way to look at this. If this was a programming error, what is it that the programmer could have done, for the Ariane 4 Inertial Reference System as actually designed and constrained, such that the Ariane 501 mission would not have been lost? Consider that 1. The developers knew that a down-conversion to 16 bits could result in an overflow, so it wasn't a lack of numerical analysis. Under the parameters of the design, the apparatus would never see conditions in which the value produced would be out of the 16 bit range. 2. The developers knew that a down-conversion to 16 bits could result in an overflow, so a proof of correctness would not help. The correctness proof, if undertaken, would confirm that the values outside of the range for the design conditions would not occur, based on external facts (physical circumstances) that would have to be accepted as hypotheses supporting the proof. 3. The developers (using Ada, which has provisions for catching an out-of-range attempt for down-conversion), intentionally allowed an uncaught exception to be thrown under the agreed conditions that the exceptional values could only happen if the hardware was failing. You can surmise that (3) turned out to be a problem, even though it was correct that, under the conditions of Inertial Reference Platform usage, including for Ariane 501, there would be and there was no down-conversion failure. The problem was that the Inertial Reference Platform was left running *after* launch when its output is not only not needed but is useless, that the unit and its backup both shut down (same problem, not equipment failure), and because of the shutdowns, the guidance system was fed a diagnostic message instead of guidance data, and for some reason, it was not designed to recognize such a thing and differentiate it from guidance data. That is what led to the violent maneuvering of the launcher and consequent pyrotechnic destruction when the vehicle lost integrity and a safety coupling separated. So there is nothing different that was available for the programmers to have done on their own. The failures of system engineering, on the other hand, are quite educational. Dennis E. Hamilton NuovoDoc: Design for Document System Interoperability http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org +1-206.779.9430 [Dennis long ago NEGLECTED to include the "notsp" tag in an earlier submission. I have no record of it, so it was undoubtedly deleted with my more than 90% manual de-spam-estration. He finally realized his error, and has resubmitted. TNX] ------------------------------ Date: Wed, 6 Oct 2010 17:20:25 -0400 (EDT) From: msb_at_private (Mark Brader) Subject: Make left turn into swamp, wait on roof for an hour In a conservation area near Trenton, Ontario, Canada, a woman's car went off the roadway on a foggy night and began filling with water. She said she had been following her GPS system's directions, although police could not confirm whether she was doing it correctly. She got on the roof, called for help by cellphone, and was rescued about a hour later by police using all-terrain vehicles. I don't know how long these links will remain valid: http://www.theglobeandmail.com/news/national/ontario/article1745101.ece http://www.winnipegfreepress.com/canada/breakingnews/gps-to-ontario-driver-make-left-turn-into-swamp-wait-on-roof-for-an-hour-104440074.html Mark Brader, Toronto, msb_at_private | "Fast, cheap, good: choose any two." ------------------------------ Date: Wed, 17 Nov 2010 17:13:47 -0500 From: Steven Cherry <s.cherry_at_private> Subject: Massive Chinese Net Reroute Exposes Web's Achilles' Heel [From Dave Farber's IP group distribution. PGN] Massive Chinese Net Reroute Exposes Web's Achilles' Heel http://www.technewsworld.com/story/71258.html?wlc=1290031152 The U.S.-China Economic and Security Review Commission says that for a period of 18 minutes last April, China Telecom hijacked 15 percent of the world's Web traffic and sent it to servers in China, an accusation the state-run organization has denied. Whether the apparent reroute was intentional or accidental, it's exposed another weakness in the structure of the Web. Steven Cherry +1 212-419-7566, Senior Associate Editor, IEEE Spectrum 3 Park Ave, New York, NY 10016, s.cherry@private http://spectrum.ieee.org ------------------------------ Date: November 3, 2010 7:31:50 PM EDT From: Lauren Weinstein <lauren_at_private> Subject: It's Time to Stop ICANN's Top-Level Domain Lunacy! [In RISKS-26.21, I included Lauren's parody, which referred to the item that I am now including in this issue. I probably should have put this one in first. PGN] It's Time to Stop ICANN's Top-Level Domain (TLD) Lunacy! http://lauren.vortex.com/archive/000776.html Greetings. I'm going to keep this relatively short and sweet, since I've written of my concerns about ICANN's handling of Top-Level Domains (TLDs) many times in the past. The existing Domain Name System (DNS) has been leveraged in multiple ways into something akin to a protection racket, with vast sums of money being funneled to existing and wannabe registries, registrars -- and to ICANN itself -- with little or no resulting tangible benefits to the Internet community at large. That is, unless you consider ever increasing levels of costs and confusion to be some sort of benefits. Dot-com is still the single TLD that most Internet users recognize as fundamental among the increasingly disruptive clutter -- and you haven't seen anything yet compared with the pandemonium about to be unleashed. "Protective registrations" by trademark owners and other concerned parties in new TLDs have become an enormous profit center for various players in the DNS ecosystem, with boasting about the income that will be derived through such arm-twisting techniques now being commonplace. The amount of money involved is staggering. In a few days, ICANN may release their new "guidebook" for upcoming TLD applicants ( http://bit.ly/9BZUNu [ars technica] ). The application fee alone for a single new TLD is reported to be almost $200K, payable to ICANN. The cost of running a new TLD if you're accepted? A whole bunch, likely including (but not limited to) big moola to ICANN every year. ICANN plans to limit the number of new TLDs to only (only???) about 1000 per year -- maybe half that in the first year. Let's see, $185,000 times 1000 ... Nice chunk of change. Of course, ICANN claims that these fees are justified by the costs involved in processing these applications. Assuming this is true, I can't think of a better proof that the entire process is rotten and dysfunctional to the core. The DNS and the domain name infrastructure made sense in an era before the universal availability of search engines and online directories. But for such massive costs and complexities -- such as those inevitably stemming from the ICANN TLD expansion -- to be incurred simply to map names to Internet sites is now both technically and economically obsolete and abominable. It's time to end the TLD madness. It will take both time and some heavy lifting. But there are alternative methodologies -- more efficient, extensible, and far more economical, much better suited to the Internet of the 21st century, and we need to start working on them now. Vested interests -- basically the entire "domain-industrial complex" -- who stand to profit mightily by exploiting the continuation and expansion of the unnecessary, counterproductive, and obsolete domain name system, can be expected to fight any efforts at significant changes, using every weapon in their arsenals. Various other parties will also fight such changes -- since as we've increasingly seen the DNS provides an ideal mechanism for centralized censorship and heavy-handed intellectual property enforcement regimes -- through the disabling on demand of Web site name-based addressability. Be that all as it may, this is a battle -- nay, perhaps a war -- necessary for the best interests of both the Internet and its global community of users. Please let me know if you'd be interested in participating. Thanks. Take care. Lauren Weinstein <lauren@private> http://www.vortex.com/lauren (818) 225-2800 NNSquad (Network Neutrality Squad): http://www.nnsquad.org http://lauren.vortex.com Twitter: https://twitter.com/laurenweinstein Google Buzz: http://bit.ly/lauren-buzz ------------------------------ Date: Tue, 16 Nov 2010 22:29:51 -0500 From: Monty Solomon <monty_at_private> Subject: Should You Be Snuggling With Your Cellphone? (Randall Stross) [Source: Randall Stross, *The New York Times*, 13 Nov 2010] WARNING: Holding a cellphone against your ear may be hazardous to your health. So may stuffing it in a pocket against your body. I'm paraphrasing here. But the legal departments of cellphone manufacturers slip a warning about holding the phone against your head or body into the fine print of the little slip that you toss aside when unpacking your phone. Apple, for example, doesn't want iPhones to come closer than 5/8 of an inch; Research In Motion, BlackBerry's manufacturer, is still more cautious: keep a distance of about an inch. The warnings may be missed by an awful lot of customers. The United States has 292 million wireless numbers in use, approaching one for every adult and child, according to C.T.I.A.-The Wireless Association, the cellphone industry's primary trade group. It says that as of June, about a quarter of domestic households were wireless-only. If health issues arise from ordinary use of this hardware, it would affect not just many customers but also a huge industry. Our voice calls - we chat on our cellphones 2.26 trillion minutes annually, according to the C.T.I.A. - generate $109 billion for the wireless carriers. The cellphone instructions-cum-warnings were brought to my attention by Devra Davis, an epidemiologist who has worked for the University of Pittsburgh and has published a book about cellphone radiation, "Disconnect." I had assumed that radiation specialists had long ago established that worries about low-energy radiation were unfounded. Her book, however, surveys the scientific investigations and concludes that the question is not yet settled. Brain cancer is a concern that Ms. Davis takes up. Over all, there has not been a general increase in its incidence since cellphones arrived. But the average masks an increase in brain cancer in the 20-to-29 age group and a drop for the older population. ... https://www.nytimes.com/2010/11/14/business/14digi.html ------------------------------ Date: Wed, 17 Nov 2010 06:50:43 -0500 From: Jonathan Kamens <jik_at_private> Subject: Re: Something has been going right in the fight against spam (R-26.21) David E. Ross wrote: > The volumes of spam arriving at my inbox and spam captured by my ISP's > filter (from which I can recover false positives) have both dropped ... I'm glad to hear it :-), but this doesn't have anything to do with the decline reported by myself and others. I've been running pre-filters of the sort you mention for years, and the decline in spam I and other have reserved is independent of that. ------------------------------ Date: Thu, 29 May 2008 07:53:46 -0900 From: RISKS-request_at_private Subject: Abridged info on RISKS (comp.risks) The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. The mailman Web interface can be used directly to subscribe and unsubscribe: http://lists.csl.sri.com/mailman/listinfo/risks Alternatively, to subscribe or unsubscribe via e-mail to mailman your FROM: address, send a message to risks-request_at_private containing only the one-word text subscribe or unsubscribe. You may also specify a different receiving address: subscribe address= ... . You may short-circuit that process by sending directly to either risks-subscribe_at_private or risks-unsubscribe_at_private depending on which action is to be taken. Subscription and unsubscription requests require that you reply to a confirmation message sent to the subscribing mail address. Instructions are included in the confirmation message. Each issue of RISKS that you receive contains information on how to post, unsubscribe, etc. => The complete INFO file (submissions, default disclaimers, archive sites, copyright policy, etc.) is online. <http://www.CSL.sri.com/risksinfo.html> The full info file may appear now and then in RISKS issues. *** Contributors are assumed to have read the full info file for guidelines. => .UK users should contact <Lindsay.Marshall_at_private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line. *** NOTE: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks for current volume or ftp://ftp.sri.com/VL/risks for previous VoLume <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r <http://the.wiretapped.net/security/info/textfiles/risks-digest/> . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: <http://www.csl.sri.com/illustrative.html> for browsing, <http://www.csl.sri.com/illustrative.pdf> or .ps for printing ==> Special Offer to Join ACM for readers of the ACM RISKS Forum: <http://www.acm.org/joinacm1> ------------------------------ End of RISKS-FORUM Digest 26.22 ************************Received on Wed Nov 17 2010 - 17:37:05 PST
This archive was generated by hypermail 2.2.0 : Wed Nov 17 2010 - 18:57:47 PST