Subject: RISKS DIGEST 12.50
REPLY-TO:
[email protected]
RISKS-LIST: RISKS-FORUM Digest Tuesday 15 October 1991 Volume 12 : Issue 50
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
TRW misreports local taxes (Mark Seecof)
ATM Doesn't Catch Cash Cache Problem (Ed Miller)
Re: buggy software (David Parnas)
Risks of genetic engineering? (Michael Pilling)
Electronic thermostat failures (Ralph Palmer, Mary Shafer, Bob Wilson)
ACM SIGSOFT'91: SOFTWARE FOR CRITICAL SYSTEMS [timely reminder] (Nancy Leveson)
The RISKS Forum is moderated. Contributions should be relevant, sound, in
good taste, objective, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to
[email protected], with relevant, substantive
"Subject:" line. Others ignored! REQUESTS to
[email protected]. For
vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 12, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
----------------------------------------------------------------------
Date: Tue, 15 Oct 91 09:48:31 -0700
From: Mark Seecof <
[email protected]>
Subject: TRW misreports local taxes
According to the Wall Street Journal Monday 10-15 page B1, TRW has decided to
purge local tax delinquency info from the files of consumers residing in four
New England states. You will recall the Norwich, CT, local tax info errors; it
seems that similar errors have been made in the files of consumers living in
several other communities. TRW blames the problem on a lax sub-contractor.
Many other people blame the problem, more broadly, on TRW's apparent
unwillingness to verify input or accept corrections... Consumers say it's
difficult to reach anyone at TRW who even appears capable of influencing the
data in a file, and further report that TRW's personnel refuse to rectify
errors even when the TRW folks' attention is drawn to them.
I heard a radio report (just a headline, really) this morning that TRW will
provide "free copies" of credit reports to some (of their New England?)
consumers, in a PR move.
I'll seize this moment (do not attempt to adjust your display) to suggest that,
darn it, Congress should require ALL credit reporting agencies and the like to
notify each consumer they report on every time they issue such a report, except
under a search warrant with a secrecy injunction. The agencies should be
permitted to batch such notifications (e.g., must notify within 3 weeks and may
include more than one notification in the same envelope). The cost of the
notification can be absorbed into the cost of the triggering report (honestly,
the cost would not exceed 25 cents/notice what with bulk mail rates and reports
usually cost $5-$10 to the requester so it's not a big burden). Every
notification should include the name, address, and telephone number of the
original report requester and a copy of the report as issued (not some opaquely
coded extract, such as the disclosures Equifax is famous for--the NSA could
hardly decode them; they are MUCH harder to understand than the ones given to
paying customers). Agencies should be liable for statutory damages in the
amount of $2500 or proven economic damages if greater plus reasonable
attorney's fees in any event if they fail to correct any substantive error in a
credit report within 30 days of written notification (with corrected reports
sent to anyone who got an erroneous one).
Mark Seecof <
[email protected]>
[WSJ article also noted by Will Martin <
[email protected]>. PGN]
------------------------------
Date: Mon, 14 Oct 91 17:34:17 PDT
From:
[email protected] (Ed Miller)
Subject: ATM Doesn't Catch Cash Cache Problem
I went to extract cash from the ATM at a nearby branch of my bank. Instead of
the twenty dollar bills normally issued by the machine, I was given one dollar
bills. My account transaction indicated that the ATM believed it had given me
twenties. (Had I been given twenties, the number of bills would have been
correct.) RISKS of garbage in, garbage out? RISKS of computers that can not
"read" their output?
Since I was actually at the bank branch and since they were open I went in to
have my account corrected. One other customer had the same problem at the same
ATM and was in line ahead of me. After the bank personnel had taken the ATM
off-line, I asked several questions. I learned that the money put into the
machine comms from U.S. Federal Banks in sealed containers. The local bank
employees can neither open or inspect the contents of the containers. Since the
bank had already paid the Fed for the cache, the bank appeared to be the loser
in the situation, unless they can convince the Fed that they owned the problem.
The bank employees did not seem to know of a process by which they could report
this problem to the Fed. RISKS of a security system that does not allow a human
monitor?
Ed Miller
[email protected] 415/336.4278
------------------------------
Date: Mon, 14 Oct 91 21:38:33 EDT
From: David Parnas <
[email protected]>
Subject: Re: buggy software (RISKS-12.49)
James B. Shearer (
[email protected]) writes:, "So far as I know no one is
required by law to buy the products of Mr. Mitchell's company. If mature
adults wish to buy buggy software I do not see why this should be any concern
of Mr. Parnas."
As far as I know no one is required by law to buy an electrical appliance.
Nonetheless, every country that I know requires appliances to meet certain
minimal standards. Nobody is required by law to buy a car, but we do require
cars to meet certain minimal safety standards. Nobody is required by law to
fly in a commercial aircraft but we all expect that those vehicles and their
pilots will be produced and/or trained in a professional way. Moreover, the
manufacturers of all of these products are all expected to take responsibility
for the things that they sell. When a defect is discovered in my car, the
manufacturer is required to issue a recall notice and to repair that defect
without cost to me. He cannot simply announce an upgrade and try to
sell it to me, not if the problem is a real defect.
We could use the "mature adult" excuse to get rid of all of these regulations,
but we would all be worse off for doing so. Your apartment could be
destroyed because one of your "mature adult" neighbours bought an appliance
that was not properly designed. Your child could be injured because one of
your "mature adult" neighbours bought a car with defective brakes. Further,
every time you bought one of those products you would have to determine its
safety for yourself, whether you knew enough to do so or not.
Those who object to the suggestion that software products should be subject to
safety requirements and that software manufacturers should be held responsible
for the results of any negligence seem to believe that we are asking for
special treatment of software. Au contraire! We are asking that software be
treated like other products, produced by registered or licenced engineers, and
that software manufacturers be treated like other manufacturers. Now, because
of the supposedly non-physical nature of software, programmer's products seem
to have special exemption. If cars were as buggy as the software on the market
today, the automobile manufacturers would have long ago been sued into
bankruptcy.
Mr. Shearer goes on to write, "A real risk is that laws will be passed
requiring people to use certain crackpot programming methodologies which
purport to be better than existing practice but which for some strange reason
people refuse to adopt voluntarily."
I can assure Mr. Shearer that we are all against "crackpots". The problem is
that it is difficult to tell the difference between crackpots and visionaries.
Years ago I read a biography of Steinmetz, a visionary who thought that
mathematics could be used to analyse the behaviour of electrical power lines
and was considered a nutty theoretician by some practical people. Today, those
who do not understand and use the methods that he proposed are considered
incompetent. I am sure that there were some real crackpots around in
Steinmetz' time, but I am certainly glad that his views prevailed.
David L. Parnas
[email protected]
------------------------------
Date: 15 Oct 91 04:01:07 GMT
From:
[email protected] (Michael Pilling (Dr Chocberry))
Subject: Risks of genetic engineering?
I would like to know what some molecular biologists, notably gene splicing
specialists, have to say about this.
As I computer scientist, I know that even though we perfectly understand every
single line of our programs, we often make mistakes in even small programs, and
it is very difficult if not impossible to generate a bug free program of any
medium to large size.
In genes, we do not even understand most of the basic instructions, and yet we
are trying to make new programs using these instructions. Since DNA has far
more single instructions in it that the average program, I wonder just how
error prone genetic engineering is and how if at all you can protect against
the effects of latent errors in the code?
Michael
------------------------------
Date: Tue, 15 Oct 91 09:31:52 EDT
From: Ralph Palmer <
[email protected]>
Subject: Electronic thermostat failures (Bukys, RISKS-12.49)
I have also had an electronic thermostat fail 'ON'. I have a RobertShaw model
T1020. I've had a problem with my transformer on my oil fired furnace, it only
supplied ~5 volts to the thermostat, not the ~10 that the thermostat needed.
Since the voltage is low, the thermostat draws down the 9 volt backup battery.
I have observed two failure modes. If the battery dies when the furnace is
off, the thermostat fails off. However if the battery fails when the heat is
on, the heat doesn't shut off! I was fortunate to find this out on a saturday
afternoon and shut down the furnace when the house was only ~90F.
I feel that the best design would be a fancy digital set back thermostat as the
primary control unit, defaulting to a mercury thermostat in case of power loss
to the control unit . Until I find such a unit I'll stick with my round
Honeywell mercury thermostat, turn down the heat at night myself, and wake up
to a cold house.
Ralph Palmer
[email protected]
------------------------------
Date: Tue, 15 Oct 91 07:53:29 PDT
From: Mary Shafer <
[email protected]>
Subject: Thermostat failure mode (Bukys, RISKS-12.49)
I had a standard, non-computerized perfectly simple Honeywell round thermostat
break about 20 years ago. We came home to find the house at about 95 deg and
the heater still running.
I think you overestimate the reliability of "old-fashioned" systems. I've
never had the trouble with any of the electronic thermostats that I had with
the gems with the mercury switches.
By the way, many of us learned long ago to either turn off the heat when on
vacation or to have someone check the house every day. Frozen water lines,
stuck toilets, broken thermostats--no computer technology needed to mess things
up. A co-worker came home from a week of houseboating on Lake Powell to
discover that her house had caught fire. Fortunately a neighbor noticed and
the damage was limited to the kitchen. The fire department says that it was
probably the toaster oven. Apparently these are known for suddenly immolating
themselves and the surrounding kitchen.
Mary Shafer DoD #0362 NASA Ames Dryden Flight Research Facility, Edwards, CA
------------------------------
Date: Tue, 15 Oct 91 10:35:20 CDT
From: Bob Wilson <
[email protected]>
Subject: Re: Thermostat failure mode (Bukys, RISKS-12.49)
Both the failure mode and the fact that it failed at all are things to worry
about, but your furnace almost surely does have a thermal shutdown. You don't
say what fuel it uses, or whether it distributes the heat through forced air,
hot water, or steam. I assume from your use of the word "furnace" and the
phrase "to run and run" that it is not any common form of electric heating.
Every plenum chamber (for hot air heat) should have an overheat switch. They
have been required by code wherever I have lived, and even if your local code
does not require it I am sure that so many do that it is much cheaper to
include them in all cases. Typically the switch is a bistable disk type
thermostatic switch mounted to the plenum chamber. I am not sure that boilers
(for hot water or steam) have switches actuated by temperature but they do have
overpressure switches which in most cases will accomplish the same thing.
Bob Wilson, University of Wisconsin, Department of Mathematics
------------------------------
Date: Mon, 14 Oct 91 17:16:26 PDT
From: Nancy Leveson <
[email protected]>
Subject: ACM SIGSOFT'91: SOFTWARE FOR CRITICAL SYSTEMS
[With the deadlines approaching for reduced-rate early registration and
for assured hotel space, it seems appropriate to run this reminder. PGN]
4-6 December 1991
Fairmont Hotel, New Orleans
FINAL PROGRAM AND REGISTRATION INFORMATION
Computer systems are increasingly affecting nearly every aspect of our lives.
They control aircraft, shut down nuclear power reactors in emergencies, keep
our telephone systems running, monitor hospital patients, and execute financial
transactions. Although such critical systems offer considerable benefits, they
also pose serious risks in that we are increasingly vulnerable to flaws and
other deficiencies in the software, hardware failures, and effects of
accidental and intentional computer misuse. SIGSOFT '91 focuses on the
problems in building and validating critical software.
General Chair: Mark Moriconi, SRI International
Program Co-Chairs: Peter Neumann, SRI International
Nancy Leveson, Univ. of California, Irvine
Travel Arrangements: Johnette Hassell, Tulane University
Registration and Coordination: Judith Burgess, SRI International
[email protected] phone: (415) 859-5924, FAX (415) 859-2844
Program Committee:
David Barstow (Schlumberger)
Dines Bj/orner (Technical University of Denmark)
Marie-Claude Gaudel (Universite de Paris - Sud)
Jim Horning (DEC Systems Research Center, Palo Alto)
Bill Howden (University of California, San Diego)
Hermann Kopetz (Technical University of Vienna)
Carl Landwehr (Naval Research Laboratory)
Bev Littlewood (City University, London)
Leon Osterweil (University of California, Irvine)
David Parnas (McMaster University, Canada)
Fred Schneider (Cornell University)
Vicky Stavridou (University of London)
Martyn Thomas (Praxis, Inc.)
Walter Tichy (University of Karlsruhe)
Elaine Weyuker (NYU Courant Institute)
WEDNESDAY, 4 DECEMBER 1991
Welcome and Introduction: 8:45am - 9:00
Mark Moriconi, SIGSOFT '91 Chair (SRI International)
Peter G. Neumann, Program Co-chair (SRI International)
Session 1: 9:00 - 10:15, Carl Landwehr, Chair
Formal Verification of Algorithms for Critical Systems
John Rushby (SRI International), Friedrich von Henke (University of Ulm)
State-Based Model Checking of Event-Driven System Requirements
Joanne M. Atlee and John Gannon (University of Maryland)
Open Discussion
Session 2: 10:45 - 12:30, Dines Bj/orner, Chair
Rigorous Development Using RAISE
Bent Dandanell (CRI, Birker/od, Denmark)
Specifying and Verifying Requirements of Real-Time Systems
K.M. Hansen, A.P. Ravn, and Hans Rischel (Tech. University of Denmark)
A Systematic Kernel Development
J.F. S/ogaard-Andersen, C.O. Rump and H.H. Lovengreen (Tech. Univ. Denmark)
Open Discussion
Session 3: 2:00 - 3:45, Elaine Weyuker, Chair
The Infeasibility of Experimental Quantification of Life-Critical
Software Reliability
Ricky Butler and George Finelli (NASA Langley Research Center)
PANEL: The Limits of Probabilistic Risk Assessment
Bev Littlewood (City University, London)
David Parnas (McMaster University)
Martyn Thomas (Praxis, Ltd)
Ricky Butler (NASA Langley Research Center)
John Musa (AT&T Bell Labs, Whippany, NJ)
The Butler/Finelli paper argues that ultra-high reliability cannot be
validated directly from testing, nor can be it demonstrated by appeals
to software fault-tolerance. What progress might we reasonably expect
to make toward numerical risk assessment of life-critical software?
Session 4: 4:15 - 5:30, Martyn Thomas, Chair
PANEL: The Confused World of Standards for Critical Software
Martyn Thomas (Praxis, Ltd)
Peter Neumann (SRI International)
Mike DeWalt (FAA)
This session will explain and assess current government regulation such as
British MoD DEFence STANdard 00-55/56 and various security criteria (e.g.,
U.S. TCSEC, European ITSEC, Canadian CTCPEC). What role should such
standards play? What should be mandated?
THURSDAY, 5 DECEMBER 1991
Session 5: 9:00am - 10:30, Fred Schneider, Chair
Comparing Fault Detecting Ability of Testing Methods
P.G. Frankl (Polytechnic University), E.J. Weyuker (NYU Courant Institute)
An Exception Handling Model For Parallel Programming and its Verification
Valerie Issarny (IRISA/INRIA)
Open Discussion
Session 6: 11:00 - 12:30
INVITED TALK: Human Error in Design
Henry Petroski (Duke University)
Author of the widely-acclaimed books ``To Engineer is Human: The
Role of Failure in Successful Design'' and ``Pencil''
Session 7: 2:00 - 3:30, Victoria Stavridou, Chair
A Real-Time Transition Model for Analyzing Behavioral Compatibility of
Telecommunications Services
E.J. Cameron and Y-J Lin (Bellcore)
Programming and Verifying Critical Systems by Means of the Synchronous
Data-Flow Language LUSTRE
C. Ratel (Merlin-Gerin), N. Halbwachs and P. Raymond (IMAG/LGI)
Open Discussion
Session 8: 3:45 - 5:30, Mark Moriconi, Chair
Invited Presentations on Practical Experiences:
Validation of Critical Flight Controls
Jim McWha (Chief Engineer in charge of 777 Flight Controls, Boeing)
Reliable Software for the 4 ESS Switch
Michael Meyers (AT&T Bell Labs)
A Case Study of the THERAC-25 Accidents
Nancy Leveson (U.C. Irvine)
Session 9: 8:00pm - 9:30pm, Evening Poster Session
FRIDAY, 6 DECEMBER 1991
Session 10: 8:30am - 10:30, Hermann Kopetz, Chair
Stepwise Design of Real-Time Systems
Reino Kurki-Suonio (University of Technology, Tampere)
On Satisfying Timing Constraints in Hard-Real-Time Systems
Jia Xu (York University) and David Parnas (McMaster University)
Automated Analysis of Bounded Response Time for Two NASA Expert Systems
C-K Wang, R-H Wang, D-C Tsou, J.C. Browne, and A.K. Mok (University
of Texas, Austin)
Open Discussion
Session 11: 11:00 - 12:30
PANEL: Future Directions, Nancy Leveson, Chair
Adjournment at 12:30
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
AIR TRANSPORTATION. Delta Airlines is offering 40% off RT Coach fares within
the U.S., 35% Canada, 5% off already discounted fares. Call 1-800-221-1212,
ask for Special Meeting Network, refer to file ref no. V18006. Valid for
travel from Nov. 30 to Dec. 10. 7-day advance purchase required.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
ADVANCE REGISTRATION FORM
SIGSOFT '91 -- Software for Critical Systems
Fairmont Hotel, New Orleans, Dec. 4 -- 6, 1991
Name _________________________________________________________
Affiliation __________________________________________________
Address ______________________________________________________
City, State and Zip __________________________________________
Phone (and FAX) ______________________________________________
Email address ________________________________________________
ACM or SIGSOFT Membership No. ________________________________
Registration Fees
Before After
Category Nov. 1 Nov. 1
---------------------------------------------------
ACM or SIGSOFT Member $280 $330
Non-Member $330 $380
Full-time Student $180 $230
To pay by credit card, circle one: AMEX VISA MC
Name on card __________________________________________________
Card number ___________________________Exp. date ______________
Signature _____________________________________________________
Make checks payable to SIGSOFT '91 in U.S. dollars. Fees include 3 continental
breakfasts, 2 lunches, and the Proceedings.
Dietary requests: Vegetarian ______ Kosher ________
SEND THIS FORM WITH FULL PAYMENT TO:
Judith Burgess / EL266, SRI International, 333 Ravenswood Ave.,
Menlo Park, CA 94025, USA
For further information, contact Judith Burgess,
telephone: (415) 859-5924, FAX (415) 859-2844, EMail
[email protected]
NOTE: REGISTRATION BY EMAIL OR FAX IS ALSO PERMITTED (ONLY WITH CREDIT CARD).
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
FAIRMONT HOTEL RESERVATION FORM
SIGSOFT '91 -- Software for Critical Systems
New Orleans, Dec. 4 -- 6, 1991
Name _________________________________________________________
Affiliation __________________________________________________
Address ______________________________________________________
City, State and Zip __________________________________________
Phone (and FAX) ______________________________________________
Date/Time of Arrival _________________________________________
Date/Time of Departure _______________________________________
Room Rates (subject to taxes):
Circle one: Single $99 Double/Twin $119
RESERVATIONS: 1-800-527-4727 or 1-504-529-7111
To guarantee your reservation by credit card:
Circle one: AMEX MC Visa Carte Blanche Diners Club
Name on card _________________________________________________
Card number ___________________ Exp. date ____________________
Signature ____________________________________________________
These rates apply from Nov. 29 through Dec. 8, subject to availability.
Reservations should be received 30 days in advance to ensure availability, but
later reservations will be accepted as possible. A deposit for the first night
must accompany your reservation to guarantee it for arrival after 6:00pm.
Cancellations must be made 24 hours in advance.
SEND THIS FORM TO:
The Fairmont Hotel, University Place, New Orleans, LA 70140, USA
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
------------------------------
End of RISKS-FORUM Digest 12.50
************************
