The RISKS Digest
Volume 20 Issue 52

Thursday, 5th August 1999

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 Can You Trust AT&T Wireless PCS Text Messaging?
Lauren Weinstein
o EverQuest devours players' lives
Mich Kabay
o Microsoft Word footnote problems irks federal appeals court
Declan McCullagh
o Perceived medical risk must often substitute for actual risk
John Doyle
o Open-source anesthesia software article in Salon
Martin Minow
o Re: IMRSS and Open Mail Relay Scanning
Lauren Weinstein
o Re: Japanese toilets
Chiaki Ishikawa
Brian Randell
Colin Sutton
o Risks of RISKS
Brian T. Schellenberger
o eBay's response to the eBay scam
Ray Randolph
o Re: Go FORTH and Multiply
Leo Wong
o Re: Heat wave
David Wittenberg
o Info on RISKS (comp.risks)

Can You Trust AT&T Wireless PCS Text Messaging?

Lauren Weinstein <>
Wed, 04 Aug 99 19:47:17 PDT
Greetings.  Can you trust that messages sent via AT&T Wireless PCS Text
Messaging will always be reliably processed and received?  Unfortunately,
the answer appears to be no.  What's worse, when failures do occur, there
may be absolutely no indication to the sender of the message that their
communication has vanished into the ether.  An an example of a serious risk
associated with a more general class of modern, widely-used communications
systems, I believe that this is worthy of a detailed explanation and
significant concern.

The use of text paging directly to digital/PCS cellular phones is rapidly
replacing the use of conventional numeric and text pagers.  Such phone-based
text messaging, actually called "SMS" (Short Messaging Service) has a number
of advantages over older paging systems.  One of its biggest benefits is
that the network will normally store messages for some extended period of
time (e.g. 72 hours) for delivery to the phone, if the target phone is off
or out of range.  When the phone again is available, the message is
delivered, and the network receives confirmation that the message was
successfully delivered to the phone.  SMS messages typically can range
between 110 and 150 characters or so, depending on how they are submitted
and various formatting considerations.

The usefulness of SMS has caused an explosion in its use for all manner of
free and pay information and warning systems, where automated systems will
send messages (usually via an Internet e-mail interface provided by the
wireless carriers) to users.  Such messages could be anything from critical
status messages for system support or medical personnel, to news bulletins
and stock price warnings to traders.

But how useful is the entire environment if you cannot depend on messages
ever actually being delivered, and if messages can vanish into
a "black hole" without any warning?

AT&T Wireless (ATTWS) has, as you might expect, one of the most extensive
SMS implementations.  They provide three interfaces to the service:

 * a web-based "form" interface: type in your message and hit send

 * a direct dialup interface for specialized text paging software's use

 * an Internet e-mail interface: messages are sent to
   <cellular-number>@; "Vortex
Daily Reality Report & Unreality Trivia Quiz"

EverQuest devours players' lives

Mich Kabay <>
Fri, 30 Jul 1999 00:12:25 -0400
Hunter Godfrey is quoted as saying that EverQuest "is the digital version of
crack."  He has spent over 656 hours on the game in about four months, the
equivalent of 82 8-hour days.  There are over 150,000 players ``hunting
monsters, collecting loot, and forging alliances in MUD world.'  [Source:
Noah Shachtman, EverQuest: the Latest Addiction, Wired Digital, 29 Jul 1999;

  [Watch out for network congestion on corporate systems when this
  infiltrates workplace networks.  M.E. Kabay, PhD, CISSP / Director of
  Education R&D Group / ICSA Labs <>]

Microsoft Word footnote problems irks federal appeals court

Declan McCullagh <>
Wed, 04 Aug 1999 14:40:40 -0700
The U.S. 7th Circuit Court of Appeals is peeved at Microsoft. Seems as
though unlike WordPerfect, MS Word doesn't count properly footnotes, and
lawyers doing wordcounts have been running over length limits on briefs.
Naughty, naughty, say the judges, who kvetch: that MS "ought to make it
possible to obtain a count of words in footnotes attached to selected
text." The august three-judge panel has forwarded a copy of its design
recommendations to Redmond. More info in a Wired News story (4 Aug 1999):


