The RISKS Digest
Volume 11 Issue 55

Monday, 29th April 1991

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Four-digit address causes NYC death
Ed Nilges
Almost Humorous Fly-by-Wire Glitch
Joseph Nathan Hall
Another article: Freedom of Information vs Computers
Bob Frankston
Re: Cable TV "bullet"
anonymous
Re: London Automatic Train Crash
Rupert Goodwins
1st CFV: comp.lsi.testing
Nikolaus Gouders via Frances `koo'
Info on RISKS (comp.risks)

Four-digit address causes NYC death

Ed Nilges <EGNILGES@pucc.princeton.edu>
Thu, 25 Apr 91 12:11:32 EDT
The television news program News 4 New York, this morning, reported the death
of a man because EMS (emergency medical service) technicians could not locate
his apartment building.  It was reported that the man lived at a building with
a five digit address but the system used to dispatch EMS technicians only
allows a four digit address.

I will report more on this risk story if it appears in the New York Times today
and no-one else on the network has further details, but I'd remark that most
programming languages encourage the apparent error responsible for this
tragedy.  To my knowledge, only REXX and certain Basic interpreters allow
completely variable length strings, which would have perhaps avoided the
problem (barring screen design considerations, of course.)  In C, you must
either malloc or decide in advance the maximum length of a field, and in
practice this decision is usually made in secret by the programmer rather than
reviewed by the end user.

Since truncation of fields usually affects "the real end user" (that is, the
general public in the form of customers, students, victims, and in this case
patients) I believe that there is not enough commercial motivation to provide
programming languages and systems that avoid the preconditions for this
problem.  How about legislation concerning responsible display and capture of
COMPLETE information?  Or, at the level of civil lawsuits, the fact that a
defendant's system truncates data should always weigh against the defendant.


Almost Humorous Fly-by-Wire Glitch

Joseph Nathan Hall <jnh@eceugs.ece.ncsu.edu>
Sat, 27 Apr 91 01:36:40 EDT
>From the pages of Popular Science, April 1991:

"...Spectators at the first flight of Northrop's [YF-23] prototype noticed its
huge all-moving tails--each larger than a small fighter's wing--quivering like
butterfly wings as the airplane taxied out to the runway.  Test pilot [Paul]
Metz says this occurred because the early generation flight-control software
didn't include instructions to ignore motions in the airframe caused by
pavement bumps.  The answer, he adds, is inserting lines of computer code that
tell the system not to try to correct for conditions sensed when the fighter's
full weight is on its nose gear."

I'll grant that in the 1990s we can analyze wind-tunnel tests in a few hours
(or less) and can even simulate untested airframes with some success.  In the
1950s pilots frequently flew prototypes before the final results of early
wind-tunnel tests were completely analyzed--a process that sometimes took weeks
or months.  But am I alone in thinking that in some respects it takes more
chutzpah to test-fly one of these modern fly-by-wire wonders?
                                                                  <shudder>

Joseph Hall, Student, sometimes Applications Programmer, NC State University


Another article: Freedom of Information vs Computers

Bob Frankston <Bob_Frankston%Slate_Corporation@mcimail.com>
Mon, 29 Apr 91 15:36 GMT
The article is in Computerworld April 29th, 1991, page 1.  The leadin is a
battle over whether an agency should release its data in the original machine
readable tape format or on "more than 1 million sheets of paper".  The article
touches on some real issues of representation — how much work should be done
to transform representations to what the requestor wants and the costs of
paper-intensive approaches.

In the case of the initial example, part of the rationale for not releasing the
information in machine readable format is that "it wanted to discourage
commercial enterprises from making big profits off of the city's data-gathering
efforts".  This does acknowledge that information in machine readable form is
very different from paper.  Did the authors of the Freedom Of Information Act
foresee the differences between paper and machine-readable data?  What does the
mean to privacy?  The census bureau works hard to protect privacy when it
releases its data.  Does the FOI mean that raw, less guarded, data will become
readily available?  Can I search real-estate databases to find out where
someone has lived for the last 20 years?  To search arrest (not conviction,
simply arrest) records?

The article ends with "In the long run, it would be best for FOI requesters and
agency FOI officers if government information systems were designed from the
outset to allow for ad hoc queries and public access, according to several
experts.  Ideally, that would be just good IS management practice, but Podesta
said that agencies need the prodding of a legislative mandate to consider the
[technical??] issues of public access at the start of systems design.".  While
this is true, they should also consider the implications of such access.


Re: Cable TV "bullet"

<[anonymous]>
Mon, 29 Apr 91 09:09:06 xxx
Some people have asked how a "pirate" receiving cable channels illegally could
be dumb enough to turn themselves in when the service stops?  Pirates who know
what they're doing WOULDN'T be turning themselves in.

But most of these folks in question are otherwise legitimate cable subscribers
who have been "sold" a modification to their cable boxes, MOST OFTEN BY A
CROOKED CABLE COMPANY INSTALLER or other "legitimate" sounding entity who tells
them that it is perfectly legit--that it's just another way of paying for the
service.  OK, so these people are gullible--but look at all the other scams
people fall for every day.  Their box goes out-- they call the cable company.
These are most often ordinary folks, not "sophisticated" pirates.

Similar scenaries have occurred with satellite TV, where crooked dealers tell
their customers that instead of paying a monthly fee for services they can pay
a lump sum and that it's all legit.  Of course it's not.  And just like in the
cable case, if the service is cutoff these folks will usually call up the
service wondering what went wrong.

The news stories on the "cable bullet" are making a big deal acting as if this
technique could be easily applied to all systems.  The incident in question
involved one PARTICULAR BRAND of cable box, which was being subverted by a
particular technique.  There is no "broad spectrum" method for doing the same
thing on a wide variety of boxes (of which there are many types), and many
existing designs would make such a "bullet" approach impossible.  Also, even
for the affected boxes, the odds are that the folks making the modifications
will find an alternate method for illicit enabling of the boxes, and so the war
of the countermeasures escalates into the future...


Re: London Automatic Train Crash

Rupert Goodwins <rupertg@cix.compulink.co.uk>
Sat, 27 Apr 91 16:11 GMT
More on Docklands Light Railway (DLR), that was reported in RISKS-11.52 as
having had two of its unmanned trains collide. This was reported in UK
newspapers, together with a picture which looked like nothing so much as two
model trains having collided on a set of points. This hasn't been the first
incident; during testing, a train over-ran its buffers. Since a large part of
the DLR is elevated, the train in question ended up hanging off the end of the
track some thirty feet above the ground.

I got an indication of the state of the routing software when I travelled on
the DLR about three years ago (during that time, I worked in Docklands). The
train drew to a halt on an empty bit of elevated track, waited for a couple of
minutes, and then carried on. On checking with a DLR official, it transpired
that there was due to be a development there at the time the routing software
was written; due to various financial factors the building had been delayed but
DLR had already included it in the software which, having been tested, they
were unwilling or unable to modify. There is now a building at that site (the
infamous Canary Wharf), but I haven't been back on the DLR subsequently.

Rupert Goodwins, East Ham, London.


1st CFV: comp.lsi.testing

<koo@tcville.HAC.COM>
29 Apr 91 21:05:58 GMT
Below is a Call For Votes to create a newsgroup on testability/reliability
issues.  Please send your Yes/No vote to the address indicated below.

                                    Frances (koo@tcville.hac.com)

- - 8< - - - - - - - cut here - - - - - - - - cut here - - - - - - - - - >8 - -

Date: 26 Apr 91 18:19:48 GMT
From: gouders@du9ds3.uni-duisburg.de (Nikolaus Gouders)
Newsgroups: comp.lang.vhdl
Subject: 1st CFV: comp.lsi.testing (was: comp.lsi.cat)
Summary: call for votes
Keywords: comp.lsi.testing
Organization: Rechenzentrum Uni-Duisburg

         CALL FOR VOTES for comp.lsi.testing (was: comp.lsi.cat)
         =======================================================

SUMMARY:
    Newsgroup: comp.lsi.testing
    Yes votes to: yes@du9ds3.uni-duisburg.de
    No votes to:  no@du9ds3.uni-duisburg.de
    Voting period: April 29th, 1991 to May 20th, 1991 (inclusive)


NAME/GROUP:
    comp.lsi.testing

STATUS:
    unmoderated

CHARTER:
    This newsgroup is intended to cover all aspects of the testing of
    electronic circuits such as (but not restricted to)
      *  Testing of Digital and Analog Devices
      *  Automatic Test Pattern Generation
      *  Fault Modeling and Fault Simulation
      *  Design for Testability
      *  Scan Design and Built-in Self Test
      *  PCB-Test and Boundary Scan
      *  Design Verification

    Important topics are (again not restricted to)
      * Announcements (conferences, workshops, special issues)
      * Books on testing
      * Standards
      * Tools
      * Benchmarks
      * Questions and answers
      * Discussions concerning technical or algorithmic problems

WHY A NEW GROUP:
    The ever increasing number of publications on testing shows a
    vivid and growing interest in that subject. A newsgroup on
    testing will stimulate and accelerate the exchange of related
    information among interested network users. It makes it easier
    to recognize current trends in testing, especially
    for novices.

    The discussion period showed a general agreement on the theme.
    Our first proposal for the name of the group was comp.lsi.cat,
    which is similiar to comp.lsi.cad. A number of contributors
    remarked that this name is not generally understandable or
    misleading. Among the proposed alternatives were:
    comp.lsi.test, comp.lsi.testing, comp.lsi.ate, comp.lsi.ft (fault
    tolerance). Taking into account that ".test" may sound like
    "alt.test", "news.test" which have a specific function within the
    USENET hierarchy, the proposed name "comp.lsi.testing" should be
    the most understandable and general one.

    Some authors commented that there are existing groups like comp.lsi
    which do not have an extreme news flow to date. Splitting therefore
    should not be necessary. We have never intended to split any group
    due to "net bandwidth", comp.lsi.testing is a new thread. A closer
    look at comp.lsi[.cad] shows that these groups are mostly design oriented,
    and this probably raises the level for participation of non-designers.
    Shortly: there was and is no forum for testing yet.

SCHEDULE OF THE VOTE
    The voting period begins on monday, april 29th and ends at (including)
    sunday, 20th.
    Everybody is allowed to send one and only one vote for (YES) or against
    (NO) comp.lsi.testing. All votes reaching the addresses described below
    during the voting period will be counted. Votes arriving not during the
    period, duplicate votes, votes containing additional comments ("I vote YES,
    but...") are VOID.

HOW TO VOTE

    Please send your vote to one of the following addresses:
    YES votes to:
            yes@du9ds3.uni-duisburg.de
    NO votes to:
            no@du9ds3.uni-duisburg.de

    Please put your vote in the subject of the mail-header. Format:
    subject: YES comp.lsi.testing        or
    subject: NO comp.lsi.testing

    Your mail MUST contain an e-mail adress to contact you (e.g. a .signature)
    to allow verification of the results.

    DO NOT SEND ANY VOTE TO A NEWSGROUP (for instance the group where you read
    this call for votes).

RESULTS
    After the end of the voting period, the voting results will be published
    in the newsgroups "news.groups" and "news.announce.newgroups" including
    names, e-mail addresses and votes of the voters.

    To create the newsgroup "comp.lsi.testing" it is necessary that there
    are at least 100 more YES than NO votes, and there must be a 2/3 majority
    of YES voters.

PUBLICATION
    This call for votes will be sent to
         news.announce.newgroups
         news.groups
         comp.lsi
         comp.lsi.cad
         comp.simulation
         comp.lang.vhdl
    and some e-mail addresses.

    You may freely distribute, translate, republish, crosspost etc. this
    article as long as the parts  SCHEDULE OF THE VOTE and HOW TO VOTE
    remain unchanged and the names of the authors are included.

Please send us your vote soon!

The authors:
    Nikolaus Gouders (gouders@du9ds3.uni-duisburg.de)
    Holger Veit  (veit@du9ds3.uni-duisburg.de)
--
| Nikolaus Gouders        | |**********************************************|
| University of Duisburg  | | INTERNET: gouders@du9ds3.uni-duisburg.de     |
| Fac. of Electr. Eng.    | | BITNET: gouders%du9ds3.uni-duisburg.de@UNIDO |
| Dept. f. Dataprocessing | |**********************************************|

- - 8< - - - - - - - cut here - - - - - - - - cut here - - - - - - - - - >8 - -

Please report problems with the web pages to the maintainer

x
Top