The RISKS Digest
Volume 12 Issue 55

Wednesday, 23rd October 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…


Power outage downs New York Stock Exchange for 24 minutes
Near-sighted or far-sighted fibre-opticians?
MCI Friends & Family & anyone else with a touch-tone phone
Brian R. Krause
Risks of double standards (on PRODIGY)?
David HM Spector
Use of Prodigy on AMC Computers
Louise R. Silsby via Brinton Cooper
A note on RISKS contributions
Re: Videos and "Dumbing Down" (again)
Daniel J Yurman
Re: More ATM anecdotes
Mark Bartelt
Re: Oki Telephone Programming
Randal L. Schwartz
Re: Computer reads water meter
Lauren Weinstein
Sam Ho via John Sullivan
Lars Poulsen
Bjorn N. Freeman-Benson
Re: Have you tested your machine lately?
Neil Hunt
Re: Software Migration at the Johnson Space Center
Joe Bouchard
Info on RISKS (comp.risks)

Power outage downs New York Stock Exchange for 24 minutes

"Peter G. Neumann" <>
Wed, 23 Oct 91 10:17:15 PDT
The NYSE was down between 10:21am and 10:45am on Tuesday 22Oct91 because of a
power outage that downed all of the computers (but not the lights!).  ConEd
suggested that the outage might have been related to a severe voltage dip at
the local power station, resulting from problems with a disconnect switch on a
138,000-volt line.  [Reuters, in SanFrancisco Chronicle, 23Oct91, p.C3]

Near-sighted or far-sighted fibre-opticians?

"Peter G. Neumann" <>
Wed, 23 Oct 91 9:21:23 PDT
U.S. spy masters prevent sale of optic fibre to Soviets' experts

   PARIS, Oct 22 (AFP) - The United States, seeking to maintain its ability to
spy on conventional telecommunications, is preventing western companies from
selling much-needed optic fibre to the Soviet Union, several western experts
say.  Agreement on policy appeared unlikely before the next high-level meeting
in Paris at the end of November or beginning of December of the western
coordinating committee for export control (COCOM) which restricts the export of
high technology to communist countries, they said.

                       [This is the beginning of a longish article.
                       The entire piece can be found in RISKS-12.55afp.]

MCI Friends & Family & anyone else with a touch-tone phone

"Brian R. Krause" <brian@EDDIE.MIT.EDU>
Wed, 23 Oct 91 19:11:07 EDT
I should have known better than to tell MCI who my friends and family are.
Here's part of the brochure they sent to introduce me to their Friends & Family

   Q.  "How can I leard the immediate status of my Calling Circle?"

   A.  All you have to do is dial 1-800-FRIENDS from any touch tone
       phone, anytime.  A recording will tell you who has been added,
       who is not eligible and who is in the process of being  contacted.

Anyone who knows your phone number and ZIP code can get a complete list of your
Calling Circle.  You don't need to know a number to check its status; the
computer lists them all.

I called MCI about this.  The first representative I spoke with tried to
convince me that nobody would try to get my numbers that way, and that, really,
if someone was malicious, they could call him and cancel or change my service
anyway.  That made me feel good.

I then spoke to the supervisor--she had never used the FRIENDS number, since "I
work at MCI and can check my numbers all the time."  She seemed surprised that
you only needed a ZIP code, and has promised to get back to me.

In the meantime, I'm not adding any more people to my list, and I'm considering
switching to a company that doesn't make my monthly bill public information.

Brian R. Krause, Software Developer, Milwaukee, WI 532XX

Risks of double standards (on PRODIGY)?

David HM Spector <spector@acf5.NYU.EDU>
Wed, 23 Oct 91 08:45:35 -0400
There have been a number of very disturbing reports in the press (CNN, and WNYW
tv in NYC) in the last several days that on one of PRODIGY's forums, which
discusses the Holocaust, members have been posting anti-semitic messages.  Some
of the messages _advocate_ "another holocaust", etc, etc...

The ADL (Anti-Defamation League) has protested to the PRODIGY management who
responded that they "oppose anti-semitism", but they "encourage the free
expression of ideas".  Is this the same PRODIGY that makes decisions about what
acceptable "free expression" is when it comes to use of electronic mail, and
what are "acceptable" topics in their Health forums?  Hmmm.. sees like a pretty
scary double standard to me....

David HM Spector, 310 West 18th Street 5A, New York, N.Y. 10011 (212) 243-5548
                                        Usenet: ..!{uunet,apple}!panix!spector

