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: email@example.com 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: firstname.lastname@example.org 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 email@example.com [... 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 firstname.lastname@example.org
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 * email@example.com 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 firstname.lastname@example.org email@example.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) firstname.lastname@example.org 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: email@example.com email: firstname.lastname@example.org
Please report problems with the web pages to the maintainer