Subject: RISKS DIGEST 15.65 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 11 March 1994 Volume 15 : Issue 65 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** EARLIER VOLUMES NOW IN FTP ARCHIVE SUBDIRECTORIES. ***** ***** See last item for information on RISKS (comp.risks) ***** Contents: Using Caller ID to catch obscene callers (anonymous) Hard-drive headache (Robert Telka) Digital Detritus (Eric Sosman, Stephen D Crocker) Re: Maybe appalling grammar is bad language design (Mark Jackson, Alayne McGregor) RISK to freedom of information (Philip Overy) Re: Clipper (Mark Eckenwiler, Daniel B. Dobkin) 13th Intrusion-Detection Workshop (Teresa Lunt) First announcement of COMPASS '94, program and info (Teresa Lunt) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 10 Mar 94 xx:yy:zz xxT From: [an anonymous contributor] Subject: Using Caller ID to catch obscene callers The recently reported case of the woman using caller ID to catch an obscene caller was noteworthy only because of its relative rarity. Fewer and fewer such callers are stupid enough these days to make such calls from other than payphones, and most won't hang around the phone long enough to get caught. To the extent that an idiot does stay around, use of the call-trace feature that is an integral part of the new systems (which provides the number instantly to the telco, rather than to the callee) would provide the same info in a much less invasive manner. The telcos know full well (all you have to do is read their own literature) that the real reason they push caller ID is to provide businesses with tools for phone number collection of inbound callers for building of telemarketing lists. Its overall usefulness for dealing with harassing calls is quite limited, and becoming less so every day as more and more of the callers catch on. ------------------------------ Date: Thu, 10 Mar 94 16:03:42 EST From: watpod13@ccs.carleton.ca (Robert Telka) Subject: Hard-drive headache! Lisa Balkes' story of the Janitor interrupting the UPS brought back to mind a problem which I ran into this past summer. I will keep the company anonymous to protect it's identity. I was employed there during the summer as a student programmer/analyst. On with the story! A new alarm system was being installed at company P over one weekend. The installers had to access the climate controlled computer room where company P's Prime system was located to incorporate the thermometer with the alarm system (if the air conditioner conks out, and the room gets too warm, the alarm is set off). The installers were let into the room by the plant manager who was working that week, however there is an unwritten rule that only authorized personnel are to enter the room, and any unauthorized people are to be escorted. When we arrived Monday morning, two of our three hard drives in the drive cabinet where crashed. We also noticed that the cabinet had been physically moved a few centimetres (there was an imprint of its original position left on the floor). The security alarm installers insisted that they did not move the units, yet they must have since they were the only people to enter the locked room that weekend. Since nobody saw them do it, we had no proof (the plant manager left them alone in the room). We were supposedly prepared for an event where one of our boot-up drives crashed, however the backup unit and the main unit were the two which crashed. It took about a month and a half and 4 refurbished drives later to get us up and running. A few weeks after we were up and running fully, there was an electrical fire in the manufacturing plant, at the point were the electricity came into the plant. Fortunately, the system was saved from being fried, but we had to deal with the soot from the fire. Because there was no electricity, we were able to bring in diesel electric generators and get the computers up and running (since our computer was accessed by our salesmen and by company P's other manufacturing plants). The generated electricity was "dirty" and our UPS consistently complained and would go online. Also, during the evenings when no one was around, the electricity consumption decreased, and somehow the generator would detect that and do something to the electricity such that the UPS would kick in. For a week we came into work with the UPS beeping in morse code SOS, and our system would be down, until we temporarily solved the problem by leaving all the lights and personal computers on during the evenings. Needless to say, it was an exciting and unpredictable summer, with lots of long hours, frustrations, and rewards. And company P is still operating today. Risks? No matter how prepared you are, you are never prepared enough. Robert Telka, Computing & Communications Services, Carleton University, Ottawa, Ontario, Canada watpod13@ccs.carleton.ca ug930017@mach.scs.carleton.ca ------------------------------ Date: Thu, 10 Mar 94 16:12:48 EST From: eric@tardis.hq.ileaf.com (Eric Sosman x4425) Subject: Digital Detritus In RISKS-15.64, jcr@msen.com (John C. Rivard) reports that "A News editor had a composting room worker sneak along a copy of the digital photo file, without the knowledge of the Free Press." I wondered idly what kind of pitchfork would be best for digital compost, but came to no earth-shaking conclusions. Despite mental ferment, I made, as they say, no hay. Eventually, I moved on to the next article ... in which dnorman@apple.com (Don Norman) speculated that "Maybe appalling grammar is bad language design." There are moments when the enjoyment to be derived from digitized debate seems to outweigh almost any RISK. Eric Sosman, Interleaf, Inc., Prospect Place, 9 Hillside Ave. Waltham, MA 02154 eric@ileaf.com ------------------------------ Date: Thu, 10 Mar 94 13:21:31 -0500 From: Stephen D Crocker Subject: Digital Destritus (Re: RISKS-15.64) > ... a composting room worker ... Hmmm... We always known what news people handle, but it's nice to know they know too. I don't recall the outcome, but there were some lawsuits a while ago concerning the government's right to paw through your trash after you put it on the street. Is compost material protected by intellectual property laws or the first amendment? I suppose one could argue about a right to privacy... Steve [An interesting question relates to information residues and remanence. When can useful information be reconstructed from compost? PGN] ------------------------------ Date: Thu, 10 Mar 1994 11:29:04 PST From: MJackson.wbst147@xerox.com Subject: Maybe appalling grammar is bad language design (RISKS-15.64) > With words that are homonyms, so the same spelling indicates contraction > and possession, the rule is that contraction wins use of the '. Hence, > "It's not its fault," where "it's" is a contraction and "its" is a > possessive. > Try explaining that to a non-native speaker of English. Hell, try > explaining that to a native speaker. In either case, try explaining it *correctly*. There is no such "contraction wins" rule. "Its", like "his" and "her," is a possessive pronoun, not a noun requiring "'s" (or "'", if already ending in s) to form a possessive. One does not even think of writing "I threw hi's ball over the fence," notwithstanding the fact that "his" has no homonym. > If English weren't so stingy with symbols and used different symbols for > possession and contraction, then we wouldn't have any problem. An extremely unlikely statement on its face, and completely unsupported by the preceding argument. Mark Jackson ------------------------------ Date: Fri, 11 Mar 1994 09:31:49 -0500 From: mcgregoa@cognos.com (Alayne McGregor) Subject: Which Johnson? (was Maybe appalling grammar is bad language design) I would have more sympathy with Don Norman's comments about bad language design (RISKS-15.64) if he hadn't confused the great lexicographer with a [...] runner. _Samuel_ Johnson, please! Mr. Norman has, however, produced an interesting analogy. Any software designer who thinks that his/her design will survive many iterations of fixes and upgrades might look at the evolution of languages for a cautionary counter-example. Alayne McGregor, mcgregoa@cognos.com ------------------------------ Date: Fri, 11 Mar 94 09:53:33 GMT From: Philip Overy Subject: RISK to freedom of information "Freedom of information" means literally "freedom to defend yourself", ie "the right to live". States can falsify information on a grand scale (eg make computers) and do pretend to respect human rights (which I would argue is a weak claim, but the UK and the USA do indeed make that claim, and spend a fairly derisory but not non-existent sum to "prove" it); if you can attribute heinous crimes, such as child pornography, to someone, then you can destroy them. Clipper in effect destroys the value of computer evidence ("it must be faked"), so I am glad in a way that the public scepticism of computer "evidence" is about to be reinforced. I don't believe that the law enforcers will thank Clinton, once they realise the true effect of Clipper on their cases - everyone will claim that the police "of course" knew all about their personal life and then falsified suitable evidence to substantiate a tailor-made case. They will edit their own version and insert points at which the police "made it all up" (as they do in many non-computerised defences). I await with interest the first defence on these lines when Clipper hits the streets. Phil Overy, Rutherford-Appleton Laboratory ------------------------------ Date: 11 Mar 1994 03:02:02 -0500 From: eck@panix.com (Mark Eckenwiler) Subject: Re: Clipper (Henson, RISKS-15.64) Since Mr. Henson speaks of "Clipper" (and not Skipjack generally), I assume he's referring strictly to telephonic communications. He's incorrect in implying that a Magistrate Judge can issue a wiretap warrant; Title III makes quite clear that they *cannot*. See _In re United States_, 10 F.3d 931 (2d Cir. 1993). >These magistrates (who are *not* judges, but work for the US Attorney's >office) tend to be busy, or lazy or corrupt or all three. Mr. Henson also misstates the facts here. Magistrate Judges most assuredly do not work for the US Attorneys nor for the Department of Justice. They are Article I judicial officers; in my experience, they are no more or less "lazy or corrupt" than life-tenure, Article III federal judges. And for the record, I oppose Clipper. ------------------------------ Date: Fri, 11 Mar 94 11:38:41 EST From: "Daniel B. Dobkin" Subject: Magistrate-Judges (hkhenson, RISKS 15.64) In RISKS-15.64, hkhenson notes that The risk under Clipper is that your private communications will be protected by the *weakest* link in the chain--one of the thousands of low level Magistrate-Judges among whom corrupt or zealous law enforcement agents shop for warrants and will shop for keys. This is hardly the only risk under Clipper, nor are the federal magistrates necessarily the weakest link in the chain: your conclusion is based on an incorrect understanding of the law and the role of U.S. Magistrate-Judges. These magistrates (who are *not* judges, but work for the US Attorney's office) tend to be busy, or lazy or corrupt or all three. The magistrates *are* judges. They do not work for the U.S. Attorney's office, but for the United States District Court. The magistrates are appointed by the District Court which they serve, for nine-year terms; the District Court judges (who appoint the magistrates) are appointees of the President, and serve for life. Magistrates are as well-qualified as the judges they serve, and have the same duties, responsibilities, and powers. They do tend to be busy; in my experience, they are not likely to be any more lazy or corrupt than any other federal judge. As in this case, even if the law is *directly quoted* in search warrant affidavits or key requests, and these laws *expressly forbid* granting warrants or key requests under the conditions cited, the magistrate may not even read the supporting affidavit before approving it. He is *very* unlikely to read or consider the underlying laws when granting a request. This is no more true of a federal magistrate than of any other judge, in either the federal or state court systems. As a rule, judges *do* try to make sure that the application is lawful and that the rules for granting it are applied appropriately. Sometimes a bad application gets through, and some judges unquestionably treat such applications more favorably than others. This is a general problem with "the system" and is not unique to Clipper. There *might* be an enhanced risk with Clipper because the bench (almost by definition) is inhabited by generalists who are called upon to be "instant experts" in many areas; they must rely on others to provide them with sufficient technical insight to allow an informed decision. Sometimes that insight is provided entirely by the applicant; very often, it is provided by the judge's law clerk. The key escrow agents provide no protection whatsoever since they simply fill orders from agents with approved applications. This, in fact, is a much more troubling weakness with the Clipper proposal, and one which has been discussed at length in other fora. While Clipper does introduce some very weak links into the security chain, judicial oversight is not one of them --- that particular link is not changed at all. (One could even argue that because the technology makes wiretaps so much easier, judges might actually be less inclined to approve every application that comes their way.) \dbd ------------------------------ Date: Thu, 10 Mar 94 10:35:03 -0800 From: Teresa Lunt Reply-to: Luntzel@csl.sri.com Subject: 13th Intrusion-Detection Workshop THIRTEENTH INTRUSION-DETECTION WORKSHOP May 19-20, 1994 SRI International Menlo Park, California, USA You are invited to attend a two-day workshop on intrusion detection to be held at SRI International in Menlo Park, California on May 19-20, 1994, which are the Thursday and Friday following the 1994 IEEE Symposium on Research in Security and Privacy in Oakland, California. This will be the thirteenth in a series of intrusion-detection workshops. The workshop will begin at 9am and will conclude at 5pm on Thursday, and will be from 9am to 2pm on Friday. The workshop will consist of several short presentations as well as discussion periods. If you and/or your colleagues wish to attend or have questions, please send E-mail to Liz Luntzel, luntzel@csl.sri.com, or call her at 415-859-3285. Specify your name, title, affiliation, address, and phone number. You can also send us a fax at 415-859-2844. Directions to SRI will be provided on request. If you have any progress to report on an intrusion-detection project or some related work that would be appropriate for a short presentation, please indicate the title and a paragraph describing your proposed talk. You can also indicate suggestions for discussion topics. There will be a $100 charge for the workshop. This fee includes lunches in SRI's International Dining Room. Please send your check to Liz Luntzel, EL248, SRI International, Computer Science Laboratory, 333 Ravenswood Avenue, Menlo Park, California 94025-3493. ------------------------------ Date: Fri, 11 Mar 94 15:17:31 -0800 From: Teresa Lunt Subject: First announcement of COMPASS '94, program and info COMPASS '94 June 27 - July 1, 1994 Ninth Annual Conference on Computer Assurance Systems Integrity, Software Safety, and Process Security National Institute of Standards and Technology, Gaithersburg, MD COMPASS Sponsors IEEE Aerospace and Electronics Systems Society IEEE National Capital Area Council In Cooperation With British Computer Society PROGRAM RELATED INFORMATION FOLLOWS. FOR General Information, Registration Form, and Hotel Info, PLEASE SEND E-mail to mclean@itd.nrl.navy.mil or FTP from RISKS archives on CRVAX.SRI.COM CD RISKS: GET compass.94 Conference Sponsors Arca Systems, Inc. ARINC Research Corporation Control Systems Analysis, Inc CTA, Inc. Logicon, Inc. National Institute of Standards and Technology Naval Research Laboratory Naval Surface Warfare Center Systems Safety Soc. TRW Systems Division U.S. General Accounting Office COMPASS is an annual conference committed to bringing together researchers, developers, and evaluators who work on problems related to specifying, building, and certifying high-assurance computer systems. What distinguishes COMPASS from similar conferences is its emphasis on bridging the gap between research and practice. Researchers are provided an opportunity to present results, new theories, and new technologies to both other researchers and practitioners who can put them to practice. They can also learn from practitioners of new research problem domains and of problems encountered in building real systems. Practitioners have an opportunity to share lessons learned, to learn of new research, and to influence future research. Welcome to COMPASS 94, the ninth in a series of annual symposia on Computer Assurance. This year's conference focuses on both the use and assessment of formal methods and on alternatives to formal verification in a variety of critical areas: * Safety * Reliability * Fault Tolerance * Concurrency and Real Time * Security At COMPASS, the diverse program and small conference atmosphere provide plenty of opportunity for audience and speakers to mingle and share their experiences. The audience bring their own wealth of knowledge, and interchanges among industry, members of government agencies, and academia provide unique opportunities to discuss current requirements and future needs. We invite you to participate and increase the benefits of COMPASS by your attendance. *** MONDAY, 27 JUNE 8:00 am Registration Opens 9:00 am - 4:00 pm Tutorial (Lunch on your own) 1. "Formal Software Development Using Z", John McDermid, University of York Much has been written about the benefit of formal methods for developing high integrity software -- but there are relatively few examples of successful use of formal methods on large scale projects. This tutorial demonstrates that cost-effective formal software development is now possible, using Z and a refinement approach into Ada that is supported by two tools: CADiZ and ZETA. CADiZ supports the production and analysis of Z specifications. ZETA supports formal, rigorous or informal stepwise development of Ada from Z specifications (in compliance with the UK Interim Defence Standard 00-55) in a cost-effective way that enables the user to determine the level of rigor for the refinement. Examples will be offered, and the tools will be demonstrated in support of the presentation. *** TUESDAY, 28 JUNE 8:00 am Registration Opens 9:00 am - 4:00 pm Tutorials (Parallel Sessions) (Lunch on your own) 2. [FULL DAY] "Software System Evaluation and Certification" Hans-Ludwig Hausen, GMD (German National Research Center for Computer Science) Software quality evaluation and certification have been recognized as important issues for the American, European and especially the Japanese software industry. This tutorial focuses on the methods and tools for the evaluation and assessment of software products and processes. Particular emphasis is given to identifying and selecting software characteristics and metrics and the handling of evaluation methods and tools. The impact of the SEI Capability Maturity Model, SPICE, ISO 9000 series, ISO 12119, ISO 9126 and the EVALUATION METHOD will be discussed in detail. 9:00 am - 12 Noon [HALF DAY] 3. "Software Hazard Analysis", Nancy Leveson, University of Washington The goals and techniques of software hazard analysis will be presented and general procedures, including new state machine algorithms, discussed. Topics include Software System Hazard Analysis and Software Requirements Analysis. Finally, an example using a real application (TCAS II) will be offered. 12 Noon - 1:00 pm Lunch (on your own) 1:00 pm - 4:00 pm [HALF DAY] 4. "Practicing Software Safety in a Virtual Corporation" Frank Houston, Weinberg, Spelton, & Sax, Inc. In this half-day tutorial, the participants will play the roles of entrepreneurs who are developing a new medical device. The goal is for participants to develop the preliminary concept for the device, including safety requirements. If time permits, participants will develop a plan for validation and verification of the device, addressing regulatory Good Manufacturing Practice issues in the process. *** WEDNESDAY, JUNE 29 8:00 am Registration and Tools Fair Open (tools that will be exhibited are listed at the end of this Agenda) 9:30 am - 10:00 am Welcoming Remarks James H. Burrows, Director, Computer Systems Laboratory, NIST Jarrellann Filsinger, General Chair and John McLean, Program Chair 10:00 am - 11:00 am Keynote Address, Jerry O. Tuttle, VADM USN (RET.) 11:30 am - 1:00 pm SAFETY I "Experience Applying the CoRE Method to the Lockheed C-130J Software Requirements", Stuart Faulk, Lisa Finneran, James Kirby (SPC) and James Sutton (Time Plus) "AeSOP: An Interactive Failure Mode Analysis Tool", Stephen S. Cha (The Aerospace Corp.) "A Development of Hazard Analysis to Aid Software Design", John McDermid and D. J. Pumfrey (University of York) 2:00 pm - 3:30 pm USE AND ASSESSMENT OF FORMAL METHODS "Formal Methods in Language Design", David Guaspari (ORA) "Case Study: Applying Formal Methods to the Traffic Alert and Collision Avoidance System (TCAS)", Joan J. Britt (MITRE) "Formal Methods and Dependability Assessment", V. Stavridou, S. Liu, and B. Dutertre (University of London) 4:00 pm - 5:00 pm ALTERNATIVES TO FORMAL VERIFICATION "Using Formal Methods to Derive Test Frames in Category-Partition Testing", Paul Ammann and Jeff Offutt (George Mason University) "Application of an Informal Program Verification Method to Ada", Bruce Wieand (IBM) and William E. Howden (University of California) 5:00 pm Tools Fair Closes *** THURSDAY, JUNE 30 8:00 am Registration and Tools Fair Open 9:30 am - 11:00 am FAULT TOLERANCE "Centurion Software Fault Tolerance Design and Analysis Tool", G. Steve Wakefield (SRS), Roger Dziegiel (Air Force Rome Lab), and Laura L. Pullum (Quality Research Associates) "Estimation of Coverage Probabilities for Dependability Validation of Fault-Tolerant Computing Systems", Cristian Constantinescu (Duke University) "Formal Verification of an Interactive Consistency Algorithm for the Draper FTP Architecture Under a Hybrid Fault Model", Patrick Lincoln and John Rushby (SRI International) 11:30 am - 1:00 am CONCURRENCY AND REAL-TIME SYSTEMS "State Minimization for Concurrent System Analysis Based on State Space Exploration", Inhye Kang and Insup Lee (University of Pennsylvania) "Compositional Model Checking of Ada Tasking Programs", Jeffrey Fischer (Verdix) and Richard Gerber (University of Maryland) "An Ounce of Prevention is Worth a Pound of Cure: Towards Physically-Correct Specifications of Embedded Real-Time Systems", Azer Bestavros (Boston University) 2:00 pm - 3:30 pm PANEL: SOFTWARE TESTABILITY FOR CRITICAL SYSTEMS Dick Hamlet (Portland State University) William E. Howden (University of California) Keith Miller (Sangamon State University) Jeffrey Voas (Reliable Software Technologies Corp.) 4:00 pm - 5:00 pm HARDWARE VERIFICATION "A Formal Model of Several Fundamental VHDL Concepts", David M. Goldschlag (NRL) "Experiences Formally Verifying a Network Component", Paul Curzon (University of Cambridge) 5:00 pm Tools Fair Closes 6:30 pm BANQUET, Speaker: Brian Randell (University of Newcastle) *** FRIDAY, JULY 1 8:00 am Registration and Tools Fair Open 9:30 am -11:00 am SAFETY II "Evaluating Software for Safety Systems in Nuclear Power Plants", J. Dennis Lawrence, Warren L. Persons, and G. Gary Preckshot (Lawrence Livermore National Laboratory) "An Approach for the Quality Analysis of Safety Specifications", Amer Saeed, Rogerio de Lemos, and Tom Anderson (University of Newcastle) "Causality as a Means for the Expression of Requirements for Safety Critical Systems", Andrew Coombes, John McDermid, and Philip Morris (University of York) 11:30 am Tools Fair Closes 11:30 am - 1:00 pm SECURITY "Covert Channels -- Here to Stay?", Ira S. Moskowitz and Myong H. Kang (NRL) "An Experience Modeling Critical Requirements", Charles N. Payne, Andrew P. Moore, and David M. Mihelcic (NRL) "On Measurement of Operational Security", Sarah Brocklehurst and Bev Littlewood (City University) and Tomas Olovsson and Erland Jonsson (Chalmers University of Technology) 1:00 pm Adjourn Technical Program TOOLS EXHIBITED AT TOOLS FAIR RiskWatch AeSOP, ARiES EVES AdaWise, Penelope Romulus, Larch-Ada McCabe Toolset ModeChart Toolset Centurion RDD-100 Boundary Flow Covert Channel Analysis INTERLOCKS Conference General Co-Chairs: Jarrellann Filsinger, Booz-Allen & Hamilton, H.O. Lubbes, NRL Program Chair: John McLean, NRL Arrangements: Laura M. Ippolito, NIST Publications: Ann Boyer, Control Systems Analysis Publicity: Paul Anderson, Space and Naval Warfare Systems Command Registration: Karen Ferraiolo, Arca Systems, Inc. Treasurer: Bonnie P. Danner, TRW Systems Division Tutorials: John J. Marciniak, CTA, Inc. Tools Fair: Charles N. Payne, NRL Program Committee Paul Ammann, George Mason University George Dinolt, Loral Jarrellann Filsinger, Booz-Allen & Hamilton Virgil Gligor, University of Maryland Li Gong, SRI International Connie Heitmeyer, NRL Jeremy Jacob, University of York Carl Landwehr, NRL Teresa Lunt, SRI International John J. Marciniak, CTA, Inc. John McDermid, University of York John McHugh, Portland State University Jon Millen, MITRE David Parnas, McMaster University John Rushby, SRI International Ravi Sandhu, George Mason University Jeannette Wing, Carnegie Mellon University Board of Directors Chair: Dolores R. Wallace, NIST Vice-Chair: Anthony Shumskas, Logicon, Inc. Treasurer: Dario DeAngelis, Logicon, Inc. Secretary: Judy Bramlage, U.S. General Accounting Office IEEE AESS: Robert Ayers, ARINC, Inc. IEEE NCAC: Arthur Cotts Members: Michael L. Brown, Naval Surface Warfare Center; Jarrellann Filsinger, Booz-Allen & Hamilton; Frank Houston, Weinberg, Spelton, & Sax, Inc.; H.O. Lubbes, Naval Research Laboratory ------------------------------ Date: ongoing From: RISKS-request@csl.sri.com 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 on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . 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, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, 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. ARCHIVES: "FTP CRVAX.SRI.COMlogin anonymousYourName CD RISKS: Issue j of volume 15 is in that directory: "GET RISKS-15.j". For issues of earlier volumes, "GET [.i]RISKS-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "DIR" (or "DIR [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.65 ************************