Use of Prodigy on AMC Computers (from Louise R. Silsby)

Brinton Cooper <abc@BRL.MIL>
Wed, 23 Oct 91 9:34:37 EDT
All of us on the Lab computer network (which is, in fact all of us)
received this note this morning.  What was the final judgement on
Prodigy?  I thought that the Prodigy flap was all a misunderstanding.


|We have been directed by HQ AMC to suspend all subscriptions to the Prodigy
|Services Company and remove all Prodigy software from AMC owned computers.
|This includes all individuals that have installed personal copies of Prodigy
|on their computers at work.  This directive will remain in effect until
|further notice.
|Employee owned computers used to access Prodigy Services may not be used to
|access government owned computers so as to preclude the possibility of
|unauthorized access to government data.
|If you have been using Prodigy as described above or if you have questions,
|contact...[name and phone deleted].

A note on RISKS contributions

"Peter G. Neumann" <>
Wed, 23 Oct 91 9:29:39 PDT
As I have remarked before, my moderatorship tends to run in cycles from
permissiveness to wholesale rejections, depending on the topic, my mood, and
how much time I can devote to interactive moderating.  But the real problem, I
fear, is epicylic rather than cyclic, because as RISKS gets more and more
readers with greater intellectual, geographic, and other forms of diversity,
more and more material gets submitted, and some of it is less generally
relevant to everyone.  After receiving a few complaints suggesting I get me
back into a more-selective moderatorship, I think it may again be time to head
back in that direction.  I do not like to flood YOU with too much, but I am
certainly flooded!  In any event, keep the good incisive contributions coming!

The following contributions represent what I hope is a final trickle on the
earlier subjects.  PGN

Re: Videos and "Dumbing Down" (again)

Daniel J Yurman <>
Wed, 23 Oct 91 10:57:37 MDT
Reference a series of reports in RISKS-12.52 and 12.53 on problems with
returning videos, I am surprised that your readers have not linked the problem
of closing rental return transactions with an earlier RISKs issue — the
"dumbing down" of the workforce.

In most of the instances reported customers were eventually moved to rage over
the stubborn insistence of employees and managers alike that the "computer had
to be right."  None of the video store staffs evidence the slightest
inclination to question the information in their computer.  This can be
ascribed to a lack of training, education, or fear of getting yelled at by the
manager for letting a late fee go by.

The larger issue is what are these people [the video store employees] going to
do when IRS screws up their taxes or when their Social Security benefits
records are scrambled, etc?  Are they going to believe that the government's
computers are right or are they going to fight for accuracy of personal
information which affects their lives?

A case can be made for asking how well we are preparing people to put the
question of computer accuracy in perspective.  For instance, is the accuracy of
the data a life and death matter.  For medical diagnostic equipment the answer
is yes, but for video rental transactions, the answer is no.  Yet, in one RISKs
report the writer reports he took the time to drive to the manager's home at 10
PM to resolve a $3 charge.  Both the writer and the video store manager have
lost it.  They allowed themselves to be driven — literally — by a bogus
record in a database maintained by people paid a minimum wage!

There seems to be a problem of scale here.  From an marketing point of view
there are many video stores so customer service becomes a competitive edge to
retain and grow sales.  Enraging a patron over a $3 late charge seems penny
wise and pound foolish.  Obviously, a more astute video store manager would
resolve a dispute over a late charge letting it slide to keep a good customer
coming back.  After all the computer would have a record of how good a customer
was in terms of repeat business.

Further, this example raises the issue that many businesses face which is how
accurate do computer records have to be to keep making a profit and keep
customers coming back?  Many businesses let minor financial discrepancies slide
in the interests of the overall commercial relationship with customers /
clients.  ATM transactions do not belong to this class of business activities,
but late charges on video rentals probably do.
                                                  Dan Yurman, Idaho National
Engineering Lab., PO Box 1625 MS 3900 Idaho Falls, ID 83415   (208) 526-8591

Re: More ATM anecdotes (Moonen, RISKS-12.54)

Mark Bartelt <>
Wed, 23 Oct 91 07:01:48 EDT
I continue to be amazed by the abysmal quality of the software that I encounter
in ATMs.  There are numerous situations where a bit of thought would have made
them far less frustrating to deal with.  Two examples:

