precedence: bulk Subject: RISKS DIGEST 19.27 RISKS-LIST: Risks-Forum Digest Friday 1 August 1997 Volume 19 : Issue 27 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, caveats, etc. ***** Contents: 45,000 GSM phones recalled for software upgrade (Veliddin Eran Sezgin) 24 more California DMV clerks fired in fraudulent license scheme (PGN) Another phony-fax get-out-of-jail scheme (PGN) Offshore Internet gambling taking *off* (PGN) Strong Capital sues alleged hacker-spammers (Mich Kabay) Risks of ordering airline tickets online (Craig Macbride) What to do about software patents () Re: AOL customer phone-number availability (Bill Seurer) Political vs Technical Errors in CA Megan's Law CD ROM (Ed Wright) Re: The dangers of Explorer-ation (Steve Loughran) Re: DEC Alpha Bug: Intel x86 FPU Diagnostics (Steven Healey) Re: DEC Alpha Bug, final resolution (Daniel A. Graifer, David R Brooks) Re: General Mills, AOL, Chex Quest (Steve Lumos, Doug Linder, Padgett Peterson) Re: Y2K: a different solution (Robert J. Sandler, Dave Weingart) CfP: Y2K in Health Informatics Journal (M.F. Smith) "CyberLaw: The Law of the Internet" by Rosenoer (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sun, 27 Jul 1997 12:00:00 -0700 (PDT) From: Veliddin Eran Sezgin Subject: 45,000 GSM phones recalled for software upgrade Recent newspaper ads recalled Ericsson GF-788 GSM phones for a software upgrade to remediate a software bug. This particular Ericsson GSM model was losing base-station signals and shutting itself off in "emergency call" mode, while other brands work fine. It should be switched off and on again to operate. Consumers' complaints about the GF-788 eventually led the company to run the ads. Well over 45,000 units have been sold in Turkey. Some European countries (like Austria and Greece) have banned import of that model GSM until the software is fixed. (Turkey has over 700,000 GSM customers.) [Source: The Turkish daily newspaper, *Hurriyet*] ------------------------------ Date: Fri, 1 Aug 97 10:45:10 PDT From: "Peter G. Neumann" Subject: 24 more California DMV clerks fired in fraudulent license scheme The California DMV has fired 24 more clerks who accepted bribes to issue driver's licenses fraudulently. This brings the total to 79 in the current statewide probe, Operation Clean Sweep. The going rate was $200 to $1000 a pop for not checking the applicant's identity, typically paid by illegal aliens, felons needing new identities, and drivers with revoked licenses. [Source: *San Francisco Chronicle*, 1 Aug 1997, A25] ------------------------------ Date: Fri, 1 Aug 97 11:18:42 PDT From: "Peter G. Neumann" Subject: Another phony-fax get-out-of-jail scheme Richard Foster, jailed for driving with a suspended licence, was set free from South Carolina's Richland County jail -- based on a fax with an ``official-looking sheriff's letterhead''. The fax stated that Georgia's Augusta-Richmond County Sheriff's Office had no interest in Foster. (Actually, at that time he was wanted on assault and weapons charges.) The fax had been sent from a public fax machine at a Kroger grocery store in Augusta GA, and had the Kroger name and phone number on the fax. As a result of this spoof, the jail supervisor has been demoted from captain to sergeant. [Source: *San Francisco Chronicle*, 23 Jul 1997, A2] [This is a case where you can have your authenticate and eat it too? Is this another argument for better authentication? Well, it certainly suggests greater suspicion of faxes.] Similar cases are recorded in RISKS in March 1997 in Florida (RISKS-18.94), and in December 1991 in Tucson AZ (RISKS-12.70). That's THREE (at least). ------------------------------ Date: Fri, 1 Aug 97 9:56:21 PDT From: "Peter G. Neumann" Subject: Offshore Internet gambling taking *off* There are now at least three dozen Internet gambling houses, the latest of which -- Bet the Net -- begins operating as an Internet casino from Dominica in the Caribbean in about two weeks. The expected revenues from all such Internet operations is estimated at $8 billion by the year 2000, where the current total take for U.S. casinos is currently $23 billion. [Source: Bloomberg News, *San Francisco Chronicle*, 1 Aug 1997, B2.] The risks include bogus virtual casinos whose payoffs turn out to be more virtual than real, semi-legitimate casinos working credit-card scams on the side, glorious opportunities for money laundering, serious gambling debts accumulated in your name by a masquerader, spawning of serious undetected addictive behavior that might otherwise be observed (on the Internet no one knows you are a gambler, except for the casino), your 9-year-old gambling with your credit card -- especially if your browser automagically inserts your credit information -- and so on into the night. As a second-order effect, massive illegal activities could also lead to attempted restrictions on the good system security and cryptography necessary to conduct legitimate Internet commerce. In any event, whether or not you bet on the Net, don't bet on the Net being adequately secure! You are already gambling with the weaknesses in our computer-communication infrastructures, but NetBet could raise the ante considerably. Caveat aleator. ------------------------------ Date: Mon, 28 Jul 1997 07:51:05 -0400 From: "Mich Kabay [NCSA]" Subject: Strong Capital sues alleged hacker-spammers [From Associated Press via CompuServe's Executive News Service] > Strong Capital Sues Alleged Hackers (AP Online, 26 Jul 1997) > MILWAUKEE (AP) -- An international mutual fund and money management > company has filed a $125 million federal lawsuit to stop the use of its > name on e-mail advertisements that include on-line striptease services. Key points: * Strong Capital Management, Inc. alleges that David Smith and Glenn Canady broke into SCM's computers to send 250,000 ads with fraudulent headers for "cyberstripping," computer equipment and sports betting. * SCM demands penalties of $5,000 per message -- about $125M in all. * SCM has added mechanisms to stop further transmission of such messages. [Note from MK: The use of civil litigation to attack hackers is one of the most powerful tools available to fight them. This will be an interesting and possibly landmark case with implications not only for the growing displeasure over fraudulent REPLY-TO addresses but also for penetration in general.] M. E. Kabay (Mich), PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com [We'll see how it holds up in court. But beware of bogus FROM: addresses, short-lived 800 numbers and P.O. boxes, etc. PGN] ------------------------------ Date: Wed, 30 Jul 1997 08:25:01 +1000 (EST) From: Craig Macbride Subject: Risks of ordering airline tickets online Last Thursday night, 24 Jul 1997, a friend of mine on the east coast of the US tried using the web server of the Internet Travel Network (www.itn.net) to book a trip. [For convenience, I'll give all dates/times in US EST.] The web server, on submission of the information (including billing address, credit card information, etc), replied with this: Data transfer complete Internet Travel Network - Server Error Could You Give Us A Hand? _________________________________________________________________________ One of our server's programs has just experienced an unrecoverable error. This is neither normal, nor desirable. We are extremely interested in any occurrence of this! Could you please send a note to bugs@itn.net and relay the precise conditions that may have sparked this incident? This is a special, high-priority mailbox that we will check right away." The details were e-mailed to bugs@itn.net that was redirected to an individual's e-mail account. That person was not only not providing high-priority service to such e-mail, she had an automatic responder in place which e-mailed back to say she was on vacation, and to try sending anything important to support@itn.net. So, e-mail was sent to that account, as well as to the response form on the web site. On Friday morning, more e-mail was sent, but by Friday midday, ITN had not responded to any of the e-mail messages that had been sent to them. One e-mail to them asked when their hours were and when they were likely to get around to responding one way or another, and this was finally answered on Friday afternoon, along with a California phone number. The customer had no idea whether a booking had been made by the web site, despite the error message from the server. She had no idea whether the booking had been made by whoever had finally received the bug report e-mail. She could have booked through someone else and ended up with 2 sets of non-refundable tickets. She could have left things as they were, and been forced to pay much more. She was going away for the weekend, so left it. ITN, when phoned on Monday, claimed that no booking had been made, and had little excuse for the 6-8 pieces of e-mail they had not responded to. They said all they could do was book on another airline, on flights which were far less convenient. Imagine our surprise when the originally booked tickets turned up on Tuesday, 29 Jul, postmarked the previous Saturday. ITN support again tried to access the booking and again couldn't immediately find it, despite the tickets having arrived! It appears the booking had been processed by the web server in the first place, despite the error message! The risks are almost too many to count here. The risk of getting an error message when buying something, so submitting it again N times, and actually getting N+1 tickets. The risk of assuming that an error message means that an order failed, and going and booking somewhere else, not realising that the order really did go through. The risk of not knowing what is happening when the people in such organisations don't bother to answer e-mail in a timely manner. The risk that an error, if it really does mean that the order wasn't processed, will result in enormous extra costs once this is confirmed. In this instance, it was necessary to phone long-distance to get any sort of meaningful response from the company. (It is possible to contact them toll-free, as I later found out, but this is not mentioned on their web site, and was explicitly denied in e-mail!) However, a seat on the same flights that were booked 5 days ago for US$164 would have cost US$563 to book today! The person who waited until contacted by the company could find themselves severely disadvantaged. There are, of course, plenty of security issues as well, particularly when sending billing details to an e-mail address, which duplicate details sent to a web server, and when that e-mail address is being redirected to a person's account who is currently away from the office. Craig Macbride http://www.bf.rmit.edu.au/~craigm ------------------------------ Date: Thu, 10 Jul 1997 20:03:14 -0400 (EDT) From: [Identity withheld by request] Subject: What to do about software patents Seeing the vast numbers of non-novel and obvious software patents issuing in my area (financial services), a number of unorthodox ideas are crossing my mind, such as ... We all know that when a governmental body, such as a city welfare agency, state prison system, state housing agency, or the like is found to be way out of line as far as administering and enforcing the laws, one of the more drastic remedies is to place the deficient agency or department into a court or legislatively ordered receivership. Are we reaching the point where we should ask a judge to place the Patent Office, or the software art areas, under a court-appointed receiver or administrator, due to its manifest ongoing failure to carry out its official duties under Federal Law with respect to 35 U.S.C. 101, 102, 103, Rule 56 and so on? I am starting to think so, but it would be a major political undertaking, to put it mildly, so I figured I would start this inquiry. Yes, it would be a lot of work to document the problem and prepare for court and/or legislative hearings, etc. ------------------------------ Date: Mon, 28 Jul 1997 09:17:11 -0500 From: billseurer@VNET.IBM.COM Subject: Re: AOL customer phone-number availability (PGN, RISKS-19.26) |> ... (But opting out is apparently not easy.) While I completely disagree with AOL's former intention to "share" telemarketing information with its "partners", it is *trivial* to opt out of any of their marketing stuff. If you go to the marketing preferences area, you can tailor what marketing information you receive if you want it or completely opt out. As far as I know this has been there for quite some time. Most people don't bother, of course, but whose fault is that? Bill Seurer, IBM Rochester, MN, BillSeurer@vnet.ibm.com BillSeurer AT aol.com (replace " AT " with "@" to e-mail me) http://members.aol.com/BillSeurer ------------------------------ Date: Thu, 24 Jul 97 09:02:00 PDT From: Ed Wright Subject: Political vs Technical Errors in CA Megan's Law CD ROM (RISKS-19.24) While much of the issue here is technical, dealing in part with inaccurate data, perhaps a more major risk is social. The Attorney General's office has been under substantial pressure from Government, caused in part by substantial public pressure to "do something". I have the pleasure of working with some of the tech. folks in that arena, and they are well aware of data inaccuracies, but have been directed to publish. Period. The risk of have politicians mandate poor quality technical activity is obvious as is the risk of hysteria in a punitive public. I just want to point out that the folks in the trenches are not the culprits in this case. ------------------------------ Date: Thu, 31 Jul 1997 20:54:37 +0100 From: "Steve Loughran" Subject: Re: The dangers of Explorer-ation (Barnett, RISKS-19.26) Roger Barnett pointed out that with some new MS products -- the compiler tools and "Visual Studio 97" presumably -- the user has to install Internet Explorer with ActiveX, Scripting and Java turned on to get at the documentation. There is a simple solution to ensuring that the web browser never access the net with any "potentially" unsafe features enabled: set it up to point to a nonexistent or "null" proxy server, so that all non-local web sites are inaccessible. This technique works pretty well -at least until all applications expect full web access for dynamic loading of remote code components and help files. The implementation of a web proxy that returns "Server Unavailable" to all requests is left as an exercise for the reader. ------------------------------ Date: Sun, 27 Jul 1997 09:06:03 -0500 From: Steven Healey Subject: Re: DEC Alpha Bug: Intel x86 FPU Diagnostics (March, RISKS-19.25) Those who have used Intel FPU's for a while may remember that Intel used to distribute FPU diagnostics both as marketing material and with FPUs sold as upgrades (e.g. 8087). These diagnostics still exist, but Intel no longer advertises or distributes them. Poke around on the Intel web site until you find the FPU technical area, then send an e-mail to the FPU tech support group asking for a copy. (Sorry I can't be more specific, but it has been more than a year since I did this). Steven Healey sphealey@worldnet.att.net ------------------------------ Date: Mon, 28 Jul 1997 15:38:18 -0400 From: "Daniel A. Graifer" Subject: Re: DEC Alpha Bug, final resolution (March, RISKS-19.25) Many years ago (early 1970s), there was a CDC3600 at the University of California, San Diego. At the insistence of the users, a test sequence was run at the beginning of every work day to validate the floating point unit in particular. I was a student employee there, and recall one failure. It turned out to be cooling related, and removing the skins from the racks cleared the problem, driving the CDC technicians crazy for several days... Daniel A. Graifer, Parker & Company 1-888-426-6548 1-703-425-6091 dgraifer@cais.com ------------------------------ Date: Sun, 27 Jul 1997 08:04:50 GMT From: daveb@iinet.net.au (David R Brooks) Subject: Re: DEC Alpha Bug, final resolution (Chase, RISKS-19.26) Of course, for the PC (and some other machines), you could simply participate in the Great Internet Mersenne Prime Search (GIMPS) http://www.mersenne.org/prime.htm The Mersenne code runs some (reputedly) real mean FPU tests as it starts up, and thereafter runs in the background, using surplus resources to hunt down prime numbers. Any FPU bugs (pre-existent or arising) are likely to be hooked by this. Dave Brooks [PGN asked: That code might not even use floating point!??] I checked with George Woltman <74473.2626@CompuServe.COM> (the author): he replies: > GIMPS is virtually all floating point. It is quite superb at finding a > variety of problems (floating point, heat-related problems, memory > problems, and even some device driver problems). ------------------------------ Date: Sun, 27 Jul 1997 20:35:34 -0700 From: STEVE LUMOS Subject: Re: General Mills, AOL, Chex Quest (Baker, RISKS-19.26) The message from Bruce N. Baker in RISKS-19.26 is just another example of what happens when children are allowed free access to complicated machines like computers without adult supervision. Had his grandson not had implicit permission to use the computer, Bruce would have been able to review the documentation and note that the Chex Quest game (which is present on the CD-ROM), requires DOS/Windows, while both the Windows and Mac versions of AOL software are included. I would imagine that including AOL on the discs cut duplication costs for Ralston Foods, probably to zero. I had no problem installing the game on a Windows 95 machine without installing AOL software. The game itself is definitely not related to AOL in any way. What I find far more interesting about Chex Quest is that it is in fact a modified version of Doom (or possibly Quake), yet has an RSAC rating of "ALL" (suitable for all audiences). How did they get the rating? By changing occurrences of "shoot" to "zorch" and "kill" to "return to their own dimension", and using different graphics. This leads to odd sounding constructions like "Many of the Flemoids will need to be zorched a couple of times before they will return to their own dimension". The RISK is that violent actions are suddenly non-violent, mainly because certain terminology has changed. Is a child used to "slagging demons to death" really more likely to become violent than one who is used to "zorching Flemoids until they return to their own dimension"? It is still up to the parents to explain the difference between the game and reality. Steve Lumos [A related note from "Harlan Rosenthal" notes that ``The decision about whether to install AOL is very clearly given as an option, and my 12-year-old has been trained not to install anything without checking and ESPECIALLY not AOL or MSN.'' PGN] ------------------------------ Date: Mon, 28 Jul 1997 11:59:18 -0400 (EDT) From: Doug Linder Subject: Re: General Mills, AOL, Chex Quest (Baker, RISKS-19.26) Something tells me that this legal language would not be enforceable. I Am Not A Lawyer, but I'd say that any reasonable judge would rule that people can't be expected to read every word on every product they buy, nor can they be bound by something like that just through the act of buying that product. After all, if that were the case, why couldn't I put something on my product that says, in fine print, "By buying this I agree to give Doug Linder all my money." This seems to me to be very similar to the "shrink-wrap" licenses on software which have, in most cases, been found to be unenforceable. I believe companies just persist on putting such language on packaging because they figure it will probably scare people, or at least convince the less determined folks that they can't sue. If you're feeling litigious, I'd say go for it and nab 'em for a few bucks for their irresponsible behaviour. Doug Linder 202 767 2572 (x28), UNIX SysAdmin, Kaman Sciences @ Naval Research Laboratory, Washington, DC ------------------------------ Date: Sun, 27 Jul 1997 10:38:19 -0400 (EDT) From: "A. Padgett Peterson" Subject: Re: General Mills & AOL in sleazy partnership: Chex Quest CD-ROM game IANAL but suspect a good one could have a field day with this "attractive nuisance" comes readily to mind as does the case eons ago of the children's program host who told his viewers to go to daddy's wallet, take out the money, put it in a envelope, and send it in. (May be legend, suspect true but why the show/host was not named - is there a legal citation?). Actually is a much more sweeping question - is a preprinted notice ("by breaking this seal") adequate to block the sharks? Suspect it might be today since is so common as to be expected but for children? In cereal boxes? Just a few years ago there was no concern about children and on-line services since they did not go together, but today? Is this really connected to the 809 (and certain other area codes) scams, where the perpetrator relies on ignorance. At what point is the "common knowledge" boundary crossed? How much "due care" is necessary? There is always the RISK that amoral people will exploit ignorance. Computers just make it easier/faster. Padgett (UDA) ------------------------------ Date: Sun, 27 Jul 1997 22:48:35 -0400 From: "Robert J. Sandler" Subject: Re: Y2K: a different solution (Driss, RISKS-19.26) Driss's solution is not new. It is already in use for some Y2K projects, and is much discussed in the Year 2000 Mailing List run by Peter de Jager. The method is generally called program encapsulation, and it is patented -- U.S. Patent number 5,600,836, assigned to Turn of the Century Solutions, Inc. of Wayne, PA. (I have no connection with this company.) The usual setback is 28 years, rather than 10, so that leap years remain leap years and the shifted dates fall on the correct day of the week. Robert J. Sandler rsandler@compuserve.com ------------------------------ Date: Mon, 28 Jul 1997 11:22:50 -0400 From: Dave Weingart Subject: Re: Y2K: a different solution (Driss, RISKS-19.26) Driss (driss@golden.net) mentions a number of concepts as a possible solution to the Y2K problem in RISKS-19.26 that hold, I think, more severe risks than the original problem! I'll summarize briefly, so as not to have to quote too heavily. I'm sure Driss will be happy to correct me if I'm missing something here. :) 1) Take all active records with dates from 1900 to 1910 and put them in a separate database. Archive all inactive ones elsewhere. 2) Subtract 10 years from the dates in the remaining data. 3) Add a new program layer to handle the conversion between "real" dates and the stored dates, leaving the current i/o interface intact. There are a number of problems with these assumptions that I see right off the bat. First is that most running databases have several date fields; which ones do you choose to archive off to the "other" set of tables (that you must still handle)? Far more serious, however, is the second. Need I even point out the inherent Risk in mucking up your data this way? The entire *point* of data processing is to deal with large amounts of data as quickly and **accurately** as possible, and an enormous amount of programming and checking goes into making sure that that this gets done, with data validation, dependencies, etc. In the corporate world, here's every chance that more than one person will get the task of doing this setting your data back 20 or more years. Or the computer will crash halfway through the operation, leaving you with some unknown chunk of your data with some fields munged. Or that some of the fields will be skipped in the general chaos; it isn't as simple as telling your DBM to type "SUBTRACT 10 YEARS FROM ALL DATES" Adding another set of programs between your data i/o and your front end interface adds additional failure points and validation problems, adds time to the processing (a millisecond here and there may not sound like much, but add it up over several millions of data records accessing constantly...), and increases your systems' complexity. Plus, there's often no easy way to accomplish this feat; many programs put requests to the database server; these programs would have to be modified to run to a different server program (I shudder to think at the concept of replacing the database server itself; that would then affect any non-date-dependent programs running!) In short, too many risks for too little benefit. Mangling your data doesn't SOLVE the problem; it only sets it off 10 more years. (Everyone who believes corporations will continue tackling Y2K if there's another decade on the the deadline instead of putting it off AGAIN, raise your hand. Anyone? Anyone?) And it's not entirely clear to me that this would, in fact be any easier or faster than using field expansion and/or date windowing as appropriate. Only 886 more days to go... Dave Weingart, AccuStaff Inc. dweingart@chi.com 516-682-1470 ------------------------------ Date: Sun, 27 Jul 1997 20:47:17 +0100 (BST) From: "M.Smith" Subject: CfP: Y2K in Health Informatics Journal ... Healthcare organisations could suffer even more serious consequences than ordinary commercial enterprises from Year 2000 problems. Urgent action is required, yet reliable reports suggest that healthcare organisations have hardly begun to consider the problem seriously. Unfortunately, discussions with healthcare computing and clinical colleagues generally confirm these reports. ... To address this urgent problem, HEALTH INFORMATICS JOURNAL will be producing a special issue this autumn, entitled Year 2000 and Healthcare Computing. This special issue will also be available as a book from Sheffield Academic Press. ... [Contact Mike Smith if you are interested.] M F Smith, Editor, HEALTH INFORMATICS JOURNAL m.smith@qmw.ac.uk +44 171 582 1409 http://www.shef.ac.uk/uni/projects/hij/ ------------------------------ Date: Wed, 30 Jul 1997 10:33:46 EST From: Rob Slade Subject: "CyberLaw: The Law of the Internet" by Rosenoer BKCYBRLW.RVW 970302 "CyberLaw: The Law of the Internet", Jonathan Rosenoer, 1997, 0-387-94832-5, U$34.95 %A Jonathan Rosenoer %C 175 Fifth Ave., New York, NY 10010 %D 1997 %G 0-387-94832-5 %I Springer-Verlag %O U$34.95 800-777-4643 fax: 201-348-4505 wborden@springer-ny.com %P 362 %T "CyberLaw: The Law of the Internet" Unlike "NetLaw" (cf. BKNETLAW.RVW), which was written for sysops and users, "CyberLaw" is written for lawyers. It is liberally supplied with footnote references to case studies and decisions dealing with the topics discussed. (Because of this, "CyberLaw", more than any other computer law book I have reviewed, is pertinent *only* to the United States.) Unlike "Net Law" (cf. BKNLHLUI.RVW), which looks at legal practice, "CyberLaw" deals strictly with points of law. Topics covered include copyright, trademark, defamation, privacy, duty of care, criminal liability, procedural issues, electronic contracts, misappropriation of information, civil rights, tax, and evidence. (One chapter which does *not* deal with the law is entitled "Ethics".) As noted, there are extensive footnote references to case law, as well as reprints of relevant issues of the author's "CyberLaw" column. For those outside the legal profession, the book is reasonably clear on the major issues. Its real value, however, would be to lawyers looking for a quick introduction to US law in respect to information technology. For this purpose, it is ideal. copyright Robert M. Slade, 1997 BKCYBRLW.RVW 970302 roberts@decus.ca rslade@vcn.bc.ca rslade@vanisl.decus.ca ------------------------------ Date: 1 Apr 1997 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 19.27 ************************