Text File

Subject: RISKS DIGEST 15.53 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Satagee 12 February 1994 Volume 15 : Issue 53

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

**See last item for RISKS (comp.risks) contributions, subscriptions, FTP ...***

Contents: Electronic tax filing: MAKE.MONEY.FAST ??? (Ed Ravin) Celebrity Risks -- Bill Gates (Jack B. Rochester) Computers and Health (Computer User Family) Microsoft Software Development Network registration (James Briggs) Re: FireFly in the Ointment (Andy Kostic, Marco Barbarisi) Re: Sounding the Alarm (Anthony E. Siegman, Georg Feil) Re: Don't trust the phone company (Joe Konstan, Spencer W. Thomas, Michal.Jankowski, Nancy Griffeth and others) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: Fri, 11 Feb 1994 20:14:53 -0500 From: Ed Ravin <eravin@panix.com> Subject: Electronic tax filing: MAKE.MONEY.FAST ???

An AP article in NY Newsday on 11 Feb 1994 describes a Congressional hearing where prison inmates told lawmakers how they used electronic filing of tax returns to defraud the Internal Revenue Service.

Here are some salient highlights:

* "I think the IRS is detecting maybe 25 percent of the fraud taking place with electronic filing..." -- Frazier B. Todd Jr., serving 2 1/2 years for collecting more than US $500,000 over two years by issuing false W-2 forms from fictitious companies in the names of people too poor to file income tax returns. Todd was able to obtain permission from the IRS to file electronically via mail. His frauds continued after he was caught, by processing phony returns through legitimate tax preparation firms. Registering the false companies with the IRS took only a phone call...

* A convicted tax preparer (doing 18 months) testified how he obtained US $750,000 over three years in undeserved refunds on behalf of his clients, by inflating deductions and other devices...

* IRS Commissioner Margaret Milner Richardson says the agency has put new computer "filters" in place to spot fraudulent returns. They've already detected 200 schemes involving 3000 or so false claims (and the tax season is only six weeks old).

* During the first 10 months of last year, the IRS detected 61,000 fraudulent returns totaling US $110 million -- but a consultant's report says the true cost could be more like billions of dollars.

* Representative JJ Pickle (D-Texas) threatens to recommend a freeze on electronic filing if the problems can't be worked out. Commissioner Richardson claims that "electronic filing is the very thing that has allowed us to detect fraud".

* The speed at which refunds are issued to electronic filers makes it difficult for the IRS to stop questionable refunds. A General Accounting Office staffer suggests that "The IRS has often appeared more interested in expanding electronic filing than in ensuring that it was fully understood and adequately addressed the associated risks"...