Perceived medical risk must often substitute for actual risk

"John Doyle" <>
Sat, 31 Jul 1999 10:16:59 PDT
All human activities entail risk.  Indeed, to live is to take risks.

In the medical realm, patients who undergo anesthesia and surgery are
frequently concerned about the risks involved, such as the risk of *not
waking up*  (or as one patient put it, *waking up dead*).

The risk of death or brain damage to patients undergoing general anesthesia
is remarkably low, particularly for healthy patients in modern hospitals.
When an accident does occur, its cause is often an error made by the
anesthesiologist, either in triggering the accident sequence, or failing to
take timely corrective action. The overall risk of death for general
anesthesia in all comers is in the range of 1 in 10,000, the exact estimate
depending on how one separates anesthesia misadventures (such as airway
problems) from surgical misadventures (such as accidentally avulsing an

Risks for individuals with specific conditions are sometimes known, but
usually not. For example, administering general anesthesia when a patient
still has residual food in his stomach poses special risks since the food
sometimes ends up in the lungs (known as aspiration), with consequences
ranging from trivial to deadly. However, risk data specific to any patient
in this situation are not yet available. For instance, factors such as the
"state of the anesthesiologist", characterized in terms of alertness,
vigilance, and competence, would also be important.

(Of course, anesthesiologists employ a few good tricks to reduce aspiration
risk. One trick that is not generally used would be to suck out all the food
under visual guidance using a gastroscope. However, this procedure in itself
introduces new risks and is at best unpleasant in the awake patient.)

Some individuals are surprised to learn that in a great many situations
(indeed, in most complicated clinical situations) the risks of anesthesia or
surgery may not be even approximately known (as in known to within an order
of magnitude). No algorithm yet exists that one can use to get quantitative
risk estimates for all situations. An example illustrates the point.

Recently I was asked to give an anesthetic for a man with several serious
heart problems, the most pressing being a chaotic heart rhythm known as
atrial fibrillation, which the heart doctors planned to fix with a big
electric shock to the chest under general anesthesia (cardioversion). Once
atrial fibrillation has started, it must be fixed within 48 hours or it will
be necessary to start anticoagulant therapy (administration of *blood
thinners*) to reduce the risk of a stroke. We had about 30 hours left.

Because of concerns about harming the patient with a general anesthetic I
initially recommended against the cardioversion (electric shock) procedure,
viewing drug therapy to be a clearly safer alternative. The trouble with
drug therapy, however, is that it is far less effective and in addition
requires a much longer hospital stay. In other words, cardioversion was by
far the quickest and more cost-effective choice, although drug therapy
appeared to be the safer choice.

But the final twist that lead us to go for the cardioversion was that the
cardiologist pointed out that if drug therapy turned out to ineffective in
this individual by the end of the 48 hour window, the option of subsequent
cardioversion could not again be exercised until 4 weeks of anticoagulant
therapy had passed. The risks (such as the risk of bleeding) and costs
associated with that option now made cardioversion seem more attractive.

The unique nature of this particular patient's problem list meant that any
risk estimates from the literature would almost certainly be meaningless. It
was therefore necessary to rely on judgement drawn from experience rather
than formal risk data. Perceived risk must substitute for actual risk in
many settings.

D. John Doyle MD PhD FRCPC, University of Toronto and Toronto General Hospital

The proposed drug therapy was intravenous amiodarone. Medical conditions
included: recent myocardial infarct with impaired ventricular function,
aortic stenosis, atrial fibrillation, gastroesophageal reflux (a *full
stomach* equivalent situation.) The patient was also known to be very
difficult to intubate because of a small chin!  Finally, note that
moderately reliable mortality estimates for multi-organ failure patients in
Intensive Care Units can be obtained by using the APACHE II algorithm; this
is one of the few situations where good risk data exist for complicated

Open-source anesthesia software article in Salon

"Minow, Martin" <>
Thu, 5 Aug 1999 07:57:03 -0700
Risks readers may be interested in an article by Andrew Leonard in the
online magazine, Salon, on the risks (and potential advantages) of
open-source medical software:


"When he isn't in the operating room taking care of patients, [Dr. Stefan]
Harms is hacking on the five computers in his basement. And he thinks he
knows how to achieve his dream of low-cost, reliable anesthesia software --
by going the open-source </tech/special/opensource/> route. Last year, Harms
founded LAMDI, <> the Linux Anesthesia
Modular Device Interface. Harms thinks that the open-source software
development model, in which the source code to a program is made freely
available to the general public for redistribution and modification, offers
fruitful possibilities for addressing anesthesiological software needs.  ...

"The obstacles faced by Harms in his quest for open-source anesthesia
software suggest that there are some serious potential limits for the
open-source software model. The experience of some medical programmers who
have placed their code in the public domain indicates that open source is
certainly no panacea for the problems faced by medical practitioners. But
there are still some intriguing possibilities. If liability issues can be
addressed, and if the peer-review component embedded in open-source software
can be proven to result in pragmatically better software, then, suggest some
open-source enthusiasts, wouldn't it be our duty to proceed down the
open-source road?"

(Transcribed by Martin Minow,, with apologies for any
residual Windows formatting cleverness)

Re: IMRSS and Open Mail Relay Scanning (Roessler, RISKS-20.51)

Lauren Weinstein <>
Mon, 2 Aug 99 19:16 PDT
In RISKS-20.51, concerns were raised over,
their ongoing automated search for open mail relays, and the publicly
accessible query database of the resulting data which they maintain.  It was
suggested that such a database might actually help spammers find potential
relay targets.

I was also concerned about this, and sent them e-mail asking for
clarification on a number of related issues.  After several attempts (they
have various automated responders I had to deal with) I was quickly rewarded
with a phone call from Ron Guilmette, who runs IMRSS.  We had a long and
friendly chat.

While my own orientation towards fighting SPAM is different than his, and I
do not agree with various aspects of his operation, I think it's worth
noting that he seems quite level-headed and sincere, and clearly has a lot
of experience in the real world of SPAM problems.

Also, they are apparently about to address one of the more serious
criticisms of their procedures, by beginning a program to attempt to send
notification messages to "postmaster" and/or related addresses (when these
exist!) for sites where open relays are found.  This will at least provide
such sites with an early warning that they were found to have an open mail
relay, and that they were added to the IMRSS database.

Lauren Weinstein, Moderator, PRIVACY Forum
Member, ACM Committee on Computers and Public Policy

Re: Japanese toilets (Landwehr, RISKS-20.51)

Chiaki Ishikawa <>
Fri, 6 Aug 1999 01:33:43 +0900 (JST)
Well the joy and risk of high-tech toilet!

It must have been quite an amusing and hilarious way to really wake up to
hear the interview on NPR (National Public Radio?).  And many seem to think
that the Japanese is too serious a nation without the proper sense of
humour, but I digress.

The case, eh, the toilet in question was an 18 years old toilet that caused
a minor fire in April this year (1999).  The cause seems to be a trouble in
electrical wiring due to leaking water.

Trying web search engines with "toilet fire" in Japanese didn't turn out
useful pages at all.  Below is what I gleaned from an article at Mainichi
Shimbun newspaper site (in Japanese).

By the way, fires believed to be caused by similar toilets were reported in
October last year (1998), and July 1993.

The fire in April this year was believed to have happened in the the
following manner.  The plastic vinyl water pipe (for supplying heated water,
I think) degraded and water began seeping.  The water caused the temperature
sensor to get rusty. The rust caused the electrical resistance of some
electrical contacts to go up much higher than it was supposed to be and thus
the excessive heat was generated.  Finally, the vinyl coating of the
electrical wires caught fire.

The family members had noticed the little water seepage about half a year
earlier, but did nothing since the basic functions of the toilet such as
heater, etc.  were still operational.

Many such toilets, of which life time the manufacturers say is about 7
years, are believed to be used in Japan.  The fire fighting department of
Tokyo government was quoted as saying that such toilets that outlived the
warranty period ought to be checked early.  (I could not find reference to
the toilet at the fire-fighting dept. web site, though.)

In Japan, these type of toilets showed up in the market early 1980's.
Today, about third of such toilets are this type according to a survey
mentioned in the article.

Personally, it was shocking and amusing to find the toilets of this type
when my office moved to a new building about 10 years ago.  Being a
gadget-interested person as I am, I tweaked the "control" myself. The
reported toilets that have seat raise control must be the "Rolls Royce" of
this type of toilets.  The one at the office doesn't have such a luxury so
to speak. Frankly speaking, I doubt if such toilets do exist: we need
hydraulic piston or something for that, don't we? In a toilet?

Anyway, even the Mainichi article had to have a cute headline talking about
this subject: it goes something like "Many fires by toilet: it smells and
your bottom is on fire!"

Oh well. It was a good thing that the interview was not aired on April
first. Nobody would have taken it seriously in USA.

Risks? We probably should not put electrical circuits unless absolutely
necessary. Toilets are not thought of as the cause of fire at least by many.
Of course, run-away faulty microprocessor or whatever will get you in a real
trouble such as minor burn!

Ishikawa, Chiaki
Personal Media Corp., Shinagawa, Tokyo, Japan 142-0051

Re: Japanese toilets (Landwehr, RISKS-20.51)

Brian Randell <>
Tue, 03 Aug 1999 11:13:04 +0100
> ... Some of these have recently been implicated as a source of fires ...

I was pleased to get the above explanation of at least some of the
electronic controls on these toilets. Such controls are, not surprisingly a
feature in the advanced research laboratory that I've visited regularly in
Japan these last few years - one that I made a point of photographing for my
unbelieving colleagues back here in the UK.

I had hinted to my hosts that I would appreciate English language
instructions or even a manual, so as to understand the multiple buttons,
keyboards, and digital displays (including of dates and times) - but neither
were forthcoming. However, they did accept the possible validity of my
concern that these toilets might well not be Y2K compatible - and we had
some interesting speculations as to the likely forms and seriousness of the
possible consequences! :-)

