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 16 Issue 52

Monday 31 October 1994

Contents

o Telephone game glitch
Julian Meadow
o The Sinking of the USS Gitarro
Mike Crawford
o Re: FEC Voting "Standards"
Rebecca Mercuri
o No Real Risks of Seemingly Similar Interfaces
Roger Carasso
o There are risks and then there are risks
Alan Wexelblat
o Re: Security screen (Bank fences, power keys, etc.)
Frederick B. Cohen
o Re: More on backspace problems
Esther Filderman
Russell Stewart
o CAPS-LOCK
Paul Barton-Davis
P. Kevin Parker
Rick Cook
Phil Keys
Doug Siebert
o Re: AOL
Greg Lindahl
Mike Crawford
o Re: Half a degree is better than none?
Curtis Jackson
o Info on RISKS (comp.risks)

Telephone game glitch

Julian Meadow <Julian_Meadow@qmailak.craycom.co.nz>
Mon, 31 Oct 1994 16:54:14 +0000 (GMT)
Computer Lied When It Said All Callers Were Winners
New Zealand's *Dominion* newspaper, 29 Oct 1994,

The hundreds of people told they had won $100 after a glitch in the telephone
TV Trivia game last weekend will not get the money. The telephone game began
awarding $100 prizes to all callers during the weekend after a computer
glitch caused by a power surge on Sunday evening. Callers said as soon as
they pressed the number 1 on their telephones to start playing, a recorded
message told them they had won.

But News Media (Auckland), which runs TV Trivia, yesterday said it would not
pay the estimated 500 callers. The company said it was quite satisfied that
all the callers who rang the 0900 number during the weekend were aware of the
nature of the game. The company said the game involved participants using
their skill and knowledge and if they were successful, they were rewarded. It
was not covered by the Gaming and Lotteries Act 1977.

It was clear the 500 callers had not been asked any questions: they did not
compete and so could not win. However, the company said it would reimburse
the callers for the cost of their calls. The Consumers Institute said the
legal issue was whether callers realised they were not playing the game
properly. If they knew there was a glitch they would not have much of a case.


The Sinking of the USS Gitarro

Mike Crawford <crawford@scipp.ucsc.edu>
Sun, 30 Oct 1994 00:02:42 -0700
I just read the section on defense in *Computer-Related Risks* and was
reminded of the following incidents:

During 1967 and 1968 I lived on Mare Island Naval Shipyard, a submarine
maintenance station just off the North end of San Francisco Bay, across a
channel from Vallejo, California.  Until recently most submarine repair
(nuclear, conventional, attack and missile) for the Pacific fleet was done
here; it has since been moved to Bremerton Washington; MINSY is being closed
down.

Sometime during 1968, the USS Gitarro (sp?) was being repaired.  The front
sonar cover was taken off, and a hatch was left open so the repair crew
could get out to work on it.  The Gitarro was floating in the water, raised
high to expose the sonar to the air.

A test engineer, who had nothing to do with the sonar people, wished to
perform a test of some mechanism that required the submarine to be level.
He went to the bridge (in the middle of the ship, far from the front) and
let some water in the ballast tanks at one end of the ship, until the
submarine was level, then closed off the tank... but he neglected to consider
inertia.  The submarine continued to settle for a bit after he closed the
valve.

