Text File

Subject: RISKS DIGEST 17.41

RISKS-LIST: Risks-Forum Digest Tuesday 24 October 1995 Volume 17 : Issue 41

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, etc. *****

Contents: "Crimestoppers" and bank-clock coincidence (Sarah Holland) A Curious Mac User (Mike Crawford) "core" files (Ross Oliver) RISKS of assuming "Flaws In Internet Security" (A. Padgett Peterson) U.S. Army to use software to control and direct artillery fire (David Graf) Lots of copies, but why? (Lord Wodehouse) RISKS of believing the newspaper's twist (or shimmy) (Sidney Markowitz) Getting your clearance on the net [Name withheld] Guess what happened at the Pittsburgh Airport? (Alan Tignanelli) More air-traffic control woes: Las Vegas (E.H. Emerson) FLASH * Marketry Dumps Marketing Plan (Marc Rotenberg) Re: Risk of not knowing [when] something goes wrong (Ken Calvert) Re: Northwest Spit Me Out (Daniel Frankowski) Re: How to derail a train (Leonard Erickson) Re: The Johnson Bug (David A. Curry) Re: Determining the health of disk drives (Martin Minow) Re: Risks in Java and Beyond Java (Charles J. Wertz) NSA Museum on Web (Adrian John Howard) Minitrack on Risks in End User Computing (Ray Panko) ABRIDGED info on RISKS (comp.risks)

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

Date: 20 Oct 95 01:37:05 EDT From: Sarah Holland <70620.1425@compuserve.com> Subject: Crimestoppers and bank-clock coincidence

>From the October 18, 1995 Vancouver Sun "Man seeks to clear his name after police error"

A Tsawwassen whose photo was wrongly placed on a "Crimestoppers" episode linking him to bank-machine fraud says he wants his name cleared and those responsible to pay. ... Sonny Walker, 19, withdrew money from a Richmond Savings Credit Union bank machine on Dec 25, 1994. On the same day, someone used a stolen card at the same machine. Because the clock in the video camera filming bank customers indicated Walker withdrew his money at the same time as the fraud occurred, the bank forwarded his photo to Richmond RCMP. But the video-camera clock was wrong. Rachael MacKenzie, manager of public relations for Richmond Savings admitted Thursday. It was out by about one hour. ... When the [Crimestoppers] episode first ran, Walker heard about it from friends. ... Walker and his mother went to the police right away. Even though he protested his innocence and insisted a mistake had been made, Walker was interrogated for 45 minutes. ... The Crimestoppers episode ran throughout the summer. Walker continued to protest his innocence to police, but said he got nowhere. ... Finally, in September, Colleen [his mother] called the bank to complain. MacKenzie said the call was the first she heard of the Crimestoppers episode, and she immediately had the bank check its records. "Within 2 or 3 days, we knew the timing was wrong," she said. "We made a mistake on the evidence. Thee is no question we feel horrible about this." MacKenzie immediately sent a letter to police notifying them of the error and criticizing police behaviour. "We are concerned that you passed this photo on to Crimestoppers with no prior notice to us and that you idn't attempt to re-contact us after your initial discussions with Sonny's mother," MacKenzie said in her letter. But two weeks later, Walker's sister saw an hour-long Crimestoppers special in which her brother's face was displayed as part of the fraud episode, with an addendum stating that the suspect and his family deny the allegations. ... Crimestoppers' police liason officer Dave Baker refused to comment except to say there was a "screw-up, but I don't know whose." ...

Risks? The usual dose of human stupidity, and as BC Privacy's commissioner put it: "Our assumption is that technology can't make mistakes, but once again we are shown it does make mistakes."

Sarah Holland sholland@cis.compuserve.com

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

Date: 17 Oct 1995 13:29:55 -0800 From: "Mike Crawford" <Mike_Crawford@quickmail.apple.com> Subject: A Curious Mac User

This item is bouncing around Apple lately. Apparently, the VP of Compaq considers it too much of a RISK to make an important presentation on a PC. Mike Crawford crawford@scruznet.com http://www.scruznet.com/~crawford

>From Guy Kawasaki's MacWay mailing list... I wonder how many closet Macintosh users are out there!

