The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 4 Issue 38

Thursday, 8 January 1987

Contents

o As the year turns ...
Jeffrey Mogul
o Automobile micros
Hal Murray
o Chemicals in semiconductor manufacturing
Michael Scott
o Cellular -- Ref to Geoff
via PGN
o "Misinformation"??
Dick Karpinski
o Burnham Book -- A Recommendation
Alan Wexelblat
o Engineering Ethics
Dan Ball
o Re: Stock Market Volatility
Richard A. Cowan
o Info on RISKS (comp.risks)

As the year turns ...

Jeffrey Mogul <mogul@decwrl.DEC.COM>
8 Jan 1987 1846-PST (Thursday)
A number of sites, including my own, have special receivers for the time
signal transmitted by the GOES satellite; the time information comes from
the National Bureau of Standards, and with a properly adjusted setup you can
set your computer's clock to with a few milliseconds.  Since the clocks are
somewhat expensive, many hosts instead slave their clocks to one of the
hosts endowed with its own satellite receiver.

The data stream from the NBS tells you what time of day it is, and what day
of the year it is, but it does not say what year it is.  The usual practice
is to assume that the local host knows what year it is, and to get the
correct time you combine the satellite clock's time-within-year with your
local knowledge of the year.

Needless to say, this doesn't quite always work.  Mostly, it tends
to not work on New Year's Eve, when many of us would rather not be
fixing our computers.  Dave Mills does a great job keeping a bunch of
clocks running, on which many other hosts on the Internet depend.  This
is his message from early on January 1st:

  From: mills@huey.udel.edu
  Subject: Ask not for whom the chimes tinkle
  To: tcp-ip@sri-nic.arpa, nsfnet@sh.cs.net

  Folks, Every year it's the same - I forget UT midnight comes five hours
  before the ball drops in Times Square. For an hour and sixteen minutes after
  the hoot and holler in Trafalgar Square at least four radiofuzz timetellers
  still squawked yesteryear.  DCN1, UMD1, FORD1 and NCAR springs have now been
  rewound to 1987 and all you guys can forget those whopping disk-usage
  refunds. Thanks to Hans-Werner Braun, who reminded me of my annual first
  duty of the new year and annual first resolution to figure out how to avoid
  paw to keyboard in the absence throughout the world, as far I know, of a
  highly reliable electronic way to find out what year it is.

It turns out that as recently as today, several Internet sites are still
stuck in 1986, apparently as a result of the efficient distribution of
faulty time information.

Meanwhile, I thought I had foreseen all eventualities and fixed the
program used here at DECWRL, so that as the year turned it would avoid
becoming confused.  The important thing is to be sure not to try to
set the time during a period where the satellite clock thinks it is one
year and the local clock thinks it is a different year.  Needless to
say, I got this part wrong, and our clocks promptly jumped ahead exactly
one year.  I found at least two bugs in my code, but I still don't
completely understand what went wrong, and I'm sure something is going
to go wrong again next year.

