The RISKS Digest
Volume 20 Issue 98

Monday, 31st July 2000

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…


o San Mateo health system upgrade is a downer
o Scientists spot Achilles' heel of the Internet
Dave Farber
o Booming computer firms are running out of power
Doneel Edelson
o Stephen King's not scared of trusting online readers
o The paperless benefits plan
Greg Compestine
o When what you see isn't what you get
Lloyd Wood
o Computer crash caused loss of cab schedule
Jacob Palme
o Re: Bloat Dissections II
Jonathan Guthrie
o Re: The Least Mail Online
Nick Andrew
o Re: London Underground magnetic ticket bug
Boyd Roberts
Clive Feather
o Re: AT&T exposes account info
Dima Maziuk
o Susan villages
Mark Brader
o Info on RISKS (comp.risks)

San Mateo health system upgrade is a downer

"Peter G. Neumann" <>
Fri, 28 Jul 2000 21:29:33 PDT
San Mateo County has spent $35 million thus far on a new Health Services
computer system (now two-years old) that was expected to integrate 40
different stovepipe entities that previously were unable to communicate with
one another.  Over the past few months, the system has been so unreliable
that it could not even send out medical bills.  The backlog of account
receivables is now more than $40 million.  Blame is being distributed among
poor initial outside advice, a sudden cut in anticipated money, and damaging
turnover in consultants.  The costs are about double what had been budgeted.
[Source: Article by Mark Simon, *San Francisco Chronicle*, 25 July 2000,

As an aside that seems relevant to many other situations if not to this one,
outsourcing of responsibilities (from requirements to design to
implementation to operation and maintenance) is increasingly popular, but
doomed if you don't have serious in-house competence to understand what is
being outsourced.

Scientists spot Achilles' heel of the Internet

Dave Farber <>
Mon, 31 Jul 2000 06:50:38 -0400
  [From Dave Farber's wonderful IP distribution.  PGN]

The complex structure of the Internet makes it resistant to errors or
failure but it is also its Achilles' heel [...].  Because the system is so
varied, if one or more nodes — the crossroads through which Internet data
travel — goes down it has very little impact.  But researchers at Notre
Dame University in Indiana ... have found if the networks with the most
highly connected nodes were attacked by cyberterrorists, it could fragment
the Web into isolated parts.  [Excerpt from an article by Patricia Reaney,,
Reuters, 26 Jul 2000]

  [But the Internet is a well-heeled beast: it has MANY Achilles' heels. PGN]

Booming computer firms are running out of power

"Edelson, Doneel" <>
Tue, 11 Jul 2000 09:45:20 -0400
Companies in Silicon Valley, California, are being forced to build private
power stations amid growing evidence that there is not enough electricity in
America's grid to drive the booming high-tech industry.  US demand has grown
by 35% in the past 10 years.  [Is that all?]  More than 10% of all US power
is for computers and related stuff.  The Internet is making it even more of
a problem.  According to Karl Stahlkopf of the Power Research Institute,
"You may think electronic gadgets can't use much electricity. In fact, when
you look at the servers and the computers that back up the wireless Palm
Pilot for example, you'll find it has the electrical load equivalent of a
refrigerator."  [PGN-ed from an article by Simon Davis, electronic
Telegraph, 11 Jul 2000]

  [Another item from Doneel noted an Associated Press article by Nicholas
  K. Geranios, Power rates in West jolting economy, 10 Jul 2000, discussing
  the effects of a sudden large hike in the cost of electric power on the
  West coast — including cases of rates being multiplied by a factor of
  40 in one case.  PGN]

Stephen King's not scared of trusting online readers

"NewsScan" <>
Mon, 24 Jul 2000 09:21:22 -0700
He's back.  Horror writer Stephen King has now used his Web site
( to post the first two installments of his new novel
"The Plant," which is about a "vampire" plant that takes over a publishing
company.  The material will be posted as pdf files, and readers will be
trusted to pay the author a dollar to download it.  If King receives payment
for at least 75% of the downloads, he will continue with his plans to post
the remainder of the book on the Web.  People in the publishing industry are
skeptical.  Literary agent Mort Janklow says that King is "a fellow sitting
up in Maine having fun, but it's not a way to run a business."  And National
Writers' Union president Jonathan Tasini says, "You still need a lot of
money and power to promote a book.  The same people who already make a good
living at the top of the bestseller list may have another way to sell, but I
don't believer there will be dramatic change for other authors."
[AP/[San Jose] *Mercury News*, 24 Jul 2000; NewsScan Daily, 24 July 2000]

The truth about e-books

Despite the hoopla surrounding the e-publishing of Stephen King's novella,
"Riding the Bullet," the truth is that most of the 500,000 electronic copies
distributed were purchased by Amazon and, which then gave
them away, and many other copies downloaded were simply "experiments" by
people who wanted to see if the technology worked.  According to a survey of
3,000 subscribers conducted by the Book Report Network, only 1%, or 5,000,
of those who downloaded King's first e-book actually read it.  "No reader is
asking for e-books," says Book Report Network CEO Carol Fitzgerald.  "This
is not the Sony Walkman." Publisher Simon & Schuster, which distributed the
novella, disputes the Book Report sampling.  [*Los Angeles Times*, 24 Jul
2000 NewsScan
Daily, 24 July 2000]

The paperless benefits plan

"Greg Compestine" <>
Mon, 10 Jul 2000 15:42:48 -0700
Last week I received an e-mail informing me that annual enrollment for
benefits at my company would now be handled on the Internet. The e-mail
included a login ID and password for use at the enrollment Web site but,
oddly enough, not the URL for the Web site. Web enrollment is mandatory.

The e-mail contained an attached memo in MS Word format (itself wrought with
RISKs). The memo in the e-mail was entitled "Read this to find out how you
can win cool stuff courtesy of ____ HR!" (Company named deleted.) It goes on
to say that "This will enable you to complete open enrollment on-line, view
your enrollment elections and tax withholding information anytime, change
your address, change your 401(k) contributions, add dependents or
beneficiaries, and soon you will be able to view your pay stub here too."

I sent off a complaint about having so much data accessible on the
Web. Today there were several developments.

First I discovered that I was not on the company-wide mailing list used to
distribute announcements about benefits.

Then I received a reply to my complaint that the company was "sensitive to
the security issues" and described two conflicting security
measures. without a URL to rule out possibilities, either:

a) the benefits Web server is behind the corporate firewall, where its
   security is administered by a third-party sys-admin shop, or

b) the Web server is on a third party machine where we have no direct
   control over the security arrangements. (I'm not sure which alternative
   is worse.)

Is there any kind of audit or accrediting that Web sites can go through to
verify at least minimal security arrangements? If so, I'd really like to
know about them.

Among the RISKs I can list:

1) the company's jumping into this whole hog, without an apparent backup
   plan, or alternatives for people who don't want their entire employment
   record and benefits package hanging out in inherently insecure and
   unreliable Web space.