>From the "Feedback" column in this week's "New Scientist":

FEEDBACK was present when the International Data Corporation held its annual European Information Technology Forum in Paris recently. Top executives from top computer companies Lotus, Oracle, Hewlett-Packard, IBM and Compaq all gave speeches. So did Bill Gates of Microsoft, who was in France to launch Windows 95.

Needless to say all the speakers relied on electronic "slides", stored in a computer and projected by a video system. The picture quality was fine, but several speakers had a lot of trouble controlling the computer. Perhaps they do not often use the equipment they sell to the public.

Whatever the reason, their slides kept refusing to change, or changed too soon. When Andreas Barth, senior vice-president of Compaq, took the stand he announced that he was not going to risk the same embarrassment.

So he was using an Apple Mac to show his slides.

It took a moment or two to appreciate the full significance of Barth's remark. The vice-president of a huge company that has built its success on selling PCs that run Windows was admitting to a top industry seminar that he dare not use a Windows PC for his presentation, and was using the rival Mac system instead.

Compaq's Mac presentation progressed without a hitch. But Feedback was more than a little disappointed to see that Bill Gates had already left the hall. So there was no chance to see the look on his face.

One is left wondering how many of the other presenters secretly identify with Barth and, in the privacy of their own homes, use Apple Macs instead of PCs.

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

Date: Sat, 21 Oct 1995 08:26:00 GMT From: reo@netcom.com (Ross Oliver) Subject: "core" files Newsgroups: alt.folklore.computers,alt.folklore.urban

[Via Mark Brader <msb@sq.com>]

Rob J. Nauta (rob@redwood.nl) wrote: : Anyway, there is an urban legend about a professor who wrote his thesis : about the earth's core in a file called 'core'. In the weekend however : a coreseeker wiped out his file. And, the clever person who wrote the : backup script had added a filter so that core files weren't backed up ...

This was definitely not a legend at my school, UC Santa Cruz. There are eight "colleges" at UCSC, and each has a required course that all freshman have to take, which supposedly makes up the "core" of the college curriculum. Thus, it was known as the "core course." At the time (12 years ago) about 50% of campus CPU cycles were used to run nroff for writing papers (the other 50% were for playing rogue.) Less imaginative freshman would use "core" as the filename for their beloved papers, with occasional unfortunate results.

Ross Oliver reo@netcom.com

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

Date: Thu, 19 Oct 95 19:08:54 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: RISKS of assuming "Flaws In Internet Security"

THERE IS NO SECURITY ON THE INTERNET (see RFC 1281 if you do not believe me). The Internet addresses one thing and one thing only: delivering the mail (packets). It is solidly on the A of Availability.

Consequently, there is no "flaw" in the Internet, rather there may be a flaw in the design of a module which makes use of the Internet, or there may be a flaw in people's expectation of the Internet, but not the net itself, it does its job very well.

It is probably best to think of the Internet as "the world's biggest party line" (if that does not translate well outside the US, I apologise but have no idea what other terms are common).

Unless the user takes steps to ensure the security of a message/file/etc., to authenticate that something actually came from where it appears to have, and that it does not contain anything you might not want to receive, then he/she/it/other has no-one to blame than themselves and certainly not the 'net (have noticed a certain tendency of the lemmings to be wont to blame *anyone* else, mob rule/mob IQ & all that).

When I examine a virus my favourite tool is DEBUG, when reading a message that came from "somewhere", I use Vern Buerg's LIST. Both have the endearing quality of assuming nothing for me.

Misplaced trust is really is not a prerogative of digital usage but "to really screw things up takes a computer." I suspect that we are rapidly reaching a point where we are going to have to reassess trust in objects for which no one is accountable.

In 1969, when the first Internet connections were made, the government relied on strong encryption not only for confidentiality but also for accountability, strong encryption which was the responsibility of the sites. I suspect that the Internet is rapidly returning to that paradigm.

Padgett

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

Date: Thu, 19 Oct 1995 21:12:17 -0400 From: DavidG3276@aol.com Subject: U.S. Army to use software to control and direct artillery fire