I guess the lesson is that it is wrong to assume that the least
significant bits are the hardest to get right.  (One reader of
TCP-IP told of how he had to use a similar year-less time format
when designing a missile-tracking system 20 years ago, and had
to put in special logic to be sure that the system could survive
the confusion on New Year's Eve.)  Now, if I could only make it
through January without writing "1986" on any checks.


Automobile micros

<Murray.pa@Xerox.COM>
Thu, 8 Jan 87 12:31:37 PST
Our hero, Joe, works for one of the "big 3" automakers near Detroit, that
strange corner of the US where everybody a late model American car.  One day, 
Joe was calmly driving down the highway, accelerating gently, when his car
stuttered a bit. It wasn't a big deal. Most people probably wouldn't have
noticed it. However, Joe's job was programming the small computer that controls
the gas and timing for car engines, so he this behavior caught his attention.

When Joe got to work, he popped the cover off the computer in his car and
took the main chip into the lab. After a bit of work, he managed to
reconstruct the necessary input conditions, and sure enough the glitch was
real. Happy that he had tracked down a minor problem in has car, Joe prowled
around the lab for replacement chip. It didn't take long to find one.

Rather than just installing the new chip in his car, Joe decided to try
it in his test rig. You guessed it, the "good" chip had the same
problem. So did several others - all the ones he found to try.

The story ended there. My guess was a PROM bug, but I didn't get that
from the horses mouth.

Speaking of risks, the first time that GM does a major recall because of
software is going to get a lot of publicity. I'll bet much of it will be
mud for the computer profession rather than teaching the public about
the realities and economics of software.


Chemicals in semiconductor manufacturing

Michael Scott <scott@rochester.arpa>
Thu, 8 Jan 87 15:12:22 est
Several submissions recently have concerned the risks of miscarriages
and other health problems associated with semiconductor manufacturing.
For anyone interested in the subject, I highly recommend the cover
story of the October 1985 issue of the Progressive magazine: "Dead End
in Silicon Valley" by Diana Hembree.  Where recent attention has
focussed on IC fabrication, the Progressive article is mainly about PC
board assembly, where low-paid semi-skilled workers, mostly women, are
reportedly exposed to large numbers of toxic, allergenic, and carcinogenic
chemicals, with a shocking array of side effects.  To obtain background
information, Hembree took a job for four months as an assembler at Q.E.S.
Corp. in Santa Cruz.  Her story makes pretty grim reading.


Re: re: Cellular -- Ref to Geoff

Peter G. Neumann <Neumann@CSL.SRI.COM>
Thu 8 Jan 87 11:28:30-PST
I had several queries about how could one possibly spoof the cellular phone
system?  Some of you will recall the earlier contribution from Geoff
Goodfellow in RISKS-3.10 noting that it is indeed utterly trivial to change
your ID.


"Misinformation"??

Dick Karpinski <dick@ccb.ucsf.edu>
Thu, 8 Jan 87 17:24:30 PST
In RISKS DIGEST 4.37
  Stock Market Volatility (Randall Davis)

>Date: Wed 7 Jan 87 12:23-EST
>From: Randall Davis <DAVIS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
>... 
>4) There's risk in incorrect and incomplete information; there's
>computer-related risk when that information is widely disseminated
>electronically: 
>    the British telephone billing scam that apparently wasn't; 
>    the automated bibliographic retrieval system that required keywords 
>    in the article title (only it didn't);
>    ...
>We should be particularly aware of this misinformation risk since it is 
>entirely under our control.

I don't recall being satisfied that there was no British phone scam.
What was it that convinced you?

   [It is altogether possible that BT is covering up.  On the other hand,
   their description of the system (by phone, to me) stated that the
   READ-AFTER-WRITE check is properly implemented and that there are three 
   other checks as well.  They claim that the Sunday Post will print a
   retraction.  (As yet no one has reported seeing it.)  Of course, there
   may be still be other vulnerabilities.  RISKS readers are learning to look 
   the proverbial gift horse in the mouth, as well as the horse you had to
   pay a fortune for.  PGN]

The bibliographic retrieval system is worse that had been alleged in
the 29 Sep 86 Risks 3.70.  It is not a "new policy" according to one
Paul Ryan of the DTIC in 4.23, but a limitation of their software.
But the fact is that only the first five words (including articles 
and prepositions) of titles are involved in automatic searches.  This
strikes me as an unconsciencable restriction to be removed as soon
as practicable.  I would certainly hesitate to count on such a 
system.  For example, Parnas' seminal CACM article on modularity
("On the Criteria to be Used in Decomposing Systems into Modules")
would only show up in searches for "On", "the", "Criteria", "to",
and "be".  What a travesty of search, retrieve, and help!

    ["To be or not to be..." would show up even more dramatically!  PGN]

"We should be particularly aware of this misinformation risk since it is 
entirely under our control."

How can I offer to help these poor souls correct (improve) their
shabby software?  How else but by discussing these problems can we
become informed about the sad existing conditions?

Dick Karpinski  Manager of Unix Services, UCSF Computer Center
UUCP:  ...!ucbvax!ucsfcgl!cca.ucsf!dick        (415) 476-4529 (11-7)
BITNET:  dick@ucsfcca or dick@ucsfvm           Compuserve: 70215,1277  
USPS:  U-76 UCSF, San Francisco, CA 94143-0704   Telemail: RKarpinski   


Burnham Book -- A Recommendation

Alan Wexelblat <wex@mcc.com>
Thu, 8 Jan 87 10:40:59 CST
Some time ago, Dave Taylor (on mod.comp-soc) recommended a book called "The
Rise of the Computer State" by David Burnham.  I have purchased this book and
hereby recommend it to RISKS readers.  Burnham is an investigative reporter,
so the book tends to have a bit of a sensationalistic streak, but it is very
interesting and covers many topics of interest to RISKS readers.  The edition
I have is softcover, published in 1984 by Vintage books for $6.95.  It's 
ISBN 0-394-72375-9.

People like PGN who collect RISKS-anecdotes may be interested in some of the
stories he tells (like the part played by punch-cards in the 1942 roundup of
Japanese-Americans).

Alan Wexelblat
ARPA: WEX@MCC.ARPA or WEX@MCC.COM
UUCP: {seismo, harvard, gatech, pyramid, &c.}!ut-sally!im4u!milano!wex


Engineering Ethics

ball@mitre.ARPA <Dan Ball>
Thu, 08 Jan 87 11:29:37 -0500
The discussions concerning engineering ethics in RISKS 4.36 and 4.37
overlook what I think is a far more critical contributor to modern
engineering disasters than the personal ethics (or lack thereof) of
individual engineers: the organizational environment in which engineers
must function.

Large engineering projects involve many thousands of engineers, and the
time required to complete them has stretched, in many cases, to over
twenty years.  In this environment, it can be difficult for an individual
to feel any personal responsibility for the outcome of the overall project.
Most of the engineers I know are neither "demented" nor "morally wicked."
They are just trying to do their job in the midst of a bureaucracy where
authority is diffused and decisions are made by committee.  It is to be
expected that short-term expediency will usually prevail, particularly
when it is difficult or impossible to assess the long-term consequences
of a decision.

The organizational dynamics involved in the development and operation of
safety-critical systems and their effect on the individuals concerned are
submit, far more important than the contemplation of Cicero's ethics.

Although I don't consider Dick Karpinski a "barbarian beast", I question
whether assigning a monetary value to human life would provide additional
insight into the management of risks.  I am not convinced that we know
how to predict risks, particularly unlikely ones, with any degree of
confidence.  I would hate to see a $500K engineering change traded off
against a loss of 400 lives @ $1M with a 10E-9 expected probability.
I'm afraid reducing the problem to dollars could tend to obsure the
real issues.

Moreover, even if the analyses were performed correctly, the results could
be socially unacceptable.  I suspect that in the case of a spacecraft, or
even a military aircraft, the monetary value of the crew's lives would 
be insignificant in comparison with other program costs, even with a
relatively high hazard probability.  In the case of automobile recalls,
where the sample size is much larger, the manufacturers may already be 
trading off the cost of a recall against the expected cost of resulting
lawsuits, although I hope not.

Clearly, though, those of us concerned with safety need to find some
way of seeing that risks are effectively managed in large projects.
It is not enough to act as a perpetual doomsayer standing in the way
of progress.  To be effective, safety engineers must be perceived as
helpful and participate in the mainstream of the design activity.


Re: Stock Market Volatility

Richard A. Cowan <COWAN@XX.LCS.MIT.EDU>
Thu 8 Jan 87 20:31:27-EST
Randall Davis makes the important point that stock market trading
really isn't any more volatile now than before.  I agree.

Computers have enabled the VOLUME of trading to go up (probably to a
level where much of the speculation serves no useful economic purpose
to non-speculators), but this does not seem to automatically insure
stock market volatility.  Even if computerized trading becomes more
widespread, I would think that any aberrant trades would be quickly
corrected the next day as long there remains some human input into the
trading process.  Yet I still see a potential effect.

A book I once read on the Stock Market crash of 1929 noted that in
times of potential panic, large traders would attempt to shore up the
market by buying, to restore confidence in the market.  It's possible
that the stability of the present market has a lot to do with this
type of activity.  But such "feedback" -- applied by large banks and
brokerage firms -- would not in the foreseeable future be applied
automatically by computer, because the decisions involve analyzing
political events and the psychological mood "on the Street."

If there currently exists a human rudder smoothing the path of the
stock market, I can see why investors might be concerned about
programmed trading.  This practice does not run the risk of a
computerized avalanche of domino trades which will drive the market
1000 points up or down in one day.  But it may interfere with the
ability of large investors to use their resources as a rudder, in the
event that trading does become volatile for economic reasons.

It is easy to see why the programmed trades get media attention.  On
the "triple-witching-hour" days, human beings will have less control
and the market may do unexpected things.  If these events are not
announced and explained before they occur, the movement of the market
may set off an avalanche of HUMAN panic selling.  Of course, this
would only occur if the preconditions existed were met -- if the
market were viewed to be overvalued, relative to economic performance.

It is true that the news media sensationalizes and often fails to put
stories into historical context; they may seem to enjoy blaming
technology.  But consider the motivations of the people from whom the
business press usually get their stories: people in the financial
community.  They may find technology a convenient scapegoat for any
problem with the stock market, especially if they have contributed to
setting up the conditions of an overvalued market.

Perhaps the market hasn't reached the point where it is overvalued.
But consider that the head of the MIT Department of Electrical
Engineering and Computer Science, in an open forum on US
competitiveness with Japan last February, said "I think we're going to
have a depression."

Lester Thurow and several other economists are now making frequent
comparisons to 1929, pointing out when large investors finally lost
confidence in the ability of the market to sustain a continued rally
or plateau, they all raced to pull out.  Anyway, the point is that
computers will not cause a crash, but could set off a crash that is
bound to occur anyway, and be wrongly blamed for it.

Of course, it is possible that there might not be a crash at all!
When US investors sell, foreign investors will buy up all our stock
and we'll be owned by the Japanese!            :)
                                                        -rich

Please report problems with the web pages to the maintainer

Top