Subject: RISKS DIGEST 18.40 RISKS-LIST: Risks-Forum Digest Tuesday 3 September 1996 Volume 18 : Issue 40 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: Accidental missile launch: color-code mixup (Ken Wood) About 3 weeks with network problems...!!! (Isaias Callejas) A funny thing happened on the way to the bank... (Andy Piper) Changing credit-card address (Gene M. Stover) Back-country technology (Andrew Duane) FedEx monitoring of cellular phonecall locations (Bernard Glassman) Re: "More power to us" (Ralph Barone) Algol passwd changer? (Marianne Mueller) Risks of multiple HTTP standards (Pete Bentley) Re: Tunnel vision of Computer Society CD-ROM (Geoff Kuenning, Theodore Y. Ts'o, Timothy R Prodin) Re: Exploding GPS (RISKS-18.39) (Matt Fichtenbaum) Re: Karpov v. the Internet" game (Dick Mills, Pete Mellor) 19th Information Systems Security Conference (Jack Holleran) Information Security Conference - Cleveland (Robert Terry) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Fri, 30 Aug 1996 12:00:09 -0500 From: Ken Wood Subject: Accidental missile launch : color-code mixup The never ending saga of technology + human error = disaster: Inquiry Ordered in Missile Incident STEWART BELL, *Vancouver Sun* The Canadian navy mistakenly launched an unarmed missile at a town near Victoria, B.C. on Thursday, hitting a residential garage and narrowly missing a food store and day care centre. Sailors were testing weapons systems aboard the HMCS Regina at 11 a.m. when the missile was fired at the town of View Royal on Vancouver Island. The military has since suspended all such testing on both coasts and ordered an inquiry. Although nobody was injured, residents of the bedroom community of 6,000 people say things could have been much worse. Thirty-two children were a half-block away at the Tiny Tots Day Care Centre when the incident occurred. HMCS Regina, one of Canada's new $1-billion high-tech frigates, was docked at CFB Esquimalt on Vancouver Island during the mishap. A military official blamed human error, saying a sailor inserted a live missile instead of a dud into the launcher. The error apparently resulted from a mix-up over the color-coding of the missiles. While the test called for a green "inert test set," which contains no propellant and therefore could not launch, a blue "inert practice round" was mistakenly used. Neither the missile that was fired, nor the one that was supposed to have been fired, contained explosive materials. But the errant missile - 1.5-metres long and weighing 18 kilograms - struck with considerable force, punching a hole in the garage roof and passing through a workbench before exiting the building and burying itself deep in the lawn. The story says it all, no commentary needed! Source: http://www.southam.com/vancouversun/ ------------------------------ Date: Fri, 30 Aug 1996 11:23:25 -0600 (CST) From: Isaias Callejas-SYC Subject: About 3 weeks with network problems...!!! About 3 weeks with network problems [resulted] when on an "enchanted" day somebody connected an Ethernet transceiver AUI-UTP over the net with the Heartbeat Switch enabled. There are two switches located on the top of the unit: the Heartbeat Enabled (HBE) switch and the Link Test (LNK) switch. The switches are initially set to both Heartbeat and Link test "Enabled". In the Heartbeat enabled position, the transceiver send a signal (called a "heartbeat") across the AUI collision pair (COL) immediately after it transmits. In the disabled position, a heartbeat is not sent back to the attached device. The manual says that if the transceiver is attached to a repeater you have to place the switch in the disabled position. Otherwise, the heartbeat signal will falsely indicate collisions to the repeater. The risks I see are : * The transceiver was connected to a PC over the net WITHOUT read the network board's manual of the PC and transceiver, and as the HBE is enabled by default... * The risk begin when somebody do something that can affect to everybody without tell it to anybody...!!! My questions are : * Is it necessary to have the HBE enabled by default from factory..??? * Is more common to need the HBE enabled than disabled...??? The problem was already solved and we spent a lot of time trying to do it. E. Isaias Callejas Mancilla Sistemas y Computadores de Gestion Luis Kuhne #10, Col. Las Aguilas C.P. 01710, Mexico D.F. (525)664 00 96 ------------------------------ Date: Mon, 2 Sep 1996 17:02:16 +0100 From: andyp@parallax.co.uk (Andy Piper) Subject: A funny thing happened on the way to the bank... Not a new subject to RISKS readers, but a personal experience that amazed me could happen. I went to our local ATM to get some cash to pay the plasterer last week. I requested 110 pounds, the machine said "please take your money", nothing appeared, then it said "please take your receipt", nothing appeared. I rushed into the bank, they checked it on the computer and yes it appeared to be a valid transaction and yes it had been debited from my account. As it wasn't a branch of my bank I have had to fill in a disputed transaction form to try and claw the money back. This of course is the age old risk of the computer says its true so it must be :). However, we usually associate problems with ATM's with malicious intent rather than software bugs. For I realised what the problem was - when I used the ATM I initially pressed proceed without entering an amount. The machine then reported the error and asked me for the amount. I am convinced that the "unusual" input conditions triggered a software bug, and sure enough when I tried again entering the right amount straight off I was presented with the cash, although by this time I was 220 pounds the poorer. I am just shocked that it was this easy to confuse a simple piece of software/firmware, where the result is rather painful. I assume that they count the ATM delivery every night so that I *will* eventually get my money. andy piper andyp@parallax.co.uk ------------------------------ Date: Fri, 30 Aug 96 22:36:31 -0500 From: "gene m. stover" Subject: Changing credit-card address I know we've already seen incidents like this, but I thought I'd mention it for the record: I recently moved and called my credit card company to inform them of my new address. To verify that I was who I claimed, they asked me for the last four digits of my social security number, which I supplied. Of course, their records didn't agree. The clerk and I discussed for a while how I could prove my identity. In the end, she said she would change my address now if I agreed to call during the next business day to work out the discrepancy with my social security number. But it gets better. I called during business hours the next day to give them my true social security number. Of course, they needed to verify that I was who I was, so the clerk asked me for my address. The risks? Let me count the ways ... gene m. stover (gene@CyberTiggyr.com) ------------------------------ Date: Tue, 3 Sep 1996 10:10:08 -0400 (EDT) From: Andrew Duane USG/PE Subject: Back-country technology >From the GORP section of the September 1996 issue of the AMC (Appalachian Mountain Club) *Outdoors* magazine: Clueless: When two Pennsylvania hikers discovered they were lost in the White Mountain National forest this summer, they tried to use their spiffy high-tech Global Positioning System (GPS) [receiver] to get un-lost -- only the darn thing turned out to be pretty useless without a map. No matter, the hikers simply dialed for assistance on their cell phone. Luckily, officials who fielded the call had not only a GPS, but a map, too, and located the hikers. Andrew L. Duane (JOT-7) Digital Equipment Corporation duane@zk3.dec.com (603)-881-1294 ------------------------------ Date: Mon, 2 Sep 1996 22:24:13 -0400 (EDT) From: glassman@sunsite.unc.edu Subject: FedEx monitoring of cellular phonecall locations A week or so ago I used my Cellular One phone to call FedEx to inquire about Saturday pickup locations near Boone or Blowing Rock NC. At the time, I was nowhere near either of those places, so I did not bother to mention my current location to the operator. The next day, Saturday, I called FedEx with the same cell phone from Blowing Rock to arrange the pickup. The operator immediately asked if I wanted them to come to the intersection that I had placed my call from the day before. Two days later, a FedEx operator confirmed that they are getting "new systems" at some locations that are able to record the locations from which cellular calls are placed. I have now asked Cellular One three times to explain to me why they do not tell subscribers that they pass this location information through the system, but to no avail. Each person I talk with says that he or she has never heard that this information is available, 1. Is it just me, or does it seem to other readers that there are legitimate concerns about RISKS to cell phone subscribers who are not warned that they may be having their locations monitored? 2. Is it possible for FedEx to capture information that Cellular One doesn't know it's passing? Bernard Glassman ------------------------------ Date: Wed, 14 Aug 1996 11:07:09 -0700 From: "Ralph Barone" Subject: Re: "More power to us" (RISKS-18.32) [This message was intended to have been included earlier. It is offered now as presenting some useful background on the 10 August power outages. PGN] In my personal opinion (not that of my employer), there are some factors that contribute to outages like this. 1) The transmission system (the lines between substations) is constructed with more redundancy than the distribution system (the lines from the substation to your house). As a result, the transmission system tends to be more reliable than the distribution system and most failures on the transmission system do not result in loss of service to customers. Usually, when you have an outage at your home, it is because of a fault on the distribution system. However, the transmission system is built on a much larger scale than the distribution system. Also, when redundant systems finally fail, they tend to fail in a much more spectacular fashion than non-redundant systems. Therefore, when an outage is due to transmission problems, it tends to be a BIG outage. 2) Utilities, like any other business, are in business to make money. To make more money, you should own as few assets (lines, generators) as possible, utilize it as heavily as possible (to maximize sales) and keep other costs low (small staffs and extended maintenance intervals). This is counterbalanced by pressures from regulatory agencies and customers to provide reliable service. The opening up of the wholesale electricity market in North America is putting greater pressure on electric utilities to be profitable. This tends to push the balance point towards the side of unreliability. A similar thing has happened in the long distance telephone market. AT&T originally lost customers over price, but is recovering customers on the basis of convenience and reliability. The electric power market appears to be going through a phase similar to the early days of competitive long distance telephone service. 3) Western Systems Coordinating Council (the coordination council for Western US/Canada) regulations mandate that each utility must have 10% extra generation or "Spinning Reserve" available in the event of a system disturbance. For example, if the utility is presently generating 1000 MW, it must be able to bring an additional 100 MW on-line within a certain period of time (1 - 3 minutes, I believe). Power brokers have recently started buying selling reserve, aggregating it into a pool and selling it from the pool back to utilities. For example, if utility A requires 100 MW of spinning reserve, but the only generator they have that isn't already generating is 200 MW, they can now either: - buy 100 MW of reserve from the pool and take their generator off standby (perhaps for maintenance). - leave their generator on standby and sell 100 MW of spinning reserve to the pool, allowing some other utility to take a 100 MW generator off standby. - buy 120 MW of reserve from the pool, put their generator on-line and sell 200 MW on the open market. The net effect of this is a reduction of total spinning reserve due to the better fit of each utilities individual resources into the larger spinning reserve pool. This gives the system a smaller buffer in the event of an emergency and increases the chances of outages cascading. Ralph Barone, Protection & Control Manager/HVDC Control Engineer BC Hydro Ralph.Barone@bchydro.bc.ca ------------------------------ Date: Tue, 3 Sep 1996 10:20:04 -0700 From: Marianne Mueller Subject: Algol passwd changer? (Re: Bass, RISKS-18.39) The article in RISKS titled "Java passwd changer?" caught my attention, but the surprising discovery was that this article has nothing to do with Java. The author speculates about the risks of an automatic password changer, but there isn't one being used today that is causing him to worry. Of course, such a system could be written and deployed in any language. But it couldn't be written and deployed as a Java applet, since the default Java applet security policy prevents applets from reading or writing to the client disk. I'm not sure what the moral of the story is, but I do know that since the RISKS list is archived all over the place, Java will now show up on search engines with the title "Java passwd changer?" and no doubt people will start writing "USA Today"-style articles about the danger of Java changing passwords! It may be that the biggest Internet security risk right now is that it's getting harder and harder to find accurate information about computer-related risks. Marianne JavaSoft engineering, security http://java.sun.com/people/mrm ------------------------------ Date: Tue, 03 Sep 1996 15:37:16 +0100 From: Pete Bentley Subject: Risks of multiple HTTP standards The Microsoft Network offers a free service allowing people to create their own custom 'start' page at http://www.msn.com/ which may contain personal information including the individual's address. All of this information is encoded into a 'cookie' which is stored by the user's own web browser and so in theory cannot be seen by other people. Or can it? MSN uses Microsoft's own product, Microsoft Internet Information Server 1.0, as its web server and it tries to send a response which will ensure that http://www.msn.com/ is not cached by any proxy servers (to prevent people seeing each others information by mistake), but is cached by the users web browser for a short time (for speed). It does this by sending an HTTP/1.0 reply with Date and Expires headers which indicate that the information is valid for half an hour and adds a "cache-control: private" header to prevent any proxy servers from caching the information. However, cache-control is a header from the draft HTTP/1.1 specification which is not interpreted by many HTTP/1.0 proxy servers in use today (verified by myself with the CERN and Squid proxies) and so is ignored. The remaining headers indicate to the proxy that it may cache the page itself for half an hour. If the proxy then caches a page containing a user's personal information then any other user accessing http://www.msn.com/ via that proxy in the next half hour will receive that page (and personal information). This scenario has indeed been observed in practice with a busy web proxy run by a large ISP and a detailed analysis has been sent to Microsoft for their attention. The risk here seems to mostly be mixing HTTP standards and assuming that HTTP/1.0 servers will understand some HTTP/1.1 headers. It raises issues for both server coders and cache coders as the Net starts gradually migrating to HTTP/1.1 at the same time as 'smart' web servers (generating pages on the fly) want finer control over caching proxies. Pete [Aside: whilst making HTTP requests by telnetting to www.msn.com:80 (to compare headers), I noticed that www.msn.com either restarts (connection refused) or goes missing (routing loops between msn.net routers) quite frequently. ] ------------------------------ Date: Fri, 30 Aug 1996 12:42:22 -0700 From: Geoff Kuenning Subject: Re: Tunnel vision of Computer Society CD-ROM (Kuenning, RISKS-18.39) Only moments after the appearance of my complaint about the short-term usability of the IEEE Computer Society CD-ROM, people started e-mailing me to defend the decision to use SGML. Rereading my posting, I realized that I did not make myself clear. I do not object to the choice of SGML as a format; to the contrary (without having had the time to read an SGML spec) I suspect that it was a very wise choice. My problem is two-fold. First, the software to view the articles on the disc was provided in a very short-term format, and one that disenfranchises a large fraction of the potential customers. (To publicly answer a couple of private suggestions, I do not think that I should have to go out and browse the net to get this software, nor do I think that it would have been any better to have included an emacs viewer as well as those already present.) The second problem, which I somehow omitted from my previous message, is that the software to search the database is proprietary. So even if I download an SGML viewer from the net, I can only display articles, and can't take advantage of the nifty search features that ought to be available to everyone. *No* solution is acceptable if it depends on external capabilities other than the ability to read simple ASCII from the CD-ROM. Bootstrapping by compiling is OK, and it's OK to provide pre-bootstrapped software for common platforms. But I doubt that any of those platforms will be common 30 years from now, so the Computer Society should have provided for this possibility. (Incidentally, Software Practice and Experience made the same mistake a year or two ago, except that they limited themselves to Windows 3.1. I contacted them at the time, and received a polite response that resulted in no action.) Geoff Kuenning g.kuenning@ieee.org geoff@ITcorp.com http://fmg-www.cs.ucla.edu/geoff/ [RISKS received messages on this topic from jdzik@aol.com (JDzik), ajm@mcs.com (Alan Miller), Matthew Wojcik , tprodin@ford.com (Timothy R Prodin), "Theodore Y. Ts'o" , Al Stangenberger . Al noted that "This is a widespread problem, though. I try to convince users that using Excel spreadsheet format for long-term archival storage of data is not a very good idea." Geoff's message more or less summarizes much of the discussion, but the following messages from Ted Ts'o and Timothy Prodin seem worthy of inclusion, even if somewhat redundant, as representative of these responses. PGN] ------------------------------ Date: Fri, 30 Aug 1996 16:01:44 -0400 From: "Theodore Y. Ts'o" Subject: Re: Tunnel vision of Computer Society CD-ROM (Kuenning, RISKS-18.39) Actually, storing its articles in SGML was the right choice for the IEEE to have made. The reason for this is that SGML is a platform independent format --- SGML, or "Standard Generalized Markup Language" is an ISO standard ISO 8879:1986. While the CD-ROM may have only had viewers for Macintosh, Windows 3.1, and a few Unix platforms, it's much more likely that an article formatted in SGML will have viewers available on other platforms than, (for example) if the articles were stored in Microsoft Word format. A few more words about SGML. What's really good about SGML is that it is designed to deal with *structured* text. You don't specify things like "Times-Roman-Italics, 10 point"; instead you specify "book title", and leave it to the SGML viewer to put the text of the book title in the appropriate font. This is important, because different platforms have different fonts available to them; and 100 years from now, who knows what fonts will be available by default. An SGML document has a prologue where it declares its Document Type Definition (DTD). The Hypertext Markup Language (HTML), which is used by the Web, is a DTD. Other examples of SGML include the QWERTZ DTD, which provides most of the facilities of LaTeX, and the LinuxDoc SGML, which is derived from the QWERTZ DTD, and which is the standardized format for the Linux Documentation Project (LDP). The LDP has provided Linuxdoc-SGML translators which will take the Linuxdoc-SGML and translate it into LaTeX, groff, HTML, and texinfo. (And of course, from all of these formats, you can then get postscript or Adobe PDF). So the mere fact that the IEEE CD-ROM is using SGML does not mean that they have "stumbled badly". What's really important is what DTD did they use to format their articles, and is that DTD documented so that other people can write their own SGML translators. Of course, it would have been best if the IEEE could have provided the source to the SGML translators, but there may have been licensing issues barring them from doing so. Could you use raw ASCII text instead of SGML? Of course. However, you would lose all the nice formatting that you would get if you were reading the article in printed form. Things like diagrams and graphics would be lost. The advantage of using SGML is that all of this information is preserved, and assuming that the definition of the DTD is public, it shouldn't be difficult to write a SGML -> raw text translator. It would no doubt lose information during this transformation, but that's what you get if you insist on viewing things using raw text. Ted ------------------------------ Date: Tue, 3 Sep 1996 10:31:22 -0400 (EDT) From: tprodin@ford.com (Timothy R Prodin) Subject: Re: Tunnel vision of Computer Society CD-ROM (Kuenning, RISKS-18.39) In RISKS-18.39, Geoff Kuenning pointed out some problems with the IEEE Computer Society publications on CD-ROM. I would like to correct a mistake and some perception problems that appeared in his article. First, SGML is not a superset of HTML. SGML is a meta-language that is used to describe content models for documents. Various flavors of HTML are implementations of SGML; with the notable exception of Netscape 3.0. The tool that IEEE provides for viewing the collection is EBT's DynaText; but because a conforming SGML document instance is tool independent, you can get many different viewers for many different platforms and not have to worry about tool compatibility. You can even construct your own viewers/publishers/search engines, use DSSSL to provide online or paper formats for the instance, and standard tools to perform transformations into other DTDs, such as HTML 3.2. [...] IEEE did not disenfranchise their members or customers. An SGML instance is not based on proprietary software; it is in fact based on the complete opposite, a recognized international standard, ISO8879. There exists many tools in the public domain and commercial markets for viewing, manipulating and transforming instances. Second, the choice reflects lots of planning for technology of the 21st century. There exists a commitment from ISO to keep any modifications to the standard backwards compatible with the current version. Because the standard is in the hands of an international body and not a corporation (such as Netscape's HTML; or Microsoft's RTF) there is a guarantee that changes to the standard will be made only with public comment, public notification, and reference implementations. It is precisely because IEEE cannot predict the future that they selected a document format that will insulate them from various operating system quirks, future changes, and emerging technologies. ------------------------------ Date: Fri, 30 Aug 1996 19:47:17 GMT From: mattf@harpa.ultranet.com (Matt Fichtenbaum) Subject: Re: Exploding GPS (RISKS-18.39) At my last employer we once had a lithium battery explode. Maybe it's the same phenomenon. The battery in question preserved calibration data in a memory chip. When the instrument in question was powered, the memory was powered from the main supply and a diode blocked current from flowing into the battery (lithium batteries are not meant to be charged). In this particular instrument, the diode had been installed backwards, so when the instrument was on the battery had energy fed _into_ it. The resulting internal heating raised the internal pressure until the battery case let go. Or maybe, in the GPS instance, the GPS receiver thought it could get a better assessment of its location if it was in lots of places at once. ------------------------------ Date: Sun, 1 Sep 1996 12:44:53 -0400 From: rj.mills@pti-us.com (Dick Mills) Subject: Re: Karpov v. the Internet" game PGN wrote: >Better yet, one grand master with others kibitzing by e-mail. >If a grand master can play simultaneous matches, it should be >no difficulty winnowing the e-mail suggestions in real-time. I didn't see the smiley after your note Peter, think again. [RISKS TENDS TO SUPPRESS GRATUITOUS SMILEYS. HOWEVER, ONE WAS EVIDENTLY IMPLIED FOR THIS ENTIRE DISCUSSION, which intended to convey that the whole thing was rather silly. PGN] Rather than an aid, this would be the ultimate sabotage for a grand master trying to concentrate on his game, while playing against a time limit. It would be akin to having many people trying to shout in his ear. The same reasoning leads us to forbid citizens from using hand-held radios to kibitz the flying techniques of pilots while on final landing approach at the airport. Dick Mills +1(518)395-5154 http://www.pti-us.com AKA dmills@albany.net http://www.albany.net/~dmills ------------------------------ Date: Sat, 31 Aug 96 20:07:17 BST From: Pete Mellor Subject: Re: Karpov v. the Internet" game PGN adds:- > The result was clearly not a surprise. Only about 300 hundred opponents? Maybe that was the 300 people who did not realise that the exercise was farce! > Suppose the group was > composed of only a few grand masters? What would that do to the odds? Improve them for Karpov! (Each grand master would propose a brilliant move in each situation. These would generally be dissimilar, since each grand master would have a different vision of how the game would look 10 moves on. Their brilliance would therefore be cancelled out.) > Better yet, one grand master with others kibitzing by e-mail. *That* is the point. Karpov was not (as far as I know - correct me if I'm wrong) playing the combined power of 300 brains. Given 300 randomly selected players, most of whom would make weak or indifferent moves, the "most frequent" response chosen "by computer" would almost certainly be one of the weakest responses, and (as an earlier correspondent pointed out) not consistent with any single well-thought out plan of attack or defence. The group that Karpov was playing were *not* consulting one another to agree on the best strategy. What is the point of having computer voting that looks one move ahead in opposition to a chess genius who thinks at least 7 moves ahead? It would be interesting to see an analysis of the resulting game. I bet it was more crapov than Karpov! 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 ------------------------------ Date: Sun, 1 Sep 96 08:28 EDT From: Jack Holleran Subject: 19th Information Systems Security Conference ANNOUNCEMENT 19th National Information Systems Security Conference Baltimore Convention Center October 21-25, 1996 The full announcement [see below] is now available on-line and has 1. The final program (complete, long, & detailed) 2. Workshop and Demonstration information 3. Registration Form 4. Housing Form (Conference Hotel with pricing information) Registration Information: Tammie Grice, Conference Registrar Voice: (301) 975 - 3883 FAX: (301) 948 - 2067 EMAIL: nissconference@dockmaster.ncsc.mil WWW: http://csrc.nist.gov/nissc/ Cost: $295, with early registration through September 19, 1996; $335 after September 19, 1996 ------------------------------ Date: 2 Sep 1996 05:03:12 -0700 From: Robert Terry Subject: Information Security Conference - Cleveland Second Annual NASA Lewis Research Center conference - "Perils of the Internet and Practical Solutions - Confronting Threats from Hackers, Crackers, and Sniffers." 24-26 Sep 1996, Cleveland, OHIO. For more Information: http://www.dis.org/se7en/ndi ------------------------------ Date: 15 Aug 1996 (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 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 18.40 ************************