The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems


Volume 11 Issue 07

Saturday 9 February 1991


o Study links leukemia to power lines, TV's
Martin Minow
o A note on electromagnetic fields
Martin Minow
o City in Turmoil
Pete Mellor
o Re: the new California licenses
David Redell
o Re: automatic flight and seasickness
Charles Bryant
o Building very reliable systems
Jerry Leichter
o Re: Predicting System Reliability...
Bruce Hamilton
o Electronic traffic signs endanger motorists...
Lars Henrik Mathiesen
o Newborn security system
Eric Postpischil
o Request for info on UNIX viruses
Tom Brendza
o Info on RISKS (comp.risks)

"Study links leukemia to power lines, TV's"

"Martin Minow, ML3-5/U26 09-Feb-1991 0946" <>
Sat, 9 Feb 91 06:56:52 PST
>From the Boston Globe, Sat. Feb 9, 1991 (page 21, under the obituaries):

Study links leukemia to power lines, TVs (Lee Siegel, Asociated Press)

Los Angeles - Children may face twice the risk of getting leukemia if they live
near power lines, frequntly use hair dryers or watch black-and-white
television, says a study sponsored by electric utilities.  The findings offer
"considerable support for a relationship between children's electrical
applicance use and leukemia risk," said a summary of the study by the
University of Southern California.

The University of Sourthern California study of 464 Los Angeles County children
age 10 and younger is considered important because it was financed by the
Electric Power Research Institute, which had been skeptical of earlier studies
linking cancer to magnetic fields.  The study found children who lived closest
to neighborhood power lines were up to 2 1/2 times more likely to suffer
leukemia.  Frequent use of hair dryers and black-and-white televisions also
increased leukemia risk.

   That's the entire article -- does anyone have more information?
   Martin Minow

A note on electromagnetic fields (and an epilog on cashless society)

"Martin Minow, ML3-5/U26 08-Feb-1991 1429" <>
Fri, 8 Feb 91 11:36:03 PST
The "risks of electromagnetic radiation" has a new, interesting, champion:
Wayne Greene, publisher of 73 magazine (and the founder of Byte Magazine).
He points out that amateur radio transmitters (especially when used by
Morse code enthusiasts) generate electromagnetic fields that seem to
match some of the more biologically active fields under study.  While
Greene isn't a scientist, he appears to be a reasonably competent
electrical engineer.  His editorial is in the current issue of 73 magazine.

If it hasn't been mentioned already, the "cashless society reading list"
ought to include John Bruner's "The Shockwave Rider."

Martin Minow

City in Turmoil

Pete Mellor <>
Fri, 8 Feb 91 18:37:00 PST
Infrastructure Collapses - 1000s of civilian casualties.

Is it Baghdad under Tomahawks and laser-guided bombs?

Is it Tel Aviv under SCUDs with nerve gas warheads?

NO! It's London under 6 inches of snow!

If Saddam Hussein could have delivered this lot, he'd be well pleased!

Once again, the Dunkirk spirit is to the fore, as the courageous inhabitants of
this plucky little island, once one of the bastions of civilisation, leaders of
the industrialised west [That's enough nauseating cliches! Get on with it! -
PM.], cope with a disaster the scale and magnitude of which is unparalleled in
the history of mankind, or even in the history of Network South-East, since at
least 1984.

The unsuspecting British were caught completely unawares by the sudden drop
in temperature last night, to the previously unheard of level of -2 degrees C.
The only warning that the authorities had was a brief announcement from the
Met. Office a mere 5 days ago that things were going to get " cold as
a Polar Bear's packed lunch".

Taken by surprise, all the major services collapsed one by one. Trains ground
to a halt as they ploughed into snow drifts, which, in places, reached depths
of almost 2 inches. Traffic skidded on the roads as gritting and salting
services, with no practice in dealing with such a major catastrophe for at
least 2 years, were stretched to the limit.

Telephone services were jammed by businessmen ringing up City University to say
that they could not make it to urgent appointments with software reliability
lecturers because it was impossible to get from Stevenage to London. In the
city itself, those who had not fled at the first sign of snow, got tanked up at
the Pheasant and Firkin and tried to get what sleep they could across two
chairs in their offices, expecting any moment to be hit by one of the
"Snowball" missiles raining down outside.