On page 24 of the October 16, 1995, issue of PC Week, an article ("Mark your target--objects in the field) describes how the U.S. Army with Magnavox Electronic Systems is designing an AFATDS (automated field artillery tactical data system) which can use battlefield intelligence data in conjunction with programmed standard operating procedures to direct artillery file onto enemy forces in a matter of seconds.

The development of an AFATDS should come as no surprise to anyone familiar with the military. The U.S. armed forces have historically relied upon fire support such as artillery to reduce enemy forces and so reduce the number of American casualties. In addition, the military is downsizing and so has to "do more with less". By automating the control of artillery fire, the military is hoping to literally get "more of a bang for the bucks". A well-designed functioning AFATDS has the possibility of being a critical "force multiplier" which could deter "enemy" forces from even tangling with U.S. forces.

However, as readers of this digest are aware, there are two main dangers from automating such a process to the point where there is little room or time for human control of the system. First, there is the problem of intentional sabotage. I would not put it past the capabilities of an "enlisted hacker" to spoof the AFATDS into mistaking the Officer's Club as a concentration of enemy troops. AFATDS could give a "fragger" the chance to do a lot more damage than he/she could do just using a grenade or gun.

Second, there are the problems of unexpected software bugs which could misdirect fire or even abend the entire system. Given that the consequences of either misdirected artillery barrages or losing artillery support altogether could literally be a matter of life or death, it would be interesting to find out how Magnavox plans to deal with these problems.

This is more than just a theoretical topic since it is possible that AFATDS could be implemented as soon as next year according to the article.

Dave Graf

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

Date: Wed, 18 Oct 1995 10:47:24 -0700 From: Lord Wodehouse <w0400@ggr.co.uk> Subject: Lots of copies, but why?

Recently I ordered a copy of a book via *The Daily Telegraph*. You collected three tokens, sent a small cheque for the postage, and waited the customary 28 days or so before the book arrived.

I came home one day to find five parcels:

1. A book, addressed to Lord Woodhouse (mispeled) 2. A book, addressed to Lord Woofhouse (a new spelling - I like this one) 3. Three books, addressed to Lord Woofhouse 4. Three books, addressed to Lord Woofhouse 5. Three books, addressed to Lord Woofhouse

A total of eleven books. We are now giving them away to friends [...], as the thought of trying to explain to someone that eleven was ten too many and getting them sent back was rather more than I could face at the time. The book order numbers are the same, except the first parcel.

Of course if the mailorder computer system has done that to more than myself, the risk is obvious. The company will go bust. I hope I don't have their software or operations procedures anywhere near anything critical I use. [They are indeed in your Doghouse. PGN]

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

Date: Fri, 20 Oct 1995 11:33:40 -0700 From: sidney@atg.apple.com (Sidney Markowitz) Subject: RISKS of believing the newspaper's twist (or shimmy)

RISKS-17.40 quoted *The Boston Globe* describing a high-level executive at a Manhattan health company accidentally e-mailing an erotic video of herself to 400 coworkers. While the story makes for interesting gossip, with the lack of details I have to wonder if it is more of a male fantasy embodied as urban myth. 1) Has anyone heard of such a neat video e-mail system being commercially available and in common enough use that a "health company" would be using it for company-wide communications? 2) If there are e-mail systems with video capability, are they so cheap, small and convenient that people have cameras on their laptops as well as on their office desktop machines? 3) Even if there were such systems, has anyone devised video compression algorithms so good that it would be practical to send video e-mail over a modem from one's laptop in the hotel? Without some corroboration, I think that the body of evidence does not support the story as being the bare truth.

-- sidney markowitz <sidney@atg.apple.com>

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

Date: Fri, 20 Oct 1995 10:50:54 -0700 From: [Name withheld on request] Subject: Getting your clearance on the net

I'm going in for a top-secret clearance, and was talking to the person who's responsible for sending off the paperwork. She's excited: seems that you can now submit the forms over the Internet, thus saving the need to send stacks of paper. You obviously don't sign the form (no digital signature capability); at some point in the future they said I'll be asked to sign a hardcopy.

I suggested that it made me uncomfortable to have all that personal information being sent over a public net without any form of protection, so they agreed to submit mine on paper.

