Text File

precedence: bulk Subject: Risks Digest 20.52

RISKS-LIST: Risks-Forum Digest Thursday 5 August 1999 Volume 20 : Issue 52

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 <URL:http://catless.ncl.ac.uk/Risks/20.52.html> and at ftp.sri.com/risks/ .

Contents: Can You Trust AT&T Wireless PCS Text Messaging? (Lauren Weinstein) EverQuest devours players' lives (Mich Kabay) Microsoft Word footnote problems irks federal appeals court (Declan McCullagh) Perceived medical risk must often substitute for actual risk (John Doyle) Open-source anesthesia software article in Salon (Martin Minow) Re: IMRSS and Open Mail Relay Scanning (Lauren Weinstein) Re: Japanese toilets (Chiaki Ishikawa, Brian Randell, Colin Sutton) Risks of RISKS (Brian T. Schellenberger) eBay's response to the eBay scam (Ray Randolph) Re: Go FORTH and Multiply (Leo Wong) Re: Heat wave (David Wittenberg) Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Wed, 04 Aug 99 19:47:17 PDT From: Lauren Weinstein <lauren@vortex.com> Subject: Can You Trust AT&T Wireless PCS Text Messaging?

Greetings. Can you trust that messages sent via AT&T Wireless PCS Text Messaging will always be reliably processed and received? Unfortunately, the answer appears to be no. What's worse, when failures do occur, there may be absolutely no indication to the sender of the message that their communication has vanished into the ether. An an example of a serious risk associated with a more general class of modern, widely-used communications systems, I believe that this is worthy of a detailed explanation and significant concern.

The use of text paging directly to digital/PCS cellular phones is rapidly replacing the use of conventional numeric and text pagers. Such phone-based text messaging, actually called "SMS" (Short Messaging Service) has a number of advantages over older paging systems. One of its biggest benefits is that the network will normally store messages for some extended period of time (e.g. 72 hours) for delivery to the phone, if the target phone is off or out of range. When the phone again is available, the message is delivered, and the network receives confirmation that the message was successfully delivered to the phone. SMS messages typically can range between 110 and 150 characters or so, depending on how they are submitted and various formatting considerations.

The usefulness of SMS has caused an explosion in its use for all manner of free and pay information and warning systems, where automated systems will send messages (usually via an Internet e-mail interface provided by the wireless carriers) to users. Such messages could be anything from critical status messages for system support or medical personnel, to news bulletins and stock price warnings to traders.

But how useful is the entire environment if you cannot depend on messages ever actually being delivered, and if messages can vanish into a "black hole" without any warning?

AT&T Wireless (ATTWS) has, as you might expect, one of the most extensive SMS implementations. They provide three interfaces to the service:

* a web-based "form" interface: type in your message and hit send

* a direct dialup interface for specialized text paging software's use

* an Internet e-mail interface: messages are sent to <cellular-number>@<a specific AT&T site>

The Internet e-mail interface is by far the simplest method to use both for Internet-connected individuals and automated systems. Unfortunately, it is also this interface that apparently has the most problems. Since phones are addressed via their mobile number without any additional access codes being required, anyone who knows a cellular number can "flood" a phone with messages, eating up a user's entire monthly message allocation in short order--there's no way for the phone user to control such access. There are also some "denial of service" issues associated with this same lack of access control.

