The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 13 Issue 15

Tuesday 18 February 1992

Contents

o PCs and airline toilets
Craig Partridge
o Phone May Trap Kidnapper
Antony Upward
o Re: Police Foil Million Pound Hacking Plot
Bob Frankston
PGN
o Risks in idle time
G. Sawitzki
o Risks in book buying -- shareware
Linda Stefny Baum via Bill Putnam
o Prescription drug plan "benefits"
Jim Purtilo
o Re: Radiation underdoses
Jon Jacky
o Re: System certification again (Re: Radiotherapy)
Rick Smith
Marc Horowitz
Perry E. Metzger
Rich Kulawiec
o Info on RISKS (comp.risks)

PCs and airline toilet usage

Craig Partridge <craig@aland.bbn.com>
Tue, 18 Feb 92 10:22:38 -0800
    Apparently airline passengers with portable PCs are using the shaver
outlets in the toilets to recharge their PC batteries.  Since recharging a
battery can take some time, this behavior dramatically reduces passenger access
to toilets. [Computers constrain key bodily functions... :-)]

    I've encountered three pieces of information that suggest this is not just
a nice urban myth.  First, two colleagues have reported encountering the
problem.  One on a flight to Japan (where apparently at one point, almost all
the toilets were taken by folks sitting inside recharging their PC batteries),
one on a flight cross the US.  Second, there was an article several weeks ago
(I think in the SF Chronicle travel section) on business travel that mentioned
that some business travelers were now requesting seats at the back of the plane
for easier access to the shaver outlets (the article suggested said passengers
were using extension cords...)
                                             Craig Partridge

   [HIT or MYTH?  Not aMYTH.  I noticed on last week's cross-country trip that
   ALL of the shaver outlets had been blocked off, with a sticker over the jack
   saying that this blockage was effective as of something like November 1991.
   A myth is as good as a mile-per-hour increase in speed.  Some planes provide
   phone hookups in each row group; perhaps we will soon see per-seat
   electrical outlets as first- and business-class perks.  Opportunity for a
   SURCHARGE?  <Quadruple pun intended.>  Call your favorite airline now.  PGN]


Phone May Trap Kidnapper [Missing from RISKS-13.14]

KPMG - Antony Upward,IVC <UPWARD.A@applelink.apple.com>
12 Feb 92 08:44 GMT
Phone May Trap Kidnapper, by Paul Cheston (London Evening Standard, 7 Feb 1992)

Detectives hunting the kidnapper of estate agent Stephanie Slater believe they
can trap him through the mobile phone he used to pass on instructions for the
175,000 (pounds) ransom drop.

Courier Kevin Watts is convinced the kidnapper used a mobile phone to direct
him in thick fog towards the disused railway bridge where he left the money.
Mr. Watts had been ordered by the kidnapper, descirbed by police as Britain's
most wanted man, to a remote phone box near Penistone outside Barnsley.
Parking nearby, he carried the ransom money into the booth when the phone rang
almost immediately.  The ring was so fast the estate agent branch manager
realised the kidnapper had been watching him and must have been using a mobile
phone.

A mobile phone's unique electronic serial number is recorded by the computer
which runs the network and can be used to trace the phone user.


Re: Police Foil Million Pound Hacking Plot

<Bob_Frankston@frankston.std.com>
Mon 17 Feb 1992 09:06 -0500
The note about extradition problems is interesting. They become especially
acute with computer crimes (ecrimes?).  In the old days one would commit a
crime and then escape to a "safe" country.  Today one can first escape and then
commit the crime.

What are the implications and remedies?


Re: Police Foil Million Pound Hacking Plot (Frankston, RISKS-13.15)