Normal life seems to have disappeared for ever. Today, students sat in
classrooms with no lecturers. The few lecturers who didn't get home last night
found their classrooms empty, because the students had assumed that lectures
would be cancelled and gone out to build snowmen in Northampton Square.

The fearsome dictator of the regime, John el Major, appeared on television to
rouse the population to new frenzies of resistance. In one speech, he went so
far as to declare: "Yes, it is a bit chilly. I advise everyone to wrap up

Defence analyst Brig. Gen. (Ret'd) Sid Spotty said in interview:
"Of course, the apparent total devastation does not mean that the British
haven't got a lot still in reserve. There must be a lot of logic bombs still
hidden in bunkers. It's amazing how a technologically unsophisticated nation
can still keep their software going in the face of overwhelming bombardment.
I could illustrate what I mean, but the last power cut ****ed my fixed disk."

  [This is Pete Mellor, RISKS network, London, Friday. (The last lecturer left
  in City University before the central heating goes off.)]

Re: the new California licenses (RISKS-11.04)

David Redell <>
Fri, 8 Feb 91 10:48:06 PST
In RISKS 11.04. Mark Gabriel writes:

> I don't see what the privacy problem is here...  If you'll give your
> driver's license to a clerk, you should be prepared to have the clerk
> copy down all of the information on that license.

As I understand his argument, it boils down to:

  There's no reason to distinguish between:
    what a clerk may see,
    what a clerk may write down,
    what a clerk may enter in a computer

Two observations:

1) There can be good reasons for distinguishing between what is seen
   and what is recorded.  Often this principle is applied to mechanical
   recording (e.g. there are many situations in which you may listen
   to a phone conversation but may not record it) but even if the
   recording is manual, there can be good reasons for making the
   distinction.  For example, recent California legislation (effective
   1/1/91) prohibits the practice of writing down credit card numbers
   on checks as ID verification.  A clerk can still ask for a credit
   card as ID, but is not allowed to copy down the information from
   the card.

