The RISKS Digest
Volume 25 Issue 79

Friday, 25th September 2009

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…


Complex Machinery: a parody
Ken Knowlton
Los Angeles Drought Restrictions: Unintended Consequences?
Thomas Russ
More on the DC Metro collision 22 June 2009
David Lesher
New York Nuclear Plant Mistakenly Blares Emergency Alarm
Air Force loses control of autonomous aircraft, shoots it down
Rob McCool
Policemen's sanitary habits result in high breathalyzer reading
Matt Fichtenbaum
Children's hospital in Ohio infected with spyware
Rob McCool
'Robot' computer to mark English essays
Polly Curtis via Tom Heathcote
Swiss watchdog sets court ultimatum for Google Street View
Peter Houppermans
*NYTimes* Web Ads Show Security Breach
Matthew Kruk
Google Buys reCAPTCHA, Creating a Potential Privacy Issue
Lauren Weinstein - a case study in how to run an insecure website
Jonathan Kamens
Retailer Must Compensate Sony Anti-Piracy Rootkit Victim
Re: Quantum chip helps crack code
Steve Wildstrom
Info on RISKS (comp.risks)

Complex Machinery: a parody

Tue, 22 Sep 2009 12:12:43 EDT

An advertisement for a high-class car [Lexus] in an equally classy magazine
[9/21/09 New Yorker] begins with a satirical quote by the president [John
Maeda] of a respected School [RISD], the punch line of which, I fear, may
float well above the grasp of many grade C students of the modern world:

  "Digital technology will enable the creation of ultra-complex machines,
  processes, and imagery.  But that amazing technology will be framed in an
  elegant and simple form that makes it user-friendly.  The more complex the
  machinery, the simpler the interface will be."

[High school dropouts, I think, might thus hope for jobs as pilots of
thousand passenger airplanes, or controllers of nuclear power plants -
punching and twiddling a few intuitively understood buttons and knobs. KCK]

  [Rhode Island is a small but nevertheless complex state.  But perhaps the
  upshot of the supposed satire is that School of Design students are
  actually learning that "Everything should be made as simple as possible,
  and then massively oversimplified."  (It won't work even in the
  architecture of buildings, let alone computer architectures.  But the
  secret of success is giving the appearance of simplicity that implicitly
  masks the inherent complexity.)  PGN]

Los Angeles Drought Restrictions: Unintended Consequences?

Thomas Russ <tar@ISI.EDU>
Tue, 22 Sep 2009 13:17:27 -0700

The city of Los Angeles, California has run into a rather curious set
of unintended consequence of lawn watering restrictions imposed as a
conservation measure.  A couple years of drought has strained the
water resources of the city.  So, to reduce water consumption, the
city restricted lawn watering to just two days per week:  Mondays and
Thursdays.  Unexpectedly, this may have led to a dramatic increase in
the number of water main breaks, 34 since September 1st.  For
comparison, the numbers for September 2008, 2007 and 2006 were 21, 17
and 13.  There is some suspicion that pressure shocks from the much
larger swings in usage and pressure overtax the aging infrastructure.
I suppose the law of unintended consequences is always operating, and
this one seems to have caught everyone by surprise:  "The rationing
began in June, shortly before they noticed an uptick in major
blowouts. There were 24 blowouts in July and 31 in August, increases
from the same months last year."

More details from the Los Angeles Times:,0,88564.story,0,4531113.story

  [Nice lesson there.  Put all your watery eggs in one leaky basket.]

More on the DC Metro collision 22 June 2009 (RISKS-25.73)

"David Lesher" <>
Tue, 22 Sep 2009 23:36:06 -0400 (EDT)

The NTSB has issued an urgent interim recommendation re: the fatal Metro
collision in June.


The letter discusses the failure they found:

"Testing found that a spurious high-frequency modulated signal was being
created by parasitic oscillation from the power output transistors in the
track circuit module transmitter. This spurious signal propagated through
the power transistor heat sink, through the metal rack structure, and
through a shared power source into the associated module receiver, thus
establishing an unintended signal path. The spurious signal mimicked a valid
track circuit signal. The peak amplitude of the spurious signal appeared at
the correct time interval and was large enough to be sensed by the module
receiver as a valid track circuit signal, which energized the track
relay. This combination — of an alternate signal path between track circuit
modules and a spurious signal capable of exploiting that path — bypassed
the rails, and the ability of the track circuit to detect the train was

and makes recommendations for WMATA, and other involved parties.