He did not take the obvious route of blowing some air back into the tank.
Apparently he did not know how to raise the submarine, only lower it.
(Perhaps this was all that was given in his test plan; I don't know).
Instead, he let water in the ballast tanks at the other end.  Again he
overshot, and again, and again... until he wiggled the open sonar hatch under
the water.

Sea water came rushing in the front.  Now, this would not be such a disaster
under ordinary circumstances, as military ships are always compartmented so
that whole sections of a ship can be flooded without sinking the ship.  But
this ship was in for repair, and temporary pipelines, hoses, and power cables
had been run through the pressure hatches that were meant to close the
compartments.  Sailors tried to use fireaxes to cut through live power cables
in order to close the hatches, but to no avail: the valiant Gitarro sank to
the bottom of Mare Island Channel.

I don't know if anyone was killed or injured - I think not.  Damage was
mitigated somewhat by a quick thinking tugboat operator who saw the "sail"
starting to roll over into the water.  He rammed his tugboat up against the
sail and kept pushing against it until a floating crane was brought in the
next morning.  Even so, damage came to $30 million.

In another incident, the radioactive coolant water was being drained from a
reactor.  This submarine (not the Gitarro) was in drydock.  The usual
procedure is to cut a hole in the hull and run the water out a pipe into a
cement mixer.  The radioactive water is used to make cement and trucked to
Hanford, Washington (about 800 miles) for "disposal".

The pipe from the reactor reached out to the hull, where it was connected
via a flange to the pipe leading to the cement mixer.  Only one time they
forgot to bolt the flanges together; as the water was pumped out it showered
upon a shipyard worker walking on the drydock below.

I understand that the shipyard worker not only survived but was still working
at the shipyard during the '80s - but the clothes he was wearing at the time,
and the patch of drydock he was standing on at the time are buried at
Hanford.  Also, this fellow exceeded his lifetime allowance for radiation
exposure during this "hot shower", and is not allowed inside the nuclear
yard.

In still another incident, the above mentioned cement mixer was stolen by the
truck driver assigned to deliver the radioactive concrete to Hanford.  He was
caught - after he had used the mixer to pour a backyard patio at his house.

But wait, there's more!  The Navy contracted with a private manufacturer to
build a piece of equipment that would be installed in a room aboard a
submarine.  The Navy gave the manufacturer plans to this room.  When the
equipment was delivered, a hole was cut in the hull of the submarine, and the
equipment was lowered in by a crane.  Because submarines are very cramped
there was not much room and the designers used up every bit of available
space for their machine.  When it was lowered into the submarine, it was
found that this device did not fit!  The Navy made all sorts of accusation's
about the manufacturer's incompetence, but in the end it was found that the
manufacturer did meet the specifications; the Navy's mechanical drawing had
an error in which "1/2 inch" was written where "1/4 inch" was intended.
(Note that one of the factors that limits the life of a submarine is the
number of times holes have been cut in its hull.  After a while the hull is
weakened so much that the submarine has to be scrapped.)

And finally, a note about the circumstances in which I lived at the base, and
the importance of unambiguous language in giving commands.  I lived there at
the height of the Vietnam War, while my father was an instructor in the
antiaircraft missile school there.  I spent the third and fourth years of my
life living on a military base at the height of a war; I remember tanks
rolling by and trucks and trains loaded with bombs.  Being a small child I
regarded this with the wonder and curiousity any childhood would have for his
playground.

My parents sternly ordered me never to cross the street - but by walking some
distance down my street and crossing an open meadow, I could freely enter
the Marine Corps rifle practice range.  Being three feet tall, my friends and
I could easily walk unobserved in the culverts along the road.  I remember
watching the men firing their M16's, and one time I sat in a bunker below
the targets - one could lower a paper target into the bunker to replace it
or tally the score - watching bullet holes appear in the targets above.

The Marines did catch us, many times in fact, and always sternly warned us to
stay away, but they never did tell my parents.  I never felt I was doing
anything wrong as I did not cross the street.

I did cross the street once, though... and the next street beyond, and snuck
under the fence into the shipyard area itself, walking right past heavily
armed sentries - remember all the riots were happening in Berkeley just 20
miles away, so I'm sure they were on the lookout for saboteurs.  They just
didn't think to look for intruders that didn't reach up to their knees!  I
remember quite clearly looking up into the cranes used to lift heavy
equipment off of railroad cars, and all manner of heavy equipment that would
have ground a four-year old boy into hamburger.  [...]

Mike Crawford  crawford@scipp.ucsc.edu  crawford@maxwell.ucsc.edu


Re: FEC Voting "Standards" (Jones, RISKS-16.52)

Rebecca Mercuri <mercuri@gradient.cis.upenn.edu>
Mon, 31 Oct 1994 16:54:28 +0500
  [CC of message to Doug Jones,]

I was forwarded your E-mail, which was posted in RISKS on-line.  I wanted
to comment on a few errors in your message.

First of all, the FEC Voting "Standards" do not "mandate" anything.  These
are not standards, they are merely suggested guidelines. The guidelines are
just that because of "states rights." This is the right of states to have
certain choices in a variety of matters. There is precedent for the federal
government to mandate some things regarding voting. One of these is who can
vote (as in women, blacks, people over the age of 18). But currently the
federal government, although it oversees federal elections, does not MANDATE
any STANDARDS regarding voting machines. The FEC document you appear to have
been reading is just guidelines. Some of the states have adopted these
guidelines, and then they become a part of those states laws. But many
states have not.

Secondly, you should know that these FEC guidelines were created with
extensive assistance from voting machine vendors and other service
providers. It was in no way a balanced group. What I and others have tried
to point out in the years since the publication of these guidelines is that
there are already good STANDARDS for assuring accuracy and integrity in
computer-based systems. These standards are the "orange-book" system that
the federal government uses for other federally-used computation systems.
(Voting machines are exempt from the 1987 Computer Security Act and are not
required to conform to these standards.) Within these standards is a system
and organization for certifying secure systems at various levels. We would
hope that eventually states (or the federal government) would enact laws
that would bring voting machines into this system, and they could be
examined for conformity. The FEC guidelines fall far short of the NIST
standards, and we would like to see this changed.

I am not in any way suggesting that even the NIST standards would be
sufficient to ensure accurate and secure electronic vote tabulation.  I am
just mentioning all of this here, because you are misled regarding the
stringency of the FEC guidelines and of their application.

Rebecca Mercuri


No Real Risks of Seemingly Similar Interfaces

e.e. <carasso@inference.com>
Sat, 29 Oct 94 19:38:32 PDT
RISKS should be a forum for real risks, not pet peeves, not minor
inconveniences, not for harmless mistakes. I am amazed by the amount of
whining in this forum.

If you hit you Mac's power switch trying to eject your floppy, you obviously
just got your Mac, there's little of value on it, and it's unlikely that
anything damaging will *really* happen.  There is very little real risk.  You
are whining about a SELF-FIXING-PROBLEM.  You won't do it again.  And if you
do, it's called natural selection.  Stupidity is its own reward.

If you accidentally push a wrong ATM button and get out $40 when you didn't
mean to, there is NO RISK.  Just take the little envelope, deposit the $40
back in, and I'm sure you won't do it again.  And if you do, it's called
natural selection.  Stupidity is its own reward.

If these were nuclear warheads, municipal power stations, or something
important, fine.  Write about it.  But for Heaven's Sake, leave your whining
at the Gate.

roger


There are risks and then there are risks (ETS) (McEvilly, RISKS-16.51)

"Girls & Boys" <wex@media.mit.edu>
Sun, 30 Oct 94 14:52:04 -0500
Carlos McEvilly tells of his friend who was denied a semester at school
because of an interface problem with the computer-administered GREs.

While I sympathize with his friend's plight, it seems that blaming the test
administrators (ETS) seems too easy and too simple-minded.  As with other
cases, we should bear in mind that there is a system and a whole process in
place, with several opportunities for human intervention.

For example, the problem would never have been seen had the friend not
chosen to take the computerized version in order to give himself more study
time.  The risks of failure to plan in advance seem to apply here.

The college's use of the GRE score as a binary decision-making factor is
itself fraught with risks.  First off, ETS itself advises against this --
the risk of using a product in a way it was not intended to be used.
Second, my friends who are college professors all tell me that the best
predictor of how good a student someone will be is not a standardized test,
but rather the person's past performance as a student.

The college already had one semester's worth of evidence for this student's
abilities, but they ignored it -- the risk of not considering all the
evidence as well as the risk of ignoring the opinions of qualified experts.

I could go on, but let me just state my main point: We've all gotten to the
stage where when we hear a so-called explanation like "Pilot error" or
"computer error" we know to dig deeper.  We know that there are processes
involved, that there are opportunities for people to intervene, and that
focussing solely on one event/incident/problem tends to obscure other
possible causes.  But we continue to apply this kind of shallow analysis to
other situations.

In this case, while I can see the error in the ETS software as being a
contributory factor, I can hardly give it primary, let alone sole importance.

Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard  MIT Media Lab,
Intelligent Agents Group wex@media.mit.edu 617-253-9833 Pager: 617-945-1842


Re: Security screen (Bank fences, power keys, etc.)

"Dr. Frederick B. Cohen" <fc@netaxs.com>
Sat, 29 Oct 1994 08:29:18 -0400 (EDT)
    It seems to me that one of the risks of robbing a bank is getting
killed by the guards, the security system, or the people you are taking money
from.  I am not convinced that we should try to make robbing banks safe.

Re: On-Off Switch on Macs ...

    I don't really understand this issue at all.  It seems to me the
solution is not a better on-off switch, but a better operating system.  My
Unix box doesn't seem to need an on-off switch, but every DOS, Windows, and
MAC system I have ever seen can't get along without one.

Re: Pacemaker failure ...

    I appreciate that if my pacemaker fails, I will die, but I don't
understand why that justifies not using a pacemaker.  Without it, someone who
needs it will die with P=1.  With it, they have P=.001 or whatever.  We seem
to overlook the issues of cost and probability in the risks forum when it
comes to accidental risks, and frankly, this is a big mistake.

Re: CMU course on dependable system design ...

    The description sounds interesting, but it also sounds like it
ignores a great deal.  I think that one of the problems with universities is
what we expect of them.  It has taken me many years of full time effort to
gain the knowledge I have in the fields I explore.  In a university, you get
9 hours per week (if you work hard) for 15 weeks on any particular subject.
135 hours on dependability is admirable, but that's about the same as 2-3
weeks of experience (depends on how many hours you work per week) in the
field.  Still, as a leading complainer about the lack of attention to
information protection in our educational system, I should support the CMU
initiative.  The only problem I have with the course description is that it
seemed to ignore the malicious aspects of risks in favor of accidental ones.
Of course, we certainly have a lot of accidents to worry about.

Re: The risks of reading risks

    Somehow, the news reader on this system, (tin) seems to believe that
it is the only program users should ever run.  It takes about 15 minutes to
examine every news group that has ever existed, and after offering me a wide
selection of new ones I have not previously asked not to get, finally allows
me to read the risks forum.  Of course, this process cannot be interrupted
by the normal Unix interrupt character, and there don't seem to be options
to have it simply read the risks forum and leave me alone.  Perhaps this
should be a class project at CMU's new class on dependability.  While they
are at it, they should look at the Elm email system, which insists that I
answer the same questions every time I read mail, even though I always give
the same answers.  No, there is no way to default them - or at least I
haven't found one.


Re: More on backspace problems

Esther Filderman <moose+@CMU.EDU>
Fri, 28 Oct 1994 19:57:02 -0400 (EDT)
In RISKS-16.51 John Vilkaitis describes trying to get Netcom to understand
that his system is showing intermittent problems connecting to Netcom, and
that it is -not- failures of his "terminal software".  At the end, he
concludes,

>   The RISK of not fixing intermittent problems is having to increase your
> marketing budget.  Same for not understanding English.

Understandable, but I suggest that the more frightening RISK is the following:

> They then repeatedly tell me to put STTY ^H in my .login file,
  which they have already done WITHOUT my permission!

I will run the risk (no pun intended) of offending my fellow systems
administrators by saying that we all have heard horror tales of
"well-meaning" systems and/or support folks screwing up users by editing
their files without their permission, or without their understanding of the
changes.  They're generally making more work for themselves.

             Esther Filderman    moose+@cmu.edu
  System Mangler  Library Automation  Carnegie Mellon University


NETCOM Backspace Problem ["terminal software"] (javilk,RISKS-16.51)

Russell Stewart <diamond@RT66.com>
Mon, 31 Oct 1994 14:17:49 -0500
  > Our technical support staff has diagnosed this kind of problem
  > innumerable times.... it is in our opinion clear [?] that any
  > remaining problem is the fault of your terminal software.

  "It can only be attributable to human error."   -HAL 9000

Russell Stewart  Albuquerque, New Mexico    diamond@rt66.com


CAPS-LOCK considered harmful

Paul Barton-Davis <pauld@cs.washington.edu>
Fri, 28 Oct 1994 17:07:20 -0700
bart@cs.uoregon.edu (Barton C. Massey) writes of various problems with
CAPS-LOCK. There's another, even more infuriating problem that CAPS-LOCK has
a risk of creating, and already has on certain keyboards.

Under the X Window System, it is possible to remap the keyboard in any way
you choose. This includes getting rid of CAPS-LOCK altogether, or so you
might hope. I do this routinely to deal with some of the problems Barton
mentioned, by mapping it be just another control key.

This works fine at work, on a DEC keyboard. When I get home, however,
there's a problem. The keyboard on my NCD X terminal considers the "lock"
attribute of this key to be a hardware feature, and thus regardless of what
I map it to under X, it always behaves like a CAPS-LOCK in terms of latching
and unlatching. Since I map the key to be a control key, you may be able to
imagine my frustration when I accidentally press the key and find that my
emacs-editing-supported shell goes haywire as I try to type alphabetic
characters. It sometimes take me quite a while to realize why nothing I type
works.

One day, I'll figure out a better way to remap it. In the meantime, even if
we're stuck with CAPS-LOCK, please hardware types: don't make the latching
feature a function of the keyboard electronics, but leave it software
controlled, where if its broken, some of us can fix it.

-- paul barton-davis     UW CS Laboratory


Follow up to CAPS-Lock and MS Natural Keyboard (Massey, Alvarez)

P. Kevin Parker <kparker@chaph.usc.edu>
28 Oct 1994 17:17:44 -0700
Interesting that these two posts should appear one after the other:
> CAPS-LOCK Considered Harmful (Barton C. Massey) <bart@cs.uoregon.edu>
> Microsoft Natural Keyboard (Don Alvarez) <dla@cmbr.phys.cmu.edu>

The RISK of the CAPS-Lock is eradicated--in Windows only--by this keyboard.
Using the software provided by Microsoft, a user can disable CAPS-Lock
entirely.

P. Kevin Parker  kparker@scf.usc.edu  kparker@eis.calstate.edu


CAPS-LOCK Key Harmful?

<rcook@BIX.com>
Sat, 29 Oct 1994 02:29:53 -0400 (EDT)
While I can sympathize with the contributor who dislikes the CAPS-LOCK key
(my own keyboard has it placed cleverly just to the left of the space bar --
sure-fire sabotage), I'd like to point out that there is a growing group of
people for whom it is vital. Those are the people who don't have the
physical ability to press two keys at once.

For that reason I think CAPS-LOCK is a Good Thing and should remain standard
on keyboards.

--Rick Cook  rcook@bix.com

   [There are other cases as well, for example, in programming languages that
   REQUIRE UPPER CASE, as noted by Brian T. Schellenberger, bts@unx.sas.com,
   who also notes the problems caused by the absence of a CAPS-LOCK indicator.
   PGN]


RE: CAPS-LOCK Considered Harmful

Phil Keys <100213.1013@compuserve.com>
29 Oct 94 05:55:03 EDT
On 10/25, Bart Massey posted an article on the risks associated with the use
of the CAPS-LOCK key on a keyboard & challenged manufacturers to come up with
a better method.  Whether it's better or not can be debated, but in Japan, AT
compatible machines running bilingual (Japanese/English) DOS (called DOS/V)
have adopted a convention where, to toggle the CAPS-LOCK key, you have to
press both the Shift key & the DOS/V key at the same time.  Personally, I
don't like this since it forces you to remove your hand from the keyboard to
toggle CAPS-LOCK, but, it does make it less likely that you will toggle
CAPS-LOCK by mistake, thus reducing this risk.

Just thought I'd let you know that at least somebody, somewhere has been
thinking about this issue too.

Phil Keys [and appropriately named for this discussion, too!  PGN]


Re: CAPS-LOCK Considered Harmful (Massey, RISKS-16.51)

Doug Siebert <dsiebert@icaen.uiowa.edu>
30 Oct 1994 21:53:34 GMT
NeXT did this right in at least the revision of the keyboard I have on my
color slab.  The command key held down while hitting the shift key toggles
caps lock on/off (and toggles the LED that is in both shift keys)  That way
the control key can be in the IMHO correct place, left of the 'A' key.

Doug Siebert   dsiebert@isca.uiowa.edu


Re: AOL (RISKS-16.51)

Greg Lindahl <gl8f@fermi.clas.virginia.edu>
Sat, 29 Oct 1994 16:01:55 -0400
>  I presume the newsgroup stuff ages just as rapidly [as E-mail].  PGN

Actually no -- it seems to stay for months, so you'll see AOL users restarting
month-old flamewars by responding to something that's expired everywhere else.

  [Ah, that suggests virtual time travel and multiple virtual realities.
  Deja vu all over again.  PGN]


Re: America Online Offlines America

Mike Crawford <crawford@scipp.ucsc.edu>
Sat, 29 Oct 1994 23:08:14 -0700
An official from AOL was quoted in the San Francisco Chronicle Business
section today, 29 Oct 1994, denying that AOL was losing mail.  This fellow
(might have been the president, I'm not sure) went on to invite the Internet
Community to "flood" AOL with mail.

Now, it's one thing to shoot your own self in the foot, but inviting the net
to spam AOL.com in the national press is likely to have the added effect of
overloading all the routers from here to there.

I'd like to suggest that the folks at aol ought to think twice before saying
such things.

Mike Crawford  crawford@scipp.ucsc.edu  crawford@maxwell.ucsc.edu


Re: AOL Offlines America (RISKS-16.51)

<RichWells@aol.com>
Sun, 30 Oct 1994 12:57:12 -0500
It appears to be the Macintosh AOL software that has the 22K limitation on
messages which prevents seeing an entire issue of Risks at one time.  Even
so, the entire issue can be read; you just cannot keep more than about 22K
of it around at one time.  This has the unfortunate consequence that you
have to stay on-line for the time it takes to read it, rather than saving it
to a file and reading it later off-line.  The Windows AOL software does
allow one to read the entire issue at one time, and to save it to a file for
later reading.

  [Stuff on deletion deleted.  Also, clarification that comp.risks
  came up at the same time as other newsgroups on AOL.]

AOL's newsgroup access is indeed limited (note that I had to edit the subject
heading to abbreviate America Online!), but it's not quite as bad as your
postscript made it sound.   [TNX.  PGN]


Re: Half a degree is better than none? (Brader, RISKS-16.49)

<cjackson@adobe.com>
Sat, 29 Oct 1994 02:08:01 GMT
  }Or rather, it tries to.  Somehow, wherever the character 1/2 is
  }supposed to occur, instead there is a degree sign!

As Mark Brader, the poster of the above, can intimately attest from the work
of both of us in certain international standards committees, this is a
primary area of concern when one is defining standards for font use and
especially font/glyph substitution. Our classic example in our ISO committee
was of the American who sends in a bid on a bit of business in the UK, only
to have his electronically-transmitted bid (these are the fast-moving '90s,
after all) printed out with the '$' replaced by the UK pound symbol. Quite a
hefty automatic bid increase, that one.  Curtis Jackson
cjackson@mv.us.adobe.com

Please report problems with the web pages to the maintainer

Top