The risks of sending any sort of confidential information over the net have been described to death, so there's nothing new. It just amazes me that the U.S. government office responsible for handing out clearances could be so unaware of the risks as to allow it. Further, as holding a clearance is generally something that's not supposed to be discussed except for those with a need to know, it seems odd that they would be willing to accept the information leading to a clearance over a public network.

P.S. For those who haven't had the pleasure of applying for a clearance, among the information they ask for is where you've lived, worked, been married to, travelled to; also any treatment for psychiatric conditions, use of drugs, criminal record, organizational memberships, communist party affiliation, etc. So there's plenty there that some people might not want posted on bathroom walls.

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

Date: 23 Oct 95 07:26:58 EDT From: Alan Tignanelli <75453.2055@compuserve.com> Subject: Guess what happened at the Pittsburgh Airport?

That's right. It's happened again. That's six times in a month. This time, however, it happened during a visit of the National Air Traffic Controllers Association and U.S. Rep. Frank Mascara, a member of the House Committee on Transportation and Infrastructure.

This time the FAA blamed a three-minute commercial power failure, and said the backup generator kicked in within 20 seconds. During the outage, controllers maintained radio communications. The FAA said weather was clear and no flights were delayed. There were high winds in the area. Since the radar system was installed a year and a half ago, there have been at least nine recorded outages. Because of the frequency of the outages, the FAA is considering UPS. (A few travellers may be considering sending themselves by UPS as well - AT).

Alan Tignanelli

[UPS and DOWNS are not good for ATC systems, but they are OK for airplanes (as long as the DOWNS can be followed by more UPS). Oh, for non-US readers, in Alan's context, the first UPS denotes Uninterrupted Power Supplies, and the second denotes United Parcel Service. PGN]

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

Date: Fri, 20 Oct 1995 15:11:42 -0700 (PDT) From: emerson@comet.lvdc.wr.irs.gov Subject: More air-traffic control woes: Las Vegas

Three-minute outage blanks approach radar at McCarran

* A union official contends equipment at Las Vegas' airport is outdated, but an air traffic official disagrees.

by Keith Rogers, *Las Vegas Review-Journal*, 19 Oct 1995

Three air traffic controllers who were tracking aircraft approaching Las Vegas experienced a 3 1/2-minute radar outage Tuesday night, raising concerns with their union that it's time for new equipment. But Paul Strybing, assistant air traffic manager at the Las Vegas Terminal Radar Approach Control, said, "At the time this took place, we had five other radar displays that continued to operate fully. At no time was there any loss or disorientation of traffic." In a statement Wednesday, Daniel Maddaus, president of the National Air Traffic Controllers Association Local-L30, the union that represents controllers for the Terminal Radar Approach Control, said, "This outage lasted long enough for an average air carrier to travel about nine to 10 miles unseen by air traffic control." The Las Vegas approach control handles aircraft up to an altitude of 17,000 feet within a 40-mile radius of McCarran International Airport. "The likelihood of a midair collision zooms," Maddaus said [...]. "You have aircraft pointed at each other with minimal separation." Three of the five controllers working that shift were affected by the outage and were able to switch to other radar screens, Maddaus said, but, "the problem I have is the equipment is old and prone to more failures." [...] "The flying public pays for the most complex air traffic control system in the world. What they are getting is a very large bureaucracy and 1950s and '60s technology." Strybing said the radar system is 1970s technology "and continues to work extremely well." "It's an extremely reliable system that has the best track record of any system configuration of its kind in the world. There are redundancies and backups." The outage at 10:02 p.m. Tuesday to what is called the Multiplex Display Buffer Memory lasted 3 minutes, 21 seconds and caused three radar screens to go blank, Strybing said. [...]

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

Date: 19 Oct 1995 17:13:56 -0400 From: "Marc Rotenberg" <rotenberg@epic.org> Subject: FLASH * Marketry Dumps Marketing Plan

Marketry [See RISKS-17.39] said this week that it was dropping plans to sell data gather from the Internet. While some company (anyone know who?) is still collecting the information, Marketry president Norm Swent, announced Marketry's "resignation as manager of the e-mail Internet Interest Selector list."

Who says a little e-mail can't make a difference? ;->

Marc Rotenberg, EPIC rotenberg@epic.org

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

Date: Tue, 24 Oct 1995 13:22:57 -0400 (EDT) From: calvert@cc.gatech.edu (Ken Calvert) Subject: Re: Risk of not knowing [when] something goes wrong (Cohen, R 17.40)

>I always felt that parity checking was not enough - I want ECC memory.

Of course, if you have ECC (error-correcting) memory alone, you have the same problem, unless you ALSO have error detection.

This is an old RISK. For a 20-year-old warning, see E.W.Dijkstra, "On a Warning from E.A.Hauck", EWD 525 (reprinted in "Selected Writings on Computing", Springer-Verlag, 1982).

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

Date: Sun, 22 Oct 1995 13:07:55 -0500 (CDT) From: Daniel Frankowski <dfrankow@winternet.com> Subject: Re: Northwest Spit Me Out

In RISKS-17.26, I reported that Northwest accidentally erased me from their records, I showed a letter I sent to the president of the company, and I promised to keep RISKS updated.

Well, there were two interesting developments.

First, an "aide to the president" called within a couple of days, and said that when another Daniel Frankowski sent in a change of address, they applied it to my account instead. Northwest rectified the error (as far as I can tell), satisfying requests (2)-(4) of my original letter, but did not satisfy my request for

(1) detailed information that your computer information and information-related problem-resolution practices are safe and effective

I am probably going to cave on this, because I do not have the desire to spend the time on it.

What this experience tells me is that if a customer service rep tells you that you are out of line (as one did me), just go yell to someone else. Your service does depend on the person serving you, not just the company. This is probably obvious to RISKS readers.

The second interesting thing that happened is that within a couple of days of my e-mail to RISKS (long before Northwest called me) I was in contact via e-mail with the other Daniel Frankowski. Small electronic world! He is Daniel J. Frankowski, I am Daniel S. Frankowski. As we are both 25 and in the computer business, probably we will be crossing wires again sometime. He seems like a nice fellow, of course. :-)