Comment: Attention has long focused on the track signaling circuit that
inexplicably failed to detect the stopped train. What was not know was why
it failed; when AC track signals have been in use for a century. After a
great deal of work on the scene and off, NTSB has part of the answer.

The RISK here is this was and is the classic "all the eggs in one basket"
protection scheme.  It was a very sturdy basket, but...

Now the issue is how to retrofit real redundancy into this system...and how
to pay for it.

  [Doug Hosking noted a CNN item.  PGN]

New York Nuclear Plant Mistakenly Blares Emergency Alarm

"Peter G. Neumann" <>
Sun, 20 Sep 2009 9:18:14 PDT

Fox News, 19 Sep 2009

A suburban New York City nuclear power plant's siren system has mistakenly
blared out the warning, "Emergency! Emergency! Emergency!"  The ominous
message rattled some of the residents of New City, about 30 miles north of
midtown Manhattan. Auto shop worker Rudy Gaspari says the mechanical voice
had an unsettling, post-apocalyptic overtone to it.

The voice came from an Indian Point plant siren located downtown during a
test Friday, The Journal News reported.  Indian Point spokesman Jerry Nappi
says the voice message "shouldn't have happened." He says plant officials
have disabled the voice mechanism in the siren.

Four other sirens with faulty connections also have been fixed.  A new $15
million system is undergoing tests. It's supposed to give voice directions
in park areas only.

  [Doug Hosking remarked,
    "disabled the voice mechanism"?  What could possibly go wrong there?  PGN],2933,552603,00.html?test=latestnews

Air Force loses control of autonomous aircraft, shoots it down

Rob McCool <>
Fri, 18 Sep 2009 21:43:09 -0700 (PDT)

The US Air Force in Afghanistan "lost positive control" of an autonomous
MQ-9 aircraft in Afghanistan, and decided to destroy it before it crossed
Afghanistan's border. A piloted plane was sent and presumably shot down the
errant aircraft.

Policemen's sanitary habits result in high breathalyzer reading

Matt Fichtenbaum <>
Mon, 21 Sep 2009 21:41:45 -0400

  [Online Swedish press, probably Svenska Dagbladet, a week or so ago.]

A motorist in Piteċ in the north of Sweden crashed his car, injuring
himself.  Before sending him off to the hospital the police gave him a
breathalyzer test, which resulted in a very high reading of 0.45 percent.

The hospital folks ran their own test on a sample of his blood, with a
result of 0.12 percent.  Still over the "drunk" threshold, but not so badly

It turns out that the police had a bottle of alcohol-based hand sanitizer in
their car, and evidently used it.  And some of it must have found its way
onto the breathalyzer.

"Officer?  Do you have a standard reference sober person to check the

Children's hospital in Ohio infected with spyware

Rob McCool <>
Fri, 18 Sep 2009 21:49:28 -0700 (PDT)

