precedence: bulk Subject: Risks Digest 20.35 RISKS-LIST: Risks-Forum Digest Friday 30 April 1999 Volume 20 : Issue 35 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. ***** This issue is archived at and at ftp.sri.com/risks/ . Contents: On-line banking customers off-line for the week (PGN) Court labels unwanted e-mails "trespassing" (NewsScan) 13-year-old makes $3M in bids on eBay (Doneel Edelson) File-conversion errors between Word and WordPerfect (Gordon Foreman) Re: The Bloatware Debate (RA Downes) Flash BIOS risks (Jonathan Levine) Re: What's DejaNews up to? (Col. G.L. Sicherman) RISKS of the net's success... (Matt Curtin) IWC Watch Company site publishing visitors e-mail addresses (Derek Ziglar) Risks of misaddressed mail (Joe Thompson) REVIEW: "The Y2K Survival Guide", Bruce F. Webster (Rob Slade) Advanced Workshop: USENIX Smartcard Technology, May 10-11, Chicago (Jennifer Radtke) CFP, 1st European Anti-Malware Conference (Jaroslav Blaha) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Fri, 30 Apr 99 9:45:34 PDT From: "Peter G. Neumann" Subject: On-line banking customers off-line for the week A glitch in the networking software in the Genesis system at CheckFree in Atlanta has caused repeated crashes affecting the operations of at least 21 banks nationwide since Monday 26 Apr 1999. Wells Fargo said as many as 150,000 of its customers using Quicken or Microsoft Money to pay bills were blocked, although its other 710,000 on-line customers paying bills directly have not been impeded. (We previously reported on-line brokerage systems saturating because of increases in demand.) [Source: Sam Zuckerman, *San Francisco Chronicle*, 30 Apr 1999, B1; PGN-ed] ------------------------------ Date: Thu, 29 Apr 1999 08:17:45 -0700 From: "NewsScan" Subject: Court labels unwanted e-mails "trespassing" A California court has ruled that mass e-mails sent to Intel workers by a disgruntled former employee were an illegal form of trespass, setting a new legal boundary between private computer networks and the public Internet. The case had centered on a barrage of unsolicited e-mail messages sent by Ken Hamidi, who'd been fired in 1995, criticizing Intel's workers' compensation policies and other issues. Intel had sued Hamidi, charging misuse of the company's computer networking resources, and Judge John R. Lewis agreed, comparing borders between computer networks to property boundaries: "The mere connection of Intel's e-mail system with the Internet does not covert it into a public forum." Meanwhile, some legal scholars questioned the judge's analogy: "In the real world, trespass involves physical presence," says Jonathan Zittrain, a law lecturer at Harvard. "But in this case, it's his speech they're restricting." However, the judge noted that Intel has never published its employees' e-mail addresses, strengthening its argument that its computer system is private company property rather than a public gathering place. (*Los Angeles Times*, 29 Apr 1999, http://www.latimes.com/home/business/t000038417.html) ------------------------------ Date: Fri, 30 Apr 1999 13:05:31 -0400 From: "Edelson, Doneel" Subject: 13-year-old makes $3M in bids on eBay Using his parents' eBay account, an eighth-grader named Andrew Tyler bid more than $3M on items such as $1.2M for a medical office in Jacksonville, $.5M for a Van Gogh painting, $35,000 for a Viking ship replica, $120,000 for the first Superman comic. He also bid on a 1955 Ford convertible, a 1971 Corvette, and a bed that once belonged to Canada's first prime minister -- for which he offered $900,000 on the previous bid of $12,000. In addition to high-bidding the bed, he had four other successful bids, and clearly upped the ante on others. It was apparently just like another computer game to him. Yes, you might ask, eBay has a policy against under-aged bidders, but until now it has been on the honor system. [Source: USA Today - Tech Report, 29 Apr 1999; PGN-ed] ------------------------------ Date: Thu, 29 Apr 1999 13:50:37 -0600 From: Gordon Foreman Subject: File-conversion errors between Word and WordPerfect DoE just posted this to all contractors and offices. It is certainly not classified, so I thought it might be interesting to your readers. FYI - this information was received from the DOE Lessons Learned List Server on 4/27. Please share it with the appropriate people in CIC. I also forwarded it to cic-news@lanl.gov and the NewsBulletin. - - - - - - - - - - - - - - - Project Hanford Lessons Learned Title: Characters Convert Inaccurately Between Word Processors Date: April 20, 1999 Identifier: 1999-RL-HNF-0018 Lessons Learned Statement: Documents converted from WordPerfect into Microsoft Word may contain errors in character mapping that could cause serious problems and potentially unsafe conditions, especially with operating procedures and other safety-related documents. Discussion of Activities: Documents converted between word processing software packages may contain incorrect characters caused by inaccurate mapping between character sets. Some fractions may not convert accurately. This could create safety issues if operating procedures were released with erroneous information. For example, the fraction 1/4 in WordPerfect® converts to a value of three (3) in Word. An operating procedure that states, "Open valve A-45, Holding Tank Fill Valve, 1/4 turn." would read "Open valve A-45, Holding Tank Fill Valve, 3 turn." after conversion. Analysis: There are basically two problems. One deals with font substitution and the other deals with the way Word converts symbols into characters. The problem related to font substitution is an issue with any Windows application. As technology improves, so have the character definition standards. Word uses a relatively new character definition standard called Unicode that assigns a unique 16-bit number to each symbol or character. WordPerfect 5.1 uses a character set called OEM (original equipment manufacturer). Older Windows applications use a standard character set called ANSI (American National Standards Institute). The 3 standards are not the same for all characters, especially for symbols and characters beyond the normal letters and characters on the keyboard. A word processor opening a file with a character set that it does not use may not map each character to the correct symbol in its own set. Users opening a document on a system that does not have the same font set as that used in the original document may see unexpected results on their screen such as boxes or other strange characters, due to font substitution. The other problem arises from the way Word treats some symbols as codes and others as characters. The character symbols are more susceptible to changing when the document base font is changed. The character may change to an empty box, or a character from a different font set. To prevent this, the character symbol should be changed to a code symbol. Any document with any character set created using any version of WordPerfect may be susceptible to this problem. Other word processors may also cause these errors. Gordon Foreman, Los Alamos National Laboratory [Note: I have removed all of the repeated \256 characters after "Word" and "WordPerfect" for the benefit of those noncompliant mailers that block the entire issue if there is a single extended-ASCII character in RISKS. The astute reader must mentally reinsert them, so that RISKS is not in violation of the trademark conventions. PGN] ------------------------------ Date: Fri, 30 Apr 1999 16:22:48 +0000 From: main@radsoft.net Subject: Re: The Bloatware Debate One of the chief hallmarks of early UNIX was how simple, compact programs worked well together. Brian W. Kernighan's definition of a good program was a program so good and so consistent that it could be used for an entirely different purpose and be expected to work well. UNIX, they said, was a way of thinking more than an operating system. And, with Brian's Software Tools series, it was surely so. Microsoft Windows is also a way of thinking - or not thinking, to be more exact. In almost every possible sense it is the anathema of the programming community, if that community still abides by and adheres to the solid thinking delineated by Brian so many years ago. MS Windows programming is considered too difficult to attempt head on. Where we come from most major corporations, financial institutions and the like promised a smooth transition from UNIX or DOS to Windows 3.1x within a matter of weeks. Management talking of course. When they found this would not work they decided to invest heavily in 16-bit Visual Basic applications. Operative word "heavily". These bloatware masters sunk almost any machine made. Clearly this was not the answer either. People looked to Kahn. Borland, with its Turbo C, saw the opening and released Borland C, and shortly thereafter Scott Randell who a year earlier had toured with MSC 7.0 (which admittedly never worked) was out rocking again, this time with Visual C++. The environment was unbelievable; the executables were extremely bloated; but still and all it was Microsoft talking, and still and all they were smaller than the corresponding Borland images. COBOL programmers everywhere were suddenly encouraged to learn C++, develop code browsing skills, learn about preprocessors, assembly language, CodeView and subsequent debuggers, and the world entered into a tailspin. What originally started as a rather feeble but lucky attempt to get on the OO bandwagon, the MFC soon became something you'd like to see Steve McQueen kill. Patches and work-arounds and bugs and more bugs, and bloat and more bloat. The current splash screen module is a case in point: Microsoft includes a 16-color bitmap which weighs in at nearly 200KB for you. This bitmap can be compressed with RLE encoding to less than half that size. The idea of banging a 100KB splash bitmap in an application is still, however, sickening. Yet Microsoft gladly gives you the bitmap at 200KB, happy if you don't understand what you are doing by using it. Your application will be more sluggish than their own bloatware, and people will be less inclined to complain about what they themselves do. Microsoft's RegClean, a popular product for fixing corruptions in the MS Windows Registry is another case in point. When this application was originally introduced I downloaded it and wondered about its size. It weighed in then at nearly a megabyte. Similar applications out there were 20KB and hardly more. What was inside this monster? I opened it and looked inside. Remember all those stories about how surgeons in the old days just threw their rubber gloves inside the patient's stomach before sewing them back up again? Well here you had it. There were humungoid bitmaps never used. There were dozens of icons never referenced. There were tens of kilobytes of entries in the string table that had no meaning for the application whatsoever. I honed the app down and came to the conclusion that the actual size of RegClean should be about 45KB. That as compared to its distribution size of nearly one megabyte. Clearly bloat is not only a question of adding features almost no one wants. Bloat is a condition of the mind, permeating software houses everywhere. Clearly again the distribution of RegClean was highly irresponsible. But remember, MS Windows is not just an operating system - it is a way of thinking, or not thinking as you may have it. And it has permeated the entire industry today. Our hats off to Microsoft. In conclusion: there are few application domains even today that require executables of over 100KB, and most ordinary tasks can be adequately managed by executables in the 20KB range. This is simply a fact. There are no excuses. Either we think or we don't. There is no in between. RA Downes Radsoft Laboratories ------------------------------ Date: Thu, 29 Apr 1999 01:13:27 -0600 (MDT) From: Victor the Cleaner Subject: Flash BIOS risks (Re: Genuine sighting, Brown, RISKS-20.34) My take on this is a little different. I'm a embedded control designer known by local component suppliers to have a lot of device (chip) programming equipment, so people are regularly directed to me for memory and microcontroller burning. Hey, it's beer (okay - single malt) money. This week I had somewhat more than the usual number of calls regarding PC Flash BIOS chips needing reprogramming. Whether this was the result of one of these reportedly BIOS-hungry viri or a coincidentally high number of failures of user-initiated BIOS upgrades I haven't determined. My attention is drawn to the latter. As a designer, I find it hard to grasp the thinking behind crippleware-in-waiting - systems such as these that rely on high-level functionality to perform low-level [firmware] changes without a net. If, for any reason, the operation does not complete properly, the machine is hosed hard. The RISK is the lack of a Plan B - any bootstrap method of recovery from such a failed upgrade. As is, the victim has the choice of either tracking down what for the average consumer must be a truly obscure and arcane service (someone who can copy the BIOS-vendor's binary from a floppy to the chip) or just calling the whole damn thing DOA, as suggested by Nick Brown. Jonathan Levine, Canada Connect Corp., Calgary ------------------------------ Date: 30 Apr 1999 13:52:38 -0400 From: colonel@monmouth.com (Col. G. L. Sicherman) Subject: Re: What's DejaNews up to? (Smith, RISKS-20.34) I don't know what commercial advantages DejaNews may gain by tracking clicks, but this can be helpful to users of any search engine. For example, consider a search on bambi book children The first two entries on the list are: 1. Book exotic dancer Bambi for your next stag party! Not suitable for children. ... 2. Bambi, by Felix Salten, is a wonderful book for children. Here's how to order: ... Most people will select item 2. Knowing this, the search engine will start presenting item 2 at the head of the list. It's an automatic way to make search engines more helpful--at the risk of making it harder to find things that most people don't want. Col. G. L. Sicherman web: work: sicherman@lucent.com home: colonel@mail.monmouth.com [... and they are easily Bambioozled. PGN] ------------------------------ Date: 29 Apr 1999 14:30:37 -0400 From: Matt Curtin Subject: RISKS of the net's success... (Re: DejaNews, Smith, RISKS 20.34) As noted, this business of tracking links is not new. DejaNews and HotBot aren't the only ones doing this, either. In other strange-but-true news, after releasing a report that was generally critical of Netscape's implementation of the "Smart Browsing" feature, we discovered that that very feature was claiming our report is "related" to the Unabomber Manifesto. A good summary of this was covered in Lauren Weinstein's PRIVACY Forum Digest 08.06[1]. It was also reported that AltaVista is preparing to give preferential treatment in search results to those who pay for their listings. [In Lauren's PRIVACY item, he noted that AltaVista says that those listings will be marked as having been paid for. PGN] Lauren made a really interesting point in the PRIVACY Forum Digest that really seems to cut through all of the noise around these annoyances and problems, getting to the larger problem, that is the risks associated with the Internet's success. He wrote: It's of enough concern when we learn that major search engines (e.g. AltaVista) are about to start selling search result placements. It's of equal concern if users need to be worried that other search results, returned by other search engines, might potentially be skewed by unobvious forces not related to an unbiased analysis of the sites in question, even if monetary considerations are not the factor involved. If search engines begin to lose the trust of their users, one of the net's most powerful category of tools may be reduced to nothing more than automated pitchmen using every means possible, no matter how biased, to try pull the yokels into the tent. In that case, it will not only be a serious loss for us all, but will also create the potential for a sort of "information pollution" on a scale we've never seen before. Is it possible that the success of the net will lead to its own demise from the perspective of a useful resource that serves its end users? [1] http://www.vortex.com/privacy/priv.08.06 Matt Curtin cmcurtin@interhack.net http://www.interhack.net/people/cmcurtin/ ------------------------------ Date: Thu, 29 Apr 1999 13:23:14 -0400 From: "Derek Ziglar" Subject: IWC Watch Company site publishing visitors e-mail addresses IWC, a Swiss manufacturer of high-end wristwatches, has opened up a severe privacy invasion on their web site at http://www.iwc.com. In an all too common RISK, I'm sure the site designers or company executives thought it would be cute to display the names of the 10 most recent visitors to their site on their main page. The privacy issue is that they ask for your name and e-mail as part of a sign-in on initial entry to the site -- then immediately display on their main page your name along with 9 other recent visitors to their site as a mailto links with each person's e-mail address! As RISK readers are well aware, this would be an easy point for someone unscrupulous to harvest e-mail addresses. Similarly, a user could enter obscenities or other information that IWC would likely not desire to display on their web site. There is no way for a first time visitor to know that their information will be publicly displayed until it is too late. There are no provisions to opt out or have the information removed (except for it to age off the list after 10 more people sign in to their site). The information is stored in a cookie under your browser and redisplayed if you return to the site via bookmark -- unless you enter through the welcome form and blank out the fields before continuing. IWC International Watch Co. Ltd., Baumgartenstrasse 15, CH-8201 Schaffhausen, Tel: +41 52 635 65 65, Fax: +41 52 635 65 05, info@iwc.ch ------------------------------ Date: Thu, 29 Apr 1999 15:50:30 -0400 From: Joe Thompson Subject: Risks of misaddressed mail Recently I got a message that looked like a lot of the spam I get; it was a business-style e-mail with a Word attachment, talking about a "business proposal". It wasn't addressed to me; I figured I had gotten on Yet Another Spam List and left it in the "spam" folder it had been filtered to. Today I got what appeared to be a follow-up mail. Same originating address. This time I looked at the full headers of both messages. It didn't look like any games had been played with open relays and I started wondering if this could be legitimate mail that had gotten misdirected. A moment's digression: I have a "blind forward" on the domain I own, so all mail addressed to my domain goes into my main mailbox unless specifically directed elsewhere. This means I can make up aliases "on the fly" for things like web form registration, which allows me to receive legitimate mail but also shows me who's been giving my address to spammers. But it also means that it's not possible for mail misdirected to my domain to bounce back to the sender as it normally would. In this case the mail was sent to the right username but the wrong domain (the domain it should have gone to was one letter less than mine). But because I've gotten in the habit of dismissing mail I get with "bogus" addresses as spam, the normal reaction of "I think you goofed your address" was delayed. In this case the ending was happy, but it's easy to imagine somebody never even looking at such mail, with the result that sensitive business negotiations break down, with each side blaming the other for failing to communicate. Besides the obvious risks of misdirected mail exposing potentially sensitive information to the third parties, another problem is that "convenient" messaging features like blind forwards may make it harder to separate genuine mistakes from games spammers play. The deeper risk is that, as I've seen predicted for some time, the general apathy and distrust that widespread spam has caused are making e-mail less useful as time goes on. Joe Thompson, Charlottesville, VA joe@orion-com.com http://kensey.home.mindspring.com/ ------------------------------ Date: Wed, 28 Apr 1999 16:42:55 -0800 From: "Rob Slade, doting grandpa of Ryan and Trevor" Subject: REVIEW: "The Y2K Survival Guide", Bruce F. Webster BKY2KSUG.RVW 990319 "The Y2K Survival Guide", Bruce F. Webster, 1999, 0-13-021496-5, U$19.99/C$28.95 %A Bruce F. Webster bwebster@bfwa.com %C One Lake St., Upper Saddle River, NJ 07458 %D 1999 %G 0-13-021496-5 %I Prentice Hall %O U$19.99/C$28.95 +1-201-236-7139 fax: +1-201-236-7131 %P 544 p. %T "The Y2K Survival Guide" "Don't buy guns, cash all your stocks, withdraw your savings, and move to South Dakota unless you already had a good reason for doing so, and maybe not even then. It's really cold in South Dakota, and the last place you probably want to be is out in the countryside with a lot of other folks armed with guns and waiting for Armageddon." While those from South Dakota may bristle a bit at the impugning of their home state, the rest of us may be glad of a little sanity in the year 2000 debate. (On the other hand, maybe the population of South Dakota will be just as glad that someone is telling the nuts to stay home while Ed Yourdon [cf. BKTMBM2K.RVW] is yelling that we're all gonna die. This is, in fact, the book that Yourdon could have written, were he not so busy trying to make application to the Charlton Heston fan club.) (Also, since Webster's roots go 'way back in South Dakota, they'll probably forgive him.) Webster does not so much occupy the middle ground as look at the entire spectrum of reactions to the situation, and tries to remain rational throughout. Whoever did the cover design caught the tone perfectly: an ostrich with its head in the sand in the foreground, and a mushroom cloud in the background. And an awful lot of territory in between. Part one looks at how we got here. Chapter one starts with an overview of the problem and its cause. Unfortunately, while there are some very good points (such as the statement that it is a century, rather than millennial, problem) the basic explanation is somewhat confused, and doesn't rise above the generally available material on the topic. Whatever faults chapter one may have, though, are more than made up for in chapter two, which gives a clear and almost lyrical description of why the problem happened. Starting with limited hardware, continuing through software bloat, and ending with the seven deadly sins, the lessons are clear and unflinching. (I can even forgive the mention of the scandal du jour, given the deft manner of its inclusion.) A number of the myriad barriers to getting the job done are examined in chapter three. Chapter four reviews a number of myths in regard to Y2K. Part two looks at preparation in this last year before the deadline. This section is full of suggested actions you can take, to a greater or lesser extent, to get ready. Chapter five looks at laying a foundation: how to plan what to protect. This may seem facile, but it has a real purpose. If you can't do everything, and you probably can't, make sure you do what is most important. To you. Where other books may have a bibliography, chapter six lays out some guidelines for actually getting yourself educated for what might come. The discussion of health ranges from the possible failure of Medicare to starting a fitness program (so as to generally improve your health and avoid the possibility of hospitalization), in chapter seven. Chapter eight reviews planning for home needs. Food concerns, in chapter nine, tend to be weighted towards flour, dried foods, and other items that need preparation (and therefore, in most people's minds, electricity and water) but the exercise and some pointers are quite helpful. The "career" plan in chapter ten is probably appropriate to any situation, quite apart from the possibility of a recession, and the financial planning in chapter eleven is pretty sound. Building a community and support network is possibly the most important thing you can do to prepare, and is hardly ever mentioned apart from this book's chapter twelve. Part three is again preparation, but more of a mental type. Chapter thirteen looks at the value (and danger) of trying to see what's ahead. A variety of scenarios, ranging in severity, are presented in chapter fourteen. Part four talks about getting on with life after Y2K, and whatever it brings. Chapter fifteen suggests taking stock and making an assessment. The lessons we should learn from the year 2000 fiasco are reviewed in chapter sixteen. Two of the appendices are from work the author did with the Washington, DC Year 2000 Group. Appendix A contains testimony presented to Congress, and Appendix B gives the results of two surveys of the group members. Appendix C has a very useful set of resources for further study, heavily weighted to Internet sites. Like the more sensationally named "Time Bomb 2000" (cf. BKTMBM2K.RVW), this book is aimed at the general population. It does a much better job of presenting the reality, and, at the same time, suggesting useful ways to address the issue. I think it's appropriate to close with another quote from the book, this one only a few sentences after the one that opened this review: "Focus on solving as many problems as you can in your own circle of influence, starting with your own life and family, but including your community. Build social cohesion. Do the same sensible personal preparation ..." copyright Robert M. Slade, 1999 BKY2KSUG.RVW 990319 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Fri, 30 Apr 1999 00:55:55 GMT From: jennifer@usenix.ORG (Jennifer Radtke) Subject: Advanced Workshop: USENIX Smartcard Technology, May 10-11, Chicago USENIX WORKSHOP ON SMARTCARD TECHNOLOGY May 10-11, 1999, McCormick Place South, Chicago, Illinois, USA Review the full program and register on-line at http://www.usenix.org/events/smartcard99/ For Researchers, Product Developers and Smart Card Deployers First of Its Kind in North America Sponsored by The USENIX Association [Abridged for RISKS. PGN] ------------------------------ Date: Wed, 28 Apr 1999 07:06:11 +0100 From: jblaha@nacma.nato.int Subject: CFP, 1st European Anti-Malware Conference EICAR - European Institute for Computer Anti-Virus Research March 4 to March 7, 2000, Brussels, Belgium SUBMISSION DEADLINE for PAPERS: JULY 1, 1999 Papers pertaining to malicious code, unwanted side-effects or malfunction, network security, information age and society, cryptography and the protection of privacy and anonymity, new media, and electronic commerce, are welcome. Subject matter may be theoretical, empirical, or methodology oriented. We are interested in receiving Research Papers, Research in Progress Reports, Case Studies and proposals for Symposia. For full details see http://www.eicar.dk/submit/call.html or send e-mail to call@eicar.dk For more information about EICAR please visit http://www.eicar.org JAROSLAV BLAHA, Dipl.Inform.(Univ), Dipl.Wirtschafts-Inform.(Univ) Senior Information Systems Engineer NATO ACCS Management Agency (NACMA), Project Implementation Division 8, Rue de Geneve, B-1140 Brussels, Tel.: +32-2-707.8540 Fax.: +32-2-707.8777 jblaha@nacma.nato.int www.jaroblaha.com ------------------------------ Date: 23 Sep 1998 (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. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact (Dennis Rears). .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, 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 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks . ------------------------------ End of RISKS-FORUM Digest 20.35 ************************