Text File

precedence: bulk Subject: Risks Digest 20.45

RISKS-LIST: Risks-Forum Digest Thursday 17 June 1999 Volume 20 : Issue 45

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.45.html> and at ftp.sri.com/risks/ .

***** THE ANNUAL SEASONAL SLOWDOWN BEGINS NEXT WEEK. *****

Contents: eBay embarrassed by crash of system and plunge of stock (NewsScan) Risks of e-mail borne viruses, worms, and Trojan horses (Bruce Schneier) Not trusting virus scans (Paul Hoffman) Risks of virus detectors blocking RISKS! (MAILsweeper) Supremes uphold law barring indecent speech online (NewsScan) Trouble for DoubleClick (Monty Solomon) Human error called culprit in 3 rocket launch failures (Lindsay Marshall) More troubles with PDF (Joe McCauley) Re: A THAAD Day in Black Rock (Danny Cohen) Re: GPS and collision risks (Peter B. Ladkin) GPS and collision risks in marine navigation (Chris Bruce or Bruce Chris?) Re: Risks - Depending on a *.xxx convention for file types (Rumy Driver) More on "Unwanted wildcard match" (Nick Brown) REVIEW: "Corporate Espionage", Ira Winkler (Rob Slade) Abridged info on RISKS (comp.risks)

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

Date: Tue, 15 Jun 1999 07:25:48 -0700 From: "NewsScan" <newsscan@newsscan.com> Subject: eBay embarrassed by crash of system and plunge of stock

