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 4 Issue 28

Friday, 12 December 1986

Contents

o Mount a scratch giraffe, too? Make that several.
Jim Horning
o Elf debuts as parking attendant
Kevin B. Kenny
o Plug-compatible plugs
Chris Koenigsberg
Henry Schaffer
o An Amusing Article on the Taxonomy of "Bugs"
Lindsay F. Marshall
o Satellite interference
Lauren Weinstein
o Fast-food computers
Scott Guthery
o Re: More on skyscraper control
Chuck Kennedy
o Re: Risks of Computer Modeling
Craig Paxton
o Re: Computerized Discrimination
Randall Davis
o Computers and Educational Decrepitude
Geof Cooper
o Symposium -- Directions and Implications of Advanced Computing
Jon Jacky
o Info on RISKS (comp.risks)

Mount a scratch giraffe, too? Make that several.

Jim Horning <horning@src.DEC.COM>
Fri, 12 Dec 86 14:17:05 PST
From DATAMATION, Dec. 15, 1986, p. 67

... The Amsterdam air cargo terminal, an enormous, fully automated
warehouse, is a major hub where cargo is stored before being routed
to destinations all over the world. In the cargo on any given day are
numerous crates of live animals, from dogs and cats to livestock and
zoo animals, many of which must be fed during their stopovers. A DBMS
is used to keep a mirror image of the warehouse and to track the physical
location of all freight traffic.

This system had first been installed by Computer Sciences Corp., El
Segundo, Calif., in the 1960s and had worked fine for several years until
the DBMS failed. All the data were lost. It took several days and several
dead giraffes before the problem was solved, according to Ken Bosomworth,
president of Information Resources Development, Norwalk, Conn., who
learned of this classic horror story through some former CSC employees.


Elf debuts as parking attendant

Kevin B. Kenny <kenny@B.cs.uiuc.edu>
Fri, 12 Dec 86 15:16:46 CST
From the (Champaign-Urbana, Ill.) Daily Illini, 12 December 1986:

           Elf debuts as parking attendant

CONCORD, N.H. (AP)-- Concord's parking elf, captured after a nationwide
search, made his debut at the downtown garage Thursday, frustrated by the
computerized meter system he was hired to make ``user-friendly'' for the
holidays.

``It's flawed,'' said Charlie Bonjorso, a 76-year-old retired barber
who answered Concord's call for someone to wear the elf suit.

``You only get 20 seconds' time when you're supposed to remember where you
parked your car, have your change ready, and push the numbers,'' Bonjorso
said.  ``If you're slow . . . that's it, you've lost your money.''

Parking in the garage dropped from 100 percent to almost nothing when
a computerized meter requiring a good memory and quick fingers was
installed this year, said Ken Lurvey, the city's director of economic
development.  ``People got confused, they got ticketed and they got
frustrated,'' he said.  ``It's far from user-friendly.''

Kevin Kenny, Computer Science   UUCP: {ihnp4,pur-ee,convex}!uiucdcs!kenny
University of Illinois      CSNET: kenny@UIUC.CSNET
Urbana, Illinois, 61801     


Plug-compatible plugs

Chris Koenigsberg <ckk#@andrew.cmu.edu>
Fri, 12 Dec 86 10:26:30 est
Someone discovered by accident that the IBM monochrome display adapter will
accept a Token Ring connector cable. (Both the Token Ring and the monochrome
display use standard D connectors.)  Then, when you power on the machine, the
display output brings down the entire local Token Ring that the machine is
on.  Anyone with a workstation that has a monochrome card can disable their
local token ring by plugging the wrong cable into the display adapter
(either accidentally or on purpose), and this is good until someone figures
out which workstation is causing the outage and removes it from the ring at
the wiring closet.

Carnegie Mellon University is wiring all campus buildings, including all
dormitories, with the IBM Cabling System. Every room will have at least one
outlet. The primary use is to attach personal workstations to the IBM Token
Ring. Typically, one or more floors of a building will be running one single
token ring. Fun with your dormitory workstation!

Notes:
- Why couldn't they have made the token ring connector a different kind than
the monochrome display connector? Did (or should) the hardware design process
include any analysis of its consequences in such conjunctions, given known
human tendencies?

- With the token ring, it is much easier to isolate the offending workstation
and remove it from the network than it would be on an Ethernet. Societal
pressures and conventions may evolve to control antisocial network behavior
(we hope!).

- Remember when you were an undergraduate, what would you do with a token
ring and a workstation in your dorm room?


Plug-compatible plugs

