Subject: RISKS DIGEST 17.24
REPLY-TO: [email protected]

RISKS-LIST: Risks-Forum Digest  Thursday 10 August 1995  Volume 17 : Issue 24

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, etc.       *****

 Contents:
Air-Traffic Control Woes (PGN)
False zero reading possible on voltmeter (Mark Brader)
An unusual off-by-one error (Mark Brader)
Emulating failures (Raymond Turney)
Cellular-phone stuff (Martin Cohen)
Kane v. McDonnell Douglas (Susan Kinney via Dan Stone)
Australia next to ban PGP (Ross Anderson via Dave Farber and Lance J. Hoffman)
Re: Dave Parnas on Tenth Anniversary Issue (Paul Green)
Re: Warning on Using Win95 (Brad Silverberg)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

----------------------------------------------------------------------

Date: Thu, 10 Aug 95 7:45:31 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Air-Traffic Control Woes

The Federal Administration's Fremont (Oakland) air-traffic control center
was "off-the-air" yesterday (9 Aug 1995) due to a local power outage.  Power
died at 7:13 a.m. as technicians were doing maintenance.  Both the archaic
system and the even more archaic backup system were down.  The center lost
all radar and radio contact with airborne planes, which is most unusual --
although it has happened before.  The immediate effects continued for over
one hour, and the aftereffects lasted long after that as planes were kept on
the ground waiting for the mess to clear.  (The Oakland center covers an
18-million square mile circle including the northern California border and
San Luis Obispo to the south, more than half way to L.A.)  Fortunately, the
weather over northern California was good, and en-route flights could
operate visually.  [Source: David Dietz, San Francisco Chronicle, 10 Aug
1995, p. 1.  David noted that in the past four months, computers have failed
20 times at the ATC centers in Chicago, Washington DC, Dallas-FortWorth,
Cleveland, and New York.  Long-time RISKS readers are not surprised.

------------------------------

Date:    Wed, 9 Aug 95 16:42:18 EDT
From: [email protected]
Subject: False zero reading possible on voltmeter

I'm merely re-forwarding this item, whose original author is not given.
I saw it in sci.engr.safety, to which it was forwarded by Kermit Carlson
([email protected]) at Fermilab.

" ...The defective units are Fluke 70 Series 2 and Fluke 77 Series 2
    The problem occurs when the DMM is used to test D.C. voltages
    between 500 and 1000 volts. If the test leads are connected
    to the D.C. source terminals with reversed polarity, the display
    will read 0 volts. If the leads are then reversed to the correct
    polarity, the display remains locked on the zero volts reading.
    Therefore, someone could be testing a 1000 volt D.C. source,
    and obtain a reading of zero. If this meter is being used to
    verify a de-energised state, there is a risk of unintended contact
    with a lethal voltage...."

Carlson adds:

 The memo does indicated that this false zero reading and the locked-up
 state has been verified by the manufacturer.

I'm not familiar with the particular model in question, but presumably it
has a digital display, and hence is fair game for RISKS.  For those who
don't know, the odd-sounding Fluke is a genuine company name.

Mark Brader, [email protected]  SoftQuad Inc., Toronto

------------------------------

Date:    Mon, 31 Jul 95 15:28:15 EDT
From: [email protected]
Subject: An unusual off-by-one error

The Usenet sci.math FAQ list discusses, among other things, the question of
whether it is appropriate to consider that 0^0 (where ^ means
exponentiation) has a well-defined value or not.  The following paragraph,
arguing that 0^0 should be defined as 1, is stated to appear at page 162 of
"Concrete Mathematics: A Foundation for Computer Science" (Addison Wesley,
1989, ISBN 0-201-14236-8) by Ronald L. Graham, Donald E. Knuth, and Oren
Patashnik:

|   Some textbooks leave the quantity x undefined, because the functions
|   0^0 and x^0 have different limiting values when 0^x decreases to 0.
|   But this is a mistake. We must define x^0=1 for all x , if the
|   binomial theorem is to be valid when x = 0 , y = 0 , and/or x = -y .
|   The theorem is too important to be arbitrarily restricted! By
|   contrast, the function 0^x is quite unimportant.

Obviously the first two quoted lines are garbled.  In fact, the corresponding
text in the book actually reads:

   Some textbooks leave the quantity 0^0 undefined, because the functions
   x^0 and 0^x have different limiting values when x decreases to 0.

(Except that it uses proper exponentiation signs.)

I emailed the list's maintainer, Alex Lopez-Ortiz, to point out what I
assumed was a typo.  He replied to say that actually the error was the
result of a bug -- he had used a program to remove LaTeX math formatting
codes from an online copy of the paragraph, and it had apparently shifted
each formula by one position in the text!

Mark Brader  [email protected]  SoftQuad Inc.  Toronto

------------------------------

Date: Tue, 08 Aug 1995 17:23 -0700 (PDT)
From: [email protected]
Subject: Emulating failures

    It is not clear that the possibility of emulating hardware in software,
and thus the possibility of creating software that emulates hardware so so
closely as to be subject only to the same failure modes as hardware, says
anything at all about the potential reliability of software in other
contexts.  If I understand things correctly, most hardware is self
referential, intended to do a limited number of clearly specified things
well.  Most software, on the other hand, is directed at a real-world task or
tasks ... which can easily be either incompletely understood or
misunderstood altogether.  It may be the case that what hardware is normally
supposed to do is better understood in the CS world than all the strange
things non computer scientists ask software to do.  If this is the case,
software is less reliable -- not because of the medium, but because a vaguer
definition of, and lesser understanding of, the task to be performed leaves
more room for error.

        Or, the reliability of software is less because the risk of human
error is greater, in the tasks which it is customarily applied to.

        Raymond Turney

------------------------------

Date: Tue, 1 Aug 95 13:46:51 PDT
From: Martin Cohen <[email protected]>
Subject: Cellular-phone stuff

Well, I am now one of those whose cellular-phone number was duplicated.
According to AirTouch Cellular, this was discovered when the pattern of
calls using my number changed (from 1-2 minutes a day to 1 hour a day!).
The detection of this type of change is clearly (IMHO) a good use of
technology.

While talking to the customer service rep, I asked about the risk of digital
phones to the hearing impaired (and their hearing aids) as reported in an
earlier risks.  She said that the European phones were higher powered and
that the American phones, because of their lower power, were safe. I asked
her to ask that this be checked anyway.

------------------------------

Date: Wed, 9 Aug 1995 09:30:07 -0500
From: [email protected] (Dan Stone)
Subject: Kane v. McDonnell Douglas

Date:         Wed, 9 Aug 1995 08:24:46 -0500
From: Susan Kinney <[email protected]>
Subject:      Kane v. McDonnell  Douglas
To: Multiple recipients of list ISWORLD <[email protected]>

Have any of you written up the Kane Carpet Co. v. McDonnell Douglas Corp.
suit as a case?  Below are details if you are unfamiliar with the case.
Susan Kinney

MISTRIAL DECLARED IN KANE CARPET CASE, The Record, April 6, 1994; Pg. D03

Seven months into a jury trial in which the Kane Carpet Co. claimed that it
had gone bust because of a computer, a Superior Court judge has declared a
mistrial.  Judge Mark A. Baber issued the decision this week after Kane's
former president, Richard Lehmbeck, testified that he had suffered a nervous
breakdown affecting his recall of events in 1989, when the computer went on
line; and in 1990, when Kane folded. The onetime Secaucus-based distributor
of floor coverings has claimed that a McDonnell Douglas Corp. computer
system destroyed its business in a few weeks as complaints about incorrect
invoices and duplicate deliveries piled up.  McDonnell Douglas denies any
responsibility for Kane's demise.  The case is expected to be rescheduled
for a new trial.

Dan Stone, Associate Professor, Univ. of Illinois, Dept. of Accountancy,
Champaign, IL 61820  217-333-4537 [email protected]  fax: 217-244-0902

------------------------------

Date: Tue, 1 Aug 1995 20:36:29 -0400 (EDT)
From: "Lance J. Hoffman" <[email protected]>
Subject: Australia next to ban PGP

Date: Tue, 01 Aug 1995 15:29:05 -0400
From: Dave Farber <[email protected]>
Subject: Australia next to ban PGP [unverified info ...]

From: [email protected] (Ross Anderson)

Australia's proposed crypto policy:

(1)     Banks will get key escrow
(2)     Other Australian residents will be forced to use weak crypto

Source: talk by Steve Orlowski, Assistant Director, Australian attorney
general's department, given at the Cryptography Policy and Algorithms
Conference, Queensland University of Technology, last month.

p 34: `the needs of the majority of users of the infrastructure for
     privacy and smaller financial transactions can be met by lower
     level encryption which could withstand a normal but not
     sophisticated attack against it. Law enforcement agencies could
     develop the capability to mount such sophisticated attacks.
     Criminals who purchased the higher level encryption products
     would immediately attract attention to themselves.'

He mentioned that his department considered itself a suitable repository
for the government central decrypting unit, which would decrypt traffic
for local police forces. He also wants to escrowed keys for banks and
other organisations allowed to use strong crypto.

Centralising the wiretap capability with the AG is represented as a useful
safeguard against abuse of power by local police forces. It would be
presented as a `data recovery' facility in order to reassure the voters.

Centralisation will enable the AG to acquire the capability to use ``more
sophisticated techniques in circumstances where the key cannot, for
whatever reason, be recovered from escrow''.

So the technical parameters would appear to be: 40 bit keys for the
masses, 56-bit escrowed keys for the banks, and a Wiener machine sitting
in Orlowski's office. Belt, braces and string.

Curiously enough, he quotes a `Review of long Term Cost Effectiveness
of Telecommunications Interception' as saying that ``Encryption by
targets of their communications (both voice and data) is not considered
as a problem for TI at present in Australia'' and goes on to say that
``there has been comparatively little market for voice encryption
products, although they have been readily available''.

He even produces some good arguments for the EFF, such as that much of
the intelligence comes from the call log data and from calls to third
parties such as airlines and hotels which are not encrypted.

He also says that the OECD countries will hold a meeting on National
Cryptography Policies later this year. While at the conference, I found
out that a classified meeting took place this March in Germany between
the signals intelligence agencies of the developed countries, plus
Australia and South Africa, at which the assembled spooks agreed to
press their governments to bring in escrow and/or weak crypto.

Australia seems rather eager to lick Uncle Sam's boots on this issue.
I wonder what the payoff was?

------------------------------

Date: Wed, 9 Aug 1995 12:16:55 EDT
From: [email protected] (Paul Green)
Subject: Re: Dave Parnas on Tenth Anniversary Issue

Prof. David Parnas makes a good point that it would be nice for each of us
to contribute more original success or failure stories and to rely less on
the popular press for our data.  I'd like to expand on this idea, and, in
the future, I will try to contribute some unpublished stories.

As someone who works for a company that sells fault-tolerant computers, which
are designed never to fail, I've often wondered why failures of our systems
(unfortunately, being human beings, neither we nor our systems are perfect)
aren't reported in the press.  It finally dawned on me that the answer is very
simple: our customers do not want their failures reported.  Failures reflect
poorly on the person who selected or implemented the system, on the department
responsible, and on the business and its image in the marketplace.  Failures
hurt customers and lose business.  (After all, that's why they are buying our
equipment in the first place!)

If you call a company whose systems are dead on the floor, some may admit it,
but I also know of instances where they have claimed to be "updating their
files" or "on holiday" or almost anything that would get you to go away and
not get angry at them.

Another aspect of this denial and cover-up is that even when the fault and
responsibility for the failure is clearly within the MIS department, we, the
vendor, will be blamed.  I just have had to learn to accept that aspect of the
computer business.  (We certainly ARE to blame some of the time, but we get
blamed far more times).

While it is healthy for society as a whole to expect perfection and to not
tolerate failure, we also have to find a way to get society to expect honest
explanations and total ownership of responsibility.  Having worked with
Japanese, European, and American companies, my feeling is that the Japanese
are the best at this, the Europeans are second, and the Americans are far
behind.  All of them will berate you for a failure and want a quick
workaround and a solid fix, but typically only the Japanese want to know
what was the root case of the failure, and what process changes you are
instituting to avoid this problem in the future.  This kind of customer
pressure to "do the right thing" is incredibly helpful within the company
towards ensuring that we understand and truly correct the problems. I wish
more customers did this.

Total Quality Management (TQM) programs seem to be a pretty good tool for
fixing these problems within a company.  In my personal, everyday life I've
made two small changes to try to help the world at large. One is to refuse
to accept the stock phrase "it was a computer error" when I receive it; the
other is to ask why the failure occurred and what will be done to prevent it
from happening again.

The end result of this human tendency to cover-up failures, deny
responsibility, and let vendors off too easily is that we are getting
neither the awareness nor understanding (to borrow from Parnas) that is
possible. I'm sure that the press is able to report on only a small fraction
of the actual failures that occur; I'd guess less than 1%. Airline pilots
have a way to report problems anonymously; perhaps we need a similar program
in the systems business.

Paul Green, Director, VOS Planning, Stratus Computer, Inc., Marlboro, MA 01752
(508) 460-2557    [email protected]   FAX: (508) 460-0397

------------------------------

Date: Sat, 05 Aug 95 15:31:00 PDT
From: [email protected] (Brad Silverberg, Sr VP Microsoft Corp)
Subject: Re: Warning on Using Win95 (RISKS-17.21)

The FACTS: These stories are NOT TRUE.

1.  A user may choose to register by the paper card, electronically, or not
at all.  It is completely the user's choice.  The online
registration application is an electronic version of the paper registration
card that traditionally comes with all Microsoft products.  The intent is to
offer customers a convenient and helpful way to register.  The registration
application must be explicitly run by the user and the user supplies,
completely on a voluntary basis, similar information that he would with the
paper registration card.  When the user runs the app, it asks for the
typical information, such as name, address, company, as well as system
configuration info for that PC (things such as type of CPU, RAM, hard disk
space, etc.) and what products the user may have installed.  This is done
only with the user's consent and not required to complete the registration.
There is no default answer to the question of whether to include the system
information or not: it requires an explicit Yes by the user.  What's more,
if the user says No to the system info, then the app does not even bother
asking about the product info (and doesn't send it); if the user says Yes to
the system info, then the user is led to the product info screen and has to
explicitly say Yes to it too.

The app does not send any user info that the user is not aware of and not
explicitly agreed to.  In particular, the app does not send any files such
as config.sys, autoexec.bat, or the registry -- just the info that was on
the screen and that the user said Yes to.

Nor does the registration application look out on the network.   It only
looks at the PC the app is being run on.

2.  MSN is involved with the registration application only in that it uses
the MSN transport to upload the registration information.  You
don't have to be an MSN member to register, and once you register you are
not an MSN member.

3. MSN does NOT transmit the user's directory structure or file names.  MSN
only uploads the version of the Win95 build and the
language that is being used on the computer, and any other user initiated
information, such as BBS postings and email. MSN uploads the build and
language info so that its on the fly upgrades are synched up with the
version of Win95 on the PC being upgraded and in the right language.  MSN is
not uploading any other information about the user's PC or files.


In addition, we have set up a section on our Windows web page for
"clarifications" -- where we place our responses or position on topics such
as press reports, rumors, etc.  The web address is:
http://www.microsoft.com/windows/pr/clarifications.htm.  We've posted our
FAQ on the regwiz rumor there
(http://www.microsoft.com/windows/pr/regwq&a.htm).
Feel free to redistribute or point people to it.  Thanks!

  [My sincere apologies to Microsoft, and to Paul Saffo who was a
  completely innocent bystander.  He did not write the piece in
  RISKS-17.21, and I should either have not run it or else run it
  without his identity, because he did not submit it to RISKS.
  Thanks to Brad for making the effort to clarify the issues.  I
  always greatly appreciate first-hand accounts in RISKS.  PGN]

  [The FAQ is too long for RISKS, but is available for
  anonymous FTP in RISKS-17.24msfaq .   PGN]

------------------------------

Date: 9 August 1995 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you.  BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS.  U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>).  UK subscribers please contact
<[email protected]>.  Local redistribution services are
provided at many other sites as well.  Check FIRST with your local system or
netnews wizards.  If that does not work, THEN please send requests to
the newly automated <[email protected]>, with first text line
  SUBSCRIBE or UNSUBSCRIBE
[with option of E-mail address if not the same as FROM: on the same line].
  HELP
gives instructions on using the Majordomo listserver in other ways.

CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored.  Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious.  Diversity is
welcome, but not personal attacks.  PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them.  Contributions will not be ACKed; the load is
too great.  **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks.  Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
  Individual issues can be accessed using a URL of the form
  http://catless.ncl.ac.uk/Risks/VL.IS.html
  (Please report any format errors to [email protected])

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 17 is in that directory: "get risks-17.J<CR>".  For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 16, J always TWO
digits) for Vol I Issue j.  Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>"  I and J are dummy variables here.  REMEMBER,
Unix is case sensitive; file names are lower-case only.  <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password.  Also ftp [email protected].  WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
  or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen.  Use wisely.

------------------------------

End of RISKS-FORUM Digest 17.24
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.