(1) I have several ATM cards (for accounts at various different banks), all
with different withdrawal limits.  Since most of my cards rarely get used, I
have trouble remembering what the limits are.  I recently stepped up to a
machine, and asked it for $500.  It insisted that I ask for a different amount,
since that machine was capable of dispensing at most $400 in one transaction.
Fine.  I asked it for $400.  This time it told me that it couldn't give me
$400, since my withdrawal limit was $300.

This incident was doubly frustrating: First, because it ought to be trivial to
check the requested amount against both the card limit and the machine limit
simultaneously, thus requiring only one retry rather than two.  Secondly, each
failed attempt required that the card be removed and reinserted, and the PIN
re-entered.  (Why?)

(2) A few months ago I tried to make a deposit to an account which I hadn't
used in quite some time.  The machine refused to allow any access to the
account, and displayed a message telling me to contact my branch.  It turns out
this bank has a policy of disabling all ATM access to an account that hasn't
been used for more than six months.  I was rather annoyed because (a) they
don't tell customers this when an account is opened, and (b) nothing is mailed
to a customer to whom this is about to happen, warning him/her that their ATM
access will soon be disabled unless they take some sort of action.

In order to get the account re-enabled, it was necessary to go into the branch
in person.  Not just any branch, either, but the branch where the account was
originally opened!  In my case, this was just a fifteen minute subway ride.
What if I'd moved to a different city?  To paraphrase H. L. Mencken, nobody
ever went broke underestimating the intelligence of people who run banks.

I'm just lucky that I was only trying to make a deposit.  What if it had been
an emergency situation, where I needed cash quickly?  If an ATM is down, I can
generally find another one that works.  But if this were my only account, and
all ATM access is denied, I'm out of luck.

Furthermore, even if you agree with the concept that it's a good idea to
disable withdrawals from a "stale" account (for security reasons, or whatever),
what possible justification is there for not permitting someone to deposit
money into an account?

Mark Bartelt, Canadian Institute, for Theoretical Astrophysics   416/978-5619

Re: Oki Telephone Programming (Bell, RISKS-12.54)