Dan Frankowski dfrankow@winternet.com http://www.winternet.com/~dfrankow

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

Date: Thu, 19 Oct 95 00:40:11 PDT From: shadow@krypton.rain.com (Leonard Erickson) Subject: Re: How to derail a train

Bob_Frankston@frankston.com writes:

> I was surprised to see TV news stories and front page articles giving > instructions on how to derail a train from which bolts to remove to how to > defeat the electronic system checks.

Actually, the information is far from secret. Any bright 13-year old with an interest in trains could tell you how to do it. Anyone with any sense of mechanical aptitude can just *look* at the rails and see how they go together. The "hard" part is fooling the block signals. And that's described in just about any article on how they work. For that matter, you can *watch* railroad employees test crossing signals and the like by placing a set of jumper cables between the rails.

So it's pretty obvious that both connectivity along the rails, and *between* the rails are checked. From there, it's but a moment of thought to any of the *many* ways of getting around them.

Leonard Erickson leonard@qiclab.scn.rain.com (aka Shadow) shadow@krypton.rain.com (preferred) FIDO: 1:105/51 Leonard.Erickson@f51.n105.z1.fidonet.org

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

Date: Thu, 19 Oct 1995 15:57:40 EST From: "David A. Curry" <davy@ecn.purdue.edu> Subject: Re: The Johnson Bug

Date: Tue, 17 Oct 1995 10:32:22 -0700 From: Tracy Pettit <tnpetti@nppdnet.com> Subject: Re: The Johnson Bug (RISKS-17.39)

[....] it sounds a lot like the stories about poisonous snakes wrapped in imported carpets or burglary victims finding their pet Doberman choking on severed fingers. I believe there have been a book or books published on these types of stories [....]

These stories are more properly called urban legends. There are four well-written books on them by Jan Harold Brunvand, a professor at (I think) the University of Utah:

The Choking Doberman The Mexican Pet Curses! Broiled Again! The Baby Train

(There are a number of other books by other authors as well, but I do not have a list.) They should be available at your local bookstore.

Aside from being an entertaining read, the books really show why it can be dangerous to accept things at face value without checking the facts. I think most people would be surprised by how many of these stories they've heard, or even repeated as true... I was.

--Dave

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

