Text File

precedence: bulk Subject: Risks Digest 20.18

RISKS-LIST: Risks-Forum Digest Friday 29 January 1999 Volume 20 : Issue 18

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

Contents: "When Doctors Make Mistakes" (Matt Blaze) Celler beware? Cell-phone blockade (Sheri Alpert) Distributed.Net & EFF Put Final Nail in DES Coffin (John Gilmore) Trojan horse planted in TCP wrapper (PGN) Internet vandals strike USIA Web site (Edupage) Digital photos from drivers' licenses (Dan Gould) Linux users want their money back from Microsoft (Edupage) Y2K update turns city into deadbeat (Debora Weber-Wulff) Programming errors (Fred Gilham) Re: ... French announcement on crypto policy (Olivier MJ Crepin-Leblond) Re: "Page-layout program hazards" and "Over-reliance on technology" (Don Byrd) Hotmail Web e-mail risk (Daniel P. Stasinski via others) Major security breach in Canadian consumer-tracking database (Wei-Yuen Tan) USENIX Security Symposium Call; Papers due March 9 (Jennifer Radtke) REVIEW: "Bad Software", Cem Kaner/David Pels (Rob Slade) Abridged info on RISKS (comp.risks)

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

Date: Mon, 25 Jan 1999 20:56:17 -0500 From: Matt Blaze <mab@research.att.com> Subject: "When Doctors Make Mistakes"

This week's _New_Yorker_ (dated February 1) has an excellent article, "When Doctors Make Mistakes," by Atul Gawande. The article, written by a surgical resident who was also a Clinton health policy advisor, offers a very nice summary of human error - and process failure - in various medical disciplines. The descriptions of widely varying user interfaces on different models of defibrilators or of design variations in anesthesia machine controls such that a clockwise turn of a knob increases dosage on some models and decreases on others should be familiar territory for RISKS junkies.

In a previous life, I worked briefly as a paramedic in New York, and I have actually performed many of the RISKy life-vs-death procedures, such as E-T intubation and tracheostomy, described in the first part of the article. I recall never worrying much about killing someone by mistake - the training, culture, and protocols really were pretty well designed to make at least the most avoidable kinds of deadly errors reasonably unlikely (for example, we used only a limited number of models of defibrilator, and everyone everyone practiced frequently with all of them). What kept me up at night were worries of screwing up some non-life threatening procedure with grave consequences, like contributing to paralyzing an accident victim by rough handling, or failing to notice secondary injuries during an examination. These things were practiced and trained for rather less intensely than the more dramatic "life or death" procedures were.

Cryptography and computer security seems so much safer by comparison...

-matt

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

Date: Mon, 25 Jan 1999 11:50:57 -0500 (EST) From: Sheri Alpert <salpert@gmu.edu> Subject: Celler beware? Cell-phone blockade