Randal L. Schwartz <>
Wed, 23 Oct 91 10:03:50 PDT
There's no risk to this.  The phone number/serial number pair is validated
on each call (which is why the phone wouldn't work in the first place).

Programming your own number doesn't circumvent this; the methods for
programming *any* cell phone are publicly available (I think the "universal"
manual costs around $50, and I have the address somewhere).  What you *cannot*
change from any sequence of keypresses is the phone serial number.  The serial
number *can* be changed by replacing a chip, and this is what the other RISK
articles have referenced.

Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095

    [...unless you can change the "tamperproof" serial number.
    Also noted by and (Lars Poulsen).
    See also recent issues of the TELECOM DIGEST.

Re: Computer reads water meter

Lauren Weinstein <>
Tue, 22 Oct 91 19:50:40 PDT
Greetings.  The description given would indicate that the meters to be read do
*not* make outgoing calls, but rather are interrogated by the central system.
There are special features in various modern telephone exchanges for "ringless"
connections to subscriber lines, specifically for such purposes as meter
interrogation and line testing.  Doesn't that give you a warm feeling?  (It
should be noted that some of these are not as "ringless" as they are supposed
to be--some phones "ding" or "chirp"--usually at very late hours--when hit by
some existing telco test routines.)

Other clues also point in this direction, for example, the note that if *your*
line is in use the system will get a "busy signal" (this would not be the case
for outgoing calls *from* your line, but would be the case for incoming calls
*to* your line).  I assume that the exchange is programmed to ignore any call
waiting features on the subscriber line in this sort of situation and just
return busy for any subscriber use that conflicts with an interrogation

The business about their only needing your phone number to set up the service,
and that then they will delete it, is bogus.  They need the number to program
into the system.  Once that's done, maybe the ordinary customer service rep.
won't be able to see the number, but it'll be in there!

Risks?  The obvious ones, mostly, many of which have parallels with manual
meter reading: accidental confusion between meters, undetected read errors
resulting in false data, etc.  Frankly, the most serious concern might be that
an "electronic" meter that crashes or is disrupted in some manner might make it
difficult to correct inaccurate billings.  With mechanical meters, if there's
an accidental over-read by the meter reader, they can go back and look at the
meter again and verify what's going on--the mechanical system is fairly robust
in that respect.  But an electronic system could crash pretty badly.

I wonder if electronic water meters would try to draw their power from the
phone line--you can draw a very limited amount for that purpose.  I also wonder
how much hassle it will be to *get* to the phone line from many water meters!
In many areas, water meters are currently mounted in the curb.  This would
imply installing a new meter somewhere closer to the house on the main water

Actually, the biggest risk may be to the utilities themselves, if people start
intercepting the interrogation calls and feeding back their own (presumably
lower) data.  Of course, this sort of thing has been going on with mechanical
meters since the dawn of metering as well.

For example, before the power companies started getting serious about really
locking down power meters with steel collars and lead seals, there were people
who used to flip their electric meters *upside-down* so that they would run
*backwards* for some calculated period of time to reduce their bill
appropriately (but not enough, presumably, to trigger computer-based flagging
of their account for odd month-to-month variations).  The rather amusing aspect
of this was that people running such upside-down meters would need to turn *on*
as many appliances as possible to try force the meter to run rapidly in the
reverse direction.

So while new technology often brings with it new risks, we see that sometimes
it also acts to bring old risks into the 21st century in new forms!

   [Many other folks commented on this one also, including Mark Bartelt.
   I gave up on trying to prune the following differentially.  PGN]

Re: Computer reads water meter

Wed, 23 Oct 91 15:01:14 CDT
Sam Ho of UIUC was kind enough to point out that I jumped to a few unwarranted
conclusions.  He believes that the phone company is more directly involved in
the scheme than I had guessed:

-> From: (Samuel W. Ho)
-> No, the meter does not call the water company.  Rather, what happens
-> is that the telephone central office sends a coded signal down the
-> line to the water meter, while the line is still on-hook.  The meter
-> then responds with the reading.  All this happens superimposed on the
-> usual battery voltage, with the line on-hook.  If your phone happens
-> to go off-hook, or if there is an incoming call, the process is aborted,
-> regular ringing or dial tone appears, and the water company tries again
-> later.
-> Normally, you tell the telephone company you want to use the telephone
-> by drawing DC loop current.  The meter is AC coupled so it doesn't draw
-> current.
-> They don't need your telephone number, since water meters are associated
-> with buildings.  If you move, you don't take your water meter reading
-> with you.  Instead, the meter is keyed to the telephone company's
-> location information.

This would also explain why they need your phone number to set up the service
(to get the telco's location info), but don't store it.
                                                           -John Sullivan

Remote Meter Reading

Lars Poulsen <>
Wed, 23 Oct 91 14:30:08 PDT
In RISKS-12.54, John Sullivan, Univ. of Minnesota (
writes about the "Easy Reader" system to be introduced in Minneapolis over the
next few years.  The note reveals some uncertainty about the technology.

The remote meter reading service is a feature of most electronic central office
systems. It is being put into service in many parts of the country.

The system requires special hardware and software on the telephone switch; the
utility company subscribes to a specially equipped trunk.

As I understand the system, the subscriber record contains a special flag to
indicate that the line has a remote-readable meter on it.  When it is time to
read the meters, the utility company activates a special "modem" on their port,
and the central office switch scans all the lines that are equipped for meter
reading by that utility. Lines that are busy are bypassed (with some provision
for scanning them later in a special pass). The switch connects the utility
trunk to the subscriber line, and the meter is polled, and transmits its data.
If the line goes off-hook during the transfer, the reading is abandoned and
retried later.

So, "your telephone will never ring" because there is not a conventional call
placed. It does not interfere with service. And the utility company does not
need to use your number, except as a record identifier to tell the local
exchange carrier to set the proper flag bit. Since there is no dialer in the
meter, it will not dial 911 in the night :-) :-)

The polling protocol is designed to allow several meters to share the line.

This is about all that I know. If you need more detail, I am sure there is a
BellCoRe document describing both the meter side and the utility trunk

Lars Poulsen, SMTS Software Engineer,   CMC Rockwell  lars@CMC.COM

Re: Computer reads water meter

Bjorn Freeman-Benson <bnfb@csr.UVic.CA>
Wed, 23 Oct 91 16:56:29 PDT
The "Easy Reader" water meter also results in a hidden rate increase for
certain customers---those who use metered local telephone service.  If I still
lived in area with mandatory metered phone service (e.g., most of Europe) and
the water company was going to do this, I'd demand a rate reduction to match
the (admittedly small) extra cost to me.

Regards, Bjorn N. Freeman-Benson

Re: Have you tested your machine lately?

Neil Hunt <nhunt@Csli.Stanford.EDU>
Wed, 23 Oct 1991 16:39:04 GMT
Boyd Roberts reports on mysterious manifestations of FPU failure on his
DecStation, and wonders about the risks of complex systems interacting to make
diagnosis hard.

We too had a similar failure, with similar symptoms: in particular, any
X-windows buttons with curved edges would be scrambled across the whole screen.
Meanwhile, most of the system seemed to run OK.  Fortunately the DEC field
service person immediately recognised the problem as I described it over the
phone.  We were skeptical, but let him swap CPU cards anyway, and the problem
went away.

Many systems have high complexity which complicates diagnosis of problems.
Modern automobile engines come to mind, for example.  However the physical
complexity of a modern workstation has been much reduced from comparable
machines of the past — after all there are only about three parts inside the
whole box.  Once having diagnosed a hardware problem, even a novice service
engineer could try swapping out all three in short order.  (In our case we
suspected a software problem and did a complete filesystem restore before
calling in the field service!)

Perhaps the RISK is in fault tolerant systems which mostly continue to work
while not alerting the user to failure, except through weird seemingly
unpredictable failure modes.

Joe Bouchard <>
22 Oct 91 18:39:18 CDT (Tue)
First, some general replies addressed to comments about the original post.

1) Other vendors did have real time simulation software... none on a large
enough box to support the proposed system.