An Ohio man who had a relationship of some sort with a woman who works at
Akron Children's Hospital decided to monitor her activities. He sent spyware
to her Yahoo account, and instead of reading his e-mail at home (and
unfortunately placing trust in him that it seems he didn't deserve), she
read it at work, infecting several systems in the cardiac surgery
department. Work she performed during the time her computer was infected,
including patient details and some medical records, were sent to the man's

This illustrates an increasing risk I think, that more and more employees
are taking casual network access for granted on their work computers.
Similar to cellular phones and USB sticks in the workplace, it's becoming
difficult to isolate sensitive data from multitasking workers who mix
personal with professional computing activity. Maintaining the kind of
separation of duties that would be required to prevent this sort of incident
seems to be either expensive or inconvenient, or maybe just not imagined
beforehand by IT departments.

'Robot' computer to mark English essays (Polly Curtis)

Tom Heathcote <>
Fri, 25 Sep 2009 18:23:18 +0100

Polly Curtis, *The Guardian*, 25 September 2009

The owner of one of England's three major exam boards is to introduce
artificial intelligence-based automated marking of English exam essays in
the UK from next month.  Pearson, the American-based parent company of
Edexcel, is to use computers to "read" and assess essays for international
English tests in a move that has fueled speculation that GCSEs and A-levels
will be next.

Swiss watchdog sets court ultimatum for Google Street View

Peter Houppermans <>
Tue, 15 Sep 2009 00:31:19 +0200

Classic example of ignoring a smoldering until it turns into a raging fire.

The Swiss data protection commissioner has made fresh proposals to Google
Switzerland to improve privacy of its online Street View.  The office of
Hanspeter Thür said on Monday that there were many problem pictures that did
not respect anonymity, particularly in private roads and gardens.

Google Switzerland has said it is "very disappointed" at Thür's position
because it had supplied much information and had received the go-ahead to go
online, only for Thür to change his position a few days later.

The office of the Federal Data Protection and Information Commissioner says
Google has to improve its system of blurring faces and car registration

It also has to pay particular attention to blurring such places as
hospitals, schools and prisons.

Google has 30 days to accept the proposals; if they are rejected, Thür may
go to the Swiss Federal Administrative Court.

The organisation says Street View has been very popular in Switzerland
and people should continue to enjoy it.

Wonderful ignoring of the real issues.  Another publication in the NZZ
illustrates what Google has been asked to do, over and above ensuring that
their masking software actually works.  They have been asked to remove small
private streets from their database, and — as in Japan — they have been
told to take pictures at eye height so fences can do what they were
originally placed for.

*NYTimes* Web Ads Show Security Breach

"Matthew Kruk" <>
Tue, 15 Sep 2009 07:20:01 -0600

"OVER the weekend, some visitors to the Web site of *The New York Times*
received a nasty surprise. An unknown person or group sneaked a rogue
advertisement onto the site's pages.

The malicious ad took over the browsers of many people visiting the
site, as their screens filled with an image that seemed to show a scan
for computer viruses. The visitors were then told that they needed to
buy antivirus software to fix a problem, but the software was more snake
oil than a useful program."

Google Buys reCAPTCHA, Creating a Potential Privacy Issue

Lauren Weinstein <>
Wed, 16 Sep 2009 14:01:48 -0700

          Google Buys reCAPTCHA, Creating a Potential Privacy Issue

Greetings.  Google has announced ( )_their acquiring of
Carnegie Mellon University's "reCAPTCHA" system.  You've no doubt seen
reCAPTCHA in action — it is very widely used by a vast array of sites.
CMU's reCAPTCHA is a specific implementation of the more generalized CAPTCHA
concept, which attempts to validate user input as coming from a human, not a
(typically spam-related) robot.

The reCAPTCHA system presents pairs of words optically scanned from books,
and asks the user to identify them.  In the process, it also uses the
resulting data to help "decode" those scanned words into their correct
machine-readable textual representations as part of larger book scanning

This obviously makes reCAPTCHA a perfect match for Google, who is faced with
the challenge of processing vast numbers of books in their Google Books
project, some of which have fairly high OCR (Optical Character Recognition)
error rates due to the difficulty of machine recognition of odd fonts, faded
printing, and so on.

However, there is a potential privacy problem with reCAPTCHA (or any
centralized CAPTCHA system, for that matter), that Google will need to face.

Early this year, while in the process of setting up an Internet-based forum,
I considered using reCAPTCHA as part of the validation procedures.  Since
centralized CAPTCHA servers will typically collect IP address and
potentially other data from users at the time of page display, and again
when users interact with the CAPTCHA systems (for registration, message
sending, etc.), these servers receive a running log of information regarding
the users of the sites who are incorporating those CAPTCHAs into their

So I was very surprised to discover that I could not find any reCAPTCHA
privacy policy explaining to ordinary Web users displaying those pages, or
interacting with the reCAPTCHA system, how that collected data would be
handled from a privacy and data protection standpoint.

I queried CMU about this, and the reCAPTCHA support team replied that they
did have an extensive privacy policy, but that it only appeared when
reCAPTCHA API keys were created — that is, when a Web site administrator
wanting to incorporate reCAPTCHA into a site applied for reCAPTCHA access.
There was nothing to tell conventional users how their IP address or other
data would be handled by reCAPTCHA as a result of their viewing or
interacting with a Web site page incorporating reCAPTCHA functionalities --
that is, no privacy policy to be found at all for those users at that time.
Partly for this reason, I chose not to use reCAPTCHA for my forum.

With reCAPTCHA moving under the Google umbrella, it will be crucial that
Google clearly explain, in a visible and specific privacy policy, how they
will collect, correlate, and otherwise use IP address and other data
associated with reCAPTCHA display and use.

Fundamentally, this situation is similar to that with ad display systems,
where the very act of viewing a page that includes external ads may pass IP
address info (and sometimes other data) to third parties.  However, while
Web users can usually choose to block external ads in various ways if they
wish (something I do not recommend or promote — see "Blocking Web Ads --
And Paying the Piper" - ),
blocking CAPTCHAs would usually mean losing access to the associated sites
in significant ways.

As an enthusiastic supporter of Google Books ("The Joy of Libraries, a
Fireman's Flame, and the Google Books Settlement" - ), I fully appreciate the value
that reCAPTCHA will bring to Google, and ultimately to all users of Google

But I also believe that it's very important for the privacy issues
associated with reCAPTCHA to be properly handled by Google, hopefully in a
manner significantly better than Carnegie Mellon's own approach earlier this

Lauren Weinstein, +1 818-225-2800
Network Neutrality Squad Blog:
Global Coalition for Transparent Internet Performance -
pfir mailing list: - a case study in how to run an insecure website

Jonathan Kamens <>
Wed, 23 Sep 2009 23:06:34 -0400

The Direct Marketing Association runs a Web site,,
that people are supposed to be able to use to enroll in the DMA's "Mail
Preference Service" (MPS) to opt out of bulk mailings (paper junk mail, not
spam), or to opt into bulk mailings from specific companies.

I registered at the site about a year ago.  I had to create two
different accounts because they only allow up to five addressees to be
specified on a single account.  At that time, I was asked to provide a
username distinct from my e-mail address, which is good idea security-wise.

Recently, I returned to the site to confirm that I was still opted out
of bulk mailings.  Lo and behold, the login page had changed, and where
before it had said "Username", it now said "E-Mail".  It appeared that
they had decided to no longer differentiate usernames from e-mail
addresses and I would have to register again using my e-mail address as
my username.  In fact, I learned later that I could have logged in with
my old username, at which point it would have prompted me to enter my
e-mail address and changed my username to it.

Problem #1:* *Forcing users to use e-mail addresses as usernames is bad

Problem #2: Switching your username format without bothering to tell
existing users that they can still log in with their old usernames is
stupid for all sorts of reasons, albeit perhaps not a security issue per se.

Thinking that my old accounts were no longer valid (having been given no
reason to believe otherwise), I set out to register again.  Note that
they still only allow up to five recipient names to be specified on a
single account, which leads us to...

Problem #3: If the site requires you to use your e-mail address as your
username, how are you supposed to register more than one account on the site
if you need to enroll more than five addressees in the MPS?

Fortunately, my mail server supports extended addresses with the
semi-standard syntax of using "+" as the separator between the mailbox name
and extension to the left of the "@" sign (i.e., "jik+foo@...",
"jik+bar@...", etc. all end up in my inbox), so I figured that I would
simply register two accounts with the e-mail addresses "jik+dma@..." and
"jik+dma2@...".  Alas...

Problem #4: The DMA Web site does not accept "+" as a valid character to the
left of the "@" in an e-mail address, even though in fact it's perfectly
valid according to all relevant e-mail standards. (I wish I could say that
this problem is unique to the DMA site, but alas it's one I've encountered
many times before.)

However, all was not lost.  Since I maintain my own mail server, I was able
to create two new aliases for myself without "+" signs in them, which I did.
I then proceeded to successfully register using the first alias.  I ran into
a bit of difficulty along the way, because...

Problem #5: The site uses CAPTCHAs to prevent automated registrations.  The
CAPTCHAs are case-sensitive, but the letters in the CAPTCHA are of varying
sizes and for many of them it's impossible to tell whether they're in lower
or upper case.  (I don't know whether this is because the DMA implemented a
stupid home-grown CAPTCHA generator or there's actually a third-party
generator out there which is this stupid, but I don't think I've ever
encountered another Web site with CAPTCHAs with the same problem.)

When I registered the first account, a confirmation screen was displayed
after I clicked the "Submit" button on the registration screen, and I was
sent an e-mail message with a link I had to click on to confirm my e-mail
address and activate my account.  Unfortunately, when I tried to register a
second time with the other e-mail alias so that I could enroll the rest of
my family in the MPS...

Problem #6: I got a blank confirmation screen after clicking the "Submit"
button, and no activation e-mail was sent.

Thinking that perhaps my cookies and/or browser cache were confusing the
site, I cleared them both.  It didn't make any difference.  Thinking that
perhaps they were throttling the number of registrations from a single IP
address, I tried from two other IP addresses on completely different
networks; that didn't make any difference either.  Thinking that perhaps
Firefox might be a problem, I tried with both IE7 and IE8; no luck.  In
short, for some inexplicable reason, although I was able to register just
fine once, I was unable to repeat the feat a second time.

Only just now, as I'm writing this, have I realized that the first e-mail
address I used was 30 characters long, while the second was 31.
Therefore, I have realized that...

Problem #7: The reason I was unable to register the second account is almost
certainly because there's a hard-coded, bogus 30-character limit on e-mail
addresses somewhere in the DMA's application or database schema, along with
a bug which prevents the application from notifying the user of the problem
when the limit is exceeded.

I used the "Contact Us" link on the Web site to let them know the address I
was trying to register and the behavior I was seeing.  A day later, I
received a response.  Paraphrasing: "Sometimes the Web site doesn't work.
Try again after about an hour.  If it still doesn't work, you'll have to
print out the form and register by mail."

Problem #8: If I'm right about the 30-character limit on e-mail
addresses, and I'm fairly certain that I am, and I told their customer
service people the e-mail address I was trying to register, then surely
the "Supervisor" who responded to my e-mail should know about this
problem and should have been able to tell me what was wrong and how to
work around it (use a shorter e-mail address).

In response, I asked to speak with someone who could actually debug the
issue and figure out why it wasn't working so that I could register
through the Web site.  My correspondent said that would not be possible.

Problem #9: Web site problems which make the site completely useless for
some users are dismissed with "Oh, well, sometimes the site doesn't
work," and, "It's just too bad for you if it doesn't."  The people
running the site simply don't care about getting to the bottom of these

I sent back a more strongly worded complaint to this effect.  Several
hours later, I received a response from someone different at the DMA.
Excerpting from her response:

  I did a little research on your behalf and found that you had already
  created two accounts last year for the same seven family members back on
  08/14/2008; for [names elided] the old username for the 2008 account is:
  [elided] and the old password is: [elided].

  The second account for the other two names [elided] was created on
  08/14/2009.  The old username name was: [elided] and password [elided].

  What I did on the existing second account was to change the username into
  the other e-mail address that you were trying to use.  So now the second
  account is username: [elided] and the password is the same.

I'm sure I don't have to tell people what's wrong here, but just to be

Problem #10: Passwords are stored in plain-text and accessible to DMA
employees rather than stored as the result of a one-way hash.

Problem #11: The DMA employee provided me with usernames that I had never
provided to her.

Problem #12: The DMA employee sent my passwords through e-mail.

(The last three problems are, of course, by far the worst of the ones listed
in this message.)

Problem #13: This second DMA employee made no more effort than the first one
to acknowledge the root cause of my problem, i.e., that I should have been
able to register the second account myself and that the DMA should actually
make some effort to figure out why I couldn't and fix it.

Problem #14: This second DMA employee also didn't say anything about e-mail
addresses more than 30 characters long not working.  (On the other hand, if
you combine the "Never attribute to malice..." rule with the fact that
neither employee I dealt with showed any inclination to try to identify the
root cause of the issue, perhaps it's reasonable to conclude that they
really don't know this is the problem.)

I'm so flabbergasted that I have to go back a bit and repeat myself in

Thanks, I feel much better now.

When there are Web sites like this on the Internet and people like this
maintaining them, is it any wonder that there are new revelations about
serious data breaches several times every week?

Retailer Must Compensate Sony Anti-Piracy Rootkit Victim

Wed, 16 Sep 2009 05:46:29 +0800

[[From the boy who cried RISK]]

...Claiming for his losses, the plaintiff demanded 200 euros for 20 hours
wasted dealing with the virus alerts and another 100 euros for 10 hours
spent restoring lost data. Since the plaintiff was self-employed, he also
claimed for loss of profits and in addition claimed 800 euros which he paid
to a computer expert to repair his network after the infection.  Added to
this was 185 euros in legal costs making a total claim of around 1,500

The judge's assessment was that the CD sold to the plaintiff was faulty,
since he should be able to expect that the CD could play on his system
without interfering with it.

The court ordered the retailer of the CD to pay damages of 1,200 euros.

Re: Quantum chip helps crack code (RISKS-25.78)

Steve Wildstrom <>
Tue, 15 Sep 2009 12:40:54 -0700 (PDT)

I'm sure it can also factor 4, 6, 8, 9, 12,and 14. But if you only have four
qubits, you can only count to 15, assuming unsigned integers. The real hard
problem is scaling a quantum computer into something useful. It seems that
no matter which technology we use, we have been stuck at 4 to 8 qubits for
many years. Wake me when a quantum computer can factor RSA151.

Please report problems with the web pages to the maintainer