A GTE Wireless cellular tower in Crystal River, Florida, was rendered incommunicado whenever Calvin Simpson used his cell phone in his motor-home park, beginning on 4 Jan 1999. His phone was apparently tying up a control channel used to direct calls, and blocking all (other?) calls. After tracking him down (it took 10 days), GTE gave him a different phone while they tried to find out why it was causing the interference! [Source: Digital Flub: A Cell Phone's Knockout, *The Washington Post*, 25 Jan 1999, F05, derived from an AP item; PGN Abstracting]

Sheri Alpert, PhD candidate, Institute of Public Policy George Mason University, Fairfax, VA

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

Date: Thu, 28 Jan 1999 09:26:07 -0800 From: John Gilmore <gnu@toad.com> Subject: Distributed.Net & EFF Put Final Nail in DES Coffin

Tuesday, January 19, 1999 RSA Code-Breaking Contest Again Won by Distributed.Net and Electronic Frontier Foundation (EFF)

DES Challenge III Broken in Record 22 Hours

RSA DATA SECURITY CONFERENCE, SAN JOSE, CA -- Breaking the previous record of 56 hours, Distributed.Net, a worldwide coalition of computer enthusiasts, worked with the Electronic Frontier Foundation's (EFF) "DES Cracker," a specially designed supercomputer, and a worldwide network of nearly 100,000 PCs on the Internet, to win RSA Data Security's DES Challenge III in a record-breaking 22 hours and 15 minutes. The worldwide computing team deciphered a secret message encrypted with the United States government's Data Encryption Standard (DES) algorithm using commonly available technology. From the floor of the RSA Data Security Conference & Expo, a major data security and cryptography conference being held in San Jose, Calif., EFF's DES Cracker and the Distributed.Net computers were testing 245 billion keys per second when the key was found.

First adopted by the federal government in 1977, the 56-bit DES algorithm is still widely used by financial services and other industries worldwide to protect sensitive on-line applications, despite growing concerns about its vulnerability. RSA has been sponsoring a series of DES-cracking contests to highlight the need for encryption stronger than the current 56-bit standard widely used to secure both U.S. and international commerce.

"As today's demonstration shows, we are quickly reaching the time when anyone with a standard desktop PC can potentially pose a real threat to systems relying on such vulnerable security," said Jim Bidzos, president of RSA Data Security, Inc. "It has been widely known that 56-bit keys, such as those offered by the government's DES standard, offer only marginal protection against a committed adversary. We congratulate Distributed.Net and the EFF for their achievement in breaking DES in record-breaking time."

As part of the contest, RSA awarded a $10,000 prize to the winners at a special ceremony held during the RSA Conference. The goal of this DES Challenge contest was not only to recover the secret key used to DES-encrypt a plain-text message, but to do so faster than previous winners in the series. As before, a cash prize was awarded for the first correct entry received. The amount of the prize was based on how quickly the key was recovered.

"The diversity, volume and growth in participation that we have seen at Distributed.Net not only demonstrates the incredible power of distributed computing as a tool, but also underlines the fact that concern over cryptography controls is widespread," said David McNett, co-founder of Distributed.Net.

"EFF believes strongly in providing the public and industry with reliable and honest evaluations of the security offered by DES. We hope the result of today's DES Cracker demonstration delivers a wake-up call to those who still believe DES offers adequate security," said John Gilmore, EFF co-founder and project leader. "The government's current encryption policies favoring DES risk the security of the national and world infrastructure."

The Electronic Frontier Foundation began its investigation into DES cracking in 1997 to determine just how easily and cheaply a hardware-based DES Cracker (i.e., a code-breaking machine to crack the DES code) could be constructed.

Less than one year later and for well under U.S. $250,000, the EFF, using its DES Cracker, entered and won the RSA DES Challenge II-2 competition in less than 3 days, proving that DES is not very secure and that such a machine is inexpensive to design and build.

"Our combined worldwide team searched more than 240 billion keys every second for nearly 23 hours before we found the right 56-bit key to decrypt the answer to the RSA Challenge, which was 'See you in Rome (second AES Conference, March 22-23, 1999),'" said Gilmore. The reason this message was chosen is that the Advanced Encryption Standard (AES) initiative proposes replacing DES using encryption keys of at least 128 bits.

RSA's original DES Challenge was launched in January 1997 with the aim of demonstrating that DES offers only marginal protection against a committed adversary. This was confirmed when a team led by Rocke Verser of Loveland, Colorado recovered the secret key in 96 days, winning DES Challenge I. Since that time, improved technology has made much faster exhaustive search efforts possible. In February 1998, Distributed.Net won RSA's DES Challenge II-1 with a 41-day effort, and in July, the Electronic Frontier Foundation (EFF) won RSA's DES Challenge II-2 when it cracked the DES message in 56 hours.

**********

EFF has prepared a background document on the EFF DES Cracker, which includes the foreword by Whitfield Diffie to "Cracking DES." See http://www.eff.org/DEScracker/. The book can be ordered for worldwide delivery from O'Reilly & Associates at http://www.ora.com/catalog/crackdes, +1 800 998 9938, or +1 707 829 0515.

The Electronic Frontier Foundation is one of the leading civil liberties organizations devoted to ensuring that the Internet remains the world's first truly global vehicle for free speech, and that the privacy and security of all on-line communication is preserved. Founded in 1990 as a nonprofit, public interest organization, EFF is based in San Francisco, California. EFF maintains an extensive archive of information on encryption policy, privacy, and free speech at http://www.eff.org.

[Thanks to all of you who commented on my incomplete reportage. Deep Crack lucked out on only 9% of the key space, whereas Distributed Crack as a whole cranked through 22.2% of the key space. My hasty note from the RSA Conference in RISKS-20.17 was based on a desire to report the crack in the absence of the fuller story, which is included above. It is clear that the DEEP CRACK exercise represents a rude awakening for those remaining folks (such as those who had touted export controls above 40-bit keys) who believed that such a machine could not be built. But the deeper message of course is that we no longer even need such a machine -- if vast portions of the total world-wide resources of the Net were mobilized, it would be possible for WORLD CRACK to break 56-bit DES in a few seconds, plus whatever e-mail delay was needed to report the crack by the lucky participant whose machine found the key! Once again, a little realism is needed. PGN]

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

Date: Fri, 22 Jan 1999 11:09:33 -0500 From: "Peter G. Neumann" <Neumann@CSL.sri.com> Subject: Trojan horse planted in TCP wrapper

At least 52 computer systems downloaded a TCP wrapper program directly from a distribution site after the program had been contaminated with a Trojan horse early in the morning of 21 Jan 1999. The Trojan horse provided trapdoor access to each of the contaminated systems, and also sent e-mail identifying each system that had just been contaminated. The 52 primary sites were notified by the CERT at CMU after the problem had been detected and fixed. Secondary downloads may also have occurred. [Source: Elizabeth Corcoran, Hackers Strike Popular Program; 52 Computers Downloaded 'Trojan Horse' Allowing Outside Access, *The Washington Post*, 22 Jan 1999, page E03; PGN Abstracting]

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

Date: Thu, 21 Jan 1999 14:36:15 -0500 From: Edupage Editors <edupage@franklin.oit.unc.edu> Subject: Internet vandals strike USIA Web site

The Web site of the United States Information Agency, which is used by American diplomats abroad for statements on American policy or texts of official speeches, was broken into recently by Internet vandals who left on the USIA system a "Trojan Horse" piece of computer code that caused basic hardware damage and the destruction of the site. A USIA computer specialist said security for the site will be beefed up. "We simply can't have this happening every six months. People rely on us." (*The New York Times*, 21 Jan 1999; Edupage 21 Jan 1999)

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

Date: Fri, 22 Jan 1999 05:58:10 -0500 (EST) From: Dan Gould <dlg@cs.brown.edu> Subject: Digital photos from drivers' licenses

For the first time since authorities began snapping photographs of drivers for licenses, state officials have begun selling the images wholesale. ... South Carolina has released 3.5 million digital photographs, Florida has started the process of transferring 14 million images in its files and other states have expressed interest in doing the same. ... While it has long been customary or a legal requirement to restrict access to driver photos to law enforcement authorities, company officials pledged to handle their new storehouse of digital pictures carefully. [Excerpted from an article by Robert O'Harrow Jr., *The Washington Post*, A01, 22 Jan 1999]

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

Date: Tue, 26 Jan 1999 14:08:04 -0500 From: Edupage Editors <edupage@franklin.oit.unc.edu> Subject: Linux users want their money back from Microsoft

Aficionados of the Linux operating system, which is available for free, say they will demand their money back for Windows software installed against their wishes on PCs they buy. Their demand is based on a Windows licensing agreement that says that if the purchaser does not agree to the terms and conditions of use of the Windows software, he or she should promptly contact manufacturer for instructions on return of the unused product for a refund. Microsoft says that agreement applies only to the issues surrounding the of making copies of the software. (*The New York Times*, 25 Jan 1999; Edupage, 26 January 1999)

[Various marches on Microsoft offices are apparently being planned. PGN]

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

Date: Wed, 27 Jan 1999 10:02:17 +0100 From: Debora Weber-Wulff <Debora.Weber_Wulff@te.mah.se> Subject: Y2K update turns city into deadbeat

Sydsvenskan, 19. Jan 1999 [paraphrased by dww]

The city of Malmo[e] in the south of Sweden updated its bookkeeping software in October in order to get ready for the year 2000. The program AdeEko by Enator takes care of paying the bills for the city.

But since it has been updated, some bills are not being paid. When the clerks leave their offices in the evening, everything looks great. But sometime during the night, the system knocks itself out, and forgets to send the rest of the files with the payments to the banks and the post office.

This has happened every night since the system has been installed, and no one knows why. Enator is having people babysit the system over night in attempts to find out what is wrong. It takes a very long time for the bills to be paid, as the clerks must sort through which ones were paid and which ones weren't. The babysitters watch for bills which knock out the system, remove them, and restart the system.

A spokesperson for Enator identified the problem as being simply files that should be going to the banks and the post office not being accepted there, but he is not accusing anyone of anything. The search continues...

Debora Weber-Wulff MALMOe HOeGSKOLA 205 06 Malmo SWEDEN Tel: +46-40-6657354 (Fax: -031) Debora.Weber_Wulff@te.mah.se

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

Date: Thu, 28 Jan 1999 18:35:19 -0800 From: Fred Gilham <gilham@csl.sri.com> Subject: Programming errors

I am reminded again of how shaky the software world is.

Someone has been making a major effort to clean up the code in the FreeBSD tree. In two days he has reported three instances of the following common C error:

if (x = y)

instead of

if (x == y)

This is in running code, in an OS whose developers consider stability to be one of its major advantages over other offerings.

He also reported some missing breaks in a switch statement---many of us remember what THAT error did not too long ago. [RISKS-9.61 to 71. Trojan horse switches in midstream? PGN]

-Fred Gilham gilham@csl.sri.com

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

Date: Thu, 21 Jan 1999 12:56:13 -0000 From: "Olivier MJ Crepin-Leblond" <ocl@gih.com> Subject: Re: ... French announcement on crypto policy (RISKS-20.17)

This, while being a total reversal of policy from the laws of 1996, is in fact the right way forward, and makes sense. I would expect other governments to adopt the same policy soon.

The previous law was seriously curbing the French industry's use of cryptography for its transfers of sensitive information, thus putting them at a disadvantage when it comes to industrial espionage. Because, let's face it, with the fall of the Iron Curtain, 99.9% of the world's espionage is now industrial espionage. Globalization has made stakes in international trade so important that corporations need to know what their competitors do, and the press has been very verbose about past scandals that have come into the open.

I suspect that the assumption made by the French government are:

1. ultimately, no code is unbreakable;

2. the legal authorities will have the power to prosecute if an entity refuses to provide them with the key to suspicious encoded data.

What about personal privacy ?

Privacy is a myth, which you and I believe in; aren't we naive ?

Olivier MJ Crepin-Leblond, Ph.D. - ocl@gih.com Global Information Highway Limited

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

Date: Tue, 26 Jan 1999 16:19:26 -0500 From: Don Byrd <dbyrd@cs.umass.edu> Subject: Re: "Page-layout program hazards" and "Over-reliance on technology"

I've been trying to avoid responding to this discussion, but I can't ignore it any longer.

As a user-interface researcher and designer, I've seen way too many solutions to the problems bad UIs cause along the lines of "understand your tools", "read the manual carefully", etc. TROFF's UI is a bad one. (This should be no surprise, since most UNIX programs, especially old ones, have bad UIs :-) ; it was a reasonable UI for when it was designed.) Training people to handle a poor UI better is very difficult, and even if successful, results in large amounts of wasted time; it should be proposed only a last resort.

No, I'm not arguing that TROFF's syntax has to be completely revamped, or that people should use it only via GUI front ends. A _much_ simpler solution that would probably solve 95 percent of Jordin Kare's problem would simply be for TROFF to report any illegal commands it encountered instead of just ignoring them: surely the vast majority of the nonsense "commands" in his case would be illegal.

Don Byrd dbyrd@cs.umass.edu 413-545-3147 FAX 413-545-1789 Center for Intelligent Information Retrieval (CIIR) Computer Science Department University of Massachusetts, Amherst, MA 01003

[This is in response to the thread of Pat Place <prp@SEI.CMU.EDU> (RISKS-20.17), Glen Turner (RISKS-20.15), and Jordin Kare (RISKS-20.14). PGN]

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

Date: Wed, 27 Jan 1999 14:29:33 +0000 (GMT) From: Lloyd Wood <L.Wood@surrey.ac.uk> Subject: Hotmail Web e-mail risk

- -------- Forwarded message ---------- Date: Tue, 26 Jan 1999 21:56:28 -0500 >From: glen mccready <glen@qnx.com> To: 0xdeadbeef@substance.blackdown.org Subject: It's good when the folks in charge have their priorities right. Resent-From: 0xdeadbeef@substance.blackdown.org

Forwarded-by: Nev Dull <nev@bostic.com>

[Background: Someone hacked the win.tue.nl ftp site and installed versions of various packages that would forward user login/uid information to Hotmail addresses.]

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

>From: "Daniel P. Stasinski" <dannys@KAREMOR.COM> Subject: Microsoft Hotmail

I contacted Microsoft/Hotmail asking them to close the account that was listed in the backdoored tcp wrapper source code. I also forwarded the offending code.

The word back from them is that they will not close it. Theft of passwords and hacking does not violate their terms of service.

Daniel P. Stasinski, Software Engineer, Karemor International, Inc. 2406 South 24th Street, Phoenix, AZ 85034 dannys@karemor.com

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

Date: Fri, 22 Jan 1999 20:32:15 -0500 From: Wei-Yuen Tan <monkeyboy@pobox.com> Subject: Major security breach in Canadian consumer-tracking database

Excerpted from the Toronto *Globe and Mail* (Canada) on 22 Jan 1998

Supposedly confidential records of up to 50,000 Canadians were accidentally left accessible to the general public on the Website of Air Miles, Canada's second largest customer loyalty program. Fortunately, the records exposed on the Website, www.airmiles.ca, were only those of potential customers who had filled out an online application form. However, very sensitive information pertaining to these 50,000 individuals was openly accessible online until the Website was taken offline mid-morning Thursday 21st Jan. The Website will remain offline until its operators are able to resolve the issue.

Air Miles tracks the consumer behavior of its five million Canadian cardholders (almost 20% of our population), tracking such information as: - purchasing history - name, address, telephone numbers and e-mail addresses. - credit ratings, credit cards held, bank records - vehicle and property ownership - for business subscribers, company name, address, industry and ranges for annual revenue, number of employees and number of locations. Air Miles, as the name implies, attracts customers by offering airline reward miles for purchases made at participating retailers. Despite my consistent efforts to discourage them, my parents have been faithful cardholders for several years. Apparently they have finally accumulated enough points for a trip to our neighbour's house across the street.

A RealVideo news clip of the subject is available from the CBC Website at the following URL:

http://www.newsworld.cbc.ca/cgi-bin/templates/view.cgi?/news/1999/01/22/ airmiles990122

Wei-Yuen Tan <monkeyboy@pobox.com>

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

Date: Fri, 22 Jan 1999 17:57:32 GMT From: jennifer@usenix.ORG (Jennifer Radtke) Subject: USENIX Security Symposium Call; Papers due March 9

8th USENIX Security Symposium August 23-26, 1999 Washington, D.C., USA Sponsored by USENIX in cooperation with The CERT Coordination Center

If you are working in any practical aspects of security or applications of cryptography, the program committee urges you to submit a paper. Dates for Refereed Paper Submissions: March 9, 1999. The full Call for Papers is at http://www.usenix.org/events/sec99/ .

The Symposium brings together researchers, practitioners, system administrators, system programmers, and others interested in the latest advances in security and applications of cryptography. Two days of tutorials will be followed by two days of technical sessions, offering refereed papers, invited talks, works-in-progress, panel discussions, and a product exhibition.

Invited Talk Speakers include: Ross Anderson, Computer Laboratory, Cambridge University Ed Felten, Princeton University Susan Landau, University of Massachusetts Peter G. Neumann, SRI Paul Van Oorschot, Entrust Technologies Marcus Ranum, Network Flight Recorder

USENIX is the Advanced Computing Systems Association. Our international membership includes engineers, system administrators, scientists, and technicians. Our conferences are recognized for delivering pragmatic, technically excellent information in a highly interactive, vendor-neutral forum.

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

Date: Wed, 27 Jan 1999 08:35:17 -0800 From: "Rob Slade" <rslade@sprint.ca> Subject: REVIEW: "Bad Software", Cem Kaner/David Pels

BKBDSFWR.RVW 981122

"Bad Software", Cem Kaner/David Pels, 1998, 0-471-31826-4, U$29.99/C$42.50 %A Cem Kaner %A David Pels %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 1998 %G 0-471-31826-4 %I John Wiley & Sons, Inc. %O U$29.99/C$42.50 416-236-4433 fax: 416-236-4448 %P 365 p. %T "Bad Software: What to Do When Software Fails"

Bad software. Isn't that phrase redundant?

This book is *not* about viruses, trojans or other malware. It talks about software that doesn't work as it should, and what you can, or should, do about it.

Chapter one is a kind of beginner's panic guide to getting a refund. It's quite practical, although those used to fighting their way through the retail bureaucracy will find little new. On the other hand, most people aren't used to that particular battle, so the book will have a fairly wide audience. One proviso: when it gets to legal issues, as with all too many such books, the material is strictly US- centric. Chapter two is not very clear, up front, as to what it is for. Ultimately it says a lot about the problems at software publishing houses, and not very much about yours. While this might make you more (or less) understanding of the problem, the advice given in chapter three is much more useful. It does tend to be of the same variety as that given in the troubleshooting sections of most documentation, but the second section, dealing with reasonable expectations of software and representations, is quite good. Judging by the number of pages, chapter four starts to get into the comfort zone of the authors: figuring out a negotiating position. This is a good template to follow, setting out all aspects of the problem and its significance, and providing good standards for what is reasonable to expect and what is not. Chapter five covers the support or complaint call itself, and, again, is reasonable, but nothing new.

Chapter six reviews the various types of consumer protection agencies. Again, when dealing with the governmental departments, the material only applies to the US (and this holds for chapters seven through ten as well). However, the coverage is both reasonable and practical, noting, for example, that the loudly vaunted Better Business Bureau is funded by business, not by consumers, and is a franchise operation that varies in operation from place to place. Warranties, disclaimers, and misrepresentation are discussed in chapter seven, with illustrations both from statutes and numerous cases. An outline of the process for a lawsuit is provided in chapter eight. Chapter nine looks at negotiating with lawyers. The procedure and limitations for small claims court are given in chapter ten. The final chapter gives some general advice on shopping, and being a careful consumer.

This work does give you advice, breathing space, and a roadmap for pursuing a complaint about software. It is appropriate for neophytes in computer use: not only the home hobbyist, but the beginning technical support person in a larger office. However, as my wife pointed out when I was describing the book, the biggest issue for most such people is having the confidence to know that the software, and not you, are at fault, and there the text is of less use. The strengths of the book are in negotiating tactics, and in a dispassionate view of what you might be able to expect. Although, if you have the experience to know what is reasonable you won't need the book, and if you have little enough experience that you need the book you probably don't know enough to be comfortable standing up to some snooty techie.

copyright Robert M. Slade, 1998 BKBDSFWR.RVW 981122 rslade@vcn.bc.ca rslade@sprint.ca robertslade@usa.net p1@canada.com

[Is the phrase "Bad software" *redundant*? If people learn how to write bad software in school, it must be a *taught-ology*! PGN]

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

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.18 ************************