"Peter G. Neumann" <neumann@csl.sri.com>
Tues, 18 Feb 92 12:55:44 PST
In partial answer to Bob Frankston's question, the implications are of course
quite profound.  We need more international cooperation to establish and hinder
what is illegal.  (Cf. the US-Dutch noncommunication noted in RISKS-13.11, 12,
13, 14.)  Might we see pirate ships from which cracking would be legal?  And a
new breed of international terrorism protected by safe havens?  The existing
international legal situation is certainly inadequate today, but it is also
intrinsically limited in what it might eventually be able to do even with
greater international cooperation.  In addition, we need more-secure
computer-communication systems, better user and system authentication,
meaningful audit trails, etc., to hinder misuse.  Without them, crying over
electronically spilled milk money leads to ECrim(e)osus/lacrimosus/lactimosus/
galactimosus.  The -osus with the mos'us is the crime that won't rhyme.


Risks in idle time

<gs@statlab.uni-heidelberg.de>
Mon, 17 Feb 1992 14:59:04 -0800
On Jan. 27th, D.C. Lawrence reported on D. Gerlernter's "Linda" for distributed
computing, and the possible lack of risk awareness shown in related trends. He
asked for related trends.

In the "NetWork Project", the StatLab Heidelberg has been working on another
system for distributed computing making use of idle times of workstations on a
net. We agree on the critical asked by D.C. Lawrence.  Here is how they are
delt with in the NetWork Project.

(1) Privacy and user control. The owner should always be in full control of the
machine. NetWork uses a demon as a communication agent. All communication for
the NetWork system is funneled through this demon, the "NetWork Processor".
This "NetWork Processor" is under full control of the owner of a machine. The
owner can set up the machine not to participate in NetWork distributed
computing at all. Or the owner can set up a certain threshold of idle time
after which the machine can be used for distributed computing. The "NetWork
Processor" takes care to repect these settings.  A machine will only visible to
the NetWork System if it is published and is idle in terms of the definition of
the l o c a l user. And if the local user comes back, the "NetWork Processor"
guaranties to remove (kill, if necessary) any guest processes immediately.

(2) Code and information security. How do you prevent the introduction of
worms, and how do you guard local information ? At present, we did not see any
solution to this problem. We would have liked to migrate code. And we would
have liked to Program/train a recipient machine "on the job", as is done in the
Japanese TRON system. But we did not see any sound possibility to overcome the
risks involved. So we had to refrain from code migration.  Again, we put
control back in the hand of the owner of the local machine.  Using the "NetWork
Processor" demon, the onwer may set up one trusted path, and only programs in
this trusted path will be accessed by NetWork.  So we rely on the risk
awareness of the owner, and the usual local system provided by the file system
access privileges. To educate user awareness, we took the aggressive way. We
gave an example of how you can risk everything by putting an unrestricted shell
in the trusted path. And we told everyone to take a lesson from it and never to
do this.

(3) Competing access. This is an issue which was not addressed in D.H.
Lawrence's letter. But we felt it of utter importance. If you have a
distributed computing system, it will compete for network bandwith.
Moreover probing and look-up will generate computing load even on those
stations which are not used for idle time computing. In particular, any
machine must be handle every broadcast it sees, even just to discard it.
Competing communication load will be negligible for small sites. But it may
become a major problem if the number of compute clients increases. If a
distributed computing system does not address these problems, mere
communication load may lead to a denial of service with increasing system
size. NetWork takes three means to address this problem. (A) instead of
using high overhead protocols like RPC, we use lightweight communcation -
for UNIX, based on UDP - and have special techniques to reduce
communication load, (B) we limit the additional bandwith taken up by the
NetWork administrative system to an arbitrary fraction (1 per cent) of the
bandwidth on the transport medium available, (C) we control and limit the
global rate of broadcasts and multicasts used by NetWork.

  G. Sawitzki <gs@statlab.uni-heidelberg.de>


Risks in book buying -- shareware

Bill Putnam <billp@ivy.isc.com> <billp>
Mon, 10 Feb 92 15:41:28 -0800
The following was reposted to comp.text from an original BIX newsgroup
(ibm.utils/onions???).  This is the first time I'd heard of such an elaborate
scheme associated with shareware.  I have not looked at the book yet, myself
(perhaps I should be fore submitting a real posting to comp.risks), but even if
the story is inaccurate, it bears passing on because it points out yet another
possibilty in mistruth-in-advertising.