2) The login and passwords sent out by e-mail could be intercepted; they were
   in no way protected.

3) The format of the logins and passwords make it extremely easy to guess
   others. (NOT the first time I've encountered this here. The third party
   company responsible for sys admin has a habit of assigning incredibly
   obvious passwords based on the user's name.)

4) Once guessed, a user ID and password could at a minimum provide for a
   denial of service attack on an individual. I don't know (and I hope I
   don't have to find out) what procedures are in place for changing or
   recovering a password.

5) Using Web enrollment has been made into a lottery game with prizes, which
   causes me to wonder if we're really supposed to take any of it seriously.

6) Overreliance on Internet technology has already caused me to miss out on
  receiving some important information on the benefits package.

7) The deadlines for enrollment obviously assume that there won't be any
   major glitches in the system. "You must enroll by 7/31 or risk having
   your benefits canceled." Yet just two months ago, when my company moved
   the employee stock purchase plan to Web-based administration, glitches
   caused several weeks delay in enrollment for many people.

When what you see isn't what you get

Lloyd Wood <>
Mon, 31 Jul 2000 18:36:48 +0100 (BST)
One of our web users seems to have had a lot of trouble with broken links in
his personal webpages on our Apache webserver over the last couple of years.

Instead of / as a directory terminator, he'd have \. Or he'd have bizarre
stuff like /\Directory\ instead of /Directory/ in his broken links.