Henry Schaffer <ecsvax!hes%mcnc.csnet@RELAY.CS.NET>
Thu, 11 Dec 86 16:48:02 est
The serial/parallel card on an IBM PC/AT has two (unlabeled) connectors.
These are a 9 pin male and a 25 pin (DB 25) female.  The owner's manual
didn't say which was which - and I wanted to hook up a modem, and I did
have a 25 pin male-male cable.  

I shouldn't have figured it could be that easy.  The nice DB25 is the
parallel port and connecting it to a modem damaged it.  (The DB9 is the
serial port.)  I admit I was not as careful as I could have been, but
I also feel as if I'd been set up for this.

--henry schaffer  n c state univ


An Amusing Article on the Taxonomy of "Bugs"

"Lindsay F. Marshall" <lindsay%cheviot.newcastle.ac.uk@Cs.Ucl.AC.UK>
Fri, 12 Dec 86 08:24:19 GMT
From "The Computer Bulletin" December 1986 by John Lansdown

One of the things Brian [Reffin Smith] touches on in his contribution [to
the book "Science*Art"] is the creative potential of software and hardware
bugs.  He suggests that these might be distinguished from the more
bothersome variety by being called, 'pugs'.  I have often thought that bugs
are as important to us in computing as snow is to Eskimos so, like them, we
should distinguish the many different sorts with different names.

To give a few instances.  There are some bugs which waylay unsuspecting
computer users and beat them into the ground - often fatally: following Brian's
example, these should be called 'thugs', particularly as they often arise
through the programmer's or manufacturer's misunderstanding of theory. Some
bugs are tiresome but the intrepid user can dismiss them as of no consequence:
'shrugs'.  All of us have written code that has a special class of bugs which,
whilst not being thuggish in themselves, obscure others that sometimes are and
hence make debugging particularly difficult: these obscuring bugs should be
called, 'fugs'.

Some people claim to write totally bug-free programs - if their programs don't
work it is not them that are to blame.  The manual, the system or, more likely,
the unintelligent user is at fault.  Bugs in these programmers' code should be
called 'smugs' or, perhaps, 'humbugs'.  Bugs which put the system to sleep
whilst it still appears to be working or, conversely, make it hyperactive -
resulting in reams of unrequired printing or an endless sequence of error
messages - should be called 'drugs'.  Finally, those which give rise to that
undesirable condition known as deadly embrace (brought about by such things as
incorrectly designed database lockout mechanisms) should be called 'hugs'.

Only by properly naming these types of errors can we hope to study their true
effects and ramifactions.  But what should such a study be called?  I'd be
happy to hear your (printable) suggestions.

  [Such a challenge will not go unheeded.
    'slugs' might be low-level bugs (like viruses?) that move slowly from 
            one place to another, especially in systems having no shell.
    'dougs' might be named in honor of Bell Labs' legendary Doug McIlroy (who
            with Bob Morris was responsible for EPL, the Multics development-
            language supersubset of PL/1).  Doug used to make multiple patches 
            to the live image of the compiler (which predated the official
            PL/1 compilers, by the way) ON-THE-FLY, oblivious to compilations 
            in progress.  I remember some horrendous (and of course completely
            nonreproducible) compilations resulting therefrom.
  PGN]


Satellite interference

Lauren Weinstein <vortex!lauren@rand-unix.ARPA>
Thu, 11-Dec-86 13:19:16 PST
... "uplinks are only about 1 watt" ...

This is incorrect.  Most commercial C-band uplinks (where 99% of the 
cable services operate) run in the vicinity of 300-500 watts at 6 Ghz,
usually via a 10 meter diameter antenna.  Ku-band uplinks can run
with considerably less power (as low as 20-50 watts under some conditions,
sometimes lower for short-term telemetry-only uplinks) but even these uplinks
will tend to run much more power when they are running a "continuous"
(rather than occasional [e.g. remote news uplink]) service.

Experience has shown that for C-band services (where the studies have been
done to date) it requires on the order of a 10db differential to "capture"
a transponder--lower amounts may cause interference but not capture.
Most uplinks have considerable power in reserve to deal with accidental
(or intentional) interference.  In fact, some new techniques have been
developed of late specifically to deal with intentional interference,
some of which are quite clever.
                                           --Lauren--


<"guthery%ascvx5.asc@slb-test.CSNET">
Fri, 12 Dec 86 09:56 EDT
          <"ASC::GUTHERY%slb-test.csnet"@RELAY.CS.NET>
To:       risks@CSL.SRI.COM
Subject:  Fast-food computers

An observation I have made after being subjected to a fair number
of McDonalds and Taco Bell junk-food delivery systems is the following:

    In an evolving man-machine system, the man will get
    dumber faster than the machine gets smarter.

What seems to happen is that people always assume a computer-based system
is smarter than it really is and, as a result, assume they can be dumber
than they really need to be.  The result is continuing improvements in the 
computer component of the system actually result in a net decline in overall 
capability of the system.

