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…
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: listproc@educom.edu 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: listproc@educom.edu 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]
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 knoedler@sangamon.edu
[... A familiar kind of case for long-time RISKS readers. PGN]
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 knowing. Darrell Oresky dforesky@tasc.com
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.
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 that. 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 * tkoppel@carl.org Work: 404 242 8733 Fax: 404 242 8511
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.
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
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]
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
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 replaced. caveat emptor
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.
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.
Padgett
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*) ?
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 spreadsheeters. 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 Panko@hawaii.edu (808) 956-5049
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 dick.nickalls@nottingham.ac.uk 100115.1010@compuserve.com
CALL FOR PAPERS
NEW SECURITY PARADIGMS '95
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.
WORSHOP ORGANIZERS
Workshop Chair:
Hilary Hosmer, Data Security, Inc., 58 Wilson Road, Bedford, MA
+1 (617)-275-8231 (voice and fax) Hosmer@dockmaster.ncsc.mil
Program Co-Chairs
John Dobson, Computing Science Department, University of Newcastle
Newcastle NE1 7RU, UK +44 91-222-8228 John.Dobson@newcastle.ac.uk
Catherine Meadows, Naval Research Laboratory, Code 5543, Washington, DC 20375
+1 (202)-767-3490 (voice) +1 (202)-404-7942 (fax)
meadows@itd.nrl.navy.mil
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
European Network of Clubs for Reliability and Safety of Software
Centre for Software Reliability
SAFETY AND RELIABILITY OF SOFTWARE BASED SYSTEMS
Reims, France, 12-15 September 1995
ANNOUNCEMENT & CALL FOR PAPERS
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
evaluation.
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
presented.
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
Contacts:
=========
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: roger.shaw@aie.lreg.co.uk email: c.a.allen@csr.city.ac.uk
Please report problems with the web pages to the maintainer