Brian Randell, Dept. of Computing Science, Univ. of Newcastle, Newcastle
upon Tyne, NE1 7RU, UK   +44 191 222 7923

Re: Japanese toilets (Landwehr, RISKS-20.51)

"Colin Sutton" <>
Tue, 3 Aug 1999 22:16:27 +1000
My wife and I went into a department store in Tokyo and she visited the
toilet. When she came out she was soaked and she couldn't stop laughing.
After she'd used the toilet (and used it well) she went to flush it and
discovered a row of pushbuttons with Kanji labels. Not wanting to leave the
toilet in an unsuitable state for the next user, and not reading Kanji, she
stood back as far as she could from the toilet and pressed one of the
buttons. Hot air started to blow up from the bowl. She tried the next
button, and got sprayed with water. Luckily it was winter and she was
wearing a raincoat. The other buttons didn't seem to do much at all, perhaps
adjust the temperature of the toilet seat or something. None of them caused
the toilet to flush. So she gave up, turned to the washbowl (in the cubicle
with the toilet, as they often are in Japan). When she turned the tap on,
the toilet flushed.

A good design. And the Japanese are so fond of cute icons. It's a pity no
one thought about the illiterate.

Colin Sutton, Development Manager, Siemens Building Technologies Pty. Ltd.
14-18 Suakin Street, Pymble NSW 2073 Australia  +61 2 98551310

  [What about the ill-litter-rate?  PGN]

