The RISKS Digest
Volume 12 Issue 38

Friday, 20th September 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…


Midwest Stock Exchange Reaps Millions Due to Accounting Glitch
Jeff Helgesen
Newark NJ high school computer problem
Martin A. Leisner
Technology and the oldest profession
Henry Cox
YATO (Yet Another Telco Outage)
Richard Johnson
AT&T switch trouble
Fernando Pereira
English Supermarket Checkout Failure
Samurai Hackers' Cunning Employer Screening Process
Marco Barbarisi
Re: Fly-by-wire without leaving the ground
A. Padgett Peterson
MSAFP, utilities, and all that
Mark Fulk
Computer monitoring of pill bottles
Jennifer Heymont
Documentation and lack thereof (Stanley
S.T.H.) Chow
Just the wrong number
Jerry Leichter
Reliability and Redundancy
Bill Murray
CPSR Annual Meeting
Eric Roberts
Info on RISKS (comp.risks)

Midwest Stock Exchange Reaps Millions Due to Accounting Glitch

Jeff Helgesen <>
Fri, 20 Sep 91 14:54:15 cdt
The Chicago Tribune reports that leaders of the Midwest Stock Exchange had
discovered a 13-year-old accounting glitch which enabled a subsidiary to
wrongfully reap millions of dollars in interest payments which should have
gone to broker-dealers.  While the exact amount of money recieved by the
subsidiary due to the error was not disclosed, the chairman of the exchange
said that he estimated that over the last twelve months, the firm received
around 1.8 million dollars.

The accounting error, due partly to human error and partly the fault of
computers[sic], apparently dates back to about 1978. At that time, the
exchange and two of its subsidiaries, Midwest Clearing Corp. and
Midwest Securities Trust Co., altered the way certain broker-dealer
transactions were handled.  Clearing Corp. instituted a change, largely
computerized, ordering broker-dealers to wire money to it for the sale
of securities before the securities were received by Securities Trust

By depositing these funds in short-term, government-backed securities,
sometimes overnight but also for longer periods, Clearing Corp. generated
for itself interest payments which should have gone to the broker-dealers.
This is referred to as "playing the float". When the clearing system is working
properly, the securities and proceeds are transmitted through the system
simultaneously, thus eliminating such a float.

The Midwest Stock Exchange insists that they are taking the situation very
seriously, and plan to pay the money back. Some exchange members are
concerned that the money used for the refund will come in the form of higher
exchange rates, putting the exchange at a serious competetive disadvantage.

