RISKS-LIST: RISKS-FORUM Digest  Wednesday 5 April 1989   Volume 8 : 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:
  Mechanical Horse Racing (Mike Trout)
  Elevator death update (Walter Roberson)
  Re: Elevator accident kills 13-year-old (Eric Roskos)
  Federal Pay System botch-up (Tim Shimeall)
  NYTimes business readers shown the future (Mitchell Charity)
  Newspapers and access to public records (J. Eric Townsend)
  High-Tech Locomotives (Mark Brader)
  Military software (Henry Spencer)
  Authenticating Internet mail (Peter Scott)
  Advertising vs the net (Brian Kantor via Skip Montanaro)
  Gorillas in the Missed Identification (Joe Morris, Jay Elinsky, Eddie Caplan)

The RISKS Forum is moderated.  Contributions should be relevant, sound, in good
taste, objective, coherent, concise, and nonrepetitious.  Diversity is welcome.
* RISKS MOVES SOON TO csl.sri.com.  FTPable ARCHIVES WILL REMAIN ON KL.sri.com.
CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line
(otherwise they may be ignored).  REQUESTS to RISKS-Request@CSL.SRI.COM.
FOR VOL i ISSUE j / ftp KL.sri.com / login anonymous (ANY NONNULL PASSWORD) /
  get stripe:<risks>risks-i.j ... (OR TRY cd stripe:<risks> / get risks-i.j ...
  Volume summaries in (i.j)=(1.46),(2.57),(3.92),(4.97),(5.85),(6.95),(7.99).

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

Date: 4 Apr 89 17:18:58 GMT
From: miket@brspyr1.brs.com (Mike Trout)
Subject: Mechanical Horse Racing

Over the weekend National Public Radio had a piece about a new form of sports
wagering: radio-controlled mechanical horse racing.  Apparently the robot
horses used are miniature, which allows racetracks to be placed in smaller
areas; the "horses" also of course do not require care, feeding or jockeys.
The idea is being proposed by an individual who has built a few operating
prototypes.

One reporter raised the question: What is to prevent an unscrupulous bettor
from interfering with or jamming the radio signals?  The promoter replied that
he would be using military technology that prevents jamming.

I'm sure the Pentagon will be delighted to hear that they no longer have to
worry about radio interference.              
                                             Michael Trout

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

Date:       Wed, 05 Apr 89 02:17:23 EST
From: Walter_Roberson@carleton.ca
Subject:    elevator death update

A small update on the death of the 13-year-old girl crushed in the
elevator a few days ago:

  It seems that the elevator the girl was killed in was the same one
that had been `repaired' only a few hours earlier. Also, a quote from
today's story (The Ottawa Citizen, Tuesday April 4, 1989, pg A1 + A2):
  "The elevator was open and she took one step inside. But she didn't
  take the other one because the door closed and went up." ' [Idil Adam]
(She was crushed against the upper door frame. I take it she must have been
caught by the inner doors and carried upwards. No mention has been made yet of
any possible reason the elevator was able to move with the doors open, or of
why the usual obstruction sensors didn't cause the door to open when they
started closing on her. Indeed, neither of these -questions- has been raised
yet in the paper.)

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

Date: Wed, 05 Apr 89 11:08:56 E+
From: Eric Roskos <roskos@ida.org>
Subject: Re: Elevator accident kills 13-year-old

Here in our office building we have elevators with similar problems, though
possibly not as dangerous.  A lot of these problems seem to be due to bad
software.

The elevators are "Otis Elevonic 401" elevators.  They appear to be
microprocessor controlled; they have voice synthesizers that announce
the floors, and scrolling text displays that give advertisements about
the stores downstairs, the date and time of day, etc. 

They have a number of problems that I've seen thus far:

1) The sensors which are supposed to stop the door when they collide with a
person do not use mechanical switches; they seem to use electronic "body
capacitance" switches.  These switches are often out of adjustment.  On some of
the doors, the door will stop and reopen before it contacts you at all.  But on
several of the doors, the doors won't reverse unless you actually touch both
doors' switches at the same time with your hands.  Contact with a coat sleeve,
or hand contact with just one door, won't work.  Apparently the traditional
mechanical switches were replaced with electronic switches to reduce problems
of mechanical wear on the switches, without consideration that the new switches
are not as reliable in the field because of this adjustment problem.

2) There is an evident software bug in the elevators' exception handling.  If
the door is held open for longer than a certain amount of time, the elevator
enters an exception mode in which a buzzer begins sounding (the voice
synthesizer doesn't say anything during this time), and the elevator tries to
close the doors even if you are still holding them open.  Sometimes when it
enters this mode, the elevator badly malfunctions.  It will sometimes clear all
or some of the buttons that were pressed.  I've been on the elevator following
this exception handling when the elevator was supposed to be going down and
would instead go up to a floor for which no button was pressed, stop without
opening the doors, and then after a moment go down to the proper floor.  It
looks as if the programmer(s) didn't test this exception handling very well.

3) The timers for how long the door stays open, etc., seem to be implemented in
software, and use a mysterious algorithm for deciding how long to keep the
doors open that sometimes results in the doors closing before anyone can get on
the elevator.  You can never tell when the door is going to close.  Sometimes
it takes a long time for it to do so.

4) It is possible to confuse the elevator by pushing more than a certain number
of floor buttons at a given time.

5) The elevator has a feature whereby, if you accidentally get on the elevator
and intend to go up when it is going down (or if it changes direction due to a
timeout before you push the button), it won't let you push the button for the
floor you want to go to.  You can push the button, but it won't light up, and
the elevator ignores it.

6) The buttons are apparently polled periodically by the microprocessor.  When
you push the button, it lights up (apparently via a local switch) while you are
holding the button down; but if you release the button before the polling has
detected that you pressed it, the light goes off.  The initial lighting of the
button seems to have been a bad design decision, since it gives the user the
incorrect impression that the button pressing has succeeded.

7) The buttons inside the elevator are labeled with cryptic icons.  For example,
at the bottom of the button panel are some buttons labeled exactly like this:

	<|>       >|<

One of these closes the doors, the other opens the doors.  Some elevators have
a front door and a back door, and the buttons for those are labelled like this
instead:

	<|>       <||>       >|<        >||<

Many people seem to be confused by these icons, and when trying to stop the
door from closing for someone, will push the button that causes the door to
close instead.

These are only the more evident problems.  The elevators have other bugs, such
as a tendency to display "Japanese" characters instead of English on the
scrolling displays, to not detect the door position properly if someone stops
it (causing the elevator to sit until it goes into the exception mode), and
other anomalies.  It appears that a lot has been implemented in software that
was formerly done in hardware, and the software has not yet been well-debugged.

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

Date: Wed, 5 Apr 89 09:16:01 PST
From: shimeall@cs.nps.navy.mil (Tim Shimeall x2509)
Subject: Federal Pay System botch-up

In late October 1988 the Naval Postgraduate School was ordered to switch its
payroll from the Civilan Pay Branch at the Naval Supply Center in Oakland to
the Navy Regional Finance Center in Washington DC.  Since then, there have been
hundreds of errors in paychecks reported to the comptroller's office at NPS.
The conversion was almost completely botched:

  - Even though the data was computerized both in Oakland and Washington,
    the switch was apparently done by manually keying in the data
    (this conclusion is based on the types of errors that were made)
  - There was apparently NO cross checking done between the original data
    from Oakland and the data as recorded in Washington
  - There were apparently NO sanity checks done on the data as recorded in
    Washington

In my case, they messed up my last name ("Shimeall" at Oakland became "Shimball"at Washington), changed my federal tax status and number of exemptions (from
Unmarried and 1 in Oakland to Single and 0 in Washington) and removed the
deduction for state taxes (required of all California workers).  My colleagues
have reported errors including failure to include deductions for health
insurance, multiplying payroll deductions (i.e., suddenly doubling the life
insurance deduction), greatly increased or decreased number of dependents, and
errors in amount of accumulated leave and sick days.  According to the
comptroller's office there have been about 5 edge-inches of reported errors in
payroll.

I'm not certain if this changeover from Oakland to Washington involved just NPS
or if it involved other facilities in Central and Northern California.  Do any
of the other RISKS readers have similar tales to tell?
                                         			Tim

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

Date: Mon, 3 Apr 89 23:29:46 EDT
From: mcharity@ATHENA.MIT.EDU
Subject: NYTimes business readers shown the future

In The New York Times, Monday, March 27 1989, page D15, Business section,
there was a 7 page, multicompany advertising block entitled
  Special Report: NETWORKING TECHNOLOGY and Applications ,
which included the following "article".  It was accompanied by, and was
undifferentiated from, several vanilla technical "articles".


Networking in the year 2000 A.D.

  In the year 2000 networked computing is not restricted by regulatory,
political, geographical, or psychological boundaries.  No longer is it of
any concern whether an MIS department can deliver a cost-effective, reliable,
and high-performance network.  [...]

[...perfectly networked world...]

  Security is not compromised in all this openness.  Imagine one small computer
virus roaming through this perfect network.  Imagine just one mischievous
hacker taking on your identity.  Imagine just one fanatical terrorist
manipulating the world's information sources.  Needless to say, "the network"
requires absolute integrity.  End-users are screened via eye, voice,
fingerprint, and brainwave patters.  In the year 2000, a worldwide common
access control scheme allows for easy yet authorized access by end-users to
both private and public sector information.  This is not to say that once you
are in, you are home free.  Not at all! Users, as they are born, educated,
employed, and retired, gain (and lose) access to information.  Provisioning of
network services is by valid want, verifiable need, absolute necessity,
specific job function, and paid subscription.

  There are no more privately operated and managed networks.  Any privatization
results in wasteful informational isolationism.  The original concept of ISDN
reaches its full technological glory and simply renders obsolete any other
networking approach.  Network processing grows to such gargantuan proportions
that the telecomm companies of the world develop into non-profit, publicly
funded United Nations' organizations that are chaged with the world's core
central information resource.

  Corporate data centers become purely business application resources in 2000.
[...] Direct memory and CPU access is available from within the corporation and
from without.  Technology is replaced long before it breaks, Murphy's Law is
amended.  [...] Programmers are a thing of the past. [...]

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

Date: 4 Apr 89 13:21:02 CDT (Tue)
From: flatline!erict@texbell.swbt.com (J. Eric Townsend)
Subject: Newspapers and access to public records [Franklin, RISKS-8.48]

>Some newspapers ... perform statistical tests and cross-database matching. ...

Newspapers have been doing this for ages, they've just had to do it by hand.
There are a handful of companies that sell all sorts of organized information
to newspapers/media outlets.

If they can be proved to have been grossly negligent they're in trouble as
well.  Also, a newspaper that builds up a record of attacking "poor, innocent
citizens" will be raked over the coals by the competition for attacking
"upstanding citizens and readers".

>Finding and printing an interesting coincidence ...

This sort of thing has been used to crack major stories concerning:  real
estate dealers with racist selling practices, small town/county "accounting
errors" and a handful of other problems.  It's still very new to the newspaper
industry (many of whom think a MacIntosh should be easier to use :-).  Give it
a few years to wear off, and they'll use it as responsibly as any other
information gathering tool.

Check recent issues of Columbia Journalism Review, Editor and Publisher, et al.
for articles on "computerized data gathering".  There are people out there, in
the newspaper industry, who are concerned about privacy and access to
computerized information about individuals.
                                                    J. Eric Townsend

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

From: Mark Brader <msb@sq.sq.com>
Subject: High-Tech Locomotives 
Date: 	Wed, 5 Apr 89 12:57:36 EDT

Quote out of context from today's New York Times (p.35):

"Engineers who design locomotives bristle at any notion that they are
 mired in a low-technology industry.  Microprocessors control the
 operations of the latest generation of locomotives, they note..."

Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com

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

Date: Mon, 3 Apr 89 23:17:25 -0400
From: henry@utzoo.UUCP [Henry Spencer at U of Toronto Zoology]
Subject: Military software

In the 6 Feb 1989 issue of Aviation Week:

  Air Force Gen. Bernard P. Randolph, commander of the service's Systems
  Command, bemoaned the state of military software as a "huge problem" that
  runs industry-wide.  "We have a perfect record on software schedules -- we
  have never made one on time yet and we are always making excuses", he said
  at an Air Force Assn. symposium.  The general also weighed in with criticism
  of electronic combat [radar, countermeasures, etc. --HS] programs, calling
  them a "disaster".  But he blamed government as well as the defense
  industry, saying Uncle Sam constantly changes requirements and budgets.

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

Date: Mon, 27 Mar 89 10:33:35 PST
From: Peter Scott <PJS@grouch.JPL.NASA.GOV>
Subject: Authenticating Internet mail

In thinking about the specific problem, originally discussed here under the
heading of "Faking Internet mail", of determining whether or not the From:
header line is valid, I came upon the following scheme which would authenticate
that a given message was sent by the specified (user,host), if you're prepared
to assume that the mail software at the actual host claimed in the message is
trustworthy, and if you assume no perversions of the network short of
line-tapping.

The following is from the point of view of host A, receiving mail:

1) A connection is opened, and a mail dialog is initiated by a remote
   host.

2) In order to maintain upwards-compatibility with the current mail system,
   the dialog may proceed the same way that it customarily does, at the
   conclusion of which host A executes step 6 below and exits thereafter.

3) If the remote system supports this authentication scheme, it will send
   a special code to initiate the following authentication sequence.

4) Host A assigns an identification number n (say, the value of the system
   clock) to the mail message being received, and tells the remote host
   to associate the number n with this message.

5) The remote host sends the message and completes the connection.

6) A passes the message on to the user it is destined for, say X,
   with a header line: "Message n, not yet authenticated."

7) A decodes the From: line and constructs a message to send to the
   host, say B, specified as the original sending host.  This will be
   a message containing special codes that talk directly to the mail
   servr on that machine.

8) A sends to B the message, which says: "I received a message, purportedly
   from user Y at your location, to which I assigned the identification
   number n.  Did you send it?"

8) B receives the message.  If it did send the message, it has kept a record
   in an authentication database cross-referencing <message from user Y>,
   <sent to host A>, and <identification number n>.  It sends a message in the
   affirmative, and deletes the authentication record.  If it did not send 
   the message, then it replies in the negative (unless it is a crooked system).

9) A receives the confirmation, which includes the identification number
   n, and the recipient X, and sends a message to user X saying, "message
   n authenticated".

I don't think that this scheme can be circumvented as easily as one can
currently fake a message on the Internet.  Handling messages forwarded
between machines (user%host%host%host...@host) is a detail I haven't
worked out, but should be possible as an extension of the above plan.
I know that much more secure schemes are possible, I was trying to think
of a least-effort approach which would provide a significant degree of
protection.

Peter Scott (pjs@grouch.jpl.nasa.gov)

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

Date: 5 Apr 89 13:30:17 GMT
From: brian@ucsd.EDU (Brian Kantor) 
[via Skip Montanaro (montanaro@sprite.crd.ge.com)]
Newsgroups: news.admin,comp.org.ieee
Subject: Advertising vs the net

California Assembly Bill AB576 (not yet passed into law) states
that a person who uses a machine that electronically transmits
messages or facsimiles of documents through connection with a
telephone network to transmit unsolicited advertising material for
the sale of any realty, goods, or services is guilty of a misdemeanor.

The IEEE San Diego Section Bulletin (from which the above is
excerpted) states that the SD-IEEE propose supporting that Bill.

Apparently this is an attempt to control FAX junkmail.

I do not have the full text of the Bill, but it seems to me that there is
some possibility that it could affect the USENET (and other BBS-like)
transmission of many types of messages that are currently accepted by this
community.  There might also be significant first-amendment issues.

Possibly other states might follow California's lead on this; some
states have already enacted or considered FAX junkmail legislation.
It seems to me that such a law must be drafted carefully to avoid
fixing things that aren't broken.

It might well be worth your time to write for a copy of the Bill and comment
upon it to your legislators.  Remember that they don't read the net, so
blowing smoke here won't help.
                                        	- Brian

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

Date: Tue, 04 Apr 89 09:25:57 EST
From: Joe Morris (jcmorris@mitre.arpa)               [Gorillas Info Mist]
Subject: Gorilla pictures on credit cards  [2nd Randell item, RISKS-8.48]

In RISKS 8:48, Brian Randell reports an experiment in which a UK organization
tested the utility of putting the holder's picture on credit cards as a theft
deterrent.  The "holder's" picture was that of a gorilla, but there was no
problem using the card.

Is that *really* a valid test?  Considering the number of strange things you
can find on credit cards in the US (and probably other countries), and given
that the merchants who accept the credit cards aren't expecting to have 
pictures on them as anti-theft measures, I don't find any justification for
concluding that the test demonstrates a failure of the concept.

The use of the photo ID on a driver's license as a check for age for booze
purchases is well-established, and if the clerk is careful will filter out
some of the more obvious "borrowed" cards.  Nobody claims that it is perfect,
just that it helps reduce the use of other people's cards.

On the other hand, there is the famous (and possibly apocryphal) story of 
a WWII defence plant worker who demonstrated that the guards were
not checking the picture badges...she replaced her picture with one of 
Hitler and wasn't ever stopped.

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

Date: Tue, 4 Apr 89 10:18:05 EDT
From: "Jay Elinsky" <ELINSKY@YKTVMX.BITNET>
Subject: Re: Credit card magstripe-encoded pictures [Randell, RISKS-8.48]

Were photographs normally included on the credit cards used in this experiment?
If not, then the store clerk would be going "beyond the call of duty" in
checking the photograph.  The clerk could even think that a picture of a
gorilla is the issuing bank's logo.  And if photos were normally used, the
clerk might think that the person presenting the card is the gorilla's legal
guardian, since you'd hardly expect the gorilla itself to walk up to the
counter :-) The experiment might have been more valid if the cards had a
photograph of a *person* who looked markedly different from the bearer of the
card.
           Jay Elinsky, IBM T.J. Watson Research Center, Yorktown Heights, NY

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

From: eddie.caplan@H.GP.CS.CMU.EDU
Subject: Re: Credit card magstripe-encoded pictures
Date: Tue, 04 Apr 89 14:19:49 EDT

Since the cashiers probably weren't aware that the gorilla was intended to
be a form of identification, this result isn't surprising nor significant.
especially now that many credit cards come with meaningless holographic
images on them, like the bird-in-flight on the card i hold.

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

End of RISKS-FORUM Digest 8.50
************************