I'd put it all down to him being a Microsoft fanboy who didn't know what he
was doing; after all, he was generating the HTML pages using Microsoft Word,
and therefore deserved everything he got.

(bugs in Frontpage such as leaving in local file:c:\\\ urls for images, so
only the author gets to see incredibly fast-loading images when he checks
his composed pages, are well-known.)

However, I had occasion to use Microsoft's Internet Explorer 5.5 today. So,
I went to view his pages to see the world through his eyes.

And, through his eyes, everything worked just fine, as if there were no
backslashes there at all. Every known-to-be-broken link did just the right
thing. Which was odd, because I knew the links in the pages stored on our
Apache server hadn't changed.

So I viewed source in IE, and discovered... no backslashes.  IE *stripped
out or converted the backslashes* before rendering the source to screen -
even before rendering the source to 'view source'.

The user wouldn't know the backslashes were there, because IE was
*deliberately hiding and converting them* for him, presumably in order to
compensate for the html rendering deficiencies of other Microsoft products -
and interoperability with non-Microsoft browsers be damned.  The user
thought he was doing a good job, based on checking using the tools in front
of him.

If you view source, you expect to see the actual source, and not a
prefiltered version. This filtering is clearly a risk in that it allows
behaviour that would previously have been clearly exposed as bugs in the
composing products to stay, unnoticed and uncorrected, because it means you
can't trust the tool you're using, and because it screws up interoperability
testing.  (Which, because IE comes from Microsoft, is hardly a surprise.)


Computer crash caused loss of cab schedule

Jacob Palme <>
Sun, 30 Jul 2000 10:45:43 +0200
When I was leaving home to travel to the IETF meeting in Pittsburgh next
week, the pre-ordered taxi did not come on time. After waiting five minutes,
I phoned them and was told that they had had a computer crash during the
night, and all pre-bookings had been erased. They sent a cab when I called,
and I arrived at the airport 20 minutes late (the bus on the second leg on
the journey was also delayed). I did catch my flight, but with criticism
from the ticket checkers that I was late. I did not have time to change
money at the airport as I had planned. So my loss was only perhaps 10-15
dollars in more expensive credit card buys as compared to cash buys. Others
may have been less lucky. The flight was not delayed, this airline obviously
did not feel that this was a reason for delaying the flight.

I do not know of the cause of the crash, so one can only guess:

1: The computer stopped, and no one on a Saturday night knew
   how to reboot it.

2: Software failure.

3: Random disk error in the data base files made them unusable.

4: A real disk crash had occurred.

One wonders about

1:   Did they have adequate instruction on error handling and education
     to their operators, or a system with a software specialist on call?

2:   Was the software tested well enough?

3-4: Did they use some disk redundancy system capable of
     continuing running if a single disk crashes or a single
     disk error occurs?

In particular, disk redundancy systems and fail-safe computers (not 100 %
safe, of course) do exist, but how often are they used when they should have
been used? A time-scheduling system, whose breakage would delay hundreds of
people by 20 minutes in going to the airport, would that be a system which
should have a disk redundancy system?  Perhaps the companies marketing such
systems could use this example as a basis for selling their software to
companies who do not understand the risks and what can be done about them.

The cab company involved was "Flygbusstaxi" — which is a shell company for
several other cab companies providing the actual transportation services

Jacob Palme <> (Stockholm University and KTH)
for more info see URL:

Re: Bloat Dissections II (Liber, RISKS 20.92)

Jonathan Guthrie <>
Sun, 16 Jul 2000 11:04:10 -0500 (CDT)
> The real cost isn't in the 10-minute fix; it's in verifying the 10-minute
> fix.  That is the RISK.