Risks of RISKS

"Brian T. Schellenberger" <>
Wed, 4 Aug 1999 10:57:03 -0400 (EDT)
A few miscellaneous risks from recent risks issues:

1. Risk of not explicitly stating the risk.

   Marshall Lindsay wrote of the "Conversion service for viewable
   formats." Our Esteemed Moderator wrote: "But, security by obscurity
   does not work too well for strange formats."

   This suggests to me that perhaps the risk that Mr.  Lindsay was
   referring to wasn't sufficiently clear.  The risk is not that formats
   are decoded; but rather, that the people supplying the conversion
   service could readily make a copy of every document passing through
   their translation service.  Sooner or later they are likely to
   acquire plenty of interesting information!

2. Risk of promoting silver bullets.

   M. Simon wrote a couple of articles; one teaser and one sort-of real
   article, promoting the FORTH programming language.

   First of all, the "teaser" article should *never* have been printed
   in RISKS.  It contained no actual information; it was just a
   shameless plug for something that wasn't even named.

   Second, as I hope all RISKS readers know, there is no "silver bullet"
   to the programming challenges facing us, and this article certainly
   promotes FORTH as just that.

   Third, I've used FORTH, and it is a lovely little language, but I
   think that it's a particularly poor candidate for such a silver
   bullet if one were to exist at all.

   First of all, by its very nature it does not support static error
   checking.  It completely lacks the concept of a "type" which renders
   its ability to do even run-time error checking very limited.  It is
   great for small projects and for controlling real-world objects.
   (Controlling telescopes, for example; the application for which was
   originally designed.) I cannot even begin to imagine managing a large
   (hundreds of programmers) project with it, and I do not believe that
   a project that takes hundreds of C or Java programmers could be done
   with a mere dozen FORTH programmers, either.  (Though a project that
   takes a half-dozen C programmers may very well be doable by a single
   FORTH programmer, and FORTH is underutilized, it's not a language
   which scales up to enormous projects well, IMHO.)