2) Unisys A-Series (Burroughs) and 1100-Series (Univac/Sperry) equipement has
the largest RANGE (i.e. ratio of fastest system to slowest system) of
compatible computer systems available.  In other words, these systems go from
desktop processing to major mainframe class processing power with NO required
changes to the software.  Depending on how generically the ECL (Exec Control
Language) was written, the change in disk drive types, etc. won't require
changes either.

Now, the RISK I was trying to point out was upper level managements lack of
understanding of the many risks involved with moving mature software from one
platform to another when there are major environmental differences between the

The software we are talking about here is something like a million+ lines of
fairly machine and environment specific flight simulator code (full instrument,
vision, and cockpit motion included), mostly in FORTRAN and assembly language.
Those languages allow a fair amount of connection to the specific details of
the machine and the software environment.  Simply transporting the code without
doing a redesign gives mediocre results.  It's something like taking a batch
oriented application on a mainframe and turning it into a transaction oriented,
relational database, desktop metaphor application on multiple PCs connected by
LANs, expecting to keep the original design (code, too) and still get all the
advantages claimed for the later environment.

The management seems to be misled by all the talk about Ada and Unix turning
computers into commodities that are VERY plug compatible.  If SMS were written
in something like Ada, it would be designed VERY differently, mostly because
Ada implementations are required to support an environment (virtual machine, if
you will) with certain givens that are true on ANY box it runs on.  I don't
believe that the Ada machine is very good at running real time simulation
programs, but you get the point.

Porting such a system from one box to another might require a bit of patching
to manage specifics.  The only catch is that you would end up with EXACTLY THE
SAME SYSTEM you started with.  It would utilize none of the advantages of the
new hardware.  The impression of the management around here seems to be that
porting the software from one box to another automatically gives you all of the
wonderful advantages of the new box without any programming effort (not to
mention the effort to port that complex a system in the first place).  And most
of the desired changes are possible ON THE CURRENT BOX, given the effort to do
the hardware and or software upgrades necessary (trivial when compared to
simply[?] porting the code).

A similar situation exists with the FADS (Flight Analysis and Design System)
project.  NASA has directed the migration of an existing system (also on Unisys
1100 series equipment) to multiple workstations, etc.  The primary problem is
that they are so concerned with avoiding change in the existing system (which
works) that it is being force-fed onto boxes that were NOT designed to run that
way.  Changing the underlying hardware with no changes in design is only
possible when the two environments are nearly identical.  I do not dispute the
advantages of the new environment.  I DO dispute that moving to such an
environment is free.

I don't believe this RISK (system migration between environments) is limited to
NASA or even just government sites.  I've seen it happen at a public utility I
used to work for (one of the reasons I left).  That example was even simpler
(changing mainframes) and was completed with ALMOST reasonable results.  Even
so, it took longer and cost more than initially estimated.  This risk is
magnified by being at a government site.  Distrusting contractors is a way of
life.  The government pays the bills and, by definition, that means they know
the best way to implement the task.

While NASA used to have the technical know-how on the part of the government
employees to come up with good designs (and still does in some areas), the
above examples show this is no longer true with regard to these projects.
Perhaps this is one of the reasons that the SSTO (Single Stage To Orbit)
project is being managed by the SDI (Strategic Defense Initiative) branch of
the Defense Department with limited paperwork.

Please report problems with the web pages to the maintainer