But of even greater concern is the fact that text messages submitted to ATTWS via their e-mail interface, at least for delivery to phones in the Los Angeles area (I don't have info about other areas at this time--it might well be a nationwide issue) can frequently simply "vanish" after delivery to the ATTWS e-mail gateway. Such "vanished" messages are never delivered to the phone user, nor is any indication of a problem ever received by the original sender of the message.

When this problem was originally brought to my attention recently, I was initially a bit skeptical, but testing indicated that it is indeed the case. While messages submitted via the web or paging software dialup interfaces were reliably delivered to phones, it was not difficult to find instances of messages submitted to ATTWS via their Internet e-mail interface which had simply gone poof! Interestingly, these seemed to all occur in the weekend period (Friday night through Sunday morning), at least in my testing. In all cases, Internet mail delivery logs showed conclusively that the messages in question had been accepted successfully by the ATTWS SMS e-mail server (which is actually labeled as an "airdata.com" server). But the messages were never delivered to the target phones.

My initial contacts with ATTWS customer service about this were not inspiring. While the front line folks tried to be helpful, they have very limited information to work with (this is unfortunately typical of ATTWS customer service in many respects--many seemingly simple questions may receive answers ranging from correct to totally wrong from different representatives).

In this case, one rep told me that they had "heard" that the web interface was better to use and more reliable, and that he'd heard about paging system problems on weekends. He suggested that perhaps they take the system down for testing on weekends. This of course, even if true, would not be an acceptable explanation for the permanent disappearance of potentially important text messages!

Eventually I found my way to an ATTWS manager, with whom I am in continuing contact. While he initially didn't seem to understand the issue--at one point asking me if I'd ever missed an old-style regular page and pointing out that ATTWS service doesn't cover all areas (neither of which are at all relevant to the store-and-forward SMS environment and the problems at hand), he did ultimately appreciate both the issue and concerns.

He promised to try track this down with the technical folks, and I am still hopeful of a response, but as of this time, I have yet to receive an explanation.

Since then, additional testing has revealed more vanished messages following the same pattern, including as recently as this past weekend. I've also received reports from other persons regarding related AT&T Wireless PCS text messaging problems using interfaces other than the Internet e-mail interface, but I've concentrated on the e-mail facet in this report since that's where my own testing revealed lost messages.

So, the moral of this story is actually pretty simple--it can be very risky to simply *assume* that messages sent through the ATTWS PCS Text Paging Internet e-mail gateway are actually being delivered to user phones, even if the messages are accepted by the ATTWS e-mail gateway itself. This should be kept in mind if you're expecting to receive important information or other messages via such a method. The end-to-end, store-and-forward sophistication of SMS should be able to avoid the whole concept of permanently "missed pages" in the conventional sense over reasonable periods of time. Unfortunately, it appears that with ATTWS, at least at present in some areas, this simply isn't the case.

I'll of course report back when more information about this matter is available.

Lauren Weinstein, Moderator, PRIVACY Forum, http://www.vortex.com; "Vortex Daily Reality Report & Unreality Trivia Quiz" http://www.vortex.com/reality

------------------------------

Date: Fri, 30 Jul 1999 00:12:25 -0400 From: Mich Kabay <mkabay@compuserve.com> Subject: EverQuest devours players' lives

Hunter Godfrey is quoted as saying that EverQuest "is the digital version of crack." He has spent over 656 hours on the game in about four months, the equivalent of 82 8-hour days. There are over 150,000 players ``hunting monsters, collecting loot, and forging alliances in MUD world.' [Source: Noah Shachtman, EverQuest: the Latest Addiction, Wired Digital, 29 Jul 1999; PGN-ed]

[Watch out for network congestion on corporate systems when this infiltrates workplace networks. M.E. Kabay, PhD, CISSP / Director of Education R&D Group / ICSA Labs <http://www.icsa.net>]

------------------------------

Date: Wed, 04 Aug 1999 14:40:40 -0700 From: Declan McCullagh <declan@well.com> Subject: Microsoft Word footnote problems irks federal appeals court

The U.S. 7th Circuit Court of Appeals is peeved at Microsoft. Seems as though unlike WordPerfect, MS Word doesn't count properly footnotes, and lawyers doing wordcounts have been running over length limits on briefs. Naughty, naughty, say the judges, who kvetch: that MS "ought to make it possible to obtain a count of words in footnotes attached to selected text." The august three-judge panel has forwarded a copy of its design recommendations to Redmond. More info in a Wired News story (4 Aug 1999): http://www.wired.com/news/news/politics/story/21096.html

-Declan

------------------------------

Date: Sat, 31 Jul 1999 10:16:59 PDT From: "John Doyle" <djdoyle@hotmail.com> Subject: Perceived medical risk must often substitute for actual risk

All human activities entail risk. Indeed, to live is to take risks.

In the medical realm, patients who undergo anesthesia and surgery are frequently concerned about the risks involved, such as the risk of *not waking up* (or as one patient put it, *waking up dead*).

The risk of death or brain damage to patients undergoing general anesthesia is remarkably low, particularly for healthy patients in modern hospitals. When an accident does occur, its cause is often an error made by the anesthesiologist, either in triggering the accident sequence, or failing to take timely corrective action. The overall risk of death for general anesthesia in all comers is in the range of 1 in 10,000, the exact estimate depending on how one separates anesthesia misadventures (such as airway problems) from surgical misadventures (such as accidentally avulsing an artery).

Risks for individuals with specific conditions are sometimes known, but usually not. For example, administering general anesthesia when a patient still has residual food in his stomach poses special risks since the food sometimes ends up in the lungs (known as aspiration), with consequences ranging from trivial to deadly. However, risk data specific to any patient in this situation are not yet available. For instance, factors such as the "state of the anesthesiologist", characterized in terms of alertness, vigilance, and competence, would also be important.

(Of course, anesthesiologists employ a few good tricks to reduce aspiration risk. One trick that is not generally used would be to suck out all the food under visual guidance using a gastroscope. However, this procedure in itself introduces new risks and is at best unpleasant in the awake patient.)

Some individuals are surprised to learn that in a great many situations (indeed, in most complicated clinical situations) the risks of anesthesia or surgery may not be even approximately known (as in known to within an order of magnitude). No algorithm yet exists that one can use to get quantitative risk estimates for all situations. An example illustrates the point.

Recently I was asked to give an anesthetic for a man with several serious heart problems, the most pressing being a chaotic heart rhythm known as atrial fibrillation, which the heart doctors planned to fix with a big electric shock to the chest under general anesthesia (cardioversion). Once atrial fibrillation has started, it must be fixed within 48 hours or it will be necessary to start anticoagulant therapy (administration of *blood thinners*) to reduce the risk of a stroke. We had about 30 hours left.

Because of concerns about harming the patient with a general anesthetic I initially recommended against the cardioversion (electric shock) procedure, viewing drug therapy to be a clearly safer alternative. The trouble with drug therapy, however, is that it is far less effective and in addition requires a much longer hospital stay. In other words, cardioversion was by far the quickest and more cost-effective choice, although drug therapy appeared to be the safer choice.

But the final twist that lead us to go for the cardioversion was that the cardiologist pointed out that if drug therapy turned out to ineffective in this individual by the end of the 48 hour window, the option of subsequent cardioversion could not again be exercised until 4 weeks of anticoagulant therapy had passed. The risks (such as the risk of bleeding) and costs associated with that option now made cardioversion seem more attractive.

The unique nature of this particular patient's problem list meant that any risk estimates from the literature would almost certainly be meaningless. It was therefore necessary to rely on judgement drawn from experience rather than formal risk data. Perceived risk must substitute for actual risk in many settings.

D. John Doyle MD PhD FRCPC, University of Toronto and Toronto General Hospital djdoyle@home.com http://doyle.ibme.utoronto.ca

APPENDIX The proposed drug therapy was intravenous amiodarone. Medical conditions included: recent myocardial infarct with impaired ventricular function, aortic stenosis, atrial fibrillation, gastroesophageal reflux (a *full stomach* equivalent situation.) The patient was also known to be very difficult to intubate because of a small chin! Finally, note that moderately reliable mortality estimates for multi-organ failure patients in Intensive Care Units can be obtained by using the APACHE II algorithm; this is one of the few situations where good risk data exist for complicated patients.

------------------------------

Date: Thu, 5 Aug 1999 07:57:03 -0700 From: "Minow, Martin" <MMinow@itc-us.com> Subject: Open-source anesthesia software article in Salon

Risks readers may be interested in an article by Andrew Leonard in the online magazine, Salon, on the risks (and potential advantages) of open-source medical software:

<http://www.salonmagazine.com/tech/feature/1999/08/05/anesthesia/index.html>

"When he isn't in the operating room taking care of patients, [Dr. Stefan] Harms is hacking on the five computers in his basement. And he thinks he knows how to achieve his dream of low-cost, reliable anesthesia software -- by going the open-source </tech/special/opensource/> route. Last year, Harms founded LAMDI, <http://gasnet.med.yale.edu/lamdi/> the Linux Anesthesia Modular Device Interface. Harms thinks that the open-source software development model, in which the source code to a program is made freely available to the general public for redistribution and modification, offers fruitful possibilities for addressing anesthesiological software needs. ...

"The obstacles faced by Harms in his quest for open-source anesthesia software suggest that there are some serious potential limits for the open-source software model. The experience of some medical programmers who have placed their code in the public domain indicates that open source is certainly no panacea for the problems faced by medical practitioners. But there are still some intriguing possibilities. If liability issues can be addressed, and if the peer-review component embedded in open-source software can be proven to result in pragmatically better software, then, suggest some open-source enthusiasts, wouldn't it be our duty to proceed down the open-source road?"

(Transcribed by Martin Minow, minow@pobox.com, with apologies for any residual Windows formatting cleverness)

------------------------------

Date: Mon, 2 Aug 99 19:16 PDT From: lauren@vortex.com (Lauren Weinstein) Subject: Re: IMRSS and Open Mail Relay Scanning (Roessler, RISKS-20.51)

In RISKS-20.51, concerns were raised over http://www.imrss.org, their ongoing automated search for open mail relays, and the publicly accessible query database of the resulting data which they maintain. It was suggested that such a database might actually help spammers find potential relay targets.

I was also concerned about this, and sent them e-mail asking for clarification on a number of related issues. After several attempts (they have various automated responders I had to deal with) I was quickly rewarded with a phone call from Ron Guilmette, who runs IMRSS. We had a long and friendly chat.

While my own orientation towards fighting SPAM is different than his, and I do not agree with various aspects of his operation, I think it's worth noting that he seems quite level-headed and sincere, and clearly has a lot of experience in the real world of SPAM problems.

Also, they are apparently about to address one of the more serious criticisms of their procedures, by beginning a program to attempt to send notification messages to "postmaster" and/or related addresses (when these exist!) for sites where open relays are found. This will at least provide such sites with an early warning that they were found to have an open mail relay, and that they were added to the IMRSS database.

Lauren Weinstein, Moderator, PRIVACY Forum http://www.vortex.com Member, ACM Committee on Computers and Public Policy

------------------------------

Date: Fri, 6 Aug 1999 01:33:43 +0900 (JST) From: Chiaki Ishikawa <Chiaki.Ishikawa@personal-media.co.jp> Subject: Re: Japanese toilets (Landwehr, RISKS-20.51)

Well the joy and risk of high-tech toilet!

It must have been quite an amusing and hilarious way to really wake up to hear the interview on NPR (National Public Radio?). And many seem to think that the Japanese is too serious a nation without the proper sense of humour, but I digress.

The case, eh, the toilet in question was an 18 years old toilet that caused a minor fire in April this year (1999). The cause seems to be a trouble in electrical wiring due to leaking water.

Trying web search engines with "toilet fire" in Japanese didn't turn out useful pages at all. Below is what I gleaned from an article at Mainichi Shimbun newspaper site (in Japanese).

By the way, fires believed to be caused by similar toilets were reported in October last year (1998), and July 1993.

The fire in April this year was believed to have happened in the the following manner. The plastic vinyl water pipe (for supplying heated water, I think) degraded and water began seeping. The water caused the temperature sensor to get rusty. The rust caused the electrical resistance of some electrical contacts to go up much higher than it was supposed to be and thus the excessive heat was generated. Finally, the vinyl coating of the electrical wires caught fire.

The family members had noticed the little water seepage about half a year earlier, but did nothing since the basic functions of the toilet such as heater, etc. were still operational.

Many such toilets, of which life time the manufacturers say is about 7 years, are believed to be used in Japan. The fire fighting department of Tokyo government was quoted as saying that such toilets that outlived the warranty period ought to be checked early. (I could not find reference to the toilet at the fire-fighting dept. web site, though.)

In Japan, these type of toilets showed up in the market early 1980's. Today, about third of such toilets are this type according to a survey mentioned in the article.

Personally, it was shocking and amusing to find the toilets of this type when my office moved to a new building about 10 years ago. Being a gadget-interested person as I am, I tweaked the "control" myself. The reported toilets that have seat raise control must be the "Rolls Royce" of this type of toilets. The one at the office doesn't have such a luxury so to speak. Frankly speaking, I doubt if such toilets do exist: we need hydraulic piston or something for that, don't we? In a toilet?

Anyway, even the Mainichi article had to have a cute headline talking about this subject: it goes something like "Many fires by toilet: it smells and your bottom is on fire!"

Oh well. It was a good thing that the interview was not aired on April first. Nobody would have taken it seriously in USA.

Risks? We probably should not put electrical circuits unless absolutely necessary. Toilets are not thought of as the cause of fire at least by many. Of course, run-away faulty microprocessor or whatever will get you in a real trouble such as minor burn!

Ishikawa, Chiaki ishikawa@personal-media.co.jp.NoSpam Personal Media Corp., Shinagawa, Tokyo, Japan 142-0051

------------------------------

Date: Tue, 03 Aug 1999 11:13:04 +0100 From: Brian.Randell@newcastle.ac.uk (Brian Randell) Subject: Re: Japanese toilets (Landwehr, RISKS-20.51)

> ... Some of these have recently been implicated as a source of fires ...

I was pleased to get the above explanation of at least some of the electronic controls on these toilets. Such controls are, not surprisingly a feature in the advanced research laboratory that I've visited regularly in Japan these last few years - one that I made a point of photographing for my unbelieving colleagues back here in the UK.

I had hinted to my hosts that I would appreciate English language instructions or even a manual, so as to understand the multiple buttons, keyboards, and digital displays (including of dates and times) - but neither were forthcoming. However, they did accept the possible validity of my concern that these toilets might well not be Y2K compatible - and we had some interesting speculations as to the likely forms and seriousness of the possible consequences! :-)

Brian Randell, Dept. of Computing Science, Univ. of Newcastle, Newcastle upon Tyne, NE1 7RU, UK Brian.Randell@newcastle.ac.uk +44 191 222 7923

------------------------------

Date: Tue, 3 Aug 1999 22:16:27 +1000 From: "Colin Sutton" <colin@sutton.wow.aust.com> Subject: Re: Japanese toilets (Landwehr, RISKS-20.51)

My wife and I went into a department store in Tokyo and she visited the toilet. When she came out she was soaked and she couldn't stop laughing. After she'd used the toilet (and used it well) she went to flush it and discovered a row of pushbuttons with Kanji labels. Not wanting to leave the toilet in an unsuitable state for the next user, and not reading Kanji, she stood back as far as she could from the toilet and pressed one of the buttons. Hot air started to blow up from the bowl. She tried the next button, and got sprayed with water. Luckily it was winter and she was wearing a raincoat. The other buttons didn't seem to do much at all, perhaps adjust the temperature of the toilet seat or something. None of them caused the toilet to flush. So she gave up, turned to the washbowl (in the cubicle with the toilet, as they often are in Japan). When she turned the tap on, the toilet flushed.

A good design. And the Japanese are so fond of cute icons. It's a pity no one thought about the illiterate.

Colin Sutton, Development Manager, Siemens Building Technologies Pty. Ltd. 14-18 Suakin Street, Pymble NSW 2073 Australia +61 2 98551310

[What about the ill-litter-rate? PGN]

------------------------------

Date: Wed, 4 Aug 1999 10:57:03 -0400 (EDT) From: "Brian T. Schellenberger" <bts@unx.sas.com> Subject: Risks of RISKS

A few miscellaneous risks from recent risks issues:

1. Risk of not explicitly stating the risk.

Marshall Lindsay wrote of the "Conversion service for viewable formats." Our Esteemed Moderator wrote: "But, security by obscurity does not work too well for strange formats."

This suggests to me that perhaps the risk that Mr. Lindsay was referring to wasn't sufficiently clear. The risk is not that formats are decoded; but rather, that the people supplying the conversion service could readily make a copy of every document passing through their translation service. Sooner or later they are likely to acquire plenty of interesting information!

2. Risk of promoting silver bullets.

M. Simon wrote a couple of articles; one teaser and one sort-of real article, promoting the FORTH programming language.

First of all, the "teaser" article should *never* have been printed in RISKS. It contained no actual information; it was just a shameless plug for something that wasn't even named.

Second, as I hope all RISKS readers know, there is no "silver bullet" to the programming challenges facing us, and this article certainly promotes FORTH as just that.

Third, I've used FORTH, and it is a lovely little language, but I think that it's a particularly poor candidate for such a silver bullet if one were to exist at all.

First of all, by its very nature it does not support static error checking. It completely lacks the concept of a "type" which renders its ability to do even run-time error checking very limited. It is great for small projects and for controlling real-world objects. (Controlling telescopes, for example; the application for which was originally designed.) I cannot even begin to imagine managing a large (hundreds of programmers) project with it, and I do not believe that a project that takes hundreds of C or Java programmers could be done with a mere dozen FORTH programmers, either. (Though a project that takes a half-dozen C programmers may very well be doable by a single FORTH programmer, and FORTH is underutilized, it's not a language which scales up to enormous projects well, IMHO.)

3. Risk of waiting for risks to be proven.

Bob Frankston wrote of "Fear in the the skies" and stated that "The real risk of this nonsense is in relieving the airlines for responsibility for safety" and Our Esteemed Moderator observed that lots of e-mail had been received, "most of it suggesting that there is still little hard evidence of bad effects."

All this is true, and yet when we weigh even slight evidence of risk and the airlines responsibility for the safety of its passengers against the rather minute convenience that a cellular phone offers on a plane; and when we consider the social risks of allowing the passengers to determine which safety rules they will follow and which they will ignore when the well-being of their fellow passengers is at stake; I do not believe that the decision in this case was outrageous.

BRIAN TOD SCHELLENBERGER bts@unx.sas.com

------------------------------

Date: Mon, 2 Aug 1999 12:47:25 -0600 From: "Randolph, Ray" <Ray_Randolph@kne.com> Subject: eBay's response to the eBay scam

The most astonishing part of the information provided in RISKS-20.51 regarding the eBay scam was the response from eBay found on the web site we were pointed to (http://mars.superlink.net/jason/ebay/ ). eBay's response, "PLEASE, do not give out details of this, as it will only cause more users to try it." Is classic security through obscurity. In this case, with all of the media attention this is getting, certain eBay employees are no doubt lamenting the Risks of the media discovering what they've attempted to obscure. :)

------------------------------

Date: Tue, 3 Aug 1999 08:54:00 -0400 From: "Wong, Leo" <LRW@mail3.cs.state.ny.us> Subject: Re: Go FORTH and Multiply (Kane, RISKS-20.51)

> You mean: > * Forth Go

One reason that Forth is simple is that it reads from left to right:

Go Forth AND *

Leo Wong hello@albany.net http://www.albany.net/~hello/

------------------------------

Date: Tue, 3 Aug 1999 08:57:13 -0400 (EDT) From: David Wittenberg <dkw@cs.brandeis.edu> Subject: Re: Heat wave (RISKS-20.51)

> athena% weather bos > Conditions at KBOS on 7/6/99 at 7:56 PM EDT (18:56 GMT)

Note also the unusual time conversion. 7:56 PM EDT is 19:56 EDT, which is 23:56 GMT, not the 18:56 they reported. Or is there an EDT other than (American) Eastern Daylight Time, presumably somewhere in England?

--David Wittenberg dkw@cs.brandeis.edu

------------------------------

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 <risks-request@csl.sri.com> 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 <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => 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.com<CR>login anonymous<CR>[YourNetAddress]<CR>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.52 ************************