In article <52928@cup.portal.com>, Lynlee@cup.portal.com (Linda Stefny Baum)
writes:
> From: Lynlee@cup.portal.com (Linda Stefny Baum)
> Subject: Beware the THOUSAND DOLLAR BOOK.
> Date: Fri, 17 Jan 92 17:07:10 PST
> Organization: The Portal System (TM)
>
> The author of the following article has allowed me to repost his article IF
> I did NOT post his name with it.. He is a BIX user.. The article was posted
> to BIX. The Header info is complete with the exception of the authors name.
>
> TINAR = This is NOT a Review..
> ============================= Beginning ===================================
> ibm.utils/onions #4290, from ------, 1245 chars, Mon Dec 30 00:45:24 1991
> There is/are comment(s) on this message.
> --------------------------
>
> TITLE: Beware the THOUSAND DOLLAR BOOK.   (TINAR)
>
> "DOS Power Tools, Second Edition" looks a lot like the First Edition.  The
> price is $10 higher, but, why not?  The first edition only had one disk,
> containing a lot of useful, ready to run, PAID FOR, utilities, at $39.95.
> This one's got THREE disks filled with "over 100 all-new utilties", at $49.95.
>
> I've had the book for a week, and I'm reading page 811.  This is where the
> author urges you to register shareware you use; it's the right thing to do.
>
>            Sounds beautiful so far, what makes this an ONION?
>
> MOST OF the "100 ALL-NEW UTILITIES" with this $49.95 book are SHAREWARE!
> 48 programs, by 7 authors, asking for a total of $925 in registration fees!
> 18 additional programs ask to "call or write" to 5 more authors for prices.
> If each "write for price" is only $25, the grand total is $1,375.  Even if I
> pay each author for ONE program, the total registrations would come to $242.
>
> On the covers, there's NO notice of the $1,375 shareware bargain inside.
> This important information is on page 815 thru 965 of this 1070 page book.
>
> Bantam Computer Books, ISBN 0-553-35464-7.  Down payment only $49.95.
> Total price approximately $1,424.95.  Postage and taxes not included.  TINAR.
>
> ================================ END ========================================
>
> Personally speaking, I feel this type of practice, if not illegal, is
> unethical..  The first edition did not require the purchaser of the book to
> pay large sums for the use of the Shareware included.. There was an
> agreement with the publisher and the shareware authors For which, Im certain,
> the authors were compensated for their labors.. I, for one, will not support
> this type of tactic.... TINAR
>                                             Lynlee@cup.portal.com

I agree with Linda, hence my forwarding this to comp.risks.  Caveat Emptor and
don't let them get away with it when despite your best efforts to prevent being
taken, you are.

Bill Putnam, INTERACTIVE Systems, 26635 W. Agoura Rd., Calabasas, CA 91302
A Kodak Company   uunet!isc!ism!billp   818/880-1200 x2119


Prescription drug plan "benefits"

Jim Purtilo <purtilo@cs.UMD.EDU>
Mon, 10 Feb 92 09:41:59 -0500
I recently needed to use my "prescription drug plan" employee benefits,
available to Maryland state employees.  (This is in response to problems with
a flu virus rather than computer virus, as usually discussed in this forum.)
This presented my fever-ridden imagination with an interesting array of risks
due to a system that is substantially supported by computer.

The prescription drug plan in Maryland is contracted out to a separate company
called PCS, Inc.   Our membership ID is, unfortunately, assigned by social
security number.  All transactions in the system are recorded in a "PCS
databank", a centralized facility that is billed as being an important employee
safeguard, since it is intended to warn pharmacists when you are given some
conflicting medications.   The obvious sorts of computer risks here have been
discussed previously -- what if the databases' list of drug interactions is
not correctly recorded, what if the data being entered for a patient is mis-
entered or associated with another patient, etc.