The real risk is using an invalid analysis to reach a bogus conclusion.
THAT is the risk.

How is Mr. Liber's analysis invalid?  Well, off the top of my head and in
no particular order, he makes an "apples to oranges" comparison, adds
costs to the bloat removal process that aren't necessarily there, does not
fully account for the costs of bloat, and assumes facts not in evidence.

When comparing the costs of the bloated software to the cost of removing
the bloat, Mr. Liber compares the amount of time required to remove the
bloat with the amount of money required to store the bloated software on a
hard disk.  Obviously, he should compare time against time or money
against money, but he cannot compare money against time unless the
conversion between the two is known.  This is especially true when he

> Your fix is worth, at best, a fraction of a cent to your customer.  If this
> causes you to slip shipping by even one day, you've made a bad decision to
> work on it.

This begs the questions: How much is a one-day slip in the release of a
commercial application worth to a customer?  Mr. Liber appears to assume
that it costs quite a bit .  However, it is not that hard for me to imagine
a situation where a single day slip in the release date of an application
has a significant NEGATIVE cost to a particular end user.  In no case is the
answer to my question large and positive for end users of mass-market
software.  Waiting an additional day for the next version of "Word" simply
doesn't cost the user very much.

How is the cost of removing bloat overstated?  Well, because the regression
testing mentioned in Mr. Liber's message would need to be done anyway as
part of the release process for any new software version.  Since removing
the bloat would, most likely, be done before the application began the long
road through the QA department (assuming, of course, that there IS a "long
road through the QA department" which is another discussion for another
time) then there is NO additional testing cost associated with removing the

Perhaps the strongest disagreement I have with Mr. Liber's message is the
attempt to argue the costs of bloat out of existence.  The cost of bloated
software is more than just a few cents worth of hard disk space.  You see,
when used, that software needs to be transferred from the hard disk into
main memory.  While the capacities of hard disks have expanded rapidly, the
time required to transfer large files from a hard disk has not decreased
quite so much and the time is not linear with the size of the software to
load: Programs that are twice as large typically take more than twice as
long to load.

And this time adds up.  If bloat causes the software to take an average of
one additional second to load and the software has an average of 100,000
uses daily over the entire customer base, then over an 18-month lifespan the
product wastes 1545 man-days of time just waiting for the software to load.
Compare that to a couple of weeks for a couple of guys and you get quite a
different answer for whether it is worth the effort to reduce the bloat than
that presented in the original message.  Especially in light of the fact
that, if the total production run for the software is 1,000,000 units, the
bloatware reduction effort takes 100 man-weeks, and each man-hour costs
$100, the total increase in the cost of each unit as a result of that
bloatware effort is 40 cents.

Nor is the time required to transfer the program off the hard disk the only
cost that was missed in the original analysis.  In addition to the cost of
the additional hardware required to run ever more bloated applications,
you've got to include the downtime required to upgrade the hardware to
satisfy the requirements of software that won't run on older hardware.  If
the application lives on a file server, then you've also got wasted network
bandwidth and wasted time to periodically upgrade the network to handle the
additional load.

Further, it seems likely to me that the larger an application is, the more
likely it is to exhibit poor locality of reference which means that bloated
applications make less effective use of semiconductor cache and require more
effort to make effective use of virtual store.  The net effect of bloatware
is, therefore, to make the entire computer system perform more poorly, even
on higher-performance computers of recent manufacture.

The facts not in evidence?  Well, Mr. Liber's message implies that the
decision to release bloatware is always the result of a careful analysis,
made by the software vendors, of the relative costs and benefits.  If only
that were the case!  There is a profound difference between a conscious
choice to reduce the cost of a product by not reducing the size of an
application and releasing bloatware because of ignorance or apathy.  Use of
the additional resources available in recently manufactured microcomputers
is allowable.  Waste of those same resources is, to me, unacceptable, and
waste is certainly what it appears, to me, to be.

In fact, the part that really makes me angry is the fact that the benefits
of not reducing the bloat are reaped solely by the software vendor, but the
costs are borne solely by the consumer.  This shows a disrespect of the end
user that borders on contempt.  I don't like to be held in contempt by those
who want me to give them money.