[This is sounding all too much like William Gibson's novel _Neuromancer_, where rogue computer jockeys could reap money out of the cyberspatial ether by crashing into big computers and tampering with data...]

Ed Ravin eravin@panix.com +1 914 448 4737

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

Date: Thu, 10 Feb 94 13:30 EST From: "Jack B. Rochester" <0002757498@mcimail.com> Subject: Celebrity Risks -- Bill Gates

The Jan. 10, 1994 issue of The New Yorker has a long, juicy article entitled "E-Mail From Bill," detailing a month-long electronic correspondence between Bill Gates of Microsoft and the reporter, John Seabrook. Seabrook is apparently somewhat new to computers and e-mail (someone says to him, "Well, hey, you're not a digital guy!") and his innocence provides a refreshing look at our industry and its leading personality -- you would NOT see such an interesting, forthright, or provocative piece on Gates in, say, PC Computing.

While the risks (as I see them) are not lethal, they are interesting and worth noting:

1. E-mail will not replace old-fashioned letter-writing as a form of personal expression. It's essentially an informal business medium for communicating facts, not for sharing Deep Feelings. Even so, in the Gates-Seabrook exchange, it soon escalates/degenerates (depending on your point of view) into ego-aggrandizement and, ultimately, an unintentional psychological profile of Gates, provided by he himself (sans any Smileys). At one point Seabrook asks "How does the rapid change in the power of microprocessors make you feel?" Gates replies, "Feelings are pretty personal."

2. Good grammar and proper punctuation are not required in e-mail, and their absence does not seem to affect regard for that person. Seabrook notes the absence of a salutation, complimentary close, or any letter-style boilerplate (e.g., "nice to hear from you", "best regards", etc). Gates often confuses or misuses _its_ and _it's_, something that would be looked askance at in a business letter, but not on e-mail. (However, just to be on the safe side, maybe Gates ought to be using Word for Windows 6.0, with all that fancy on-the-fly correction capability, to draft his e-mail.)

3. Finally, the risks of notoriety. Gates talks about his forthcoming marriage ("Being married I don't think is that big a change."), and when asked about wealth corrupting, replies "Absolutely. Hey. Being in the spotlight is a corrupting thing. Being successful is a corrupting thing. These are very dangerous things, to be guarded against carefully. And I think that's very, very hard to do."

In the final e-mail exchange with Seabrook, Gates is asked what he thought of Henry Ford:

Ford is not that admirable -- he did great things but he was very narrow minded and was willing to use brute force power too much. His relationship with his family is tragic. His model of the world was plain wrong in a lot of ways. He decided he knew everything he need to fairly early in his life.

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

Date: Thu, 10 Feb 94 22:22:38 EST From: cuf@aol.com Subject: Computers and Health

The Computer User Family (CUF) is concerned about the health problem associated with computers. Video Display Terminals, emit UV and ELF radiation and may cause cancer, immune system irregularities, miscarriages and eye fatigue. Computer noise from fans, disk and CD drives is also becoming a source of anxiety, stress and general discomfort. We usually don't realize how loud our computers are: 50dB and more. These problems should be dealt with and add-ons should be provided for present computers to avoid putting us at risks. Some safe screens and quiet power supplies are coming out but they are marginal and prices are prohibitive.

Meanwhile the general guidelines for the users are:

1. Position yourself approximately 22 inches to 28 inches (arm's length) from the screen and four feet from the sides and rear of other terminals. 2. Eliminate sources of glare and lower light levels in the room. Don't sit facing a bright window. If necessary, use screen hoods, glare shields over the screen or wear anti-UV/anti-glare glasses. 3. Put a noise absorbing mat under your computer. Pull your computer away from the wall or any hard surface that reflects noise and vibration back to you. 4. Rest occasionally during periods of intense concentration. Closing your eyes helps. 5. Turn off the VDT when not in use.

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

Date: Thu, 10 Feb 1994 15:56:00 -0500 From: jeb@vigard.mef.org (James Briggs) Subject: Microsoft Software Development Network registration

The Microsoft Software Development Network (MSDN) programme has lost my registration twice in Canada and 3 times in the United States (the US number is 1 800 759 5474). This has caused about 10 months of frustration. Registering means you give a credit card number and an address. In return, you are sent a CD-ROM every quarter.

Today I tried to change my address for future mailings. The operator took my name, then told me that there was no record of my registration. It appeared lost yet again. I asked why they were losing it. The operator (Dean Miller) said he didn't know.

I asked if they were using Oracle or a MS product. He said that it was a MS product and could be Foxpro or Access. He also said the system seemed busy while doing a look-up on it.

It would appear that there are either serious administrative problems or that there are software problems or both at this Microsoft branch. Likely the software problems are related to multi-user addition of records (there are multiple operators).

Does somebody know which database they are using and why the system doesn't work?

Please do not use the operator's name. Please allow me to see the final posting before using my name.

James Briggs, Toronto jeb@vigard.mef.org or CI$ 71022,3700 C, MS Windows & dBASE consulting GPS(NAD27): N43o39.840' W079o22.701'+120m

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

Date: Thu, 10 Feb 94 21:55:36 EST From: ark@whamr.att.com Subject: Re: FireFly in the Ointment

This article (re: backwards accelerometers) reminds me of a story from my own past. Years ago, I was writing a simulation of a guidance system. For some inputs, the output rate was in the wrong direction. So I traced through the equations and found the "erroneous" sign. This fixed the original problem, but created a similar problem along another axis. I changed the "wrong" sign in another equation, and presto, the problem moved to the third axis. I changed another sign, confident that I had the correct combination now. Instead, the problem now appeared on *two* axes. Any change I made in any equation just moved the bug elsewhere.

Well, after spending the better part of a day, I realized the true problem. I had reversed the sign of the acceleration due to gravity, so my program thought that the force of gravity pulled *up*. Once I corrected this, the program worked fine.

The moral: How about "Can't fool Mother Nature, or Mr. Newton"?

Andy Kostic ark@whamr.att.com

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

Date: Fri, 11 Feb 1994 13:04:44 -0600 (CST) From: marco@email.ncsc.navy.mil (Barbarisi) Subject: Re: Firefly in the Ointment

Don Watts' letter describing the reversal of the Firefly control system, such that it flies in a direction opposite to that intended, is archetypical of navigation, guidance, and control systems.

Most such systems specify spatial conventions (i.e., which way is up) for the vehicle very early in the development, usually in the system specification. A competent system engineer will lay down the law that these conventions shall be followed now and forever and always. This is good. However, as the systems evolves from paper to actual hardware, it is found that some off-the-shelf subsystems do not conform to the spatial conventions established early in the program. Furthermore, costs to reconfigure such off-the-shelf items may appear prohibitive. This is bad.

An example might be an avionic inertial navigation unit which is adopted for use in an underwater vehicle. Is the altitude readout signed? Does depth correspond to negative or positive altitude? Maybe we could mount the inertial navigation unit up-side down - but no - that reverses pitch and yaw! By this time, the system engineer has that resigned, forlorn look of Gary Cooper in High Noon.

What about standards? There are standards for these things, but as someone on the net liked to point out, "The nice thing about standards is there are so many to choose from."

Marco Barbarisi

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

Date: Wed, 9 Feb 1994 21:49:51 -0800 From: "Anthony E. Siegman" <siegman@Sierra.Stanford.EDU> Subject: Re: Sounding the Alarm: Noisy medical alert systems

Following the 1989 earthquake, all the fire and other hallway alarms in my one-story laboratory building at Stanford University went off and could not be stopped.

These alarms all in concert were so loud that in attempting to do a building check for possible fires, spilled chemicals, injuries in interior lab rooms and the like, I found it almost physically impossible to stay in the hallways, much less communicate audibly with others. Cries from possible victims, perhaps trapped under furniture or bookshelves in laboratory rooms, would have been totally impossible to hear. Emergency rescues or damage repair would have been greatly hampered.

There was no way to turn off these alarms; I was told that only the appropriate Public Safety personnel could do so, and that the staff in our building did not even know how or where to turn them off. Because necessarily every building on campus was in a similar situation, our alarms continued to operate for several hours before they could be turned off.

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

Date: Thu, 10 Feb 1994 16:31:39 -0500 From: georg@sgl.ists.ca (Georg Feil) Subject: Fire alarm testing risks

The building where I work has its fire alarm system tested annually, in addition to possible fire drills. A few days ago the following email message was sent out to all occupants:

Xxxx Limited will be testing the Fire Alarm System on TUESDAY FEBRUARY 15, 1994 FROM 9:00 A.M. to 5:00 P.M. This is just going to be a test, so if you hear the bells ringing you do not have to evacuate.

There are at least two obvious risks, first of course that an actual fire on that day could be quite disastrous, and second the usual email risk that not everyone in the building that day will have seen the message, leading to confusion.

The capper came the next day when another email message was sent out:

The date for the fire alarm testing has been changed to Wednesday February 23rd from 9:00 to 5:00.

Talk about a perfect way to amplify a risk...

Georg Feil, Space Geodynamics Laboratory, Institute for Space and Terrestrial Science (416) 665-5458 georg@sgl.ists.ca

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

Date: Thu, 10 Feb 1994 16:07:12 -0600 From: Joe Konstan <konstan@cs.umn.edu> Subject: Re: Don't trust the phone company

I've heard (on comp.dcom.telecom.tech) of several tricks that can be used to set up these situations. The two most common are:

1. For caller-ID systems, there are devices that send another caller ID down the line after the phone call is answered. Somebody looking at the display would have to scroll backwards to find the "real" number, but would have no reason to know to do so.

2. For automatic callback, as you describe, the obscene caller can forward the return call (along with any other calls) to a different number. In this case, if the obscene caller forwarded calls to your phone, the return would end up there.

Your subject is one of the lessons. Another is not to let the phone company off the hook for tracing obscene calls simply because they've provided a few technical features to the user.

Joe Konstan

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

Date: Thu, 10 Feb 94 15:11:39 EST From: Spencer.W.Thomas@med.umich.edu Subject: Don't trust the phone company

A question: what does the "dial back" service do if the caller has suppressed caller-id with *70? Does it "wipe" the memory, or does it keep the number from the previous call?

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

Date: Thu, 10 Feb 94 23:17:57 +0100 From: <Michal.Jankowski@fuw.edu.pl> Subject: Re: Don't trust the phone company (Bodine, RISKS-15.46)

Another possibility is that his wife had called your wife recently and he actually pressed `redial' on his phone instead of activating that `abuser-combating feature'. It's easy to misdial some keys when you are angry.

Michal.Jankowski@fuw.edu.pl

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

Date: Thu, 10 Feb 1994 22:30:44 GMT From: nancyg@banshee.bellcore.com (Nancy Griffeth) Subject: Re:Don't trust the phone company (Bodine, RISKS-15. )

This is an interesting and disturbing story. You have probably been the victim of either a feature interaction or a bug in the implementation of the code that updates the calling number.

I've been following the discussion of this problem on the Telecomm Digest, and most of the possibilities have been listed there:

To summarize: Possibility 1: The calling number from the obscene call was not updated because for some reason it wasn't delivered to Tom's central office. The register still contained the Tom's number, from an earlier call placed by his wife.

Possibility 2: Another feature (possibly call waiting) interfered in such a way that Tom's number replaced the number of the obscene caller.

Possibility 3: The obscene caller was clever enough to call-forward his or her phone to Tom's number immediately after ending the obscene call. This is an unpleasant thought, since it suggests that he or she knows Tom or his wife and is actively trying to make trouble.

Tom, you should tell your friend, or is it your wife's friend's husband, that any one of these could have happened.

The first possibility is almost certainly a bug -- Bellcore writes requirements for these features, and its requirements say that the number should always reflect the last caller unless the last caller received busy or call forwarding treatment. On the other hand, Bellcore doesn't write switching software, and the companies that write it don't have to follow the requirements exactly. So it may not even be a bug, it may have been the way that AT&T or NT or whoever wanted it to work.

The second possibility could have happened if your wife's friend has call waiting, and your wife called her after the obscene call began, and her friend was sufficiently distracted by the call not to notice the call waiting. Then your number would have been used by automatic recall, at least according to Bellcore specifications.

The third possibility means that the return call went initially to the obscene caller, but was routed to you by call forwarding. Recommending that your wife's friend get Calling Number Delivery won't help -- if an obscene caller is clever enough to do the call forwarding right after the call, he has already blocked Calling Number Delivery. On the other hand, there's yet another feature, Call Origination Trace, that may be useful. I can't find the documentation for it right now, but if I remember correctly you enter a code immediately after hanging up and the caller is reported to the police. Tell your wife to suggest to her friend that they try it.

Nancy Griffeth nancyg@bellcore.com

P.S. For anyone interested in more detail, here are the responses that appeared on Telecom Digest:

Possibility 1: The calling number from the obscene call was not updated because for some reason it wasn't delivered to Tom's central office. ...

>>From: rhorer@medics.jsc.nasa.gov (Kyle Rhorer) >>Is it possible that Mrs. Bodine was the last caller *before* >>the obscene call, and the obscene call came from a subscriber in a >>different operating company? Perhaps the OC that serves the Bodines >>simply doesn't update the call return register if the call is from an >>"unidentifiable" source? >> >> >>[TELECOM Digest Editor's Note: I don't think this is true. I think the >>buffer which holds that information is flushed each time around, meaning >>valid, identifiable information from an earlier call would be erased by >>the new call, even if the new call put nothing more than 'outside' or >>'cannot identify' in the buffer where the previous information had been. PAT]

and also:

>>From: Monty Solomon <monty@roscom.COM> >>Call Return works only for calls which originate in areas which have >>the availability of the PHONESMART package (Caller ID, Call Return, >>Repeat Dialing, and Call Trace). >> >>[TELECOM Digest Editor's Note: What seems to put a fly in the ointment >>where the arguments about false identification due to a variety of >>possible causes (one call arrived when line was busy, next call went >>in the 'return call' buffer, etc, call returned to the wrong party of >>the two who called about the same time) is Mr. Bodine's comment that >>this woman had received *several* obscene calls over a period of time. >>Surely the intricacies of the modern phone network did not interact >>in such a bizarre way every time. If there have been so many obscene >>calls, can't the woman at least identify the voice of the caller, or >>listen to Mr. Bodine's voice and qualify or disqualify him as the >>person responsible? PAT]

Comments: Kyle, Monty, and Pat are both right in a way.

In favor of Pat's point: The Bellcore requirements state that if the calling number is not available, the register that holds the calling number should be updated in such a way as to reflect its unavailability. To quote from the LSSGR Feature Specification Document FSD 01-02-1260 on the subject of Automatic Recall (Bellcore's name -- the name varies from region to region and country to country):

The AR feature enables a customer to place a call to the last station that called the customer and did not receive busy or call forwarding treatment.

In favor of Monty's and Kyle's points: Bellcore doesn't write switching software; almost all switching software used in the US is written by AT&T or NT. Bellcore requirements are more suggestions than real requirements... so, does Tom's particular switch (which may be any one of several AT&T or NT switches) actually do the updating as recommended by Bellcore? It's quite possible that it doesn't. And two different switches may do different things!

Pat's argument that coincidences couldn't have caused this problem every time is irrelevant, though, because Tom was talking about just *ONE* callback, immediately after his friends had bought the service. The point he was making was that his friends bought the service because they had received a number of obscene calls.

Possibility 2: Another feature (possibly call waiting) interfered in such a way that Tom's number replaced the number of the obscene caller.

>>From: brena@sol.aa.hcia.com (Brian D. Renaud) >>Lars Poulsen (lars@eskimo.CPH.CMC.COM) wrote: >> >>> I believe that there is no such interaction problem in the case of the >>> "calling number identification" feature, since the number is delivered >>> in real time and only when the call rings through. Thus, the call that >>> would come in DURING the problem call, would only be recorded if the >>> recipient had the "call waiting" feature, and in that case would not >>> get busy, but ringback, and the CNID (if subscribed) would be delivered >>> between the rings (call waiting tones)). >> >>In my experience, CNID is not delivered if your phone is busy, even if >>you have call waiting. >> >>Brian >> >> >>[TELECOM Digest Editor's Note: You are correct, it is not delivered if >>your line is busy, and it is only delivered (if arriving via call waiting) >>on one condition that I can determine: if the call-waiting party stays on >>the line, allowing it to ring, then when the called party and whoever he >>is talking to disconnect the call-waiting call will start to ring through >>and Caller-ID will be delivered between the first and second audible >>rings heard by the called party just as though it was the first and second >>'true rings'. That is to say, you ring me and I am on a call. I get the >>call-waiting signal and tell my party we have to ring off so I can take >>the new call. We chat a few seconds more and hang up. Rather than flashing >>to accept the new call, I actually hang up and let my phone ring a couple >>times more. Between the first and second rings *that I hear* my display >>will get the Caller-ID, even if the calling party had to sit for a dozen >>rings or more. I'm not sure, but I think if I flash to answer, then put >>the party on hold and later hang up (the first call) allowing 'reminder >>rings' to tell me about the party on hold, I'll get Caller-ID between the >>first and second of those 'reminder rings' also. I know the first instance >>is correct; I think the second one is. That seems to be the one and only >>way of receiving Caller-ID under the circumstances: you have to hang up >>on the party you are talking with and let the call-waiting actually cause >>your phone to ring so delivery can be made to your display, regardless of >>how long that may be (or how many rings have occurred) since the call- >>waiting party entered your premises. PAT]

Whew! Well, Pat's wrong, and Lars has it right, if we look believe the Bellcore requirements. On the other hand, the implementation could be different.

Details of how the register is actually updated are given in Appendix E of Bellcore feature specification document FSD 01-02-1260 on Automatic Recall. As Lars said, customers that are call waited DO NOT receive busy treatment -- instead they get ringing. Appendix E specifies that "The incoming memory slot should always be updated for all incoming calls that are call waited, whether or not the incoming call is answered by the called party."

Pat is right about actual delivery of the Calling Number, but he is wrong to assume that this means the register is not updated. Even for Calling Number Delivery (or Caller ID), the register is updated when a caller is call-waited. It's not actually delivered to your phone because the signal is delivered in-band and delivering the number in the middle of a call would also deliver an ugly noise to your ear. There are proposals, however, for muting the sound briefly to deliver it. After all, often the only thing you want to know when you're already on the line is who's calling, so you can call them back.

Possibility 3: The obscene caller was clever enough to call-forward his or her phone to Tom's number immediately after ending the obscene call. This is an unpleasant thought, since it suggests that he or she knows Tom or his wife and is actively trying to make trouble.

>>From: Ben Burch <Burch_Ben@msmail.wes.mot.com> >> >>In article <telecom14.69.1@eecs.nwu.edu> TELECOM Digest Editor noted >>in response to Lars Poulsen, lars@eskimo.CPH.CMC.COM: >> >>> ... If Mr. Bodine insists he is not the party who made the obscene >>call, then I guess we take his word for it and find someone else to >>blame; but it seems quite a stretch of the imagination ... >> >>Well ... I hope you'll take *my* word for this, too! >> >>About six, maybe seven months ago, I was sleeping, and was awakened by >>the telephone ringing: >> >>Me: "Good evening, Burch residence" >> >>Female Caller: "Who is this?" >> >><moment of disorientation, non-sequiturs at 1:00 AM cause this ...> >> >>Me: "I think I ought to ask you that, since you called me..." >> >>FC: "No, *you* called me." >> >>Me: "The telephone was ringing, and I answered it, so, really, I'm pretty >>sure you called me." >> >><this was starting to sound like some bad practical joke.> >> >>FC: "No, you made an obscene call to this number just now, and I used >>call return to call you back." >> >>Me: "I'll beg your pardon, but there is nobody at this number but me at >>present, and I was sleeping." >> >>FC: "If you ever call me again, I'll see you arrested." *click* >> >>So, I'm absolutely *certain* that there are major bugs with this >>feature. Possibly some bright jerk has figured out how to give it >>false information, but I'd bet on a bug first. (I've done telephone >>switch programming, so I'm allowed to have an opinion ...) >> >> >>Ben Burch Motorola Wireless Data Group Ben_Burch@msmail.wes.mot.com >> >> >>[TELECOM Digest Editor's Note: Oh, I believe you. It could be that >>whoever called the lady quickly call-forwarded his line to yours >>immediately after disconnecting; he woke her up with his call, she sat >>there in a just-awakened stupor and thought about it for a minute then >>used 'return last call' to reach you via him. This is where having >>Caller-ID *and* 'return last call' both on the line would be useful. >>That way one could see the actual number placing the call even if the >>return trip led somewhere else. Maybe there ought to be a dialing code >>for the purpose of 'do not forward'. That is, the person placing the >>call would dial some two-digit code (such as for blocking or do not >>disturb) which meant 'absolutely ring number such and such'. This would >>be sort of like the post office endorsement we can use on letters which >>says, 'do not forward, return to sender if unable to deliver as addressed'. >>Telco's response would be to ring that number or respond with a voice >>intercept, 'cannot ring that number now' if the number was being for- >>warded. There may be times, for example, when I wish to speak with you >>but not if I know you are elsewhere; in those cases I am willing to wait >>until you are at home. The recipient's Caller-ID box would show some >>notation such as 'forced delivery from xxx-yyyy' to indicate a call had >>been received but not forwarded at the caller's request. PAT]

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

Date: ongoing From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. PLEASE read it as a newsgroup if possible and convenient for you. Undigestifiers are available throughout the Internet, but not from RISKS.

Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line; others may be ignored! Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially .UUCP folks. If you cannot read RISKS locally as a newsgroup (e.g., comp.risks), or you need help, send requests to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS".

Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>YourName<CR> CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 15, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out. The COLON in "CD RISKS:" is vital. CRVAX.SRI.COM = [128.18.30.65]; <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories.

IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM .

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.

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

End of RISKS-FORUM Digest 15.53 ************************