precedence: bulk Subject: RISKS DIGEST 19.59 RISKS-LIST: Risks-Forum Digest Friday 13 February 1998 Volume 19 : Issue 59 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: [Back after travel and busy-ness.] Prisoner released due to program design flaw (Richard Fahey) California legislation proposed to limit Y2K liability (Terry Carroll) Report on ATC Outages (Peter B. Ladkin) Markus Kuhn and Ross Anderson's Soft Tempest (Martin Minow) High-tech car AA call-outs (Pete Mellor) Re: Crash of A-320, Strasbourg (Pete Mellor) Re: robots.txt (Bertrand Meyer) Re: Dangerous handling of null variables (Anthony W. Youngman) Re: Netscape, Fortify & the NSA (Vin McLellan, Ian Goldberg) Privacy on the Line, Diffie and Landau (Martin Minow) REMINDER: ISOC 1998 Network and Distributed Security Symposium (Dave Balenson) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 02 Feb 98 08:43:00 CST From: "Fahey, Richard (CDSI)" Subject: Prisoner released due to program design flaw Sorry that I do not have much specific information on, or identifiable sources for, this story - it was reported in my local newspaper (San Antonio Express-News), and my copy was recycled before I thought of posting it here (being a new RISKS reader - I promise to do better next time!). Some of the details may be misremembered, but the gist is correct. Seems like a Dallas prisoner was temporarily transferred from one prison to another (from a federal prison to a state prison?) so that he could serve as a witness in somebody else's trial. Apparently, one of the computer systems involved recognized that he was on "temporary assignment" and absent from the original prison - all well and good, except that after 30 days of absence the system defaulted to flagging him as no longer being incarcerated in the original prison. Once the trial in which he was a witness ended, he was released from the "loaning" prison and was released. Although he was eventually put back in prison, since this man was in for a dangerous crime, this episode is pretty alarming. Richard Fahey ------------------------------ Date: Fri, 30 Jan 1998 17:07:28 -0800 (PST) From: Terry Carroll Subject: California legislation proposed to limit Y2K liability This bill, if enacted, would limit recovery in actions for damages resulting from a "computer date failure," i.e., Y2K failures. Under the bill (if passed), in a lawsuit for a Y2K bug, the plaintiff could recover only the reasonable costs of correcting the bug, and damages resulting from bodily injury. As I read this, if, for example, a bug in a money management program caused the system to send out checks in appropriately, you would not be able to sue the software company to recover the money you lost (assuming you couldn't get a refund from the improperly paid parties), and you wouldn't be able to recover for the check-bounce fees imposed by your bank because your balance was not sufficient to cover all the incorrectly-issued checks. The bill seems to apply to contracts as well as to torts (such as negligence), and there's no provision specifically limiting it to contracts entered into after the date of enactment (however, it does permit a contract to override this provision and expressly allow for further damages). I've added the bill to my Copyright Resource Page (a misnomer -- I now have a lot of stuff besides copyright, this being one example) at . I have both a text copy and a PDF version (for those who would like the official printings). Here's the most pertinent part of the bill. For the rest (definitions, clarifications, etc.), please see the above-referenced URL. (a) Notwithstanding any other provision of law, in any action to recover damages resulting directly or indirectly from a computer date failure, including any action based on an alleged failure properly to detect, disclose, prevent, report on, or remediate a computer date failure, the damages that may be recovered shall be limited to either or both of the following, according to proof: (1) Any damages resulting from bodily injury, excluding emotional injury, to the plaintiff proximately caused by the defendant's conduct. (2) Any costs reasonably incurred to reprogram or replace and internally test the relevant computer system, computer program or software, or internal hardware timer, to the extent those costs are incurred as a proximate and direct result of the defendant's conduct. Terry Carroll Santa Clara, CA carroll@tjc.com ------------------------------ Date: Wed, 11 Feb 1998 12:12:17 +0100 From: "Peter B. Ladkin" Subject: Report on ATC Outages Outages (complete failures, a distinct from degradation of service due to partial failures) of air traffic control computer systems, particularly those at the U.S. Air Route Traffic Control Centers (ARTCCs) have been a subject of continuing interest in RISKS (a keyword search on the archive showed well over a hundred references, many of which refer to partial failures or outages). The U.S. National Transportation Safety Board (NTSB) prepared a report in January 1996 (NTSB/SIR-96-01) on ATC system outages, dealing with incidents between September 12 1994 and September 12 1995 and assessing the FAA's modernisation program. There is a significant `legacy' problem with some of the systems, and the scope of the FAA's Advanced Automation System (AAS), which has been in development since 1981, was significantly revised downwards when the contract for the `be all to end all' system was cancelled by the FAA in mid-1994 because of continual schedule slippage and cost overruns. The NTSB report discusses the architecture of the display systems in the ARTCCs, the nature of the outages (4 power failures, 7 computer problems), and the FAA's upgrade plans (which crudely amount to replacement of legacy systems in an evolutionary manner, rather than a redesign). In the 11 incidents, only one operational error (loss of separation) was reported, although all involved degradation of service (i.e. delays) ranging from the trivial (1) to the extreme (485). The report also notes that many controllers do not appear to be aware of the full range of functions still available to them during partial degradation. The board concludes that the system remains `very safe', even though the failures have a significant economic impact, but is concerned about the safety implications of the increasing number of failures of the older equipment. The AAS is considered a `high-risk program' by the U.S. General Accounting Office (GAO), which has produced a series of reports, the latest from 1997 being on the WWW. A `high-risk program' is one at `high risk for waste, fraud, abuse and mismanagement' (!). The NTSB report is now available on the WWW in the compendium `Computer-Related Incidents with Commercial Aircraft', which also contains links to the GAO reports: http://www.rvs.uni-bielefeld.de --> `Computer-Related Incidents..' --> `U.S. Air Traffic Control Center Outages and the Advanced Automation System'. Other recent additions to the compendium include the Rapport Preliminaire of the French DGA on the A330 test flight accident in Toulouse (Mellor, RISKS-16.19; Jackson, Ladkin, 16.22, Ladkin, 16.23; Hollnagel, 16.31; Ladkin, 16.39); the final report on the Lauda Air B767 accident (Leyland, 11.78; Grodberg, Kopetz, Morris, Philipson, 11.82; Neumann, 11.84; Mellor, 11.95; Leveson, 12.16; Leveson, 12.69); the 1985 China Air B747 accident (Trei, 3.79); and the 1983 Eastern Airlines L1011 Common Mode Failure incident (not itself computer-related, but I believe relevant for understanding common mode failures resulting from imperfect maintenance, as in the 1996 Aeroperu B757 accident, Ladkin, 18.51; Neumann, 18.57; Ladkin, 18.59). I am very grateful to Hiroshi Sogame of the Safety Promotion Committee of All-Nippon Airways for his public service in preparing various of these and other reports for the compendium. Peter Ladkin ladkin@rvs.uni-bielefeld.de http://www.rvs.uni-bielefeld.de ------------------------------ Date: Sun, 8 Feb 1998 18:34:18 -0800 From: Martin Minow Subject: Markus Kuhn and Ross Anderson's Soft Tempest An interesting article on "Software Tempest" -- here's a short notice posted by Peter Gutmann to the Cryptography e-mail list: > There's a fascinating paper on software anti-TEMPEST (and, in general, > TEMPEST-related) measures by Markus Kuhn and Ross Anderson available > from http://www.cl.cam.ac.uk/~mgk25/ih98-tempest.pdf. It describes > both how to make TEMPEST eavesdropping difficult using only software, > and how to build TEMPEST-friendly software. A much longer and more detailed announcement (with some background notes by one of the authors) was posted by John Young to the Cypherpunks e-mail list. > To: ukcrypto@maillist.ox.ac.uk > Subject: It is really me - the story of Soft Tempest > Date: Sun, 08 Feb 1998 15:09:40 +0000 > From: Ross Anderson $The Washington Post$ gives a highly distorted account of some very important scientific work we have done. I suggest that list members read our paper - - for themselves before getting carried away. The story is as follows. Bill G gave our department $20m for a new building, and his people said that what they really wanted from our group was a better way to control software copying. So it would have been rather churlish of us not to at least look at their `problem'. Now the `final solution' being peddled by the smartcard industry (and others) is to make software copying physically impossible, by tying program execution to a unique tamper-resistant hardware token. We wouldn't like to see this happen, and we have already done a lot to undermine confidence in the claims of tamper-proofness made by smartcard salesmen. So Markus and I sat down and tried to figure out what we could do for the Evil Empire. We concluded that (1) large companies generally pay for their software; (2) if you try to coerce private individuals, the political backlash would be too much; so (3) if the Evil Empire is to increase its revenue by cracking down on piracy, the people to go after are medium-sized companies. So the design goal we set ourselves was a technology that would enable software vendors to catch the medium-sized offender - the dodgy freight company that runs 70 copies of Office 97 but only paid for one - while being ineffective against private individuals. We succeeded. In the process we have made some fundamental discoveries about Tempest. Army signals officers, defence contractors and spooks have been visibly flabberghasted to hear our ideas or see our demo. In the old days, Tempest was about expensive hardware - custom equipment to monitor the enemy's emissions and very tricky shielding to stop him doing the same to you. It was all classified and strictly off-limits to the open research community. We have ended that era. You can now use software to cause the eavesdropper in the van outside your house to see a completely different image from the one that you see on your screen. In its simplest form, our technique uses specially designed `Tempest fonts' to make the text on your screen invisible to the spooks. Our paper tells you how to design and code your own. There are many opportunities for camouflage, deception and misconduct. For example, you could write a Tempest virus to snarf your enemy's PGP private key and radiate it without his knowledge by manipulating the dither patterns in his screen saver. You could even pick up the signal on a $100 short wave radio. The implications for people trying to build secure computer systems are non-trivial. Anyway, we offered Bill G the prospect that instead of Word radiating the text you're working on to every spook on the block, it would only radiate a one-way function of its licence serial number. This would let an observer tell whether two machines were simultaneously running the same copy of Word, but nothing more. Surely a win-win situation, for Bill and for privacy. But Microsoft turned down our offer. I won't breach confidences, but the high order bit is that their hearts are set on the kind of technology the smartcard people are promising - one that will definitively prevent all copying, even by private individuals. We don't plan to help them on that, and I expect that if they field anything that works, the net result will be to get Microsoft dismembered by the Department of Justice. Meantime we want our Soft Tempest technology to be incorporated in as many products as possible - and not just security products! So to Rainier Fahs, who asked: > If these rumors are true, I guess we will face a similar discussion on > free availability in the area of TEMPEST equipment. Does privacy > protection also include the free choice of protection mechanism? I say this: our discovery, that Tempest protection can be done in software as well as hardware, puts it beyond the reach of effective export control. So yes, you now have a choice. You didn't before, Ross Anderson [Tempest foo-gets! PGN] ------------------------------ Date: Sun, 18 Jan 1998 11:41:09 +0000 (GMT) From: Pete Mellor Subject: High-tech car AA call-outs From the $London Evening Standard$ of 18 Jan 1998: Drivers are defeated by clever cars Breakdowns caused by lost keys and confusion over sophisticated car security systems overtook flat tyres for the first time in an analysis of calls to the AA. Of the 4.5 million call-outs last year, the most, 825,424, were due to flat or faulty batteries, followed by 269,070 because alarm systems or locks failed. Peter Mellor, Centre for Software Reliability, City University, London, p.mellor@csr.city.ac.uk [In Britain, AA is presumably the Automobile Association. PGN] ------------------------------ Date: Sat, 31 Jan 1998 16:23:00 GMT From: Pete Mellor Subject: Re: Crash of A-320, Strasbourg (Siniakov, RISKS-19.58) Is this a joke? If so, how did it get past our trusty moderator? (Book now and avoid the April 1st rush! :-) The crash of the A320 on final approach to Strasbourg in 1992 was most probably due to the fact that the crew were using the "vertical speed" mode of the autopilot to control their descent instead of the "flight path angle" mode, and somehow failed to notice this. The result of this "mode confusion" was that they descended three times as fast as was shown for the approach path on the plates for Strasbourg. This is only the "most probable" cause, since there are still uncertainties about the last moments of the flight. I summarised the findings of the accident report (and included some speculations of my own) in my paper:- ``CAD: Computer-Aided Disaster'', High Integrity Systems, Vol. 1, Iss. 2 (Oxford University Press: 1994) pp 101-156 I will leave it to others who have studied the relevant accidents to comment upon the relevance of the "resonance characteristics of both the solar system and outer space" to those. Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422 p.mellor@csr.city.ac.uk [Ah, yes, thanks to all of you who responded so strongly to this item. PGN] ------------------------------ Date: Sun, 1 Feb 98 15:45:41 PST From: bertrand@eiffel.com (Bertrand Meyer) Subject: Re: robots.txt (Meyer, RISKS-19.57) I continue to receive mail on my robots.txt comments. Those who disagree with my criticism are (I must say) the majority, but not by far unanimity, and there are interesting nuances in the disagreements. I found all the contributions very enlightening. I will continue to add all messages received (unless contributors specify otherwise) to the Web page, which is now in place: http://www.eiffel.com/private/meyer/robots.html Bertrand Meyer, Interactive Software Engineering, makers of ISE Eiffel , http://www.eiffel.com ------------------------------ Date: Sun, 1 Feb 1998 00:45:31 +0000 From: "Anthony W. Youngman" Subject: Re: Dangerous handling of null variables (Jeays, RISKS-19.58) > The treatment of null values is arguably reasonable once it is > understood - null values simply fail all comparisons with non-null > variables. ... Nowhere does it tell us which language. Java, VB, what? I think it's rather important to know. In all the languages I know there is no genuine null value, just something along the lines of "equate null to 0" Anthony W. Youngman wol@thewolery.demon.co.uk [Lots of other messages on this topic. TNX. PGN] ------------------------------ Date: Tue, 27 Jan 1998 03:00:13 -0500 From: Vin McLellan Subject: Re: Netscape, Fortify & the NSA (Wilson, RISKS-19.57) John Wilson worried about what unscrupulous folk, unwilling to acknowledge or respect interests other than their own, might inflict on the public now that Netscape has decided to release the source code for the Netscape 5.0 browser. What Mr. Wilson overlooks, perhaps, is what some unscrupulous folk, unwilling to acknowledge or respect interests other than their own, have already done to tens of millions of Internet users -- and what they were able to get away with largely because Netscape's source code was unavailable. By forbidding the export of web servers and browsers with strong crypto to non-American users (with a few narrow and humiliating exceptions,) US policymakers have left the commercial, professional, and personal correspondence and web-based transactions of millions of non-American citizens all but naked to eavesdropping by criminals (petty and organized,) industrial spies, gossip-mongers, aggressive office-pols, wannabe blackmailers, rogue cops, managers with feudal delusions, and curious 14 year-olds with access to a contemporary PC (or -- if they they want to pop secrets free within hours -- the computational resources of a typical college computer lab.) The image and reputation of the US, and of American engineering and technology, has suffered grievous harm so as to allow the NSA to gain what transient enlightenment it could from it's world-wide "Echelon" sweeps of the data lines and communications spectrum. Reaction to the scheduled release, today, of a report by the Civil Liberties and Interior Committee of the European Parliament on the NSA's systematic snooping on all European telephone, fax, and digital communications may indicate how bitter that resentment has become. (Swedish parliamentarians were outraged recently to discover that the confidentiality of encrypted traffic on their Lotus Notes system was apparently dependent on the self-restraint of the NSA -- which demanded partial access to the Notes crypto-key before the product was shipped abroad.) The web -- and in particular, Netscape's browser, due to its popular success and widespread use -- has become the focus of much concern and attention from those who believe that privacy and optional confidentiality are fundamental to the dignity and liberty of any man or woman, anywhere. SSL, the encrypted channel built into the WWW spec, offered the first encryption systems that was universally available, to the far reaches of the global Internet. The problem was, only Americans got strong (128-bit) crypto. US export policy allowed vendors to ship only weak easily-broken 40-bit crypto in browsers exported to non-Americans, so the browsers freely downloaded off the Microsoft and Netscape ftp sites world-wide were almost always insecure, providing security of poor quality by design and government fiat. Non-American webservers can offer strong-crypto alternatives to the innovative American products which paced the technology -- and even the crippled export-level American webservers can have their weak SSL encryption enhanced by java applets (Brokat's Xpresso ) or proxy/translators (C2's SafePassage ) -- but it was only a few months ago that Farrell McKay's remarkable freeware product, Fortify, became widely available. Fortify allows anyone anywhere to upgrade a Netscape browser (Navigator v3 or Communicator v4) with weak or export-strength crypto into one with the 128-bit SSL capabilities for confidentiality (and secure e-commerce) that Americans take for granted when they do business on the web. An executive with one of the big international auditing firms told me a month ago that Fortify is "all over Africa," particularly in banking. "It's free, and it's legally available from its British website. They'd be idiots not to use it! I recommend it to all my international clients." McKay's program installs itself directly in the Netscape browser to upgrade it's SSL code, so that anyone with a export-quality browser can get a 128-bit strong-crypto link when he connects to a webserver that is itself capable of establishing a strong SSL connection. Unfortunately, McKay's magic did not extend to strengthening the S/MIME crypto has added encryption for electronic mail to recent versions of both the Netscape and the Microsoft browsers. McKay gave international users of Netscape a secure 128-bit SSL channel, but neither he -- nor, apparently, anyone else -- has been able to do the same with the S/MIME routines which were also crippled and weakened to 40-bit crypto, by government order, before export. The web is popular, but e-mail is still the "killer app." Strong SSL, now universally available, enables many types of form-based transactions on the Web -- but freely-available strong S/MIME for private mail will break the dam. Some dream it could change the world. Farrell McKay fervently believes that getting the Netscape source in circulation among those who can pick it apart is the gateway to a future in which everyone can expect their mail to be confidential (at least until some local lawmen shows up, with proper authority to demand access from one of the correspondents.) "I live in the hope that there will be entire armies of enthusiastic programmers all busily building strong crypto facilities into the v5.x releases," he exulted in a note he sent me yesterday from Australia. "This move really opens up a huge number of possibilities for the international community." Many American think that's just great, on balance. ("All men are created equal," and stuff like that.) Virtually all non-Americans have no doubt. Much of the world is hoping that electronic commerce will be the backbone of the 21st Century economy -- and you practically have to rate a limousine in Washington, D.C., before you can believe that international finance and trade will go online if the merchants, bankers, and businessmen believe that American spooks have rigged a party-line, and may or may not be listening. Having Netscape browser source-code in circulation won't change much overnight, of course. Given US restrictions on the export of privacy products, the release of the Netscape source code will doubtless be restricted too. Netscape's cryptographic modules will either not be released in source, or will be forbidden for export. Still, with all _but_ the Netscape privacy code accessible to clever programmers world-wide, it becomes all but certain that -- as Netscape cryptographer Tom Weinstein suggested yesterday -- "some enterprising individuals outside the US (will) replace the missing pieces." Odd what Americans have to do to get a quality product to the world market, huh? ------------------------------ Date: Sun, 1 Feb 1998 15:45:39 -0800 From: Ian Goldberg Subject: Re: Netscape, Fortify & the NSA Actually, the moment I started playing with McKay's wonderful program, I noticed that it didn't activate strong S/MIME, so I fixed it. Although I am (currently) in the US, I use Fortify because (at least the last I checked) there was no strong-crypto version of 4.04 for Linux. Now, I don't actually _use_ S/MIME, so I can't say for sure if it works, but the option to encrypt email with strong crypto is certainly presented to the user in my version. When I told McKay about this, he said that he had done a similar thing, and it was in testing. Another interesting point about Fortify: Fortify contains _no crypto_. The version of Netscape that is internationally available actually has _full-strength_ crypto in it. I believe this has something to do with the deal that was made that will allow full-strength crypto to be exported, but only if it is used with special servers (like some banks). The Netscape binary contains a table that lists all the available crypto routines, and along with each is a flag that indicates whether it should always be available (for the 40-bit stuff) or only available when talking to the special servers (for the good stuff). There is also some sort of integrity check to make sure you don't mess with the table. All Fortify does (as far as I can tell) is disable the integrity check, and then set all the SSL crypto routines in the table to "always available". It is straightforward to make it set the S/MIME routines in the same way. Now, of course, I can't _send you_ my version of Netscape with the strong S/MIME. It's very unclear to me whether I can send you my patched version of Fortify (all it does is set some bits in a table, remember). And, of course, I'm not 100% positive the S/MIME is working. On the other hand, if someone who uses Linux (though the fix should be trivial to port to other systems) wants to email me, and can convince me that he is a U.S. or Canadian citizen, understands the EAR regs, will not violate them, and will report on the usability of strong S/MIME, then I'll send my patches to Fortify along. - Ian ------------------------------ Date: Fri, 30 Jan 1998 18:23:00 -0800 From: Martin Minow Subject: Privacy on the Line, Diffie and Landau Risks readers may be interested in a new book on the politics of privacy: Whitfield Diffie and Susan Landau Privacy on the Line - The Politics of Wiretapping and Encryption Cambridge: The MIT Press ISBN 0-262-04167-7 This book provides an overview of cryptographic history, particularly as it has influenced -- and been effected by -- public policy, national security, and law enforcement. It not a technical book but, specifically, a book about the politics of cryptography. From the book jacket: Whitfield Diffie and Susan Landau argue that if we are to retain the privacy that characterized face-to-face relationships in the past, we must build the means of protecting that privacy into our communication systems. This has not proved simple, however. The development of such protection has been delayed -- and may be prevented -- by powerful elements of society that intercept communications in the name of protecting public safety, intelligence and law-enforcement agencies see the availability of strong cryptography as a threat to their functions. Martin Minow minow@apple.com [Excellent book. I read it cover to cover, and it held my attention better than many spy novels. PGN] ------------------------------ Date: Wed, 11 Feb 1998 00:00:23 -0500 From: "David M. Balenson" Subject: REMINDER: ISOC 1998 Network and Distributed Security Symposium 1998 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM March 11-13, 1998, Catamaran Resort Hotel, San Diego, California Sponsored by the Internet Society Program Chairs: Matt Bishop and Steve Kent ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss98 EARLY REGISTRATION DISCOUNT DEADLINE: ==> 13 Feb 1998 <== KEYNOTE SPEAKER: Howard Gittleson, Director of the Internet Security Products Group at Bell Laboratories, Lucent Technologies THIS YEAR'S TOPICS INCLUDE: - Internet and Intranet security - Implementation issues for electronic commerce - All-optical networks security - Secure single login - Timestamping protocols - Remote password protocols - Mobile agent systems security - Java security - Trust management - Traffic analysis of TCP gateways - Secure bootstrapping - Firewalls and IP security NEW THIS YEAR! PRE-CONFERENCE TECHNICAL TUTORIALS FOR MORE INFORMATION contact the Internet Society: Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA Phone: +1 703 648 9888 Fax: + 1 703 648 9887 E-mail: ndss98reg@isoc.org URL: http://www.isoc.org/ndss98/ ------------------------------ 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.59 ************************