[Summary from Chicago Tribune Business Section, 9-20-91, "Exchange: Unit
profited from 13-year glitch"]

Newark high school computer problem

Fri, 20 Sep 1991 11:55:41 PDT
>From the New York Times, Wednesday 18Sep91, page B2:

"Computer Glitch Sends Newark School Into Chaos"   by Joseph F. Sullivan

The article starts off:

Newark, Sept. 17 — When Central High School's 1000 students and 90 teachers
showed up for the start of the school year on Sept. 5, many found themselves in
a computer-generated game that was part musical chairs and part hide-and-seek.

About half of the students had no schedules for classes or had schedules with
holes in them.  Some classrooms had no teachers, while others had four teachers
instead of one.  Many students spent much of last week in the school auditorium
conferring with guidance conunselers who were trying to correct the scores of
mistakes in their classroom assignments.

The article then goes on to talk about absenteeism and the other problems this

marty   UUCP:uunet!!leisner.henr801c

Technology and the oldest profession

Henry Cox <>
Thu, 19 Sep 91 09:37:25 EDT
This morning, the Boston Globe had an article about a $3 million prostitution
ring which had been running out of a Boston suburb, which was broken in a
series of raids yesterday.  The computer relevant (or irrelevant, as the case
may be) portion of the story was that the group kept a database of their
4000-odd customers and had used call forwarding/etc. to be able to move
headquarters from place to place quickly and easily.

The story was unclear on what the police intend to do with the customer list,
most of whom are apparently fairly well off.

    [Similar stories have been recorded in the RISKS annals before --
    e.g., SoftwEngNotes 11 5, 12 1, 14 1.  (See RISK-7.72, 8 Nov 88,
    Computers in the oldest profession (Dave Horsfall).  PGN)

YATO (Yet Another Telco Outage)

Richard Johnson <>
Fri, 20 Sep 91 9:19:19 PDT
According to KINK radio in Portland, Oregon, this morning, most of the suburbs
south and east of Portland were without telphone usage for about six hours
because someone cut a fiber-optic cable.

More importantly, the towns of Milwaukie and Lake Oswego (just south of
Portland, upstream on the Willamette river) were without 911 coverage for over
three hours.
                 Richard Johnson

AT&T switch trouble

Fernando Pereira <>
Thu, 19 Sep 91 14:51:13 EDT
According to the AP, the union for the technicians in charge of monitoring the
AT&T switch that shut down this Wednesday causing major disruptions to air
traffic control (RISKS-12.36) claimed that they were not on duty because they
were attending a class to learn about a new alarm system for the problem that
caused the shutdown.

English Supermarket Checkout Failure

"Maddock :-)" <>
Wed, 18 Sep 91 10:41 GMT
The English 'Daily Telegraph' (Sept 18) reports on the failure of 32 computer
operated checkout tills in the Sainsbury supermarket in Aylesford, Kent.

    'Shoppers ...  were invited to suggest a fair price for the goods in
their trolleys when the scanners which which read the bar codes refused to
work.  The breakdown happened only 10 days after the opening of the new store
... The store was then closed for the rest of the day.'

Sainsbury's described the failure as 'extremely rare' and said 'when a total
failure occurs we ask the customer to suggest a price'.  The chain said that
'this allows customers already shopping to complete their purchases'.

Samurai Hackers' Cunning Employer Screening Process

Barbarisi <>
Wed, 18 Sep 91 13:59:07 CDT
I'm sure many of you have seen the recent issue of Rolling Stone magazine, with
the article entitled "Samurai Hackers".  It discusses the hiring of young
computer enthusiasts by law firms, ad agencies, and the like, for the purpose
of prying into the electronic data of subordinates and coworkers.  Basically,
individuals and firms recruit "hackers" from BBSs and pay them thousands of
dollars to do little more than break passwords and riffle through files.
Appropriately, the young hackers call these people "Stupids".  Of course, the
young hackers should really be called "crackers", but I really don't want to
start another semantics war.

Both the crakcers and their employers have unsettling views on privacy: Data
stored electronically is considered public information, regardless of the locks
(passwords) enabled by the keeper.

The really cunning aspect of the article is one little paragraph in
which the samurai explain how they screen potential employers over a BBS.
Claiming the need to "authenticate" potential employers and differentiate
them from the Feds, the crackers will not deal until they get the person's
social security or credit card numbers!  Though not mentioned in the
article, it seems reasonable to assume that this "authentication" process
includes requests for other information such as birthdate, childrens'
names, home phone number, car tag, etc.  All of this occurs remotely over a
BBS system.

I'll leave it as an exercise for the reader to figure out what is wrong
with this picture.

Marco C. Barbarisi  -  NCSC Panama City, FL  -

Re: Fly-by-wire without leaving the ground

A. Padgett Peterson <>
Wed, 18 Sep 91 17:10:51 -0400
From: fmsrl7!art-sy!

>James Higgins, THE DETROIT NEWS, 15 September, page 1C: ...  Clemson engineers
>... have patented a new automobile camshaft/throttle control system they say
>can boost fuel economy by 20 percent in a gasoline engine.

Over what ? A '74 Toronado, or a Honda Civic HF ?

>A camshaft controls the action of the valves that let mixed fuel and air into
>an engine and allow burned gases to escape.  Usually it's set up so that the
>valves will open or close according to just one setting.  That setting is a
>compromise, not...optimal...for all engine speeds. ... In the Clemson system,
>the camshaft consists of two shafts, one of which rotates inside the other.  An
>infinite variety of valve settings is possible, theoretically allowing optimal
>valve action in every situation.

Both Bruce Crower (1973) and the Cadillac 8-6-4 (1978) tried similar but less
complex solutions. Neither was  satisfactory.

>But here's the nub--his
>system also includes a computer-controlled device that electronically allows
>the camshaft to act as the car's throttle--a revolutionary idea.
>The Clemson system substitutes [for] the mechanical connection...a computer
>control--a "fly by wire" device like those...on advanced aircraft.

The Knight sleeve-valve engine had some similar characteristics back in the
20's as I recall.

The idea has promise but a MAP (Manifold Absolute Pressure) following throttle
plate would have the same charactoristics without the drawbacks. So does any
cruise control. See below.

> When the engine doesn't have to labor against a partially closed throttle,
>significant fuel economy gains are possible, Nelson says.

This is wrong. An engine doesn't "labor" against a partially closed throttle
any more than a vaccuum cleaner "labors" against a blocked inlet - the power
requirement goes down, not up as the MAP decreases since less air volume is
being moved/compressed. When you remove the combustion aspects, a gasoline
engine is often modeled as an air pump with maximum capacity at WOT (wide
open throttle) and minimum load with a closed throttle.

One point not mentioned is that such a scheme would also require direct
cylinder fuel injection, also like a Diesel & considerably more expensive
than the port or throttle body injection currently used on "conventional"
gasoline engines since the very short intake duration and low manifold &
port gas velocities at cruise woud preclude other methods.

This is not to mention the lack of any manifold vaccuum source for accessories
or emissions devices (why passenger Diesels have little vaccuum pumps mounted
on them). Of course this is souluble with a bit of engineeering but the
question remains whether any advantage is gained that is not available with
a "fly-by'wire" throttle plate alone. It would be interesting to see how
this device would match up with a good cruise control on a modern engine.

This is not to say that the variable camshaft duration (haven't seen the
device, but would expect the delta to be in duration not lift since a) is
much simple to impliment, and b) would allow tailoring not only of the
effective flow, but also the advance/retard charactoristics that could spread
effective scavaging/ram effects over a broader range than with a fixed cam)
doesn't sound theoretically feasible, just that there are easier ways to go
about it and I have to wonder if it might be more suited to racing than the

