The RISKS Digest
Volume 16 Issue 66

Tuesday, 20th December 1994

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…


Microsoft has no plans to acquire Catholic Church
Mistaken Identity
Tom Knoedler
Emergency Broadcast System Goes Automatic?
Darrell F. Oresky
Brands Burn the Bull's Behind
Peter Wayner
Followup to "No I'm not Newt"
Ted Koppel
Re: Oral Hackers
Steve Holzworth
Re: Technology Under the Weather
Ross Oliver
Intel announces new Pentium replacement policy
Rich Kulawiec
Pentium bug as data management problem
Rob Aitken
Testing the Pentium bug
Daniel Essin
Mary Payne and "Good to the last bit!"
Paul A. Karger
Pentium FDIV problem - so what's new ?
A. Padgett Peterson
Spreadsheet Errors Study
Ray Panko
The Status of Disclaimers
Dick Nickalls
CFP: New Security Paradigms Workshop
Catherine A. Meadows
CFP: Safety and Reliability of Software Based Systems
Stella Page
Info on RISKS (comp.risks)

Microsoft has no plans to acquire Catholic Church (from EDUPAGE)

"Peter G. Neumann" <>
Mon, 19 Dec 94 11:43:01 PST
The latest Internet hoax has Microsoft acquiring the Roman Catholic Church,
including exclusive electronic rights to the Bible. The story, written
under an Associated Press byline, says the agreement provides for Pope John
Paul II becoming the senior vice president of the company's new Religious
Software Division, and two Microsoft senior vice presidents being invested
in the College of Cardinals. The fake story included a promise from Bill
Gates to "make the sacraments available online for the first time."
Officials at Microsoft and AP said they didn't know where the story
originated. (Tampa Tribune 12/17/94 B&F10)

  [FROM EDUPAGE, 18 Dec 1994, which concludes thusly:]
  [EDUPAGE is what you've just finished reading. To subscribe to Edupage: send
  a message to: and in the BODY of the message type:
  subscribe edupage Count Dracula (assuming that your name is Count Dracula;
  if it isn't, substitute your own name) ... To cancel subscription to
  Edupage: send a message to: and in the BODY of the
  message type: unsubscribe edupage.]

    [Several folks submitted the original hoax to RISKS.  It was not run
    here for a variety of reasons.  The omission was not a sacra-mental
    lapse on my part.  Fakes Vobiscum.  PGN]

Mistaken Identity

"Knoedler, Tom" <>
Wed, 14 Dec 94 13:50:00 PST
In the 19 December 1994 edition of *Newsweek*, read the `My Turn' column
entitled ``A Case of Mistaken Identity: On the Information Highway, you are
guilty until proven innocent'' by Michael W. Klein.  Mr Klein, an attorney
in New Jersey, was was falsely identified as a reckless driver because a
police clerk made a mistake on an address search.  Law enforcement personnel
were prepared to lock him up even though the physical descriptions did not
match, even though the demographics did not match, just because the warrant
had come out of the computer.

Thomas Knoedler

    [... A familiar kind of case for long-time RISKS readers.  PGN]

Emergency Broadcast System Goes Automatic?

Darrell F. Oresky <dforesky@jumbo.Read.TASC.COM>
Fri, 16 Dec 94 14:48:28 EST
I heard a short note on the local all news radio station recently about a
planned upgrade to the Emergency Broadcast System (EBS). This upgraded
service would allow the EBS to reach radio and TVs that were not actually
turned on when the broadcast was sent. The intent is to inform even those
misfortunates who were not actively listending or watching at the time of an
emergency. I assume such an upgrade would require changes to radios and TVs
to allow them to be turned out remotely via some sequence of commands
carried over the airwaves?  One potential risk of this configuration is that
one could remotely activate speakers or video devices that may be part of
the television or radio, and use this mechanism to listen in without anyone

Darrell Oresky

Brands Burn the Bull's Behind

Peter Wayner <>
Tue, 20 Dec 1994 09:36:51 -0500
The Sports Monday of the NYT (12/19/94) ran a headline calling one
basketball team the "Pentium" of basketball teams. It wasn't because
they were playing 2-3 times  faster than last year's team.

This illustrates the RISKS of imprecise technical language. There was no
real meaning to the word "Pentium" before. The Intel, AMD and other clones
were all supposed to be interchangeable. The brand name was just a marketing
ploy that was even more hollow than the work of the folks at P&G, Coke or
Pepsi. After all, there _is_ a difference between colas. So, if there is no
meaning to the word, it shouldn't be surprising that the first hint of a
meaning, no matter how irrational, rushes in to fill the vacuum.

Followup to "No I'm not Newt"

Ted Koppel <>
Fri, 16 Dec 1994 18:50:38 -0700 (MST)
To add to Steve Barr's comments about AOL and how anyone can have any name
on that system:

My real name is Ted Koppel.  There happens to be another fellow, a
broadcaster, who has the same name as I do.  I took my "ten free hours" on
AOL, and explored the system.  Not surprisingly, I used my name (actually
Tkoppel, which is a reasonable login variation).

One of the places to visit on AOL is an area 'owned' by ABC News.  I was in
there, reading some of their stuff, and talking in one of the forums there,
when I was told, in no unambiguous terms, to either get off the forum or
change my name.  Since my name is, after all, on my driver's license, I
figured that I had a pretty good right to use it :-) So I told the fellow

It turns out that he is/was some sort of a staff person working for the ABC
Ted Koppel, and he was concerned that people would mistake ME for his Ted
Koppel (a legitimate risk, I suppose).  On the other hand, I'm not convinced
that threatening me rudely was the appropriate way to go about it.

By the way, I subsequently dropped AOL, partially for this reason, but
primarily because there was no 'killer app' that made me want to stay.

Ted Koppel * The UnCover Company * The CARL Corporation *
Work: 404 242 8733 Fax: 404 242 8511

Re: Oral Hackers (RISKS-16.65)

Steve Holzworth <>
Tue, 20 Dec 1994 04:40:19 GMT
Mac 840AV machines (and presumably other AV machines) have a voice
recognition feature.  When we got ours, shortly after they had been
released, and before anyone started doing useful work, we used to have great
fun popping into someone's office and stating:

  "Computer, Restart, Yes."

whereupon the Mac would dutifully reboot. ("Shutdown" was another option...).

Steve Holzworth, SAS Institute, SAS/Macintosh Development Team, Cary, N.C.

Re: Technology Under the Weather (Symonds, RISKS-16.65)

Ross Oliver <>
Fri, 16 Dec 1994 22:01:46 GMT
This article is biased and oversimplified view of a complex set of
requirements.  I wonder whether the weather specialist quoted in the article
has an axe to grind against automated weather reporting systems.

The fact that the weather station report did not match current conditions is
not unusual, regardless of who or what is making the report.  Most airport
weather reports are made once per hour, so if the weather is changing
rapidly (for example, a storm front is moving in), actual conditions may be
quite different from what is reported in the last hourly observation.  This
is not the fault of the automated observation system.  Pilots must take into
account when the observation was made, and how likely it is that conditions
may have changed.

The article also stated, "the machines also cannot tell when there are
clouds above 10,000 feet," implying a crippling limitation.  In reality,
clouds more than 5,000 or 6,000 feet above the ground are not particularly
relevant to airport operations (i.e. takeoffs and landings), so less effort
is expended to gather data on high clouds.

Ross Oliver

Intel announces new Pentium replacement policy

Rich Kulawiec <>
Tue, 20 Dec 94 08:55:07 EST
Public radio's "Marketplace" show is carrying a story this morning
announcing that Intel will now replace, on request, any and all Pentium
processors.  This is a revision of their earlier policy, which required that
Pentium owners justify the replacement to Intel staffers.  I suspect that
they could no longer afford the bad publicity or the manpower cost
associated with the phone banks used to screen replacement requests.

   [I suppose it is the corrected chip that will be called RePentium.  PGN]

Pentium bug as data management problem

Rob Aitken <>
Fri, 16 Dec 1994 12:44:26 -0800
With all the discussion of verification, formal or otherwise, it seems to
me that another explanation is being overlooked. Given the immense amount
of data associated with a given chip design, it could be that the hardware
implementation of the Pentium divide unit and the software representation
which was verified (by whatever techniques Intel uses) were not the same.

Before a chip is fabricated, it exists as a huge software database, often
including several mutually incompatible representations, with a large number
of people using and changing it. Version control is a serious problem. If
a design change was made after verification, or if verification was
inadvertently performed on an earlier design, it is easy to see how a
bug could slip in, even with formal verification.

If something like this did in fact happen, then the Pentium bug is an
example of a much more mundane data management RISK than it has been made
out to be, both in this forum and elsewhere.

Rob Aitken

Testing the Pentium bug

Daniel Essin <>
Sat, 17 Dec 94 1:10:26 PST
I need a new, faster computer so I went to some computer stores to look at
the Pentium 90's. Knowing of the fpu bug, I took my trusty formula snared off
the net to test them.

>put in 5505001/294911. The correct answer is 18.66665197297. The Pentium
>produced 18.666092939000.

I carried out this test on two Pentium machines in the store using windows
calculator. they both produced the wrong answer. A 486/66 of the same brand
produced the correct answer.

 When I asked the sales people about the bug,
they said that the also had a test routine so we tried it. The instructions
were to perform the use qbasic and run the following program:
PRINT (4195835 * 256)/(3145727 / 256)

Their instructions say that the correct answer is  87413.2569545927.

Both Pentiums produced the correct answer - however - they also produced the
correct answer to 5505001/294911. I suspect that since qbasic has to run on
oldx86 machines that lack fpu's, all floating point is probably done with a
software emulator. Using this test, the store will never identify a single
chip as defective creating a false sense of security with the customers and
avoiding the difficulty of getting chips that are actually defective

caveat emptor

Mary Payne and "Good to the last bit!"

"Paul A. Karger" <>
Fri, 16 Dec 94 10:06:30 -0500
Tony Lauck commented on Mary Payne's work on assuring that DEC's computational
routines always gave good results.  I also worked with Mary at DEC, and was
VERY impressed with her commitments to mathematical accuracy.  Her motto at
the time was that the computations should be "Good to the last bit!"

I have to agree that between Mary's work on algorithmic analysis and DEC's
VERY extensive testing of instruction sets on each new processor model, it
would have been very unlikely for a bug of the severity of the Pentium FDIV
problem to have gotten out on a VAX or an Alpha processor.

Pentium FDIV problem - so what's new ?

A. Padgett Peterson <>
Fri, 16 Dec 94 09:23:39 -0500
Might point out that there is nothing new in the FDIV problem, 80x86
chips are notorious for "different" microcode - for a semi-complete
list see the "86BUGS.LST" file in Ralf Brown's interrupt list.

For just one example, the operation of the instruction AAA ("ASCII Adjust
for Addition" hex code 37) is noticeably different when executed on an
8088 as opposed to an 80386 - with initial value of AX=FFFF on an 8088
the result will be 0005h while on a 386, 0105h will result.

As a consequence any financial programs using BCD addition and requiring
the AAA instruction may have different values on different systems.


PS.  Of course, I do not know of any program using either BCD or AAA and
   AX=FFFFh should never result from BCD addition, but what does that
   matter (AAM 37 now... 8*) ?

Spreadsheet Errors Study

"Ray Panko" <>
Fri, 16 Dec 1994 10:02:15 -1000
I have recently completed a study on the types of errors that people make
when they uses spreadsheet programs.  I am currently writing up the results.
If you know of previous research that looked at spreadsheet errors other
than the Michigan work of Olson and others or the Brown and Gould study at
IBM, I would be grateful for citations or other information.

Basically, we found that student spreadsheeters have about the same
error rates as professional programmers.  About five and a half percent
of their cells have errors before debugging.  The problem is that they
did not spontaneously debug, a lack seen in the Brown and Gould lab
study and also in two ethnographic studies of real world

Given these error rates and apparent lack of deep debugging, the question is
not what fraction of spreadsheets have errors but rather how many errors the
typical large spreadsheet has.

Aloha, Ra3y (the 3 is silent)

Prof. Raymond R. Panko, Decision Sciences Dept, College of Business Admin. U
of Hawaii, 2404 Maile Way, Honolulu, HI 96822 (808) 956-5049

The Status of Disclaimers

17 Dec 1994 10:28:18 GMT
This is a HELP message.  Can anyone out there direct me to any info/archive
which will tell me the current state of disclaimers.  I am writing some
programs for medical use, and have come across the problem of how to phrase
the disclaimer so that it stands up in court. The problem seems to be, at
least in the UK, that one cannot say "..we disclaim all liability.."  since
apparently one has to put a sensible and realistic liability limit in the
disclaimer.  Perhaps some folk can help me here.

Dick Nickalls,, Dept Anaesthesia, City Hospital, Nottingham, UK

CFP: New Security Paradigms Workshop

Catherine A. Meadows <>
Thu, 15 Dec 94 19:33:40 EST
                 CALL FOR PAPERS

        A Workshop Sponsored by ACM SIGSAC, DoD, and the Aerospace Institute

                Residence Inn
            University of California at San Diego
                La Jolla, CA
                 August 22-25, 1995

Paradigm shifts disrupt the status quo, destroy outdated ideas, and open the
way to new possibilities.  This workshop explores radical new models for
computer security, trusted system integration, and intercomputer networking
security.  The goal is to develop transcendent solutions that provide the
flexibility and interoperability users require in trusted systems.

We offer a creative and constructive workshop environment for about 25
participants at a small campus inn in scenic La Jolla adjacent to San Diego.
Dress is casual. The tone is exploratory rather than critical.  The refereed
papers will be printed in a workshop proceedings.

To participate, submit preferably via email a research paper or a 5-10 page
position paper to Program Chairs John Dobson and Catherine Meadows at the
email addresses listed below by April 1, 1995.  Alternatively, submit five
copies of a hard-copy paper to either program chair by March 24, 1995.  The
Program Committee will referee the papers and notify authors of acceptance
status by June 9, 1995.

Cost of the workshop, lodging, and meals will be about $550.  Scholarships
are available.


Workshop Chair:

Hilary Hosmer, Data Security, Inc., 58 Wilson Road, Bedford, MA
+1 (617)-275-8231 (voice and fax)

Program Co-Chairs

John Dobson, Computing Science Department, University of Newcastle
Newcastle NE1 7RU, UK  +44 91-222-8228

Catherine Meadows, Naval Research Laboratory, Code 5543, Washington, DC 20375
+1 (202)-767-3490 (voice)  +1 (202)-404-7942 (fax)

Program Committee:

Thomas Haigh, Secure Computing Corporation
Deborah Hamilton, Hewlett Packard
Leonard LaPadula, MITRE
Ruth Nelson, Information System Security
Pierangela Samarati, Universita di Milano
Marvin Schaefer, Arca Systems
Bruce Schneier, Counterpane Systems
Olin Sibert, Oxford Systems
Adrian Spalka, University of Bonn
Daniel Sterne, Trusted Information Systems

Local Arrangements: Dr. Thomas Lincoln (Rand)   +1 (310)-393-0411

Publications: Deborah Hamilton (Hewlett Packard)

Scholarships: Prof. Ravi Sandhu (George Mason Univesrity) +1 (703)-993-1659

Treasurer: Janet Haley (Haley Computer Services) +1 (609)-266-1471

Registration Chair:  James Williams (MITRE) +1 (619)-223-2301 ext 31

ACM SIGSAC Liaison: Dixie Baker (Aerospace) +1 (310)-336-7998

CFP: Safety and Reliability of Software Based Systems

Stella Page <>
Tue, 20 Dec 94 12:53:26 GMT
European Network of Clubs for Reliability and Safety of Software
Centre for Software Reliability

              Reims, France, 12-15 September 1995

                    12th Annual CSR Workshop
                 1st Annual ENCRESS Conference
      Supported by the EC ESSI Programme and Lloyd's Register

In the past decade, there have been enormous advances in the use of
computers - and hence software - in areas where safety and reliability are
of significance both to individual users and to society at large. Examples
can be found in all sectors of industry: railway signalling is increasingly
computerised; fly- by-wire aircraft are the current technological trend in
civil aviation; motor car engines and braking systems are computer-
controlled; programmable logic controllers (PLCs) used in the process
industries have increasingly complex software embedded within them; and
commercial companies of all sizes become ever more dependent on the reliable
operation of their computer systems.

These systems do not always deliver the levels of safety and reliability
which users and society are entitled to expect.  There are many reported
examples of software-related failures which have caused, or had the
potential to cause, death, injury, environmental damage, or significant
economic loss. These include deaths in hospitals of patients undergoing
radiotherapy treatment, software-defect induced release of sufficient water
from a reservoir to flood a valley, lost space-craft, and company failures.

Very often, these incidents could have been prevented, or their consequences
reduced, by better awareness of safety and reliability issues as they apply
to computer-based systems.  Ideally, developers of systems should have
evidence that their approach to system development is likely to lead to the
required levels of safety and reliability. Often, evidence of this sort will
form part of a safety case, or other justification for system reliability
and/or safety, that has to be presented for approval or acceptance by an
appropriate authority.

Many projects in the ESSI programme aim to produce evidence to support the
use of particular technologies, in the development of safe and reliable
systems. These projects are particularly encouraged to submit papers to this
conference, which has been selected as one of the events at which ESSI
Application Experiments can present their results for peer review and

This is an open call for papers: we also seek other papers which argue for
the suitability of particular technologies, methods or management approaches
for use in developing reliable and safe systems, especially those which
present the results of industrial experience.

Topics that could be addressed include:

   A historical perspective on safety cases, and on how the current
   regulations requiring the production of safety cases have arisen.

   How do software engineering methods and tools contribute to
   product safety, reliability, etc.?

   What evidence is there to support the use of particular
   technologies to achieve reliable systems?

   How do organisations deal with the safety and reliability of
   PES? Do different industrial sectors deal with PES safety and
   reliability in a similar manner?

   Should we focus on management procedures more and technology
   issues less? (Some accident reports suggest this is so.)

   Are tightly coupled time critical systems inherently less
   safe or reliable than other systems?

   How do software metrics, software reliability models, etc.,
   relate to dependability attributes?

   How do we deal with the integrity of evidence used in safety arguments?

   What is the impact of organisational rules and work practices
   on safety and reliability?

Dates for Authors
Authors are invited to submit extended abstracts (two A4 pages),
or near full papers, to Carol Allen at the address given below.
Papers should be written in English which will be the language
of the Workshop/Conference. The following dates have been set:

   Submission of abstracts/papers          31st January 1995
   Notification of acceptance              28th February 1995
   Announcement of provisional programme   31st March 1995
   Workshop version of paper available     31st May 1995

The proceedings will be published following the Workshop. As
there is a requirement for the proceedings to be edited changes
may be requested of authors after the papers have been

Organising and Programme Committee
Roger Shaw      Chair              Lloyd's Register
Carol Allen     Administration     City University
Ole Anderson                       DELTA (Denmark)
Tom Anderson                       Newcastle University
Robin Bloomfield                   Adelard
Sandro Bologna                     ENEA CRE-Casaccia (Italy)
Annie Combelles                    Objectif Technologie (France)
Chris Dale                         ENCRESS Project Manager
Norman Fenton                      City University
Bev Littlewood                     City University
Bob Malcolm                        Malcolm Associates
Francesca Saglietti                ISTec (Germany)
Peter Scharbach                    Lloyd's Register

Chairman: Roger Shaw             Administration: Ms Carol Allen
Lloyd's Register                 Centre for Software Reliability
Lloyd's Register House           City University
29 Wellesley Road                Northampton Square
Croydon                          London
CRO 2AJ                          EC1V 0HB

Tel: +44 (0)181 681 4818         Tel: +44 (0)171 477 8421
Fax: +44 (0)181 681 4839         Fax: +44 (0)171 477 8585
email: email:

Please report problems with the web pages to the maintainer