One opinion, worth what you paid for it.

Jonathan Guthrie, Brokersys, 12703 Veterans Memorial #106, Houston, TX
77014, USA +281-580-3358

Re: The Least Mail Online (RISKS-20.97)

Nick Andrew <>
29 Jul 2000 16:42:52 +1000
> ... Sprint Canada's The Most Online service had one of its regularly
> unscheduled outages last week, this time affecting incoming e-mail.

There is a related risk here - the risk of assuming that you are dependent
on a provider for E-mail services. It is a relatively simple matter, given
a static IP address, your own domain name and a (semi-)permanent link,
to run your own mail server which will allow you to have some control
over E-mail reliability. So long as your server is actually connected
to the Net, (which you can test) the ISP's mail server is now out of
the loop as E-mail can pass directly from the source to your destination.

Nick, Pacific Internet  +61-2-9253-5762

Re: London Underground magnetic ticket bug (Feather, RISKS-20.97)

Mon, 31 Jul 2000 10:56:11 +0200
> ... If the member of staff has to leave for some reason, he or she *MUST*
> deactivate the system, which opens all the gates. This is a Health and
> Safety issue, and LU would be fined heavily if caught breaking it.

You never fix bad design by kludging around it.  That, by definition, proves
that it was badly designed.  You design it right and you design it so that
it's fail safe.

Boyd Roberts  <>

Re: London Underground magnetic ticket bug (Roberts, RISKS-20.98)

"Clive D.W. Feather" <>
Mon, 31 Jul 2000 13:50:56 +0100
> You never fix bad design by kludging around it.  [...]

"Don't let people get trapped behind unmanned gates" is a bad design?
I hope you don't design life-critical systems.

Clive D.W. Feather <> +44 20 8371 1138

Re: AT&T exposes account info (Chapin, RISKS-20.97)

Dima Maziuk <>
Fri, 28 Jul 2000 23:44:01 -0500
> You can type a home phone number into their voice menu system and it will
> answer back with the account standing, recent payment amounts and dates,
> without any password or other authentication. ...

Were you calling from home? — I[1] would check if the number you typed
matches CLI[2] we get from the exchange when answering your call. If it does
there's no reason for extra security: whoever's calling is already inside
your house...

Telstra[3] voice mail works the same way: if you call from home you're
asked for PIN, if you call from somewhere else you have to type in
mbox number and pin[4].

[1] my last job was IVR programming
[2] caller line id
[3] main carrier in .au
[4] of course you don't know your mbox number — you've always called
from home before and nobody ever told you your mbox has a number...


  [Also noted by Jonathan Kamens, who added:
     Sure, there's the possibility that someone without legitimate need for
     that data could call AT&T from your home telephone, but that's not a
     particularly likely scenario or one with much risk associated with it.]

Susan villages

Mark Brader <>
Sun, 30 Jul 2000 00:08:35 -0400 (EDT)
* From: Frances Kemmish <>
* Newsgroups: alt.usage.english
* Subject: Re: Susan
* Date: Wed, 26 Jul 2000 08:50:17 -0400

John Steele Gordon wrote:
> Alex Chernavsky wrote:
> > Frances Kemmish wrote, quoting _Finest Hour: The Battle of Britain_:
> >
> > >A fuller quotation, from page 179 of the US edition:
> > >"But a forced peace, rather than Panzers in Susan villages,
> > >was the most likely way Britain might lose the war in 1940."
> >
> > Pandas in Sichuan villages?  Certainly, that strategy would have been
> > a less likely way for Britain to lose the war.
> Panzers in Sussex villages, however, would have done the trick.

I think this is the answer; it fits both the references to "Susan".

I assume that the US edition was spell[ing]-checked using the same
spell[ing]-checker which I have - it offered me "Susan" as first replacement
for "Sussex".


  [This thread included a variety of other computer-aided mispelingz.  PGN]

Please report problems with the web pages to the maintainer