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 8: Issue 69

Wednesday 10 May 1989

Contents

o Computers and Redistricting
PGN
o Re: Atlantis spacecraft computer problem resolved nicely
Henry Spencer
o Computer-generated checks
Art Werschulz
o Re: Hear No Evil
Clay Jackson
o Computer Bugs/Recalls/Upgrades
Clay Jackson
o Info on RISKS (comp.risks)
---------------------------------------------

Computers and Redistricting

Peter Neumann <neumann@csl.sri.com>
Mon, 8 May 1989 17:18:03 PDT
I have had several high-level inquiries lately concerning census database
privacy/confidentiality/integrity, and integrity of the analysis used to govern
redistricting -- as well as more on the confidentiality and integrity of
computer systems used in elections.  There are several risks worth noting here.

 * Early knowledge by one party of census data could be used to plan
   appropriate gerrymandering and campaign strategies.

 * Manipulation of census data (in gathering, computer data entry, and storage)
   could influence redistricting, at both state and federal levels.

One of my recent visitors was ostensibly interested in protecting the
redistricting process from tampering (through legislation, oversight, etc.),
but I had a nagging feeling that there might also conceivably have been some
interest in how that process could be subverted.  1992 is not too far away, so
it seems appropriate to raise these problems now.

---------------------------------------------

Re: Atlantis spacecraft computer problem resolved nicely (RISKS-8.68)

<henry@utzoo.UUCP>
Tue, 9 May 89 12:51:39 EDT
> NASA officials ... buried the computer several layers underneath other
> equipment.  Apparently that tradition has continued...

NASA has a considerable tradition of implicitly assuming that the only failures
that can happen are the ones in the book.  For example, it was pure luck that
the Apollo 13 astronauts survived, because that particular type of accident --
Service Module systems completely dead -- had been classed as unsurvivable and
no preparations had been made for it.  Using the Lunar Module's life-support
systems for most of a mission required using Command Module lithium-hydroxide
canisters in the LM... and the two were not mechanically compatible, and no
adapter was provided (one was improvised).  Using the LM computer to navigate
home was possible only because one or two people at MIT had loudly insisted
that the CM and LM computers should be identical.  Nobody had ever thought
about how to separate CM from LM without the SM maneuvering rockets, but
improvisation saved the day again.  All the emergency-planning emphasis had
been on dealing with *foreseeable* problems; very little attention had been
given to building versatility into the system so that *unforeseen* difficulties
could be handled.  One might speculate that this is a "characteristic error" of
organizations that try hard to plan for all possible failures.

                                     Henry Spencer at U of Toronto Zoology

---------------------------------------------

Computer-generated checks

Art Werschulz <agw@cs.columbia.edu>
Tue, 9 May 89 12:25:37 EDT
Yesterday, I received a check from my mother for a substantial amount of money.
I took said check to the bank and deposited it, and then asked how long it
would be held.  I expected an answer of "five days," since the check was from
another state.

Much to my surprise, the teller said that there would be no hold at all on the
check.  You see, it was printed out by Mon's ImageWriter, and hence was a
computer-generated check (courtesy of "Dollars and Sense" for the Mac SE, as I
recall).  The bank's policy was to not put a hold on *any* computer-generated
checks.

The RISKS of such a policy are mind-boggling.  One who desires to commit larceny
on a large scale need only acquire an ImageWriter, a Mac, some program that
prints out checks, and a supply of checks that can be fed into the printer.

          Art Werschulz

---------------------------------------------

Hear No Evil (RISKS-8.68)

<microsoft!clayj@uunet.uu.net>
Tue May 9 08:57:13 1989
First, as a followup to the article about the movie audio problem reported in 
Risks 8.68:  My understanding of FARs (Federal Aviation Regulations) is that
during landings and takeoffs, everything that could conceivably interfere
with the safe, rapid evacuation of the A/C has to be stowed.  It wasn't noted
what sort of A/C the writer was flying in, but, unless it was one of the
newer widebodies with ALL of the move screens embedded in the overhead or
in some other fashion set up so as to NOT block ANY aisles, lights, etc,
then the crew was almost certainly in violation of several FARs.  In any
case, I think the hazards presented by the continuation of the movie into
the landing (people tied to thier seats with headsets, not paying attention
to crew instructions, lighting not set full on, headsets preventing people from
hearing crew instructions, etc) would FAR outweigh the potential anger
from folks who wanted to watch the whole movie.  I would suggest that the
writer contact the airline, and investigate the possibility of reporting
the violation to the FAA.
                                        Clay Jackson, Microsoft

---------------------------------------------

Computer Bugs/Recalls/Upgrades

<microsoft!clayj@uunet.uu.net>
Tue May 9 08:57:13 1989
I own a HeathKit ID5001 Weather Computer, which is essentially a set of basic
weather instrumentation (Pressure, Temp, Humidity, Wind Speed/Dir) controlled
by a Z80C.  The Z80's programming resides in an EPROM in the unit.  One of the
"features" of this unit is that it is battery backed, and will continue to
record data during a power outage.  It also has memories, which contain things
like High and Low Temps, Highest Wind Gust, and other goodies.  Heath is
pitching this unit very hard at Aviation users, and makes a very clear point of
noting in their ads and documentation that the unit correctly computes average
wind direction/velocity (in compliance with FARs) over a 1 minute interval.
Since the unit will potentially be used to provide pilot briefings at small
(uncontrolled) airports, I think it's important that the company be forthcoming
with any "bug" fixes and/or corrections to their code.  Unfortunately, that has
not been my experience:

A few weeks ago, I called Heath Technical Support (on a different matter) and
asked "by the way, I also have a 5001, have their been any ROM changes since I
bought the unit several years ago (I bought one of the first production
units)?"  The answer was an unqualified "No, there have been no changes since
the unit went into production".  Last week, I ordered and received the
"Technical Manual" for the unit.  On about page 5, taking up a whole page, was
a listing of the 4 different RELEASED versions of the ROM, and the checksums
(there was also a listing for a 5th ROM version, with the notation "Never
Shipped").  On the next page was a listing of "Operational Characteristics",
one of which was a note that read:

  "On battery backed units from the first production run, there was a problem
  such that after a power failure, the true high wind gust reading is replaced
  by a random value".  It went on to note that this problem was corrected
  by a later release of the ROM.

To their credit, when I called Heath and reported that I had the problem, they
agreed to send my a ROM, at no charge.  But, I could NOT get the person I spoke
to to tell me what ELSE had changed.

Clay Jackson, Microsoft


Report problems with the web pages to the maintainer