2) There is an important difference in effort between manually copying
   down information and swiping it through a magstripe reader.  (After
   all, if there weren't, the state wouldn't be going to all this
   trouble to issue magstripe licenses.)  Currently, if you pay by
   check, you greatly reduce the likelihood of your purchasing habits
   ending up in the kind of database described by Mary Culnan in RISKS
   11.06.  Using a magstripe driver's license for check ID will make
   it significantly easier for the merchant to pull together online
   information about you and your purchases.  (Of course, it would be
   possible for the clerk to type in the information manually, but the
   extra effort is enough to represent a qualitative change in

Dave Redell, DEC Systems Research Center

Re: automatic flight and seasickness

Charles Bryant <>
Wed, 6 Feb 91 18:40:08 GMT
In risks 10.83 "Olivier M.J. Crepin-Leblond" <>
quotes from "Le Figaro" concerning computer-controlled low level flight:

>  Unfortunately, the actual pilots cannot stand this type of passive flight.
>Not because by vanity, but because they tend to get sick...

Surely this is not because the plane is not controlled by the pilot, since
there are two-seater aircraft in use where both crewmembers are expected to be
alert when they reach the target. It must be some characteristic of the motion
which is different when a human is in control.

Charles Bryant (

Building very reliable systems

Jerry Leichter <>
Fri, 8 Feb 91 10:28:45 EDT
There have been a couple of notes on RISKS of late on the problem of building
very reliable systems - say, for the sake of discussion, those for which we
have some good reason to believe that the probablity of failure is less that
1 in 10^8.  The general problem is hardly new to computer systems, and really
there are only two techniques in existence that can give you this kind of

    1.  Testing (whether by explicit test in a lab or by actual use in
        the field) of very large numbers of copies of the system
        at issues.  This is the approach that most of the previous
        notes have mentioned.  That such an approach is being used is
        often clear when you see people talking about things like
        "aggregate experience hours".  The theory here is that running
        100 units for 100 hours apiece gives you the same information
        as running one unit for 10,000 hours.  Reliability of reactors
        is often argued in these terms; for items in mass production,
        where there may be hundreds of thousands if not millions of
        copies, "aggregate experience hours" mount very rapidly.

    2.  Functional decomposition of the system into a number of modules
        such that failure can occur only when ALL the modules fail.
        If there are three modules each of which has a probability
        of failure of 1 in 10^3, the system as a whole has a proba-
        bility of failure of 1 in 10^9 - extremely reliable.  Making
        modules that assured failure probabilities in the 1 in 10^3
        range is relatively easy.  SDIO always uses arguments of this
        form - "defense in depth" is an informal notion of the same
        thing.  An article in the New York Times this Tuesday talked
        about missile defense systems, and showed five successive
        layers.  Even if each layer misses 10% of the incoming
        targets, after five layers only one target in 10,000 makes it
        through - reliable enough to stop almost any conceivable
        attack.  This technique is, of course, also used in reactors
        in the form of multiple redundant safety systems.

Now, the criticism of technique 2 is that the multiplication of failure proba-
bilities is only valid when the failures of the different modules are known
to be uncorrelated.  There are many classic examples of lack of independence,
as for example in the fire that destroyed all the cables for several "indepen-
dent" reactor safety systems (at Brown's Ferry?).  In the software community,
technique 2, under the name of "n-version programming", has been sold as a
way to build reliable software:  Just run multiple independently-written
versions of the same software in parallel.  Unfortunately, Nancy Levenson and
others have shown that the "independently-written" versions cannot be assumed
to have independent failure modes.

So, is technique 2 worthless?  By no means:  It's just often misapplied.  To
use it, you need to establish (by formal techniques, testing, experience in
the field) not just the failure rates for the individual modules, but an
upper bound on failure correlation among modules.  This is by no means impos-
sible to accomplish.  For physical systems, it is often assumed (with little
real "proof") if the modules involved are physically far apart, and especially
if they are based on different physical mechanisms - e.g., a gasoline motor-
generator set as a backup for the main power grid, which in turn is driven
by multiple power sources scattered over the countryside, using a variety of
very different energy sources.  Things get much harder when the modules have
to be packed closely - correlated failures are much more of an issue in an
airplane than on the overall road system of a city.  The "different physical
mechanisms" idea doesn't translate easily to software (though the fifth
shuttle computer, using different hardware, is pretty close).  n-version
programming was a good idea, though it neglected this piece of the technique.
That's not to say that some still-unknown variant of n-version programming
can't be made to work.  In fact, I'd guess that it can be, though it won't
be easy - and I certainly wouldn't want to propose a mechanism.  If so, then
software systems to which we can reasonably ascribe "1 in 10^9" failure
probabilities should be quite buildable.

It's also worth pointing out that technique 1 ALSO relies on an assumption
- often unstated, rarely proven in any sense - that failures across copies of
a system are uncorrelated.  The fact that 100,000,000 digital watches have
calculated the date correctly for the last 5 years tells us nothing at all
about the probability that they will all decided incorrectly whether 2000 is
a leap year.  In general, technique 1 can let you make predictions about
reliability in the presence of external circumstances that occur fairly
frequently (e.g., wear over time); they can tell you nothing about design
flaws dealing with extremely rare circumstances.  Ten thousand "reactor years"
of experience in and of itself tells us nothing about what will happen if
a plane crashes into a containment dome.  (On the other hand, we have hundreds
of thousands of "experience years" with steel-reinforced concrete shells.)

In fact, techniques 1 and 2 are fundamentally the same thing:  One cuts the
world "vertically" between many complete copies of the same system; the other
cuts the system itself "horizontally" across its components.  The same two
issues - reliablity of the individual slices; independence of failure modes -
occurs in both cases.  Either technique can be used to get believable failure
estimates in the 1 in 10^8 (or even better) range.  Such estimates are never
easy to obtain - but they ARE possible.  Rejecting them out of hand is as much
a risk as accepting them at face value.
                            -- Jerry

Re: Predicting System Reliability...

Fri, 8 Feb 1991 10:23:01 PST
Re: " test hundreds or even thousands of units, all in parallel.  This is
how a disk drive manufacturer can say something like "50,000 Hours Mean Time
Between Failures" -- you didn't think they actually had a single drive that
they tested for 50K+ hours, did you?  I would go so far as to say that no well
known drive manufacturer today has a single drive with 50K hours on it"

I'm no M.E., but it's absurd to suggest that any mechanical system can be
meaningfully tested in parallel.  Fatigue, friction, dust accumulations, etc.
occur as a result of cumulative loads on a single system.

I can't speak for disk drives, but Aviation Week often talks about how one
airframe of each new type is used for fatigue testing, undergoing thousands of
repeated pressurize/depressurize cycles.

--Bruce     BHamilton.OSBU_South@Xerox.COM     213/333-8075

Electronic traffic signs endanger motorists...

Lars Henrik Mathiesen <>
Fri, 8 Feb 91 19:33:45 +0100
>I can only
>imagine what we are going to see happen when they start displaying things like
>"LEFT LANE BLOCKED, USE COLLECTORS AHEAD" and 700 motorists first slow down to
>read this and then try and pull over to the two rightmost lanes in order to
>exit off that section of the highway.

I have seen a similar system in use in Belgium or the Netherlands; there,
however, they know enough to limit the information to a few bits. Each lane has
a square display that can show symbols for "go ahead", "don't use this lane",
lane changes (to warn of upcoming closed lanes) and speed limits; the first two
are color-coded (green and red, of course).

The displays stand at intervals of 1/2 to two miles, closest around exits etc..
Since they are visible at a distance of at least 1/2 mile, nobody has to slow
down or think. There were a fair amount of roadworks at the time I was there,
and the system really helped the traffic flow.

>From what pictures I've seen, the amount of text on North American traffic
signs would strike a European traffic engineer with horror.  I'd think that it
all only works because most drivers are commuters who don't really need to read
the signs.

The RISK of the Toronto system is that the computer system can confuse
everybody in a new way every day.

Institute of Datalogy -- we're scientists, not engineers.

Newborn security system

"Always mount a scratch monkey. 08-Feb-1991 0832" <>
Fri, 8 Feb 91 07:36:21 PST
The following is from the Nashua, New Hampshire, _Telegraph_, by Denise Lavoie
of Associated Press, entitled "Hospitals using electronic security to protect

     Retailers use them to keep shoplifters from walking off with their
     merchandise.  Now hospitals are using electronic security devices to
     protect a more precious commodity:  newborns. ...

     St. Francis Hospital and Medical Center in Hartford quietly installed
     an electronic surveillance system after a woman kidnapped a
     16-hour-old baby from a maternity ward two years ago.  The girl was
     found unharmed 12 hours later.

     Abington Memorial Hospital in Abington, Pa., has one of the more
     elaborate systems.  There, the infant bracelets trigger an alarm and
     automatically turn on a video camera that records an abduction.

     St. Joseph's Medical Center in Wichita, Kan., normally uses the
     sensitized wrist bracelets, but has experimented with sensitized tags
     that are sewn into babies' clothing, and sometimes, their diapers. ...

     The costs of the systems vary, depending on how sophisticated a
     hospital wants to get.  Some hospitals want a system that triggers an
     alarm, turns on a video camera, and even locks the doors and
     elevators, [Sam] Shirley [of Sensormatic Electronic Corp.] said. ...

Automatic door locks is obviously a disaster waiting to happen -- imagine the
plight of people in a fire who realize they can leave but they cannot take the
babies with them.
                -- edp (Eric Postpischil)

request for info on UNIX viruses

Tom Brendza <tomb@bellhow.UUCP>
Thu, 7 Feb 91 15:49:06 EST
I am requesting the following information as part of a research project
involving computer viruses, prophylactic software, and recovery procedures.
When the research is completed, I will gladly make available any information
that I am able to release to any interested RISKS readers.

Has there ever been a documented occurence of a computer virus attacking
the UNIX operating system outside of laboratory conditions?  I refer
to the strict definition of "computer virus" (i.e. reproducing by attaching
itself to existing code), and not the standard media definition of
computer virus (i.e. just about anything).

Personal anecdotes are also welcome.

Any information regarding this matter (including other places to request
information) would be greatly appreciated.  Please contact me at:

        Tom Brendza,       Bell & Howell, PSC,     5700 Lombardo Center #220
        Cleveland, OH 44131-2531           (216) 642-9060 x288 (voice)

Please report problems with the web pages to the maintainer