But the fine print in our benefits contract reveals there is room for other
sorts of problems.  We aren't given much in the way of promises concerning
accuracy of information ("... neither PCS nor your ... sponsor is responsible
for any damage or liability out of or in connection with the performance, or
failure to perform, ... services for you.")  Neither are we given much in the
way of assurance concerning how information is to be used.  Is PCS free to
decide someday to sell mailing lists based upon records?  Or (more likely)
sanitized records?  Send all those heart patients advertisements for the latest
Ronco CPR-o-matic!  (And what if they mix it up and send diabetics those
chocolate ads really intended for folks with eating disorders....?)  A longer
range issue, of course, is that this is one more way for the state to get
access to personal medical information.  Want to custom-tailor a benefits
package to the employee? No problem --- just tap into the centralized medical
records and see what kinds of problems they'll likely have down the line.
(Let's see, this Purtilo guy is overweight, attitude-ridden and near-sighted...
better charge him the max for medical insurance.  Now if we could only cross
reference the DNA mapping info in order to predict other diseases....)  Entry
into this database is mandatory for any employee who uses the plan benefits.

This assumes you can use the benefits.  The cough syrup I wanted to buy took
about 40 minutes to prepare. 10 of these minutes were due to waiting in line
and paperwork, 30 were due to the lab person fooling around at the computer
terminal.  The pharamacist was not very open to gab about this, so I cannot
report on his perceptions concerning system reliability, but I got the distinct
impression that if they could not log in to the centralized facility, then I
could not buy the medication (under the plan).  Moreover, since membership
cards are only issued in the employee's name, it is plausible that a valid user
might _not_ get medication at all: spouse goes with prescription and no cash,
expecting to get critical prescription filled under terms of the plan; computer
is down, denying verification of user [the card explicitly states that only the
user whose name is on the card can get benefits ... participating pharmacies
are told to overcome this problem for family members by checking in the
computer]; spouse has different last name than on card, so the pharmacy cannot
even honor the card based upon paper records; and spouse doesn't have the cash
to buy the medication (and hope the paperwork doesn't kill him or her later).

Jim (purtilo@cs.umd.edu)


Re: Radiation underdoses

Jon Jacky <JON@gaffer.radonc.washington.edu>
Mon, 10 Feb 1992 10:52:27 -0800 (PST)
All I know about the recently reported radiation therapy underdoses are what I
read in RISKS.  As usual, it is not possible to determine what actually
happened from the news account.

However, since I do work in a radiation therapy clinic, I can provide some
general information.

Doctors prescribe the radiation dose that is to be delivered to particular
sites in the patient's body.   Typically the prescription includes, in
effect, a lower limit on the dose to the tumor and an upper limit on the dose
to various healthy tissues such as the spinal cord, etc.  Then a physicist or
dosimetrist creates a treatment plan, including a geometric configuration of
radiation sources (usually beams from a linear accelerator), and the amount
of radiation to be delivered from each source.   Because of the nature of
the radiation producing machinery, and the physics of radiation absorption in
the body,  physics calculations are required to determine the machine settings
needed to deliver the prescribed doses to the prescribed sites.

Clinic staff usually use computer programs called "treatment planning
programs" to perform some of these calculations.  Usually, these programs
produce a printed chart with instructions for setting up the treatment
machines, including the total quantity of radiation to be delivered.  The
treatment planning computer system is usually a completely separate system from
the therapy machines.  Usually the information from the planning program must
be manually entered into the control console for the therapy machine (whether
or not the therapy machine itself is computer-controlled).  Recently some
vendors have produced treatment planning systems that allow some calculated
machine setup information to be loaded directly into a (computer-controlled)
treatment machine via some kind of network connection.

All treatment planning programs depend on tables of data representing actual
machine characteristics measured at the clinic.  Clinic staff must measure this
data and enter it into tables in the format required by the planning program.
These days, the data is often collected with the aid of a semi-automated "beam
scanner" that includes a small computer.  This system is usually completely
separate from both the therapy machine and the treatment planning system.
Sometimes there are facilities for loading data from the scanner into the
planning system via network, without having to type it in manually.

In addition, the therapy machines themselves have calibrations that must be
adjusted frequently by clinic staff.  On some of the newer computer-controlled
machines, a computer is involved in this process as well.

Besides the therapy machine, the treatment planning system, and the beam
scanner, clinics have other instruments that are used to calibrate the rest.

I hope I have conveyed that there are many steps and stages where the clinic
staff have the obligation to measure, record and update information that  must
be accurate and consistent.  Computing is involved in many of these stages.
There are many opportunites for errors, in particular there  are many
opportunities for dose delivery errors other than the therapy machine itself.
Clinics must have quality assurance procedures in place to detect and correct
the errors that do occur before they can affect patients.   To me, the most
alarming aspect of this recent story is that some kind of error was apparently
allowed to remain uncorrected for years.

One thing that is important to understand is that many clinics do not depend
solely on stock equipment from vendors; some use quite elaborate procedures and
instruments that are custom built by clinic staff.   As part of this tradition,
it has long been common to use custom computer programs written by clinic staff
for treatment planning and other tasks.   Many clinics that own and use
commercially produced treatment planning systems and beam scanners also use
locally-written programs for some special applications, or to act as
pre-processors, post-processors or interfaces between purchased programs.
Moreover, almost all commercial offerings are actually adaptations of systems
that were originally developed by staff at some clinic to meet some local need.

Quite often there is no clear distinction between "the physicist" or "the
expert" and "the programmer".    Many people who develop software that is used
in radiation therapy clinics (including yours truly) also have clinical service
duties, and their formal education often does not include specialization in
computer science or software engineering.  I don't believe this is necessarily
a bad thing, but I think it is fair to say that the quality of the methods used
and of the resulting products varies a great deal.

- Jonathan Jacky, Department of Radiation Oncology, University of Washington


System certification again (Re: Radiotherapy, Randell/PGN, RISKS-13.12)

Rick Smith <smith@SCTC.COM>
Mon, 10 Feb 92 14:48:30 CST
>  [The Therac 25 case was one of OVERdoses being life critical.
>  It is appropriate to note that UNDERdoses may also be life critical.  PGN]

If a machine is expected to do it _right_ then people should have a way of
monitoring whether or not the machine did it right. There should be some way of
measuring what the machine is doing while it takes place.  They could monitor
the radiation and keep a record of what the patient actually received.

These machines should be subjected to routine measurements and calibration
checks to insure that they're doing what they should. The state department
of weights and measures goes around and verifies that gas pumps and
grocery scales are accurate. Shouldn't we expect that hospitals could
do the same to their radiation machines?

Any museum worth its salt has thermographs and humidigraphs all over
the place, recording on paper the temperature and humidity next to
their valuable relics. I'm sure that all of these buildings have central
heat/AC/climate control. But they stil use separate measuring tools to
verify the results of the automatic systems.

Perhaps we're just seeing the "black box to solve all your problems" mentality
in the buyers of these automated radiation machines. Or else it's another case
of cost containment.

Rick Smith, SCTC, Arden Hills, Minnesota.


Software Engineering licensing again (Radiotherapy, Tyzuk, RISKS-13.13)

Marc Horowitz <marc@Athena.MIT.EDU>
Sun, 09 Feb 92 01:25:57 EST
<> With regard to computer risks in general:
<> I think it is time to establish licensing of software engineers, ...

Is it a meta-RISK that making such a controversial recommendation
(which has been beaten into the ground before) to such a large
audience is likely to flood PGN with responses to the point where he's
likely to ignore all of them?

        Marc


Software Engineering licensing again (Radiotherapy, Tyzuk, RISKS-13.13)

Perry E. Metzger <pmetzger@shearson.com>
Tue, 11 Feb 92 13:45:13 EST
  > I think it is time to establish licensing of software engineers,...

I strongly disagree.

Licensure of most professions exists not to protect the public, but to restrict
entry into a field so as to artificially protect the wages of the professionals
belonging to the newly-formed guild. This concept of licensure goes back to
medieval times. One would think that we had advanced beyond feudal times, but
it appears that we have not. A recent cause celebre in Washington, DC has been
a hair salon fighting the districts strict cosmetologist licensing laws. You
heard me: licenses are required to style hair in Washington. The AMA has, via
its legal right to control accreditation of medical schools and licensure of
physicians, systematically reduced the supply of Doctors in our country, thus
driving up the price of health care. Lawyers manage every day to drive anyone
who is willing to help people fill out simple legal forms out of business with
lovely laws about practicing law without a license.

All of this is silly. There is little or no evidence that licensure
does anything other than creating a new protected class of people who
can jack up their fees arbitrarily because they can restrict entry
into their field. No studies or statistics exist to show that people
get better lawyers, cosmetologists, or even physicians, thanks to
licensing laws. However, in the absence of any substantive evidence
for quality improvements in the presense of licensure, people anxious
to run the lives of other people add hundreds of new protected classes
of people every year. Recently, the state of New Jersey created a new
protected class of food specialists. No one but a licensed dietitian
can pronounce your carrots nutritious these days; anyone else giving
out "dietary advice" can get their fannies whacked by the long arm of
the state licensing board.

Even if government licensing could increase safety, the costs involved would
have to be considered. Just as safety could be enhanced by forcing all cars to
travel under 10 MPH, but needed productive uses of automobiles would then be
eliminated, government licensing could drastically increase the costs of
software development without a commensurate improvement in safety.

Government is a fearsome weapon, and rarely a useful tool. I think of it in the
"guilty until proven innocent" category. Until someone can present clear and
sound evidence that licensure of software engineers has actually dropped the
number of dangerous product failures, without incurring excessive costs to
society, I will oppose the concept.
                                                Perry Metzger


Software Engineering licensing again (Radiotherapy, Tyzuk, RISKS-13.13)

Rich Kulawiec <rsk@gynko.circ.upenn.edu>
Wed, 12 Feb 92 23:17:28 EST
  >I think it is time to establish licensing of software engineers,...

I might agree with this in theory, but want to point out that licensing and
review boards are not silver bullets, to borrow a phrase from Fred Brooks'
recent article in "Computer".

The history of civil/mechanical/electrical engineering is replete with examples
of disastrous projects designed by appropriately trained and licensed
engineers, and approved by suitably experienced review boards.  I'm not sure
the situation would be any different for software engineering; we just might
feel better about the issue if licensing and boards existed.

>Many programmers of such systems have no knowledge whatsoever of the techniques
>of reliable programming. They were the scientist, or expert, or whatever on the
>object under software control, and were chosen to write the program because
>they could hack out something that worked.

Sometimes they're chosen because they're the only person available who
understands the entire task at hand.  I wrote some of the firmware that
controls the X-ray tube gantry in the Omnimedical Quad-One CT scanner; I was
selected because I understood something about X-ray tubes, stepper motors,
power control circuitry, real-time software, 6809 assembler, sliding-ring
mechanics, and gate-level TTL circuit design.  A person with a better
background in software engineering almost certainly would have written better
code -- but they may not have understood the electromechanical aspects of the
system as well as I did.

>Consequently, they turn out spaghetti.

Well, sometimes they turn out spaghetti, and sometimes they do a pretty good
job of organizing the code into something that's robust, testable, and
maintainable.  But "they" may turn out to be software engineering graduates or
medical physics specialists -- and it's hard to tell which by looking at their
code.

---Rsk   rsk@gynko.circ.upenn.edu   Cardiothoracic Imaging Research Center

Please report problems with the web pages to the maintainer

Top