The fallout from the 22-hour system outage last week of eBay, the popular Internet auction site, has resulted in an 18% tumble of that company's stock. Analysts seem to regard the technical problems as normal growing pains. Michael Bernstein of the Gartner Group regards eBay's technical and investor problems as relatively minor, and explains: "It's a fiasco like this that will force a company to really fix the problem." (AP/*San Jose Mercury News*, 14 Jun 1999; NewsScan Daily, 15 June 1999) http://www.sjmercury.com/svtech/news/breaking/merc/docs/000266.htm

[Earlier eBay troubles were reported in RISKS-20.38. PGN]

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

Date: Tue, 15 Jun 1999 16:48:25 -0500 From: Bruce Schneier <schneier@counterpane.com> Subject: Risks of e-mail borne viruses, worms, and Trojan horses"

Looking back from the future, 1999 will have been a pivotal year for malicious software: viruses, worms, and Trojan horses (collectively known as "malware"). It's not more malware; we've already seen thousands. It's not Internet malware; we've seen those before, tool. But this is the first year we've seen malware that uses e-mail to propagate over the Internet and tunnel through firewalls. And it's a really big deal.

Viruses and worms survive by reproducing on new computers. Before the Internet, computers communicated was through floppy disks. Hence, most viruses propagated on floppy disks, and sometimes on computer bulletin board systems (BBSs).

There are some obvious effects of floppies as a vector. First, malware propagates slowly. One computer shares a disk with another which shares a disk with five more, and over the course of weeks or months a virus turns into an epidemic. Or maybe someone puts a virus-infected program on a bulletin board, and thousands get infected in a week or two.

Second, it's easy to block disk-borne malware. Most anti-virus programs can automatically scan all floppy disks. Malware is blocked at the gate. BBSs can still be a problem, but many computer users are trained never to download software from a BBS. Even so, anti-virus software can automatically scan new files for malware.

And third, anti-viral software can easily deal with the problem. It's easy to write software to block malware you know about. You simply have the anti-virus scanner search for bit strings that signify the virus (called a "signature") and then execute the automatic program to delete the virus and restore normalcy. This deletion routine is unique per virus, but it is not hard to develop. Anti-viral software has tens of thousands of signatures, each tuned to a particular virus. Companies release them within a day of learning of a new virus. And as long as viruses propagate slowly, this is good enough. My software automatically updates itself once a month. Until 1999, that was enough.

What's new in 1999 is e-mail propagation of malware. These programs -- the Melissa virus and its variants, Worm.ExploreZip worm and its inevitable variants, etc. -- arrive via e-mail and use e-mail features in modern software to replicate themselves across the network. They mail themselves to people known to the infected host, enticing the recipients to open or run them. They don't propagate over weeks and months; they propagate in seconds. Anti-viral software cannot possibly keep up.

And e-mail is everywhere. It runs over Internet connections that block everything else. It tunnels through all firewalls. Everyone uses it.

It's easy to point fingers at Microsoft. Melissa uses features in Microsoft Word (and variants used Excel) to automatically e-mail itself to others, and Melissa and Worm.ExploreZip make use of the automatic mail features of Microsoft Outlook. Microsoft is certainly to blame for creating the powerful macro capabilities of Word and Excel, blurring the distinction between executable files (which can be dangerous) and data files (which, before now, were safe). They will be to blame when Outlook 2000, which supports HTML, makes it possible for users to be attacked by HTML-based malware simply by opening an e-mail. Microsoft set the security state-of-the-art back 25 years with DOS, and they have continued that legacy to this day. They certainly have a lot to answer for, but the meta-problem is more subtle.

One problem is the permissive nature of the Internet and the computers attached to it. As long as a program has the ability to do anything on the computer it is running on, malware will be incredibly dangerous. Just as firewalls protect different computers on the same network, we're going to need something similar to protect different processes running on the same computer.

This cannot be stopped at the firewall. This type of malware tunnels through a firewall using e-mail, and then pops up on the inside and does damage. So far the examples have been mild, but they represent a proof of concept. And the effectiveness of firewalls will diminish as we open up more services (e-mail, web, etc.), as we add increasingly complex applications on the internal net, and as crackers catch on. This "tunnel-inside-and-play" technique will only get worse.

And anti-virus software can't help much. If a virus can infect 1.2 million computers (one estimate of Melissa infections) in the hours before a fix is released, that's a lot of damage. What if the code took pains to hide itself, so that a virus won't be discovered for a couple of days. What if a worm just targeted an individual; it would delete itself off any computer whose userID didn't match a certain reference? How long would it take before that one is discovered? What if it e-mailed a copy of the user's login script (most contain passwords) to an anonymous e-mail box before self-erasing? What if it automatically encrypted outgoing copies of itself with PGP or S/MIME? Or signed itself; signing keys are often left lying around the system. Even a few minutes of thinking about this yields some pretty scary possibilities.

It's impossible to push the problem off onto users with "do you trust this message/macro/application" messages. Sure, it's unwise to run executables from strangers, but both Melissa and Worm.ExploreZip arrive pretending to be friends and associates of the recipient. Worm.ExploreZip even replied to real subject lines. Users can't make good security decisions under ideal conditions; they don't stand a chance against a virus capable of social engineering.

What we're seeing here is the convergence of several problems: the permissiveness of networks, interconnections between applications on modern operating systems, e-mail as a vector to tunnel through network defenses and as a means to spread extremely rapidly, and the traditional naivete of users. Simple patches won't fix this. There are some interesting technologies on the horizon that try to mimic the body's own immune system to automatically deal with unknown malware, but I am not very optimistic about them. Sure they'll catch some things, but it will always be possible to design malware specifically to defeat the immune systems. A large distributed system that communicates at the speed of light is going to have to accept the reality of viral affections at the speed of light. Unless security is designed into the system from the bottom up, we're constantly going to be fighting a holding action.

Melissa: http://www.zdnet.com/zdnn/stories/news/0,4586,2233116,00.html http://www.zdnet.com/zdnn/stories/news/0,4586,2234121,00.html

Worm.ExploreZip http://www.zdnet.com/zdnn/stories/news/0,4586,2274306,00.html http://www.wired.com/news/news/politics/story/20160.html http://www.symantec.com/press/1999/n990614d.html

Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com

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

Date: Tue, 15 Jun 1999 14:21:42 -0700 From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Not trusting virus scans (Re: Karger, RISKS-20.45)

[On the other hand,] I ran *two* virus checkers against an attachment I got last week, and both said it was fine, so I opened the attachment. It was the new ExploreZip worm. Virus checkers inherently don't work on viruses that are newer than your last update of the settings file. In this case, I had the latest version of both checkers, but the virus was "too new" for either of them.

Paul Hoffman, Director, Internet Mail Consortium

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

Date: 16 Jun 1999 07:51:24 +1100 From: MAILsweeper@health.gov.au Subject: Risks of virus detectors blocking RISKS! (retitled by PGN)

[Original Subject: A copy of Melissa Virus may have been detected in a message] [NOTE: At least the intended recipient was CC:ed. PGN]

CONTENT VIRUS ALERT!

This is an automated response to inform you that a potential Melissa computer virus (or variant) has been detected in an inbound electronic mail message to:

[...]@health.gov.au

Date: Tue, 15 Jun 1999 12:07:31 -0700 (PDT) From: owner-risks@csl.sri.com [Subject: RISKS-20.44]

The message has been quarantined to prevent further propagation of the virus. Please remove the virus from the original document(s) or program(s) and send again. If you wish to discuss this matter, please contact the postmaster as indicated below.

Email: postmaster@health.gov.au Phone: +61 2 6289 7828 Fax: +61 2 6289 4928

[So, which part of RISKS-20.44 looked like Melissa herself? Presumably the CERT Advisory which told where to get the advisories? PGN] [BankBoston Gatekeeper Server also blocked the issue, but did NOT CC: the intended recipient. I also had a note from Lindsay Marshall (who handles the RISKS redistribution for the UK); he also reported receiving such bounces. PGN]

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

Date: Tue, 20 Apr 1999 10:20:26 -0700 From: "NewsScan" <newsscan@newsscan.com> Subject: Supremes uphold law barring indecent speech online

The U.S. Supreme Court has upheld a lower court ruling that affirmed the constitutionality of a provision of the Communications Decency Act of 1996 that makes it a crime to transmit a "communication which is obscene, lewd, lascivious, filthy or indecent with intent to annoy, abuse, threat or harass another person." The provision had been challenged by a San Francisco company that had developed the "annoy.com" Web site to let people send anonymous (and allegedly "indecent") messages to public officials. (AP 19 Apr 1999, http://www.usatoday.com/life/cyber/tech/cte912.htm; NewsScan DAILY, 20 Apr 1999)

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

Date: Tue, 15 Jun 1999 23:44:37 -0400 From: Monty Solomon <monty@roscom.com> Subject: Trouble for DoubleClick

Barely 24 hours after DoubleClick said that it would acquire marketing research company Abacus Direct for $1 billion in stock, privacy coalitions announced that they would file complaints with the FTC, contending that the merged entity would pose a threat to consumer privacy. The merger, which would help DoubleClick build the ultimate online database of consumers, brings the company closer than any other to achieving every online marketer's dream. But along the way, DoubleClick may have stumbled into a consumer-backlash nightmare.

[Jacob Ward: http://www.thestandard.com/articles/display/0,1449,5017,00.html]

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

Date: Wed, 16 Jun 1999 12:38:34 +0100 (GMT) From: Lindsay.Marshall@newcastle.ac.uk Subject: Human error called culprit in 3 rocket launch failures

<http://www.flatoday.com/space/today/061699e.htm> is a Florida Today article that claims that typos in software caused the loss of three rockets.

Lindsay http://catless.ncl.ac.uk/Lindsay

[The article claims that the 30 Apr 1999 Titan 4B failure (RISKS-20.39) is being blamed on a shifted decimal point in the software for the rocket's upper stage. PGN]

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

Date: Tue, 8 Jun 1999 09:56:01 -0500 From: "Joe McCauley" <mccauley@davesworld.net> Subject: More troubles with PDF

The article in RISKS-20.43 from Bryan O'Sullivan about troubles printing a PDF document reminded me of my own experience with PDF around tax time. I moved last year and had to file two different state tax returns in addition to my federal return. I downloaded some of the tax forms and publications I needed from the web, all of which were in PDF format, and ran into several cases of PDF forms that looked fine on my Win95 PC display but not so good when I printed them on a LAN-attached Laserjet printer: - Some of the Federal publications and instructions printed without any spaces between the words (luckily the forms themselves came out fine, at least the ones I needed); - The Illinois form IL-1040 was unusable; apparently it couldn't handle a character graphic about halfway down the first page and didn't print any of the rest of the form after that; - Many of Massachusetts tax forms are color-shaded and use colored areas in parts of the forms. When printed on a Laserjet, which doesn't support color, all these colors were replaced by shades of gray, making some parts of the forms difficult or impossible to read. Some of these problems may have been due to my local computing environment (though I think at least the Mass. forms should have been available in non-color versions). All illustrate the risks associated with assuming PDF is a stable and reliable format for online distribution of forms and documents.

Joe McCauley

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

Date: Tue, 15 Jun 99 13:34:38 PDT From: Danny Cohen <cohen@rand.org> Subject: Re: A THAAD Day in Black Rock (PGN, RISKS-20.43)

Antimissile missile hits flying target on 7th try

An expensive experimental antimissile missile did Thursday what it had been unable to do on six previous attempts: Hit a flying target. A white puff of smoke in the southern New Mexico sky marked where the Army's Theater High-Altitude Area Defense, or THAAD, missile struck a target missile, which left a squiggly white trail of vapor just to the west. [Source: CNN item, 10 Jun 1999, http://cnn.com/US/9906/10/missile.test.ap/

[RISKS always seeks good success stories -- although this one must qualify as only a relative success, considering the previous failures. However, we receive very few RISKS-relevant success reports, and do not want readers to conclude that there are no successes. But in the long run, it does seem that there are very few risk-free successes. PGN]

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

Date: Wed, 16 Jun 1999 14:03:09 +0200 From: "Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de> Subject: Re: GPS and collision risks (Wood, RISKS-20.44)

> [...] The probability of a collision between aircraft using GPS on > established air routes is significantly higher than between aircraft > using conventional navigation aids because of the greater accuracy of > navigation using a GPS.

Intuitively, I doubt this. Here's the reasoning.

To begin with, let us consider flight along, say, US Federal Airways.

Firstly, (a) separation in instrument meteorological conditions is ensured by ATC. No change in risk here. Secondly, (b) aircraft flying under instrument flight rules in visual meteorological conditions are flying in cruise at different altitudes (thousands of feet) than those flying under visual rules (thousands + 500 feet). Thirdly, although I cannot find it in the US Aeronautical Information Manual (AIM), (c) pilots of aircraft flying visually on designated airways have *always* been advised to keep the airway centerline/fix to one side of them - yes, the same side (actually, this is well-known pilot lore all over). This takes care of the climb/descent problem. US Federal Airways extend horizontally to 4 nautical miles (4.6 statute miles) each side of the centerline.

Federal Airways are defined by VOR transmitters not more than 50nm from any point on the airway that they are defining. Even though a signal may be distorted, all receivers will be receiving the same distorted signal, so any individual variation must be in the individual receivers in the aircraft. I can see no way of demonstrating either than pilots fly more accurately to GPS guidance than they do to VOR guidance, or that VOR reception is generally sloppier than the accuracy to which visual pilots are flying an airway (my experience, in fact, is quite the opposite, as would be that of most instrument flight instructors trying to get their proteges to hold a VOR course, I would suppose!). Unless one or the other of these can be demonstrated, one could not conclude that flying behavior on airways had changed significantly with the introduction of GPS.

But suppose that one could demonstrate somehow that people were flying more accurately with GPS guidance. Then to conclude that the risk of collision was higher, one would have to show that the protocols (a)-(c) above were not in general being followed. Since (a) and (b) are enshrined in aviation regulations, and (c) in good practice/pilot lore, I doubt this would be easy to demonstrate.

One other way to show that the risk of midair collisions had increased would be to show that there had been more midair collisions since GPS use became prevalent, and that this was not just a statistical fluctuation. Well, I don't know for sure, but I don't think there have been more. Even if there had, the cause of the phenomenon would have to be determined, and for the above reasons it would be very hard to show that it was due to suddenly-increased accuracy of flying of VFR pilots.

So much for airways. On to other possibilities. Perhaps Wood was thinking of pilots wanting to fly to point X and lots of them all getting exactly to point X. If point X are the published GPS coordinates of an airport, there exist procedures to follow well before one gets to point X, which have been designed to alleviate the possibility of midairs in the neighborhood of an airport. One would have to imagine that somehow pilots are ignoring these procedures because they have a GPS, and I don't see how one could show any such thing. If point X is some specific sightseeing point, then I grant that there may be an increased need for vigilance since now one can navigate precisely to X. However, I don't know what the proportion of such flights would be, and I doubt that they are representative of most flights (It would seem appropriate to reiterate the usual warnings to pilots about increased traffic density in the vicinity of sightseeing attractions.)

Finally, I should note the article in Risk Analysis 17(2):237-248, 1997, by Robert Patlovany entitled U.S. Aviation Regulations Increase Probability of Midair Collisions, brought to my attention by Hal Lewis (who, by the way, has written a fine, fine book on making decisions called Why Flip a Coin?, New York: John Wiley & Sons, 1997, which I found very entertaining as well as enlightening and have promised for two years to review for Risks, but haven't yet. Hal's got a great writing style. Read it. So there). Patlovany uses "a purely stochastic Monte Carlo model [..] to compare the relative midair collision course probabilities and mean closing velocities of four systems of rules for aircraft cruising altitudes as a function of altitude error: (1) current U.S. federal rules, (2) random altitudes, and (3) [etc...] The calculations verify that (1) federal rules increase collision course probabilities by about four times more than for a chaotic system of aircraft cruising at randomly selected altitudes, (2) risk is directly proportional to the level of compliance, and (3) [etc]."

Note that Patlovany is considering cruising flight only, and altitudes, that is, vertical displacement, not the horizontal displacement which I take to be the relevant factor for evaluating Wood's GPS vs. VOR contention.

Prof. Peter Ladkin Ph.D., Univ. Bielefeld, Technische Fakultaet, D-33501 Bielefeld (Germany) http://www.rvs.uni-bielefeld.de +49 (0)521 106-5326/5325

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

Date: Wed, 16 Jun 1999 11:00:06 -0000 From: Bruce Chris <chris.bruce@hyder.com> Subject: GPS and collision risks in marine navigation (Re: Wood, RISKS-20.44)

Lloyd Wood's comment regarding the probability of a collision between aircraft using GPS on established air routes applies equally to marine navigation. Navigation using electronic aids is generally from waypoint to waypoint. A "marine" waypoint is often a fairway buoy marking the end of a channel into a harbour or perhaps a buoy marking a shoal area at sea or a headland to be rounded. Vessels head from all directions towards the waypoints. A good lookout is necessary! This topic has had mention in the marine press for some years.

It also reminds me of the use of radar for collision avoidance at sea leading to what is known as Radar Assisted Collisions!

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

Date: Wed, 16 Jun 1999 13:40:41 -0500 From: "Rumy Driver" <Rumy.Driver@sybase.com> Subject: Re: Risks - Depending on a *.xxx convention for file types

This is to note we are still paying for the archaic way of using the *.xxx extension for defining the file type.

This is only on Windows platforms which are a legacy of DOS days.

In most other platforms files have 2 parts (e.g. MacOS) part1 resource fork Contains the actual meta-data - program that created file, date of creation, date of last modification .... part2 data fork Actual data

Now in the DOS-legacy world it is soooo easy to rename a file to another extension and the file morphs itself. This is the sneaky trick/way used to spread the latest virus/worm.

Another suggestion for *.ZIP files is NOT to double-click them and launch, but to use the Classic mode of WinZip and check what is in the ZIP archive before extraction. This would have let people know that it's a EXE file and they could have taken precautions(?).

Another suggestion is not to have a completely homogeneous environment (reminiscent of the potato"e" (apologies to Dan Quayle) famine)

Rumy Driver, Sybase Technical Support

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

Date: Wed, 16 Jun 1999 18:45:08 +0200 From: BROWN Nick <Nick.BROWN@coe.int> Subject: More on "Unwanted wildcard match" (RISKS-20.44)

I received quite a lot of mail on this subject. A couple of people helpfully tried to explain what they thought was the problem, based on their knowledge of DOS, but "assuming" that NT works that way, which it doesn't. (RISKs of assuming next-generation systems are infelicity-compatible, I guess.)

Yes, in DOS, the wildcards *1.LNK and *.LNK are identical, since DOS treats * to mean "everything up to the period" (and there can only be one period). However, NT's wildcard matching does more or less what you'd expect - it's quite close to, say, how DCL does it under VMS. My problem is that it matches both the visible and the invisible filenames.

For example, if I do this:

C:\>copy afile.txt longname2.txt C:\>copy afile.txt longname1.txt C:\>copy afile.txt longname4.txt C:\>copy afile.txt longname3.txt C:\>dir /x long*.* LONGNA~2.TXT LongName1.txt LONGNA~1.TXT LongName2.txt LONGNA~4.TXT LongName3.txt LONGNA~3.TXT LongName4.txt

> and delete *1.TXT, I "only" lose the first two files. > Footnote: Microsoft have, however, faithfully re-implemented in NT the wonderful DOS bug whereby, if you change a file's extension while copying it using a partial-match wildcard, the copy is done as if you said /A for ASCII. For example, if I have WINWORD.EXE and I want to copy it to NICK.XXX and I'm feeling lazy, I might say > COPY W*.EXE NICK.XXX without putting the /B switch on the COPY command.

> Try it - you'll get a file truncated to the offset of the first ctrl-Z > character in the original.

Thanks also to the person who pointed out that the automatic note appended to all outgoing e-mails from our site (saying that our domain name has changed), which PGN didn't chop off as he sometimes does with voluble sigs, contained a reference to a site which didn't work. Apparently this went wrong about two weeks ago. Of the 80000 or so Internet E-mails we have sent out since then, nobody else has bothered to mention the problem. This must mean something.

Nick Brown, Strasbourg, France http://dct.coe.int/info/emfci001.htm

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

Date: Tue, 15 Jun 1999 08:39:25 -0800 From: Rob Slade <rslade@sprint.ca> Subject: REVIEW: "Corporate Espionage", Ira Winkler

BKCRPESP.RVW 990424

"Corporate Espionage", Ira Winkler, 1997, 0-7615-0840-6, U$26.00/C$34.95 %A Ira Winkler %C 3875 Atherton Road, Rocklin, CA 95765-3716 %D 1997 %G 0-7615-0840-6 %I Prima Publishing %O U$26.00/C$34.95 800-632-8676 916-632-4400 fax: 916-632-1232 %P 365 p. %T "Corporate Espionage"

This readable and realistic guide to becoming professionally paranoid has a special emphasis on data security and high tech companies, but can be very useful to pretty much anyone.

Part one looks at espionage concepts. Chapter one, and the introduction that precedes it, points out that information is one of the primary sources of value in any business. Chapters two through five look at the basic ideas for any examination of data security, those of risk, value, threat, and vulnerability. Presented in terms, and with examples, that anyone can understand, they nevertheless form the foundation for examining security and protection for computer and communications systems as well as the sales "red book" for next quarter.

Part two presents a variety of case studies. Winkler concentrates on the non-technical, relatively simple, and devastatingly effective "social engineering" aspect of break-ins. Chapter six is a compilation of tactics used in various penetration tests. One particular test is outlined in chapter seven. Chapters eight to eleven detail actual espionage cases carried out by foreign companies. A different penetration test is presented in chapter twelve. A third party account of a "crack" is discussed in chapter thirteen.

Part three outlines what you can do to protect yourself. Chapter fourteen describes a significant list of countermeasures to take, starting with an effective education program. Finally, chapter fifteen presents a large scale program for overall security.

This book is very down to earth, and very real. Unlike any number of "hacker" books, it doesn't attempt to impress the reader with displays of arcane knowledge: it doesn't have to. Technical details are almost non-existent, making the text an excellent choice for use in educating any level or type of employee on the need for security.

copyright Robert M. Slade, 1999 BKCRPESP.RVW 990424 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: 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.45 ************************