Really digging now but didn't Mercedes experinent with variable durations
on the 300SLR's desmodromic (sp?) valve gear in the early fifties ?

In short, the idea has promise but, at least for the moment, I would have
to put it in the same category as the D.A.F. "DAFODIL"  with the constant
velocity transmission of a few years ago - the same idea approached from the
opposite side.

MSAFP, utilities, and all that

Wed, 18 Sep 91 11:42:42 EDT
I must regret having created something of a monster.

My original point was simply this: the advocates of the MSAFP assigned
different utilities to the various possible outcomes than I did.  However,
their advocacy literature did not address this possibility.

On questioning, one MSAFP advocate (a geneticist at Strong Memorial Hospital)
admitted that the rate of spontaneous abortions had relatively little impact on
consideration of the MSAFP.  It was clear from our conversation that the MSAFP
advocates (the geneticist was one) were concerned with the social good of
reducing defective births, whereas I was also concerned with the grief and
self-recrimination that would surely follow an accidental abortion.

Although it is tempting to respond at length to Mr. Grodberg, I will limit
myself to three points: I did this calculation in 1987, it was done with the
numbers supplied to me by the ADVOCATES of MSAFP screening, and I possessed and
used some relevant facts that Mr. Grodberg lacked.

In particular, I regarded anencephalic births as having only about double the
(negative) utility of spontaneous abortions, whereas spina bifida was given a
much lower (worse) utility.  This because anencephalic infants do not survive,
whereas infants with s.b. do and require surgery; at least a few years ago they
were generally paralyzed from about the waist down.  Almost all s.b. victims
also suffer hydrocephaly (maybe it's all, I forget); and the shunts used to
treat hydrocephaly frequently break down.

I'd provide you with precise numbers if I could find my notes.  Unfortunately,
they are buried under about a foot of papers on my table here.  After all, it
has been nearly four years now.
                                             Mark Fulk

Re: MSAFP, utilities, and all that

Wed, 18 Sep 91 13:47:47 -0400
If people would stipulate three points:

  (1)  The parties affected by a choice do not usually share a common
    assignment of utilities to outcomes (if they can be said to
    have utilities at all; see Kahneman and Tversky).

  (2) Point 1 is rarely acknowledged by published risk-benefit analyses.
    (Emphasize rarely; some studies may, but the studies that I've
    read haven't.)

  (3) Points 1 and 3 are of interest to RISKS readers, and should
    be born in mind whenever discussing risks of any sort.

then I would have succeeded, and I don't really give a damn what people
think of the MSAFP.  In fact, my position would be that people OUGHT TO
make their own evaluations of the MSAFP.

The same point can be made in several different ways.  For example, government
tends to equate all deaths, or at least to equate years of life lost; people in
general, however, have strong preferences about the NATURE of their deaths.


Computer monitoring of pill bottles

Wed, 18 Sep 91 13:57:05 -0400
    There seems to me to be one very obvious problem with the
so-called "Smart Pill Bottles," which is that there does not need to
be any correspondence whatsoever between the number of times that a
patient opens a pill bottle and the number of times that they actually
*take* the medication.  Two scenarios, both of which are common to
people who take medication regularly, come readily to mind:

    a) patient opens the pill bottle to see how many are left and
whether or not they need to refill their prescription.  This would
result in more openings than pills taken, and the doctor might well
think that the patient was taking the appropriate number when in
reality they are not.  This would probably be in the noise, since it
doesn't happen that often.

    b) much more common is a patient who opens the bottle,
