The RISKS Digest
Volume 26 Issue 22

Wednesday, 17th November 2010

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


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
Info on RISKS (comp.risks)

New study on adverse events in hospitals (Rita Rubin)

Peter Neumann <>
Tue, 16 Nov 2010 08:21:39 -0500

  [Thanks to Nancy Leveson for spotting this one.  PGN]

Rita Rubin, Hospital care fatal for some patients, *USA TODAY*

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.

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?"

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

* About one in seven Medicare hospital patients—or about 134,000 of the
estimated 1 million discharged in October 2008—were harmed from medical

* 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

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."

Computer crash affects Chicago-area hospitals (Gerry Smith)

"Peter G. Neumann" <>
Tue, 16 Nov 2010 14:38:53 PST

  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.

Re: Trust the Vote, Rebecca Mercuri on DC (RISKS-26.20)

"E. John Sebes" <>
Thu, 11 Nov 2010 15:52:31 -0800

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

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

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

Re: Trust the Vote, Rebecca Mercuri on DC (Sebes, RISKS-26.22)

Rebecca T Mercuri <>
Wed, 17 Nov 2010 00:05:44 -0500

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.

Ariane 501: Not that Kind of Bug (Re: RISKS-26.16)

"Dennis E. Hamilton" <>
Wed, 17 Nov 2010 07:45:43 -0800

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

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

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 +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]

Make left turn into swamp, wait on roof for an hour

Mark Brader
Wed, 6 Oct 2010 17:20:25 -0400 (EDT)

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:

Mark Brader, Toronto, | "Fast, cheap, good: choose any two."

Massive Chinese Net Reroute Exposes Web's Achilles' Heel

Steven Cherry <>
Wed, 17 Nov 2010 17:13:47 -0500

  [From Dave Farber's IP group distribution.  PGN]
  Massive Chinese Net Reroute Exposes Web's Achilles' Heel

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,

It's Time to Stop ICANN's Top-Level Domain Lunacy!

Lauren Weinstein <>
November 3, 2010 7:31:50 PM EDT

  [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!

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 ( [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

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

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

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

Please let me know if you'd be interested in participating.  Thanks.  Take care.

Lauren Weinstein <> (818) 225-2800
NNSquad (Network Neutrality Squad):  Twitter:
Google Buzz:

Should You Be Snuggling With Your Cellphone? (Randall Stross)

Monty Solomon <>
Tue, 16 Nov 2010 22:29:51 -0500

[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. ...

Re: Something has been going right in the fight against spam (R-26.21)

Jonathan Kamens <>
Wed, 17 Nov 2010 06:50:43 -0500

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.

Please report problems with the web pages to the maintainer