Subject: RISKS DIGEST 15.47 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 9 February 1994 Volume 15 : Issue 47 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: "Sounding the Alarm: Noisy medical alert systems" (B Fitler) (Semi-)electronic locks (Pete Kaiser) Safety in Telescript, Part Deux (Luis Valente) Risks of email exacerbating typos (M. Hedlund) Patents Hearing as it relates to Software (Paul Robinson) Network surveys et al. (Steve Holzworth) Re: Don't Trust The Phone Company (Lars Poulsen) Re: "Misunderstanding" a CERT advisory (D.R. Newman) Re: Clipper Petition (Pete Kaiser, John Mainwaring) Re: Altered White House Documents (Firth, Larry Nathanson) EFF Wants You (to add your voice to the crypto fight!) (Stanton McCandlish) Information on RISKS (comp.risks), contributions, subscriptions, FTP, etc. [at the end of each issue, as an experiment to save readers' eyes.] ---------------------------------------------------------------------- Date: Tue, 08 Feb 94 19:05:55 pst From: bfitler@ccmail.com Subject: "Sounding the Alarm: Noisy medical alert systems" Article titled "Sounding the Alarm: Noisy medical alert systems are getting out of hand" by Jon Van, Chicago Tribune, appeared in San Jose Mercury News Science & Medicine Section 8 Feb 1994. The article pointed out the alarm systems from medical equipment are "driving doctors and nurses to distraction" who agree that "alarm noise pollution is a significant problem that threatens patient health" presumably because "doctors order that all alarms be disconnected except those deemed absolutely necessary for patient safety." Points raised in the article: * Efforts to create international standards for alarms have been underway since 1983 and are still unfinished. * "...it is common for one event, such as a drop in a patient's blood pressure or speeding of his heart's rate, to set off a cascade of alarms from several sources..." * "... conditions change during surgery, and medical equipment isn't able to distinguish context..." * "... typically the attorney or chief executive [of the medical equipment manufacturer] thinks that the louder the alarm, the less likely their company is to be sued if someone doesn't respond..." * Manufacturers see legal problems in trying to tie together warning systems from a variety of medical systems. The article did not point out the technical difficulties involved in prioritizing alarm conditions. ------------------------------ Date: Wed, 9 Feb 94 08:18:15 MET From: Technology Strategy & Architecture Subject: (Semi-)electronic locks The "New Scientist" for 6 February 1993 contains this article: Chips hold key to door security An electronic key with a chip in its tip is to be marketed by the locksmiths, Chubb Security of Sunbury-on-Thames. The key, called Eloctro, has a tiny silicon chip which stores a unique number ranging from 10 to 70 000 billion. The key fits a special battery-powered lock which stores all the authorised numbers in a memory chip. When a key is inserted, the lock generates an electromagnetic field, which is picked up by an antenna on the chip. The antenna switches on the chip, allowing the lock to read the key's unique number. If the number matches one in the lock's memory the key can turn. The numbers in the lock's memory can be stored individually, by inserting a controllor's key followed by the numbered key; or, a computer can load a list of authorised numbers. Although individually numbered swipe cards have been available for years storing the number on a chip is more secure because it is almost impossible to read or reprogramme the number without breaking the key. It is not available for homes yet. Several rather evident risks there. ___Pete kaiser@heron.vbo.dec.com +33 92.95.62.97 FAX +33 92.95.50.50 ------------------------------ Date: 31 Jan 1994 10:54:14 -0800 From: "Luis Valente" Subject: Safety in Telescript, Part Deux Following my posting to RISKS on January 17 entitled "Safety in Telescript" a number of readers have strongly questioned some of the statements I made in that posting. Two of those statements, in which I used casual or imprecise language, were particularly criticized: 1- "Telescript is interpreted and, thus, is safer than compiled languages." As pointed out by many readers, an interpreted language is not intrinsically safer than a compiled language. It is the Telescript language definition that provides that protection. Within the abstraction created by Telescript, programs lack operations for directly manipulating the physical resources of the "real" computer(s) on which they execute. That doesn't mean that Telescript programs cannot interact with applications (e.g., databases) outside the Telescript abstraction. However, that interaction can only take place via Telescript objects that act as proxies for the "external" applications. Each such proxy object defines the features of the corresponding external application that are to be made available to Telescript agents and places. It may also define and enforce a security policy for controlling access to those features (e.g., based on an agent's credentials and permit). Furthermore, the administrative authority for a given Telescript engine is capable of controlling (by means of mechanisms built into the language) who can and cannot create these proxy objects. 2- "Authority names are cryptographically generated and cannot be forged." Obviously, that statement is not true in an absolute sense since the "unforgeability" of the authority name is directly related to the cryptographic mechanism used to generate it. We currently use RSA-based public key cryptography for generating authority names. Entitlement to use a particular authority name can be linked to the secret key used to generate it. Aside from the criticism leveled against my poor choice of words in the aforementioned statements, several readers complained about the lack of more detailed information on the security technology used by Telescript, namely, what cryptographic algorithms are used, key sizes, key distribution and management issues, exportability issues, etc. Let me start by saying that my posting was not meant as a treatise on Telescript Technology but merely a brief description of some of the features of Telescript that can be used effectively against misprogrammed or ill-intentioned telescripts. General Magic has already published a white paper entitled "Telescript Technology: The Foundation of the Electronic Marketplace." This paper provides a high-level description of Telescript and is intended for the layman, not the techno-savvy reader. It can be requested directly from General Magic by calling (415) 965-0400. In the coming months we will publish additional information on many different aspects of Telescript Technology (including security). Let me further say that the point of my original posting was not that Telescripted networks are intrinsically secure (i.e., the "it won't happen here" syndrome). It was simply to let RISKS readers know that we have put a lot of thought into the security aspects of Telescript. In fact, when General Magic started developing Telescript, security was at the top of our list of concerns. As a result, we have built into the fabric of the language a number of features that, we believe, will enable application developers to write safe Telescript programs and network operators to run highly secure Telescripted networks. Heretofore, the discussions on RISKS have only covered a few of the many security issues faced by a dynamic, interpreted, communication-centric language like Telescript. As more detailed information on Telescript becomes widely available, I am certain it will generate heated debates on this and other forums. I look forward to them! -Luis Valente, General Magic, Inc. ------------------------------ Date: Tue, 8 Feb 1994 20:03:17 GMT From: hedlund@netcom.com (M. Hedlund) Subject: Risks of email exacerbating typos >From the New York Times, Tuesday, February 8, p. C5: E-mail apparently made a bad situation worse for Bon Marche, a department store in Washington, Oregon, Idaho, Montana, and Wyoming. The store misprinted a sale price for a Sony five-disk carousel CD player as $99, when it was intended to be $179 (on sale from $199). The NYT reports that nearly 5,000 people took advantage of the misprint, some placing paid orders once available stock had been sold. One salesman called attention to an unusual risk of email: The surge came in part because some employees at the Microsoft Corporation, based in nearby Redmond, had mentioned the deal in electronic-mail messages, he said. Although the store could have run a correction ad or posted a disclaimer, they did not; the price, according to the senior VP for marketing John Buller, "was not totally irrational for this product." I suppose the risk shouldn't keep us up nights. M. Hedlund ------------------------------ Date: Tue, 8 Feb 1994 22:23:46 -0500 (EST) From: Paul Robinson Subject: Patents Hearing as it relates to Software Those of you on the West Coast be advised that there will be a hearing on the issue of Patents as they relate to the issues of software development. The hearing is scheduled for February 10, in Room J of the San Jose Convention Center, San Jose California, starting at 9:00 or so. There will be a subsequent hearing on the East Coast a couple of days later, near the Patent Office in Crystal City, Virginia. A copy of the notice as published in the Federal Register (about 45K) was posted to several lists on the Internet almost a month ago. It is possible to go to the hearing(s) to see them, but it is too late to sign up to speak, I believe. However, comments on the Federal Register notice may be E-Mailed to Jeff Kushan . Paul Robinson - Paul@TDR.COM ------------------------------ Date: Wed, 9 Feb 1994 11:29:30 -0500 (EST) From: Steve Holzworth Subject: Network surveys et al. Craig DeForest (zowie@daedalus.stanford.edu) describes how an automated survey daemon managed to show him a list of other subscribers to a political-speech service. I had a similar, but more serious incident occur on my account with a commercial Internet access provider. The access provider (approximately 1000 users), in the interests of security, routinely runs one of the many password cracking programs against their /etc/passwd file. One day, I received Email stating that my password was weak (it was). The interesting thing about the Email is that it included a list of all recipients of the same message; the To: field was a concatenated string of all users with weak passwords... I sent Email to the operator, advising that this might not be the best strategy for dealing with the problem :-). He assured me that this was a one-time slip, due to his having used a Email command that improperly included the full distribution list... Sigh. The site DOES use a shadow password file, so it's not as bad as it could be. Steve Holzworth sch@unx.sas.com "Do not attribute to poor spelling SAS Institute x6872 That which is actually poor typing..." SAS/Macintosh Development Team - me Cary, N.C. ------------------------------ Date: Wed, 9 Feb 94 14:03:35 +0100 From: lars@eskimo.CPH.CMC.COM (Lars Poulsen) Subject: Re: Don't Trust The Phone Company (Bodine, RISKS-15.46) Tom Bodine reports the unsettling experience of being accused of making an obscene phone call, after the husband of the recipient of the call (his wife's best friend) used the "call return" feature at the end of the obscene call, and then reached his number. He speculates that his number was captured by the friend's telephone switch as the result of a failed call from his wife while the friend's line was busy with the obscene call. While such a feature interaction is possible (is the number supposed to be captured on a busy ? I know it is on a no-answer failure), there is another way for this to occur: The perpetrator may have applied the call forwarding feature on his own phone prior to making the call, and left it there for a bit afterwards. In this situation, the number that was captured would not be the Bodines', but that of the perpetrator. The effect would be the same, however, except that if the call is a billable long distance call, the number would show up on the next phone bill, and in the case of forwarding it would be the perpetrator's number (since the last leg of the call is billed to the forwarding phone). I believe that there is no such interaction problem in the case of the "calling number identification" feature, since the number is delivered in real time and only when the call rings through. Thus, the call that would come in DURING the problem call, would only be recorded if the recipient had the "call waiting" feature, and in that case would not get busy, but ringback, and the CNID (if subscribed) would be delivered between the rings (call waiting tones)). I am forwarding this note to the TELECOM DIGEST where someone from AT&T or Bellcore will probably be able to look up whether the mechanism surmised by Tom Bodine is also possible. I hope that this technical information will go some way towards repairing relations between the families. ------------------------------ Date: Wed, 9 Feb 94 18:55 GMT From: "D.R.NEWMAN" Subject: Re: "Misunderstanding" a CERT advisory Expect journalistic exaggeration. 2 people died in a cyclone on the island of Mauritius in the 1970s. In the Kenyan papers this was 20 - in the British papers 200. Now if CERT sued for libel and got damages, that might get the journalists to check their facts! Dr. David R. Newman, Queen's University, Information Management Dept., BELFAST BT7 1NN, Northern Ireland. ------------------------------ Date: Wed, 9 Feb 94 08:28:38 MET From: Technology Strategy & Architecture Subject: Re: Clipper Petition Someone of my acquaintance (who doesn't care to be identified here) sent in a response to CPSR's Clipper petition and received a full and explanatory confirmation from CPSR at the address from which it was sent. So if CPSR is also culling out signatures from bogus addresses, those two measures together are a good beginning. ___Pete kaiser@heron.vbo.dec.com +33 92.95.62.97 FAX +33 92.95.50.50 ------------------------------ Date: Wed, 9 Feb 1994 11:11:00 +0000 From: "john (j.g.) mainwaring" Subject: Re: Clipper Petition In Risks issue 46, David Gursky mentions the possibility that some of the responses to the CPSR petition will be of the "Vote early, vote often" variety, and goes on to cite previous discussion of the risks of dial up voting. Petitions are not votes. CPSR does not claim to be collecting votes on Clipper and tallying the ayes, nays and throat clearings. Petitions are an unsupervised form of expression. The older paper variety could be padded pretty easily too. Other risks associated with petitions (electronic or not) include the possibility of bias in the question to manipulate response: "Even though the President claims to have stopped beating his wife, it is the opinion of responsible rabble rousers in this great country that..." Anybody who's been in politics even as long as our present youthful president knows that petitions can be manipulated, and adds salt accordingly. The theatrical value of collecting a petition about the electronic superhighway in the rest stops of the present byways is obvious. The strong risk that the petition will include invalid responses needs to be weighed against the risk of having an unnecessarily expensive and possibly untrustworthy security system in future. Or does anyone believe that Clipper would make collecting petitions safe from democracy? ------------------------------ Date: Wed, 9 Feb 94 10:39:22 -0500 From: firth@SEI.CMU.EDU Subject: Re: Altered White House Documents (Roberts/Crawford, RISKS-15.46) RISKS-15.46 reports on how an electronic document available from whitehouse.gov was surreptitiously changed without any visible audit trail. The relevant quote came to mind immediately: "He who controls the past controls the future." I believe the answer is an independent party that will daily download all documents from this site and systematically scan for similar attempts to revise history. ------------------------------ Date: 8 Feb 1994 17:26:04 -0500 From: lan@panix.com (Larry Nathanson) Subject: Re: Altered White House Documents (Roberts/Crawford, RISKS-15.46) Perhaps a site on the net with a little bit of spare disk space would like to mirror this site??? I know I'd find the 'diff's more informative than the speeches themselves. ------------------------------ Date: 7 Feb 1994 17:34:17 -0600 From: mech@eff.org (Stanton McCandlish) Subject: EFF Wants You (to add your voice to the crypto fight!) The Electronic Frontier Foundation needs your help to ensure privacy rights! * DISTRIBUTE WIDELY * Monday, February 7th, 1994 From: Jerry Berman, Executive Director of EFF, jberman@eff.org Dear Friends on the Electronic Frontier, I'm writing a personal letter to you because the time has now come for action. On Friday, February 4, 1994, the Administration announced that it plans to proceed on every front to make the Clipper Chip encryption scheme a national standard, and to discourage the development and sale of alternative powerful encryption technologies. If the government succeeds in this effort, the resulting blow to individual freedom and privacy could be immeasurable. As you know, over the last three years, we at EFF have worked to ensure freedom and privacy on the Net. Now I'm writing to let you know about something *you* can do to support freedom and privacy. *Please take a moment to send e-mail to U.S. Rep. Maria Cantwell (cantwell@eff.org) to show your support of H.R. 3627, her bill to liberalize export controls on encryption software.* I believe this bill is critical to empowering ordinary citizens to use strong encryption, as well as to ensuring that the U.S. software industry remains competitive in world markets. Here are some facts about the bill: Rep. Cantwell introduced H.R. 3627 in the House of Representatives on November 22, 1993. H.R. 3627 would amend the Export Control Act to move authority over the export of nonmilitary software with encryption capabilities from the Secretary of State (where the intelligence community traditionally has stalled such exports) to the Secretary of Commerce. The bill would also invalidate the current license requirements for nonmilitary software containing encryption capabilities, unless there is substantial evidence that the software will be diverted, modified or re-exported to a military or terroristic end-use. If this bill is passed, it will greatly increase the availability of secure software for ordinary citizens. Currently, software developers do not include strong encryption capabilities in their products, because the State Department refuses to license for export any encryption technology that the NSA can't decipher. Developing two products, one with less secure exportable encryption, would lead to costly duplication of effort, so even software developed for sale in this country doesn't offer maximum security. There is also a legitimate concern that software companies will simply set up branches outside of this country to avoid the export restrictions, costing American jobs. The lack of widespread commercial encryption products means that it will be very easy for the federal government to set its own standard--the Clipper Chip standard. As you may know, the government's Clipper Chip initiative is designed to set an encryption standard where the government holds the keys to our private conversations. Together with the Digital Telephony bill, which is aimed at making our telephone and computer networks "wiretap-friendly," the Clipper Chip marks a dramatic new effort on the part of the government to prevent us from being able to engage in truly private conversations. We've been fighting Clipper Chip and Digital Telephony in the policy arena and will continue to do so. But there's another way to fight those initiatives, and that's to make sure that powerful alternative encryption technologies are in the hands of any citizen who wants to use them. The government hopes that, by pushing the Clipper Chip in every way short of explicitly banning alternative technologies, it can limit your choices for secure communications. Here's what you can do: I urge you to write to Rep. Cantwell today at cantwell@eff.org. In the Subject header of your message, type "I support HR 3627." In the body of your message, express your reasons for supporting the bill. EFF will deliver printouts of all letters to Rep. Cantwell. With a strong showing of support from the Net community, Rep. Cantwell can tell her colleagues on Capitol Hill that encryption is not only an industry concern, but also a grassroots issue. *Again: remember to put "I support HR 3627" in your Subject header.* This is the first step in a larger campaign to counter the efforts of those who would restrict our ability to speak freely and with privacy. Please stay tuned--we'll continue to inform you of things you can do to promote the removal of restrictions on encryption. In the meantime, you can make your voice heard--it's as easy as e-mail. Write to cantwell@eff.org today. Sincerely, Jerry Berman, Executive Director, EFF jberman@eff.org P.S. If you want additional information about the Cantwell bill, send e-mail to cantwell-info@eff.org. To join EFF, write membership@eff.org. For introductory info about EFF, send any message to info@eff.org. The text of the Cantwell bill can be found on the Internet with the any of the following URLs (Universal Resource Locaters): ftp://ftp.eff.org/pub/Policy/Legislation/cantwell.bill http://www.eff.org/ftp/EFF/Policy/Legislation/cantwell.bill gopher://gopher.eff.org/00/EFF/legislation/cantwell.bill It will be available on AOL (keyword EFF) and CIS (go EFFSIG) soon. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From: Stanton McCandlish Subject: Administration adopts coldwar mentality, pushes for Clipper EFF Press Release Feb 4 '94 * DISTRIBUTE WIDELY * At two briefings, Feb. 4, 1994, the Clinton Administration and various agencies gave statements before a Congressional committee, and later representatives of civil liberties organizations, industry spokespersons and privacy advocates. The Electronic Frontier Foundation's position, based on what we have seen and heard from the Administration today, is that the White House is set on a course that pursues Cold War national security and law enforcement interests to the detriment of individual privacy and civil liberties. The news is grim. The Administration is: * not backing down on Clipper * not backing down on key escrow * not backing down on selection of escrow agents * already adamant on escrowed key access procedures * not willing to eliminate ITAR restrictions * hiding behind exaggerated threats of "drug dealers" and "terrorists" The material released to the industry and advocacy version of the briefing have been placed online at ftp.eff.org (long before their online availability from government access sites, one might add). See below for specific details. No information regarding the Congressional committee version of the briefing has been announced. EFF Director Jerry Berman, who attended the private sector meeting, reported the following: "The White House and other officials briefed industry on its Clipper chip and encryption review. While the review is not yet complete, they have reached several policy conclusions. First, Clipper will be proposed as a new Federal Information Processing Standard (FIPS) next Wednesday. [Feb. 9] It will be "voluntary" for government agencies and the private sector to use. They are actively asking other vendors to jump in to make the market a Clipper market. Export licensing processes will be speeded up but export restrictions will not be lifted in the interests of national security. The reason was stated bluntly at the briefing : to frustrate competition with clipper by other powerful encryption schemes by making them difficult to market, and to "prevent" strong encryption from leaving the country thus supposedly making the job of law enforcement and intelligence more difficult. Again in the interest of national security. Of course, Clipper will be exportable but they would not comment on how other governments will view this. Treasury and NIST will be the escrow agents and Justice asserted that there was no necessity for legislation to implement the escrow procedures. "I asked if there would be a report to explain the rationale for choosing these results - we have no explanation of the Administration's thinking, or any brief in support of the results. They replied that there would be no report because they have been unable to write one, due to the complexity of the issue. "One Administration spokesperson said this was the Bosnia of Telecommunications. I asked, if this was so, how, in the absence of some policy explanation, could we know if our policy here will be as successful as our policy in Bosnia?" The announcements, authorization procedures for release of escrowed keys, and q-and-a documents from the private sector briefing are online at EFF. They are: "Statement of the [White House] Press Secretary" [White House] file://ftp.eff.org/pub/EFF/Policy/Crypto/wh_press_secy.statement "Statement of the Vice President" [very short - WH] file://ftp.eff.org/pub/EFF/Policy/Crypto/gore_crypto.statement "Attorney General Makes Key Escrow Encryption Announcements" [Dept. of Just.] file://ftp.eff.org/pub/EFF/Policy/Crypto/reno_key_escrow.statement "Authorization Procedures for Release of Encryption Key Components in Conjunction with Intercepts Pursuant to Title III/State Statutes/FISA" [3 docs. in one file - DoJ] file://ftp.eff.org/pub/EFF/Policy/Crypto/doj_escrow_intercept.rules "Working Group on Data Security" [WH] file://ftp.eff.org/pub/EFF/Policy/Crypto/interagency_workgroup.announce "Statement of Dr. Martha Harris Dep. Asst. Secy. of State for Polit.-Mil. Affairs: Encryption - Export Control Reform" [Dept. of State] file://ftp.eff.org/pub/EFF/Policy/Crypto/harris_export.statement "Questions and Answers about the Clinton Administration's Encryption Policy" [WH] file://ftp.eff.org/pub/EFF/Policy/Crypto/wh_crypto.q-a These files are available via anonymous ftp, or via WWW at: http://www.eff.org/ in the "EFF ftp site" menu off the front page. Gopher access: gopher://gopher.eff.org/ Look in "EFF Files"/"Papers and Testimony"/"Crypto" All 7 of these documents will be posted widely on the net immediately following this notice. Contacts: Digital Privacy: Jerry Berman, Exec. Director Daniel J. Weitzner, Sr. Staff Counsel Archives: Stanton McCandlish, Online Activist General EFF Information: info@eff.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From: Stanton McCandlish Subject: EFF Cantwell campaign update - a torrent of responses EFF's "Letter to Cantwell" campaign, to collect and send letters to Rep. Cantwell in support of her bill to ease export restrictions on cryptography, collected more that *five hundred* responses the first day along, and at 5pmEST Tue. (2/8/94), was gaining more at a rate approaching 100 per *hour*. To add your voice to this clear signal to Rep. Cantwell that her legislation (bill HR 3627) is on the right track, send a message with a subject line of "Subject: I support HR 3627" to cantwell@eff.org Stanton McCandlish * mech@eff.org * Electronic Frontier Found. OnlineActivist INFO@EFF.ORG FOR INFO: OPEN PLATFORM, ONLINE RIGHTS, VIRTUAL CULTURE, CRYPTO ------------------------------ Date: ongoing From: RISKS-request@csl.sri.com (PGN in disguise) Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. PLEASE read it as a newsgroup if possible and convenient for you. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line; others may be ignored! Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially .UUCP folks. If you cannot read RISKS locally as a newsgroup (e.g., comp.risks), or you need help, send requests to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS". Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousYourName CD RISKS:GET RISKS-i.j" (where i=1 to 15, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is vital. 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. 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 . 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. ------------------------------ End of RISKS-FORUM Digest 15.47 ************************