transfers some to another bottle, which he keeps in a different place,
takes on a trip with him, etc.  This would result in a number of
bottle opens that was drastically less than the number of pills taken,
causing the doctor misattribute effects the effects of too low a
dosage to incomplete ingestion of medication.

    Now granted, in both of these scenarios, all that is necessary to avoid
the problem is for the patient to know what is going on and make sure to keep
track of things like this.  However, presumably if they were on the ball enough
to do that, they wouldn't need something like this in the first place!

Jennifer Heymont
                   [There are many problems with the original approach...
                   But the fundamental problem is another example of looking
                   for a high-tech solution to a low-tech problem...  PGN]

Documentation and lack thereof

Stanley (S.T.H.) Chow <>
19 Sep 91 13:02:00 EDT
In a recent issue of "Vectors", published by Hughes Aircraft, there is an
article entitled "So, you can't replcae it then make it better". The article
talks about the amazing feats the Hughes achived in winning the MTSP
(Microelectronics Technology Support Program). The whole MTSP seems to be a
response to the problem of not being able to obtain obsolete components for
military systems. This is itself of some interest due to the military going
from leading edge to the trailing edge.

Of more interest to RISKS readers, contractors to the MTSP had to solve three

   - "Reverse engineer an obsolete intergreated circuit".
   - "Given technical data on a circuit board, reverse engineer the
     circuit board". (There is no statment of how much technical data)
   - develope replacements for above, using silicon compilers and generic
     gate arrays.

Given the well-known mountains of paper that the Pentagon requires for any
hardware, and the many mil-spec's for documenting and testing any and
everything, it is quite a surprise to me that anyone should need to reverse
engineer anything.

To make explicit the RISKS:

  Even excellent documentation is usesless, Unless you can find it again.

Stanley Chow        (613) 763-2831

BNR PO Box 3511 Stn C, Ottawa, Ontario, Canada  K1Y 4H7  BitNet: schow@BNR.CA       ..!uunet!bnrgate!bcarh185!schow

Just the wrong number

Jerry Leichter <>
Thu, 19 Sep 91 22:33:47 EDT
Sanford Sherizen's recent posting about the Tandem crash due to the date/time
have "just the wrong value" reminds me of two other such incidents that I
know of.  Curiously, in both cases the POTENTIAL for the problem was spotted
in the code, but as far as I know in neither case was it ever triggered.

Case 1:  So you think that's a good password?

When I was an undergraduate at Princeton, a group of friends and I, ahem,
made full use of some of the more arcane and undesireable aspects of OS/360.
Now, OS/360 had no provision for passwords on accounts - it was, after all,
a batch/card system.  However, the local system support people decided that
passwords were needed.