When you couple this phenomena with the fact that our schools are turning
out system operators who not only are less well-educated but for the
most part devoid of initiative and common sense (having been pumped up on 
gratuitous self-esteem and the notion of a risk-free life), I foresee many, 
many more system catastrophes, life threatening and otherwise.

When it comes to improving these systems, I wonder what the impact of 
focusing almost exclusively on the computer component of the system is.
Won't the tendency be for the computer component to take on more and
more responsibility?  If I, as the designer of the computer part of the 
system, am going to be held primarily responsible for its malfunction, 
isn't the wise course for me to design for an arbitrarily stupid operator?

The point is that by not regarding system performance as the joint
responsibility of the people and the machines which comprise the system 
--- and at least trying to define precisely who is responsible for what ---
those who are to be held responsible will understandably assert the right
to build the system as they see fit.  You can't put people in the loop
without making them liable for the performance of the loop.  And yet this
seems to be exactly what humanist designers seem to be wishing for.


Re: More on skyscraper control

Chuck Kennedy <kermit@BRL.ARPA>
Fri, 12 Dec 86 4:12:55 EST
Yes, interestingly enough, even such mundane businesses as Sears are now
using UPSs [Uninterruptible Power Supplies].  I was recently in the local
mall (Whitemarsh) during a heavy thunderstorm and the lights went out.
Except in the Sears store where things continued normally.  Too bad the rest
of the mall didn't have UPSs.  (I believe the Penney's at the other end
remained lighted as well.)

The connection to computers of this story is, of course, the point of
sale terminals that need the juice so that sales can be made.  Also,
having the lights available makes for less panic.  The other merchants
in the mall started to close their doors and quickly stationed sales
people near them presumably to make sure that nothing "walked off".

I'm not sure what the cost of UPSs is, but if the power shortage were
moderately long and happened often enough (we get lots of thunderstorms
here at times) I think the UPSs would be worth it.  The benefit of being
able to continue to conduct business, and not worry about looting, etc.
seems well worth it.
                        -Chuck Kennedy, Ballistic Research Laboratory


Re: Risks of Computer Modeling

<PAX00325%NUACC.BITNET@WISCVM.WISC.EDU>
Fri, 12 Dec 86 01:06 CST
Yes, there are problems in doing empirical work in economics that economists,
such as myself, are quick to point out.  Verification is done by most, to
some degree, but the costs to outside verification are much greater than
generally believed.  Subtle errors can slip by not only economists, but others
as well.  For example, in the article to which I am refering to, the name
of the professor at UCLA is wrong.  E. Leamer is the author of "...Con out of
Econometrics."

Craig Paxton, Northwestern University.


Re: Computerized Discrimination

Randall Davis <DAVIS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Fri 12 Dec 86 19:28-EST
>  Perhaps the most worrying feature of the situation described in the
>  following extracts from an article in the Guardian, dated 8 Dec. 1986, is
>  that the computer "was only following orders"!
>     [extract entitled "Claims of Prejudice Against Women and Blacks"]

Perhaps the most wonderful feature of this situation is that it happened and
demonstrates one of the powerful beneficial consequences of computers as one
vehicle for making knowledge explicit.  Discrimination cases are often
prosecuted on statistical arguments, which are at best circumstantial and
depending on the sample size can be weak.  It is very difficult to prove
intent and quite rare that anyone admits to it directly.  Yet the existence of
this program is explicit and direct evidence that the school has in fact been
discriminating for however long the program has been in use ("several years")
and is interesting circumstantial evidence that the school's panel was in the
past doing the same (they agreed that it matched them).

One can only imagine the reaction of the program authors when they discovered
what one last small change to the program's scoring function was necessary to
make it match the panel's results.  It raises interesting questions of
whistle-blowing.

The panel is now in an interesting position: they can no longer claim that the
admission judgment is "intuitive" or ephemeral: they have themselves agreed
that a program captured their behavior.  Now that the genie is out of the
bottle, it is public and examinable, and that is enormously important.  The
computer has in this case become an instrument to empower people to enforce
equal treatment.

It's quite unlikely that any of this would have come to light in the absence
computers and their application to this task; admissions would still be a
back-room task carried out with unspoken intuitions and feelings.


Computers and Educational Decrepitude