Date: Thu, 19 Oct 95 15:53:21 -0700 From: minow@apple.com (Martin Minow) Subject: Re: Determining the health of disk drives

In RISKS-17.40, Sean Reifschneider notes that some modern disk drivers intended for portables have extensive error management built in, and asks "but how does it report the problems."

All SCSI devices can implement an extensive error logging command protocol defined in the ANSI SCSI Standard (ANSI X3-131-1994), including commands to initiate self-test sequences and commands to report errors. Presumably, the device's manufacturer would provide a vendor-specific utility to monitor the device. In the Macintosh community, there are several very competent third-party disk driver vendors who are certainly technically capable of writing this utility.

My experience, however, is that modern SCSI disks are extremely reliable, and there isn't much cost/benefit in doing this: remember, the personal computer user community does not -- and should and should not -- need to know about technical details within their computer systems. Here, a comparison with modern computer-infested automobile control systems seems relevant: how often do you want to examine the engine logs?

Martin Minow minow@apple.com

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

Date: Thu, 19 Oct 1995 19:00:35 -0500 (EST) From: "Charles J. Wertz" <WERTZCJ@SNYBUFAA.CS.SNYBUF.EDU> Subject: Re: Risks in Java and Beyond Java (Riddle, RISKS-17.39)

I read Prentiss Riddle's comments on the risks of Java with considerable interest. This seems to me to be one example of a larger problem that seems worthy of considerable discussion in Risks. The Microsoft Word viruses that have come to light recently provide another example. (Simply stated, a Word document can contain a "macro" that executes when the document is opened. Someone finally realized that this macro can do something nasty to the unsuspecting recipient of the document.)

The more general concept that many folks are propounding is that we will regularly exchange "objects" containing both data and code by mechanisms such the World Wide Web and various kinds of object request brokers. The broader supposition seems to be that the concepts of applications and data files as we know them will disappear.

I've been viewing this with growing alarm for some time. It seems to me that if all this does happen, it will be possible to turn all sorts of nasty things loose. It also seems that scanning for nasties is not going to be able to catch them. Monitoring various kinds of system calls might have a better chance but this seems inadequate as well as cumbersome.

Am I missing something? Does anyone have some good solutions?

Charlie Wertz

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

Date: Fri, 20 Oct 1995 14:48:13 +0100 (BST) From: "Adrian John Howard" <adrianh@cogs.susx.ac.uk> Subject: NSA Museum on Web

Risks readers might be interested in knowing that the NSA National Cryptological Museum now has a web page at:

<http://www.nsa.gov:8080/museum/>

It includes a brief tour with pictures of some of the exhibits.

Adrian adrianh@cogs.susx.ac.uk +44 (0)1273 678367 http://www.cogs.susx.ac.uk/users/adrianh/

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

Date: Mon, 23 Oct 1995 15:11:44 -1000 From: "Ray Panko" <PANKO@busadm.cba.hawaii.edu> Subject: Minitrack on Risks in End User Computing

There will be a six-paper minitrack on Risks in End User Computing at the Twenty-Ninth Hawaii International Conference on System Sciences in January, 1996. Most of the papers will focus on spreadsheet risks and spreadsheet errors.

Three of the papers are available online. If you are interested, please use the following URL.

http://www.cba.hawaii.edu/panko/h6reuc.htm

You can also access these papers through links in my home page, which is listed below.

The papers add to past findings. Wherever quantitative errors have been studied in spreadsheeting, they have been found in disturbingly high numbers. Galletta et al.'s paper extends this to the debugging phase. In addition, controls on spreadsheeting and end user computing are at best informal.

Aloha, Ray

World Wide Web: http://www.cba.hawaii.edu/panko

Prof. Raymond R. Panko, Decision Sci., Coll. of Business Admin., U of Hawaii 2404 Maile Way, Honolulu, HI 96822 (808) 956-5049 Fax: (808) 956-9889

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

Date: 6 September 1995 (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) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] DIRECT REQUESTS to <risks-request@csl.sri.com> (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for further information]

CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR> cd risks<CR> or cwd risks<CR>, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://unix.sri.com/risks [if your browser accepts URLs.]

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

End of RISKS-FORUM Digest 17.41 ************************