3. Risk of waiting for risks to be proven.

   Bob Frankston wrote of "Fear in the the skies" and stated that "The
   real risk of this nonsense is in relieving the airlines for
   responsibility for safety" and Our Esteemed Moderator observed that
   lots of e-mail had been received, "most of it suggesting that there
   is still little hard evidence of bad effects."

   All this is true, and yet when we weigh even slight evidence of risk
   and the airlines responsibility for the safety of its passengers
   against the rather minute convenience that a cellular phone offers on
   a plane; and when we consider the social risks of allowing the
   passengers to determine which safety rules they will follow and which
   they will ignore when the well-being of their fellow passengers is at
   stake; I do not believe that the decision in this case was


eBay's response to the eBay scam

"Randolph, Ray" <>
Mon, 2 Aug 1999 12:47:25 -0600
The most astonishing part of the information provided in RISKS-20.51
regarding the eBay scam was the response from eBay found on the web site we
were pointed to ( ).  eBay's response,
"PLEASE, do not give out details of this, as it will only cause more users
to try it."  Is classic security through obscurity.  In this case, with all
of the media attention this is getting, certain eBay employees are no doubt
lamenting the Risks of the media discovering what they've attempted to
obscure. :)

Re: Go FORTH and Multiply (Kane, RISKS-20.51)

"Wong, Leo" <>
Tue, 3 Aug 1999 08:54:00 -0400
> You mean:
>        * Forth Go

One reason that Forth is simple is that it reads from left to right:

Go Forth AND *

Leo Wong

Re: Heat wave (RISKS-20.51)

David Wittenberg <>
Tue, 3 Aug 1999 08:57:13 -0400 (EDT)
>  athena% weather bos
>  Conditions at KBOS on 7/6/99 at 7:56 PM EDT (18:56 GMT)

Note also the unusual time conversion.  7:56 PM EDT is 19:56 EDT,
which is 23:56 GMT, not the 18:56 they reported.  Or is there an EDT
other than (American) Eastern Daylight Time, presumably somewhere in

--David Wittenberg      

Please report problems with the web pages to the maintainer