Geof Cooper <imagen!geof@decwrl.DEC.COM>
Fri, 12 Dec 86 10:17:36 pst
The other day I heard a report on NPR's Morning Edition that the 
Educational Testing Service had expressed concern about the diminishing
literate capabilities of American high school (and thus, eventually,
college) students.  This concern struck me as ironic, since I consider
the ETS the prime backer of a great impediment to literacy, the multiple
choice question.  Because of the importance (or perceived importance)
of the SAT examinations, I believe that modern high school programs
have virtually standardized on the use of multiple choice questions to
test their students.  Tests that in earlier days demanded essays or
short, written answers -- tests that challenged not only the student's
knowledge of the subject matter, but also his or her literacy -- now
demand only smudges on a computer form.  Questions that earlier solicited
a clear exposition of the student's knowledge of the subject now instead
demand that the student distinguish between fine shades of meaning and
phraseology.  It is my experience that a student who has shown initiative
and learned extra subject material will often find this added information
enough to muddle the distinctions between possible answers to the question.
The more you know, the worse you do.

The popularity of multiple choice questions stems not from some theory
of their importance in education, but from the desire to automatically
grade examinations by computer.  This brings up a RISK that I haven't
yet seen mentioned on the Digest (I haven't been watching it long, so
apologies if it has been beaten to death earlier) -- the risk that
computers allow for poor solutions to problems by their ability to
allow impersonal, centralized institutions to scale up to larger
populations.

In the example, above, a desire to produce a standardized test that is
given to all students has led to a requirement that the test be multiple
choice, so that the exams can be graded by machine.  The importance of
these tests to the futures of young people has caused high schools to
shift their program away from essay questions, so that students' writing
skills are not emphasized in every subject, as they once were.  The net
effect is a societal problem, the decline of literacy in America.

If computers had not been available to correct multiple choice tests,
perhaps the ETS would have set up a more distributed testing system,
based on certified test graders.  Perhaps a wider range of question
types would be used, or perhaps oral examinations would have become
part of the test.  This question is moot, and the answer would not be
of pertinence to this digest.  The pertinent question does remain:

    * Does the ability of computers to process masses of social
      data encourage poor, centralized, solutions to social programs
      when distributed (non-computer) solutions would help society more?

- Geof Cooper, IMAGEN


Call for papers - Directions and Implications of Advanced Computing

Jon Jacky <jon@june.cs.washington.edu>
Fri, 12 Dec 86 08:40:51 PST
         (CPSR-sponsored symposium in Seattle, July 12 1987)

                               Call for Papers

              DIRECTIONS AND IMPLICATIONS OF ADVANCED COMPUTING 

            Seattle, Washington   July 12, 1987

The adoption of current computing technology, and of technologies that 
seem likely to emerge in the near future, will have a significant impact 
on the military, on financial affairs, on privacy and civil liberty, on 
the medical and educational professions, and on commerce and business.

The aim of the symposium is to consider these influences in a social and
political context as well as a technical one.  The social implications of
current computing technology, particularly in artificial intelligence, are
such that attempts to separate science and policy are unrealistic.  We
therefore solicit papers that directly address the wide range of ethical
and moral questions that lie at the junction of science and policy.

Within this broad context, we request papers that address the following
particular topics.  The scope of the topics includes, but is not limited
to, the sub-topics listed.

RESEARCH FUNDING           DEFENSE APPLICATIONS

 - Sources of Research Funding      - Machine Autonomy and the Conduct of War
 - Effects of Research Funding      - Practical Limits to the Automation of War
 - Funding Alternatives             - Can An Automated Defense System Make War 
                      Obsolete?

COMPUTING IN A DEMOCRATIC SOCIETY  COMPUTERS IN THE PUBLIC INTEREST

    - Community Access              - Computing Access for Handicapped People
    - Computerized Voting           - Resource Modeling
    - Civil Liberties               - Arbitration and Conflict Resolution
    - Computing and the Future      - Educational, Medical and Legal Software
      of Work 
    - Risks of the New Technology


Submissions will be read by members of the program committee, with the
assistance of outside referees.  Tentative program committee includes
Andrew Black (U. WA), Alan Borning (U. WA), Jonathan Jacky (U. WA), 
Nancy Leveson (UCI), Abbe Mowshowitz (CCNY), Herb Simon (CMU) and 
Terry Winograd (Stanford).

Complete papers, not exceeding 6000 words, should include an abstract, 
and a heading indicating to which topic it relates.  Papers related to 
AI and/or in-progress work will be favored.  Submissions will be judged 
on clarity, insight, significance, and originality.  Papers (3 copies) 
are due by April 1, 1987.  Notices of acceptance or rejection will be 
mailed by May 1, 1987.  Camera ready copy will be due by June 1, 1987.

Proceedings will be distributed at the Symposium, and will be on sale
during the 1987 AAAI conference.

For further information contact Jonathan Jacky (206-548-4117) or Doug
Schuler (206-783-0145).  Sponsored by Computer Professionals for Social
Responsibility, P.O. Box 85481, Seattle, WA  98105

Please report problems with the web pages to the maintainer

Top