Subject: RISKS DIGEST 16.89 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 10 March 1995 Volume 16 : Issue 89 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Celsius-to-Fahrenheit conversion risk (Michael Tobis) Two on net porn charges (Jonathan Bowen) Re: 6-cent T-shirts (Evelyn C. Leeper) Re: Remote-Control Risks (Mike Cavanagh) Consumer electronic problems (Les Hatton) Can Pakistan Eavesdrop in America? (Peter Wayner) Sow's Ear from a Purse (Joseph H Presley) Resetting BSD/OS is easy as resetting MS-DOS (Re: Sparc10) (Kenji Rikitake) Re: Microsoft and Lotus spreadsheet errors (Tony Lauck) Loss of one of the X-31 research airplanes (Peter Ladkin) PGP Moose: moderator authentication and antispamming tools (Greg Rose) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 8 Mar 95 18:15:15 CST From: tobis@skool.ssec.wisc.edu (Michael Tobis) Subject: Celsius-to-Fahrenheit conversion risk I thought the RISKS readership shouldn't miss this gem, posted in sci.geo.meteorology by stevenb@pauli.jhuapl.edu (Steven Babin at Johns Hopkins University Applied Physics Laboratory): > There seems to be some confusion over the giant iceberg. [...] > The Reuters news agency reported that the iceberg was 656 feet 2 > inches thick, implying a tremendous accuracy of measurement. It > is actually 200 m thick and the reporter converted this to English > units. Reuters also reported that this event was the result of a > 36.5 F increase in temperature since the 1940's. It was actually > a 2.5 C increase. The reporter apparently converted this to F > as a temperature rather than a temperature difference. > I don't know whether this speaks more for the educational level of > reporters or more for the fact we should all be using SI units. The risks of the transmission of technical information by people who don't know what they are talking about will be familiar to RISKS readers. Perhaps more striking is the risk that something as simple as a Celsius to Fahrenheit conversion algorithm can be misused by making invalid assumptions about context. Michael Tobis tobis@skool.ssec.wisc.edu [And the mention of SI reminds me of Steve Lipner's OLD joke about being an SI, namely a Civil Engineer. (For those of you who don't get it, sivil injinears are not supposed to be able to spell.) PGN] ------------------------------ Date: Fri, 10 Mar 95 13:13:31 GMT From: Jonathan.Bowen@comlab.oxford.ac.uk Subject: Two on net porn charges Newspaper: The Times Higher Education Supplement URL: http://www.timeshigher.newsint.co.uk/ Reference: page ii, Multimedia news section, 10 March 1995 Headline: Two on net porn charges An 11-month investigation by West Midlands police has led to two men being charged with distributing child pornography on the Internet. The charges arise from a raid by police on the metallurgy department at Birmingham University following information on child pornography passed to them by federal authorities in the United States. ... The prosecution is seen as [a] test case on what can be legally transmitted globally across the network from computer hosts. Jonathan Bowen, Oxford University Computing Laboratory, Programming Research Group, Wolfson Building, Parks Road, Oxford OX1 3QD, England. ------------------------------ Date: Thu, 9 Mar 1995 19:50:44 GMT From: ecl@mtgp003.mt.att.com (Evelyn C. Leeper) Subject: Re: 6-cent T-shirts > we end up with .06 cent t-shirts and free shallots. XXXXXXXX This is a pet peeve of my husband's (and by extension, of mine, I suppose). He keeps trying to explain to the clerks why they should sell him that two-liter bottle of Coke for a cent, when the sign says, ".99c" ("c" actually being a cents-sign). The Risks in this? I suppose it's the risk that if people have turned over all their computing to machines and don't even *think* about where the decimal point should go, then we're all in trouble. Evelyn C. Leeper | +1 908 957 2070 | Evelyn.Leeper@att.com ------------------------------ Date: Thu, 9 Mar 1995 02:18:41 +0100 (GMT) From: mike Subject: Re: Remote-Control Risks I was interested to see the examples of optical remote-control systems being upset by other light sources. In my student days I worked as a TV engineer in holidays. A customer complained that his set would randomly switch channels. Several weeks of to-ing and fro-ing to the workshop failed to find a problem. Eventually the cause was found. The customer kept budgies in an aviary outside the window next to the TV. The set had an ultrasonic remote control. The budgies were setting off the remote. If you made the budgies tweet, the set changed its channel. These risks are still there 20 years later. Mike Cavanagh [A new Hallowe'en motto: Click or tweet? With the new noise-cancellation techniques, the challenge is how to balance the budgies. PGN] ------------------------------ Date: 10 Mar 1995 11:44:38 +0000 From: Les Hatton Subject: Consumer electronic problems Has anybody heard of consumer electronic stuff being recalled because of software problems yet? The reason I ask is that most such products will have massive amounts of software in them by the end of the decade, (many tens of thousands of lines in such things as televisions, cars, washing machines, electric razors and so on). As an example: In August'94 I rented a Vauxhall Omega car for 1 month. This car was brand new and consequently has a number of micro-processor controlled systems. In the first week, the sun-roof started to oscillate (in the rain!). The sun-roof is a simple rotating switch which you turn to the position you want the roof and then leave it to move there. Mildly concerned and alternately dampened by this, my eldest son figured out that by pushing the button, the roof reset. On looking through the manual, in tiny writing at the back, this featurette was described, "in case of some circumstances when the sun-roof ...". One week later, I discovered one morning that the car was completely without power - not even the control panel lights came on. A volt-meter revealed that the battery was perfectly OK. A call to the RAC (Royal Automobile Club, a UK organisation that operates a rescue service like the US. AAA), brought an engineer out who said it was one of two things, one of which he could fix. He moved the drive lever from Park to Drive and back and all the lights came on and the engine would then start. (The drive train is also controlled by a microprocessor in this car). I asked him what was the one he couldn't fix. He said that on this model, the auto immobiliser (the cute little button on the key ring) could in some circumstances at the edge of its range so immobilise the car that only the factory could get it going, (the ultimate theft deterrent!). I suspect that this is also controlled by a microprocessor. In fact on this car, the radio is controlled by two microprocessors ! In terms of reliability growth modelling, one person experiencing two defects and hearing of another in just one month in one car adds up to a shaky reliability record. Hence my question at the beginning. Maybe its just me, because I'm in the profession. Les Hatton, Ph.D. C.Eng, Director of Research & Engineering, Programming Research Ltd, England les_hatton@prqa.co.uk +44 (0) 1 932 888 080 ------------------------------ Date: Thu, 9 Mar 1995 14:44:35 -0500 From: pcw@access.digex.com (Peter Wayner) Subject: Can Pakistan Eavesdrop in America? RISKS-16.88 includes a transcript of a Voice of America broadcast describing Pakistan's hardball play to get access to Motorola's best cellular eavesdropping technology. The transcript says that Pakistan shut down Motorola's cellular service until it got the device that would let them eavesdrop on all conversations. I'm not sure if Motorola complied, but I hope that someone asked these questions: 1) Can this eavesdropping hardware work in the United States? Many speculate that Pakistan wants to be (or is) a member of the nuclear club of nations. When a Princeton undergraduate designed a nuclear bomb for credit, he was visited by someone who seemed to be a Pakistani intelligence operative. The goal? Nuclear information. 2) Can this eavesdropping hardware work against Motorola? Industrial espionage is a popular way for countries to do "research." Does Pakistan want to build up a local electronics company? 3) Can this eavesdropping hardware be used against US companies angling for business in Pakistan? 4) Will the technology make its way into the hands of the terrorists? Several days ago, US citizens were killed in an ambush. The dead included at least one intelligence operative. Today's Washington Post says that some witnesses claimed a police car with a submachine gun mounted on the top stood by idling and let the killers get away. The excuse is that they were afraid. The ambush was supposedly retaliation for the US capture of terrorists. Years ago, we only needed to worry about whether we could trust our immediate neighbors and the other folks in town. Now trust is a global game. ------------------------------ Date: Fri, 10 Mar 95 10:39:21 EST From: presley@whserva.wh.att.com (Joseph H Presley) Subject: Sow's Ear from a Purse (Tepper, RISKS-16.88) A zealous and unscrupulous prosecutor could "prove" that the KJV (King James Bible) is obscene by using a mask of A=[KJV xor obscene]. [A xor KJV] gets you the obscene file. Can you imagine trying to prove that you didn't just erase your encryption mask to a technologically naive jury? I should also mention that you could transmit A as your file and your recipient use KJV as the encryption mask. Joe Presley ------------------------------ Date: Fri, 10 Mar 1995 13:17:25 +0900 From: Kenji Rikitake Subject: Resetting BSD/OS is easy as resetting MS-DOS (Re: Sparc10 keyboards) The Sparc10 story reminds me of my 486 PC running BSD/OS; it was configured to ask for rebooting if you press CTRL+Alt+Delete as default. I immediately disabled this feature. I even consider this a bug, although you can fix it by recompiling the kernel. Think about this. Most MS-DOS users know CTRL+Alt+Delete, and many of them just do it if they think they have done something wrong with their PCs. And few of them know the difference between MS-DOS and BSD/OS; what if they start to use BSD/OS? Rebooting everytime they think they've got crashed? BSD/OS has another design flaw on its X server. You can terminate it anytime by pressing CTRL+Alt+Backspace. This is enabled as default, though you can turn this off by its configuration file. I respect flexibility of UNIX, but it's obviously dangerous to enable emergency-stop features to everybody. // Kenji Rikitake ------------------------------ Date: Thu, 09 Mar 1995 09:46:17 -0500 From: tlauck@CERF.NET (Tony Lauck) Subject: Re: Microsoft and Lotus spreadsheet errors Errors in financial calculations are not new. When I worked at Autex, Inc. in the early 70's I wrote a program to calculate bond tables. I was told that my calculations, right or wrong, had to agree with a certain book that all the traders used. Bond prices were given in dollars and cents and I was told that a difference of one cent was unacceptable. A one cent error in a large trade could easily cost more than a Wall Street lunch for two, hence was significant. The bond table book gave the formula used and indicated the method of rounding. It was very easy to duplicate these calculations, but would they agree using a different processor? By printing out my own version of the book and comparing each entry by hand I found only a single error, in the amount of one cent. In the early 70's fancy desk calculators still ruled. The one I happened to have had a switch that controlled rounding mode (down, up, halfway) so it could do interval arithmetic. Cranking the calculation on this calculator to 15 digits I was able to bound the correct value. It was almost exactly halfway between two pennies, and my rounding was correct. (This didn't surprise me as I had used 64 bit floating point, a large number of guard digits indeed for a four decimal place answer.) Knowing that I was right and the book wrong was a nice position. I discussed this with my boss and we decided to stick with our value. I secretly hoped there would be a dispute someday between two traders over this entry, figuring that I could somehow turn this into a nice lunch. No such chance. Do people still use these old tables? How many have errors? ------------------------------ Date: Mon, 6 Mar 1995 00:22:37 +0100 From: ladkin@techfak.uni-bielefeld.de Subject: Loss of one of the X-31 research airplanes Flight International, 1-7 February 1995, reports the loss of a Rockwell-Daimler-Benz Aerospace X-31A enhanced fighter-manoeuverability research aircraft on 19 January 1995. `Investigations [..] are focusing on the air-data system, say sources close to the project. "There is a possibility that hardware operation of some of the systems may be involved [and] it cannot be excluded that the instruments were giving false readings," says one source, adding that there is no indication that the aircraft's advanced flight control system was involved [..].' Flight International, 8-14 February 1995, reports that investigations are centred on the pitot-static system (which measures altitude and airspeed by means of pressure differentials, and that pitot icing is suspected by some. `The aircraft was [...] in straight-and-level flight, when [the pilot] detected false airspeed readings, followed by pitch oscillations. These increased and were followed by a violent roll before [the pilot] ejected.' So, investigators suspect that false sensor readings caused by icing-up of the sensors led to inappropriate actions of the flight control system which led to loss of control. Generally, airplanes which may fly in instrument conditions, i.e. clouds, including my Piper Archer, are equipped with pitot heat to avoid similar problems, but if my pitot ices up, all I lose is my airspeed indicator, and not my control. A colleague who is a Chief Engineer at NASA Dryden, where the accident took place, points out that airplanes such as F4s, which are not fly-by-wire airplanes, have also been lost when false sensor readings led to inappropriate actions of the flight control system - but in the case of an F4 it is a mechanico-hydraulic system rather than a computer. She suggests that a distinction be made between the flight control system itself, which implements the control laws, and the system that sends signals to the actuators to wiggle the control surfaces. While we may not be able to ascribe the `fault' to a `computer' in this case, it does raise the continuing issue as to how one ascribes faults. It is always possible in theory to replace a computer control system by wires, pulleys, hydraulics, bells and whistles - but not to fit all this hardware in the same airplane all at the same time. For example, Airbus argues that its computer-controlled airplanes are `evolutionary', that is, the same control characteristics could be achieved with more traditional control systems - and the only consequence of computer control is weight savings, and therefore extended range or the ability to carry more passengers. This is debatable. The more interconnection between systems contributing to control (possible when most things are software unless extreme care is taken), the more opportunity for an inappropriate sensor reading to send everything haywire. The X-31 would not be able to fly without computer control. It is true that any individual system fault may be replicated by means of wires, pulleys and hydraulics. But I doubt that this knowledge would help anyone to analyse the fault and prevent its reoccurrence. I suspect that techniques developed by computer scientists for dealing with safety-critical computers are more useful. Whereas in the case of my Archer, only plumbers would be involved ........ Peter Ladkin ------------------------------ Date: 10 Mar 1995 20:28:33 +1000 From: Greg_Rose@sibelius.sydney.sterling.com (Greg ROSE) Subject: PGP Moose: moderator authentication and antispamming tools -----BEGIN PGP SIGNED MESSAGE----- PGP Moose ========= by Greg Rose The aim of this software is to monitor the contents of consenting moderated newsgroups, and to automatically cancel messages that appear in the newsgroup without having been authorised by the moderator(s) of the group. This has (obviously) been prompted by the recent spammings. PGP, the crux of the cryptographic software, was written by Phil Zimmermann , who otherwise has nothing to do with this. The cryptographic framework was written by Greg Rose . The INN news system hooks are being provided by Chris Lewis . How Does It Work? - ----------------- When a moderator wants to protect their group from forged/unapproved postings, they should register their interest with one or more of the sites running PGP Moose, and pick up the submission script. As part of this process, the moderator would specify a PGP public key that is allowed to approve postings. When a post comes in, and the moderator wishes to approve it, they do whatever they would normally do before actually using inews (or whatever) to post the message. As their last action, they run the PGP Moose Approval program "pmapp". This inserts a special form of Approved: header which looks like this: Approved: PGP Moose V0.9 950310 sci.crypt.research iQBVAgUBL1/Kg2zWcw3p062JAQEYIgH/Xyrz6LaGG+fHaSxoexMECovzkIoADrQx l73IXlUQEIoFl5jnDBBdHVvqTMEPS0118ytYVQZoQrdStuXB9Oc9gQ== =azqs In this example you can see that the approval carries a date stamp and the name of the newsgroup in question. These, as well as the From: and Subject: lines, and the non-blank lines of the message itself, are used as input to the PGP program to generate a signature. The PGP signature is the inserted into the Approved: header, mostly so that it won't interfere with, or be confused with, any signature in the body of the message. Anybody can check whether the message has been modified in any significant way, simply by running the PGP Moose Approval Checking program "pmcheck". More importantly, though, the sites running the PGP Moose Checking Daemon will be doing this automatically for every posting to the registered newsgroups. And, if a posting fails the checks, it will be automatically cancelled and a notification sent to the moderator. This software is made freely available for just about any purpose, but I've retained copyright so as to keep some semblance of involvement. See the last section of this file. The Bits: - --------- PGP Moose consists of a number of Bourne Shell scripts calling standard Unix utilities and PGP. I could have used perl more elegantly, but this stuff is marginally more widely available. If there are Unix version dependencies, they should be considered to be bugs and I'll happily attempt to remove them. pmapp usage: pmapp newsgroup [file] This script takes the not-yet-posted article, specified either by filename or from standard input, and creates a signature for it, which is then inserted in the Approved: header. The article, ready for posting, appears on the standard output. In the configuration section at the top of the script, the moderator may build in the PGP User Id to be used for the signature, and the corresponding password. This is simply for convenience, since spammers are not so likely to go cracking the computer to get the password, and it is a relatively simple matter to generate a new user if it is, indeed, compromised. For the paranoid, like myself, if the password is not configured into the script it is read from the terminal instead. pmcheck usage: pmcheck [article] This script takes the article, specified either by filename or from standard input, and checks that the Approved: line is something it considers to be correct and that the article has not been tampered with. Pmcheck returns successfully if everything checks out. Otherwise it will return failure and issue one of a number of error messages, for example: Usage: $0 [article] Posting not approved with PGP Moose. Wrong newsgroup: $6 != $GROUP. Bad signature (altered or damaged file) on $FILE. Signature '$SIG' on $FILE invalid for newsgroup $GROUP. Anybody can run pmcheck. It behaves slightly differently depending on the existence of a file called (by default) PGP_Moose_accept. This file, if it exists, should contain lines with a newsgroup name, some whitespace, and the PGP User Id approved by the moderator (usually made up specifically for this purpose). For example: sci.crypt.pgpmoose pgpmoose test If such a file exists, pmcheck is silent if all is well, and issues the last of the error messages above if everything else was all right but the signature was from the wrong person. Without such a file, if the signature is otherwise valid you will get a message like: Valid signature from '$SIG'. A script is being developed by Chris Lewis (who has more control over news stuff than I do) which will perform the automatic cancellations. Stay tuned. There is plenty of prior art, so this shouldn't take too long. Soon, when I get back from my trip in two weeks, I will create mail server scripts that allow moderators who are not using Unix to use these facilities. The first allows a moderator to mail a PGP signed copy of the article to be posted. The server will then verify that the moderator sent it, and post it with a (different but corresponding) approval. The second will accept an article and return something that you can check the signature on. Either way, any moderator will still need PGP. How Do You Register For The Service? - ------------------------------------ Ahhh, this is the hard part. After all, it would be pretty undesirable if someone, meaning well, took any old body's word for it that some important moderated group should start working this way, before the moderator was able to start approving postings. A great way to hijack a newsgroup. Another possibility is that someone, having seen what the valid signature looks like, simply creates a whole new PGP key that happens to have the same PGP User ID. Then they can sign and post stuff too. The solution to both of these problems is the classical one for public key systems. You need either a certifying authority or the PGP Web of Trust. We're using the Web of Trust. If you don't understand about PGP and the Web of Trust, go away now and come back after you really do understand it. For each newsgroup that wants to utilise this program, the moderator will have to create a special PGP key pair (preferably 512 bits to keep the Approved: lines short), and sign it. They must then establish a path of trust to someone who is running the PGP Moose server. It will be up to the administrator of that server to make sure that only trusted moderators' keys ever get into the server's keyring. THERE CAN BE NO SHORTCUTS TO THIS PROCEDURE. Otherwise we are all back where we started. What If You Have Multiple Moderators? - ------------------------------------- Simple. Create one PGP key pair which can approve posting, and share it among the moderators. You have to exchange it securely, but by definition you have PGP, so that shouldn't be too hard. You can still tell which moderator approved a posting from the Sender: line. Possible Problems We've Forseen: - -------------------------------- If an article is mangled e.g. by truncation, it will fail the authentication and be cancelled. Until it is demonstrated otherwise, this is assumed to be a rare and minor problem. When a cancel is issued, mail is sent to the moderator of the group telling them, and they can tell us if it becomes a problem. Currently the signature produced is assumed to be a PGP version 2.6 compatible one. The moderated newsgroup in question must be the first newsgroup on the Newsgroups: line; as a corollary it is not possible at the moment for an approved posting to multiple moderated newsgroups. Only one PGP User Id can approve postings to a particular group. This means that that PGP User's private key must be shared between all of the moderators, with all of the attendant risks. Status: - ------ These scripts are implemented already, or as noted above. They are undergoing testing by Chris Lewis , and as soon as they have settled (within a week for sure) they will be made available via anonymous FTP and posting to comp.sources.misc and sci.crypt.research. It Really Wasn't That Hard. - --------------------------- I wish people (other than me and Chris Lewis) had put as much effort into doing this as they did into clogging the Moderators' mailing list. It wasn't hard. But you know what was hard? What Phil Zimmermann did creating PGP in the first place. Phil is in serious legal hassles over PGP, and if you think this effort saves you or your company some time or money, I'd like you to consider donating some of it to Phil's legal defence fund. Write to me or Phil's lawyer Phil Dubois regarding how to donate. You can do it over the net using PGP! Share and Enjoy! License Terms - ------------- This software is copyrighted by Sterling Software, and other parties. The following terms apply to all files associated with the software unless explicitly disclaimed in individual files. The authors hereby grant permission to use, copy, modify, distribute, and license this software and its documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this software may be copyrighted by their authors and need not follow the licensing terms described here, provided that the new terms are clearly indicated on the first page of each file where they apply. IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBL2Ao0aRQkCwJ0+ZNAQEC5QQAzYC388xAkKCG+737mOLH0Bg3vbPnlSPO 4epkvW7GD6HyaCUq34mhqYx2h1gCn4ywRG0bTZbjOyEMjU9d78Xyar/abu+jkMGc umwwbcNHssYfsHMsfbrUR8vVz2C8+5ULUyavN9aNRIlFTpekWGklYfa+NGtIB84I Xr9QW8Y2TqY= =tjMn -----END PGP SIGNATURE----- Greg Rose, Sterling Software, 28 Rodborough Rd., French's Forest. NSW 2086 Australia. +61-2-975 4777 (FAX: +61-2-975 2921) greg_rose@sydney.sterling.com ------------------------------ Date: 6 February 1995 (LAST-MODIFIED) 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 (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains 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, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] 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. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymousYourName cd risks or cwd risks, depending on your particular FTP. Issue J of volume 16 is in that directory: "get risks-16.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 15, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 16.89 ************************