They needed to retrofit a password scheme into an existing system.  To store
the password, they re-used 3 bytes in the existing user data file (they had
previously contained the user's initials).  A submitted deck could, anywhere
at all within it, contain a $PASSWORD card with the correct password.  (The
recommendation was that carry with you a $PASSWORD card, pre-punched with your
password, but with the printing turned off.  The card would not appear in your
output, and without the printing it couldn't be "accidentally" read without a
deliberate effort.  Given the technology, not a bad system.)

Since many old decks existed, and there was a large group of existing users,
it was decided that the password feature would be optional:  Initially, you
had no password.  If you had no password, you didn't need a $PASSWORD card;
if fact, if you provided one, your job was rejected.  Once you had set a pass-
word, you had to provide it.

Now, there is no free bit to indicate "has set a password", so instead the
chosen field was re-used:  If it was three 0 bytes, the system assumed you
had no password.  In that case, it didn't even check the password provided
on a $PASSWORD card - it immediately rejected the job.

Three bytes does not a good password make.  It's not that there are too few
combinations - in an environment where the only way to try a password is to
submit a deck of cards, 2^24 of them is plenty.  However, people want some-
thing they can remember.  So the system allowed passwords of, as I recall,
up to 16 bytes.  The 16 bytes were run through an encryption algorithm (the
designers apparently thought it was a one-way encryption - it wasn't, as we
proved by inverting it) and then compressed down to three bytes.

There are many perfectly valid passwords which, after running through this
algorithm, produce an encrypted, compressed password of three zero bytes.
The password setting code didn't check for this; it simply stored the cal-
culated value.  Set one of those passwords, and you were locked out of your
account until you thought to run a deck with no $PASSWORD file in it at all.

Case 2:  A spacey kind of Saturday.

A number of years ago, I worked on a system that supported all of DEC's manu-
facturing plants.  The system was written in BASIC PLUS on RSTS/E - sounds
bizarre, but it worked out quite well.  (This experience also left me per-
manently skeptical of all claims that any new language/OS/whatever is a
panacea.  Most programmers, and probably all academics, would look down
their noses at the environment we had - but we built and maintained a large,
successful system, running quite reliably 24 hours a day, tying together
multiple CPU's - in 1974, when networking was virtually unheard of.)

The standard RSTS representation for the date was a two-byte number represen-
ting an offset from some base day, I forget when.  BASIC PLUS had some very
nice file management calls, but they worked with strings, not numbers.  No
problem:  There was a set of what amounted to type coercions that would take,
say, a date and treat it as a two character string.

One day. I did a little calculation and realized that we were quite close to
an interesting anniversary:  The day that the date, interpreted as a string,
came out to two spaces.  The date happened to fall on a Saturday.

Some string operations in BASIC PLUS truncate trailing spaces - the obvious
string comparison operation is one.  I could imagine many potential failures
in programs that suddenly found that the current date was the null string.  So
I was looking forward to an interesting Monday morning of panicked calls from,
literally, all over the world.  I must say that I was glad that none came in!

                            — Jerry

Reliability and Redundancy (Re: PGN, RISKS-12.36)

Fri, 20 Sep 91 15:34 EDT
>Here we have another example of creative redundancy and supposedly
>conservative design (hardware reliability, fault tolerance, extra capacity,
>alternative routing, standby power, etc.) still not being good enough to
>prevent massive outages.

This should not come as a surprise to anyone.  There is an upper bound to the
degree of reliability that can be built into a system by redundancy.  At some
point, one introduces so much complexity, so many components, and so many
connections that these begin to cause failures that would not have occured in
their absence.

I do not intend to suggest that there is an upper bound to reliability; while I
suspect that there is, I do not pretend to know.  Only that there is clearly an
upper bound to the reliability that can be achieved by redundancy.

I have more hope for what can be achieved by integration and simplification.

William Hugh Murray, New Canaan, Connecticut

CPSR Annual Meeting

Thu, 19 Sep 91 14:09:33 PDT
                         1991 Annual Meeting
           Computer Professionals for Social Responsibility
                          October 12 and 13
                Massachusetts Institute of Technology
                   Cambridge, MA  Auditorium 34-101

                     Celebrating Ten Years of CPSR

Computer Professionals for Social Responsibility, the nation's only public
interest organization of computing professionals, will hold its 1991 Annual
Meeting on October 12 and 13 in Cambridge, Massachusetts.  The CPSR Annual
Meeting is a national gathering that gives computer professionals from all over
the country a chance to meet and to discuss the important and interesting
issues facing the profession and the public.  The meeting is open to everyone
who has an interest in computers, communication, the future of our high-tech
society, and our role as citizens in the development of policy.

This year's meeting will focus on current developments in information
technology and the impact they will have on our ways of communicating and
distributing information.  The Bush administration has proposed a $2 billion
program of investment in new computer networking technologies, which have the
potential of transforming the future of international communication.  There are
many pressing policy issues raised by the proposal: Who will control the new
network?  Who will have access to its resources?  What are the provisions for
privacy, security, and equity?

The sessions on Saturday, October 12, will include several distinguished
speakers addressing these and other pressing public-interest issues surrounding
electronic communication and the emerging "information age."  It will provide
an opportunity to think together about the problems, and through CPSR to pass
the resulting assessments along to the media, to policymakers, and the other
participants in the democratic process.

Admission to the CPSR Annual Meeting is $20 for members, $25 for non-members,
and $10 for students and low-income attendees.  We welcome additional
contributions to support our work.  Contributions to CPSR are tax-deductible.

For more information and registration materials, contact CPSR at (415)
322-3778 or by electronic mail at


Saturday, October 12

8 a.m. to 9 a.m.  Registration and Continental Breakfast
9 a.m. to 9:15 a.m.  Welcome from the CPSR Board

9:15 a.m. to 10:45 a.m.
"The Past, Present, and Future of Government Policy in the Information Age"

John Shattuck, Vice President, Government, Community and Public Affairs,
Harvard University.  Research Associate in the Science, Technology, and Public
Policy Program at the John F. Kennedy School of Government, Harvard University.
Former Washington director of the American Civil Liberties Union, and former
vice-chair of Amnesty International.

10:45 a.m. to 11 a.m.  Break

11 a.m. to 12:30 p.m.
"The Personal and the Political in Electronic Communication"

Judith Perrolle, Associate Professor of Sociology, Northeastern University.
Research Associate at the Harvard School of Public Health.  Author of the book,
_Computers and Social Change_.

12:30 p.m. to 2 p.m.  Lunch (not included in the conference)

2 p.m. to 3:30 p.m.
"Educational Equity and the International Economy in the Information Age"

Herb Gintis, Professor of Economics, the University of Massachusetts at
Amherst.  Co-author of the books _Inequality_ (with Christopher Jencks and
others), _Schooling in Capitalist America_ (with Samuel Bowles), and _Democracy
and Capitalism_ (with Samuel Bowles).

3:30 p.m. to 4 p.m.  Break

4 p.m. to 6 p.m.
Parallel presentations on public interest programs involving information

   o  An overview of CPSR's programs and operations, intended for
      new members and those who would like to become more active in
      the organization, presented by members of the CPSR Board of

   o  Mass OnLine, a project of the Boston Computer Society,
      presented by Tracy Licklider, president, Boston Computer

   o  Community Bytes, a project of the MIT Community Fellows
      Program, presented by Laxmi Ramasubramanian, research
      associate, Community Fellows Program.

   o  The Electronic Frontier Foundation, to be presented by a
      representative of EFF.

   o  The CPSR Computing and Civil Liberties Project, presented by
      Marc Rotenberg, National Program Director, Computer
      Professionals for Social Responsibility.

Sunday, October 13

8 a.m. to 9 a.m.  Continental breakfast
9 a.m to 10 a.m.  Reports from CPSR leadership
10 a.m. to 10:30 a.m.  Break
10:30 a.m. to 12:30 a.m.  Chapter organizing workshop
12:30 p.m. to 2 p.m.  Lunch
2 p.m. to 3 p.m.  General CPSR business meeting
3 p.m. to 4:30 p.m.  Parallel workshop sessions on CPSR projects
4:30 p.m. to 5 p.m.  Wrap-up and evaluation

Please report problems with the web pages to the maintainer