Text File

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

RISKS-LIST: RISKS-FORUM Digest Tuesday 17 May 1994 Volume 16 : Issue 07

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 information on RISKS (comp.risks) *****

Contents: Crossover of Diagnosis and Procedure Code creates risk (Paul Stoufflet) The Italian Crackdown? (Fabrizio Sala via Stanton McCandlish) Umass/Amherst Suffers From Week-long Service Degradation (Randy Sailer via Jonathan Welch and Sullivan) More on the A300 crash at Nagoya on 26 April 1994 (Peter Ladkin) Palm-reading and immigration (John Oram) Computer-based Notice Boards and Emergency Information (John R. Gersh) Re: Killers sue over phone taps (Adam Shostack) Revision to the Secure Hash Standard (NIST message via Paul Carl Kocher) Automated address changes (Linus Sherrill) Re: Tandem and California DMV (Scott Hazen Mueller) Tracking (Phil Agre) Secret... not so secret [NYNEX PINs] (Alan Wexelblat) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: Mon, 16 May 1994 15:23:49 +0000 From: pstouffl@dsg.harvard.edu (Paul Stoufflet) Subject: Crossover of Diagnosis and Procedure Code creates risk

I work at a local HMO, Harvard Community Health Plan, on evenings and weekends. When we see patients, we get a printout of the recent visits by those patients, along with diagnoses, major and minor problems, medications, etc. HCHP uses a 4 character code for most of these, consisting of a letter followed by 3 numbers (for example, O991 is a headache). However, the same code can mean different things in different areas. I saw one chart that had a diagnosis of Chronic Lymphocytic Leukemia, which is odd as an isolated finding in a young adult. Curious as to how this devastating diagnosis got on this persons chart, I did some looking, and finally found that the same code was a procedure code for the administration of a particular vaccine, but it had been cast as a diagnosis instead. I alerted the patient (and medical records) to the problem, since otherwise I could see this person being denied life insurance in the future.

Obviously, identical codes should not mean different things in different fields.

Paul Stoufflet, Decision Systems Group, Brigham and Women's Hospital 75 Francis Street, Boston, MA 02115 pstouffl@dsg.harvard.edu (617) 732-7746

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

Date: Mon, 16 May 1994 13:03:15 -0400 (EDT) From: Stanton McCandlish <mech@eff.org> Subject: The Italian Crackdown? (fwd)

[notes in brackets are mine. - mech@eff.org]

Forwarded message: Date: Mon, 16 May 1994 12:29:14 +0200 (MET DST) From: Fabrizio Sala <fsala@varano.ing.unico.it> Subject: The Italian Crackdown?? To: BBS-L@SAUPM00.ing.unico.it Cc: eff@eff.org

Hello. I'm the Sysop of one of the BBSs in Italy.

I'm writing this message in this list to inform you, the BBS community, of what is going on in Italy.

Some days ago, starting from Pesaro (Italy), our Police started a large perquisition through [inquisition against] many Amatorial [amateur] BBSs, mostly connected to the main networks (One for all: Fidonet... but also PeaceNet and many others)

They're getting everything they can find: computers, monitors, drives, hard disks, floppy, cdrom, streamer tapes ... everything, without looking if they are or not in any way "illegal" ...

Generally, every network in Italy is now full of holes... and many of us lost everything "in the name of the anti-piracy"...

Nobody of us is doing anything in any way illegal, but they are still getting everything...

They got more than 50 BBS and Police's work is still going on...

I hope that everyone diffuses this message ... or in any way tells everybody what's going on ...

...and if you have any way to help us...please do it! We made our best to make the Italian telecommunication scene working... they are killing us!

See you later... if they don't get me!

______ end fwd ______

Stanton McCandlish * mech@eff.org * Electronic Frontier Found. OnlineActivist

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

Date: Mon, 16 May 94 20:56:51 -0500 From: sullivan@geom.umn.edu Subject: Umass/Amherst Suffers From Week-long Service Degradation

Date: Mon, 16 May 1994 09:09:11 -0500 From: Jonathan_Welch <JHWELCH@ecs.umass.edu> Subject: Umass/Amherst Suffers From Week-long Service Degradation Newsgroups: comp.dcom.telecom X-Telecom-Digest: Volume 14, Issue 229, Message 4 of 14

After slightly over a week of unreliable phone service things returned to normal and the following appeared in the May 13th edition of "The Campus Chronicle".

Jonathan Welch VAX Systems Manager Umass/Amherst JHWELCH@ecs.umass.edu

- - -

Telephone system returned to normal

As you know, the University had a major problem with the campus telephone system which began last Monday, May 2. The symptoms of the problem included calls being cut off, static, a "fast busy" tone when calling on campus and telephones without dial tone. The symptoms were sporadic and fairly random for both academic/administrative telephones and residential telephones.

As soon as the problem started, Ericsson, the manufacturer and maintainer of the telephone system, responded. Ericsson staff worked straight through from Monday morning to late Thursday evening to diagnose and remedy the problem. In addition to the normal three on-site technicians, Ericsson brought in staff from their regional headquarters in Northboro, and flew in a high level technician/ system programmer from the Technical Assistance Center in Cypress, Calif. They also had programmers in Cypress and Sweden working remotely to stabilize the system and to determine the cause of the problem.

The problem with the system resulted from a unique set of circumstances involving software parameters, system clocking and a normal maintenance procedure performed on the system. The problem was exacerbated by the increases of load on the telephone system we have experienced this year.

The campus telephone system is a complex, distributed computer. Such systems are designed with a great deal of redundancy and can self-correct for many faults. Once the problem occurred, parts of the system were continually trying to reset themselves. In this instance, the complexity of the system and its attempts at self-correction made it difficult to trace the problem and stabilize the system. By Wednesday afternoon, Ericsson had made substantial progress in correcting the problem. They made a configuration adjustment in the system and implemented a slight but important programming change in the software. This adjustment, while straightforward, was difficult to install on the system because of the heavy call volume on campus and the size of the campus system (18,000 lines on 119 system modules). What Ericsson accomplished is analogous to fixing an electrical problem in a car traveling down the highway at 50 miles per hour. The parameter they adjusted did not initiate the problem, but the change allowed the system to return to normal operations.

By early Thursday morning in the residence halls and noon on Thursday in the academic/administrative area of campus, service had considerably improved. Except for a brief interruption of service while circuits were being tested, calls in progress were no longer interrupted by static or cut off. There may have been some problems completing a call or placing long distance calls while work was in progress. However, in general TelCom was quite successful at assisting individuals in making their long distance calls. Ericsson has made adjustments in the system configuration, system clocking and maintenance procedures to ensure that this problem will not recur. I realize the telephone service problems last week were very frustrating for everyone. Telephone service is an important part of our daily lives and any interruptions or degradations in service are a very serious problem. I truly appreciate the patience of the campus community while we struggled to deal wilh the problem.

We in TelCom, as well as the Ericsson staff, were even more frustrated (if that is possible) at not being able to get the problem resolved quickly. We apologize for the difficulties and will work closely with Ericsson to prevent this problem from occurring again.

Randy Sailer, director, Telecommunication Services

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

Date: Fri, 13 May 1994 21:24:17 +0200 From: Peter Ladkin <Peter.Ladkin@loria.fr> Subject: More on the A300 crash at Nagoya on 26 April 1994

On 26 April, a China Airlines A300-600 crashed on landing at Nagoya airport, killing 264 people. The crew had announced they were `going around' (aborting the approach and gaining altitude to come back for another landing attempt), but continued the approach. Near the ground, the aircraft pitched up (raised its nose in the air), stalled, and `hit the ground at a high rate of descent, tail-first and completely stalled'. (Flight International, 11-17 May 94, p5). Part of what is known so far is that the Flight Director or FD (a form of autopilot) was in `go-around mode', and the co-pilot was physically trying to counteract the guidance of the FD, specifically against published procedures (FI, op. cit.). The FD, trying to fly up with the co-pilot commanding fly-down on the elevator, counteracts with nose-up trim (the horizontal stabilizer at the tail is repositioned by the pilot or by the FD so as to maintain a desired attitude of the aircraft, climbing, cruising, or descending, simply by aerodynamic equilibrium. This is called `trim').

At 700 ft, both autopilots are disconnected. The aircraft pitches up steeply because full nose-up trim has been applied (this cannot be overcome by control-column input alone -- pilots must readjust trim). At 540 ft, the anti-stall system triggers full power, which gives additional pitch-up moment, and the aircraft enters a very steep climb with a pitch of 36 degrees. The pilots fail to readjust trim. At 980 ft, a pilot selects flaps-up to go-around setting causing a pitch-up to 52 degrees, and a speed decay from 124kt (slow) to 78kt (disastrously slow) (FI, op.cit.)

To give an idea, light planes stall (their wing ceases to provide lift) when the angle of the wing to the `relative wind' (the airflow vector considered relative to the wing of the aircraft) becomes roughly 15 degrees. Transport aircraft are similar, but I don't know the stall angle of the A300-600 wing in landing configuration.

The Japanese Transport Ministry's Aircraft Accident Investigation Committee is also looking into an apparent loss of all electrical power moments before the crash. The chairman, Manabu Matsumoto, has `no recollection of a case like this, an apparent failure of all power'. (International Herald Tribune, 11 May 94 p2).

Features of this accident of potential interest to RISKS readers at this point are (a) the preliminary confusion of the crew about which control mode was selected on the autopilot; (b) the full nose-up trim consequence of the interaction between the co-pilot and the FD; (c) the autopilot triggering full-power and therefore a high nose-up moment when the nose was already high; (d) the apparent failure of all power.

One should be cautious if trying to `second guess' the accident investigation. Airplanes such as this are meant to be flown a certain way, in which pilots are thoroughly trained. Pilots are generally legally required to hold to those procedures except in case of emergency.

Peter Ladkin

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

Date: Sat, 14 May 1994 17:53:38 -0800 From: oramy92@halcyon.com (John Oram) Subject: Palm-reading and immigration

In the May 12 Financial Times of Canada, there is an article entitled "How palm-reading can speed your way into the U.S."

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

Put your hand up if you've had it with the interminable lineups to pass through airport immigration checkpoints when travelling to the United States. That upraised hand could be your ticket to zipping right through.

The U.S. Immigration and Naturalization Service (INS) is testing a new system that turns your hand into the only piece of identification you need to bypass immigration officials ans skip right through customs, cutting up to 45 minutes off the procedure for heading south.

Called the INS Passenger Accelerated Service System (INSPASS), it works like this: a three-dimensional image of your hand is electronically recorded on a white, plastic, wallet-sized card. You run the card through a scanner, place your palm onto an electronic reader and, as long as your hand and the card match, you're issued a computer-generated receipt that opens a gate arm, sending you past immigration officials to custom inspection.

[Summarizing the next few paragraphs, INPASS is being tested at three sites: Pearson (Toronto), JFK, and Newark. The article goes on to explain registration at INS offices, which takes about 10 minutes and is free during the indefinite test period. Open to citizens of Canada, Bermuda, Japan, New Zealand, most of Europe and the U.S., but have to make at least three business trips per year to qualify.]

Concerned about privacy? Sally Jackson, director of public affairs for the Offices of the Information and Privacy Canada, says you shouldn't be. The only people participating are those who consent to putting their hand impression on the card; besides, no other record of the hand image is kept.

So far, 26,502 people have signed up for INSPASS, including 2,764 Canadians. More people, no doubt, will follow when they realize how, uhhh, handy the system is.

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

What happens if the systems does not recognize your hand? I'm curious as to the recognition rate. For example, if you get married after registering, will a ring throw the system for a loop?

Also, I find it interesting that the image is kept on the card only. Will the INS keep a record of your travels? (Or do they already?)

John Oram oramy92@halcyon.com Victoria, BC Canada

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

Date: Mon, 16 May 1994 10:29:07 -0400 From: John_Gersh@aplmail.jhuapl.edu (John R. Gersh) Subject: Computer-based Notice Boards and Emergency Information

RISKS-16.05 and -16.06 included discussion of problems with cable-TV notice-generation systems crashing and leaving cryptic or amusing error messages for all to see ("Amusing computer-related anecdote about local cable service," Long, Jones, Hrisko). Failures and usability problems with such computer-driven notice boards can sometimes have more serious consequences:

My father lives in a retirement community in a high-rise building. While I was visiting there recently the building's fire alarm went off. My father immediately said, "Turn on the TV -- channel 8."

The building's cable system includes a local notice-board channel that typically shows screens rotating through the dining room menu, daily events, and so forth. It's also used for emergency notices.

Sure enough, within a few seconds, the notice channel stopped showing the lunch menu and switched to something like:

The fire is on the 75th floor. Please follow the directions of your floor warden.

(Evacuation procedures apparently differ according to location above or below the fire floor.) The problem with this notice is that the building has only 24 floors!

Evidently someone in the management office soon realized the error. Everyone in the building was then treated to several minutes of cursor-dancing around the screen, as that person tried, unsuccessfully, to change the notice. A cursor would move around the screen, closing in on but failing to select the floor number; the screen would switch to a Master Menu Page and back to the fire notice again; more vain attempts would be made to select the floor number; back to the Master Menu; and so on. Finally things remained static for several minutes. "Aha," said I, they've gone to get The Expert." Sure enough, when screen activity resumed the floor number was immediately changed to a reasonable one, just in time for the all-clear. (It was a false alarm, as are most of the alarms in that building, but that's a different RISK.)

Electronic notice boards in public or semi-public settings can be used for things other than routine bulletin-board postings. If they're going to be used for getting across emergency information, then the same requirements for usability under stress and that we'd expect for other safety-critical applications apply to them, too. We'd also expect that users of such systems ought to be thoroughly trained for emergencies, but system design ought to allow for situations where a not-so-thoroughly-trained user is all that's available.

John R. Gersh (John_Gersh@aplmail.jhuapl.edu) The Johns Hopkins University Applied Physics Laboratory

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

Date: Mon, 16 May 1994 15:10:55 -0400 From: Adam Shostack <adam@bwh.harvard.edu> Subject: Re: Killers sue over phone taps (Kabay, RISKS-16.06)

Mich Kabay complains about criminals wanting their 4th amendment rights preserved. If the state wants to wiretap their conversations, odds are good that a judge could be convinced of probable cause. The fact is these wiretaps are warrantless, and should be replaced by wiretaps authorized by warrant. I've also yet to hear of criminals (outside of Congress) who want to deny others rights they claim for themselves.

There are several clear risks in denying someone all of their rights because of a conviction. They include false convictions, a growing disregard for the Constitution, and the moral problems of punishments being chosen by prison officials/cops, rather than the judicial system.

Adam Shostack adam@bwh.harvard.edu

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

Date: Mon, 16 May 1994 02:48:15 -0700 From: Paul Carl Kocher <kocherp@leland.Stanford.EDU> Subject: Revision to the Secure Hash Standard

The following notice was released by NIST a couple weeks ago, but doesn't seem to have made it to RISKS yet.

No additional information is available regarding the nature of the "minor flaw." I called NIST and the NSA when the announcement first came out, but was told that details of the problem were confidential. They also didn't know when a revised version would be available.

It will be very interesting to see whether non-NSA cryptographers find the problem...

Paul Kocher, Data security consultant kocherp@leland.stanford.edu

(The following bulletin is available via anonymous FTP at csrc.ncsl.nist.gov as pub/nistnews/sec_hash.txt)

--- Begin Included Message ---

April 22, 1994 Contact: Anne Enright Shepherd (301) 975-4858

MEDIA ADVISORY

NIST ANNOUNCES TECHNICAL CORRECTION TO SECURE HASH STANDARD

The National Institute of Standards and Technology today announced it will initiate a technical modification to a computer security standard used to support the authentication of electronic messages. The revision will correct a minor flaw that government mathematicians discovered in a formula that underlies the standard.

The Secure Hash Standard, adopted as a federal information processing standard (FIPS 180) in May 1993, can be used for computing a digital signature and remains a highly secure way to ensure the integrity and authenticity of data used in electronic mail, electronic funds transfer, software distribution and data storage applications. NIST expects that products implementing the current standard can be used until the technical correction becomes effective.

Researchers at the National Security Agency, who developed the formula and discovered the flaw in a continuing evaluation process, now believe that although the formula in FIPS 180 is less secure than originally thought, it is still extremely reliable as a technical computer security mechanism. The discovery of this flaw indicates the value of continued research on existing and new standards.

The Secure Hash Standard specifies a secure hash algorithm for computing a condensed representation of a message or data file. This 160-bit condensed message "digest" represents the original message and can be used in computing a digital signature to authenticate the integrity of the message. It is highly probable that any change to the message after it has been signed will result in a different message digest, and the recipient will not be able to verify the signature. Signing the message digest rather than the whole message usually improves the efficiency of the digital signature process.

It is very highly improbable that today's computation equipment can figure out any message that corresponds to a given message digest.

The standard applies to agencies of the federal government for protecting unclassified information when a secure hash algorithm is required. Private and commercial organizations have been encouraged to use this standard on a voluntary basis. The SHS was designed to be used with the proposed Digital Signature Standard, which is based on the digital signature algorithm and has not yet been approved.

As a non-regulatory agency of the Commerce Department's Technology Administration, NIST promotes U.S. economic growth by working with industry to develop and apply technology, measurements and standards. NIST also is responsible, under the Computer Security Act of 1987, for developing standards and guidelines for the cost-effective protection of unclassified federal computer systems.

National Institute of Standards and Technology, Public Affairs Division Admin. A903, Gaithersburg, MD 20899-0001

--- End Included Message ---

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

Date: Tue, 10 May 94 15:19:40 EDT From: julius!sherrill@sky.com (Linus Sherrill) Subject: Automated address changes

Recently I've had a problem with incoming mail to my home address. A few months ago, mail started arriving (late) with just the wrong zip code and sometimes with the wrong town name too. The incorrectly addressed mail was usually magazines and junk mail but when credit card bills started arriving (or not arriving) with the wrong address it was time to investigate.

My wife checked at the local post office and they said that this was a problem for the whole zip code; the whole town had been affected. The post office officials had no explanation as to how this might happen. They explained that it our responsibility to correct those who have the wrong address.

The more important ones were corrected over the phone, although it was sometimes difficult to convince the operator that we hadn't moved, the address had spontaneously changed.

Whatever generated the wrong address is still at work. After getting the mail addressed correctly for a few months, the wrong address would reappear.

The post office's solution to this problem is to print bar-coded labels with the correct zip code and stick them to the mail. Mail is now arriving on schedule even with the wrong address.

I've all but given up on correcting the wrong addresses.

I'm guessing that some address verification service shipped a data base with the wrong zip code for our town. (I wonder how many other towns were affected?) Some mailers just updated the zip code and others trying to get a canonical address used the new (wrong) zip code to determine the town name.

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

Date: Sat, 14 May 94 21:20 PDT From: scott@zorch.sf-bay.org (Scott Hazen Mueller) Subject: Re: Tandem and California DMV

Recently a bit ran in risks about the California DMV computer upgrade fiasco; the original story mentioned Tandem Computers in a poor light. I'd just like to point to a reference on the World-Wide Web to Tandem's official statement on the issue, at <http://www.tandem.com/press-releases/dmv.html>. Also, a copy of the California Legislative Analyst's report on the topic is online at <http://www.tandem.com/press-releases/cla-dmv.html>; there is a hyperlink to this latter item from within the first document.

Claimer: Tandem is my day job. DisClaimer: I am not an official spokesperson for Tandem; one such is however listed in the dmv.html document.

Scott Hazen Mueller scott@zorch.SF-Bay.ORG or (tandem|ub-gate)!zorch!scott

[Thanks. The original item was in RISKS-15.80. Actually, the item noted the DMV position that neither the software vendor nor the hardware maker were responsible. Of course, the consulting firm was fired from the job. PGN]

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

Date: Tue, 5 Apr 1994 15:31:31 -0700 From: Phil Agre <pagre@weber.ucsd.edu> Subject: tracking

"There is something a little eerie about picking up a car phone and having a voice describe your location to within a few feet on a pleasant if unremarkable street of colonial and tudor-style houses."

That's a quote from a second article in the New York Times promoting the Avis project to track the company's rental cars through GPS hardware and wireless communications. The full reference is:

Peter Marks, For a few lucky motorists, guidance by satellite, New York Times, 2 April 1994, pages 1, 16.

The reporter apparently went for a ride with the system, and was enthralled. No doubt it was a fascinating experience. This article does at least mention privacy concerns, in a parenthetical note, as follows:

"On the Nynex computer screens, the cars show up as small dots moving along the roads on the computer maps. Nynex officials say, however, that for the sake of privacy, a car's position will only show up on a screen for the duration of a driver's call to the Project Northstar number."

Note that "privacy" only extends to what's presented on the operator's screen. Nothing is said about the more fundamental issue, what records are stored in the computer.

Phil Agre, UCSD

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

Date: Fri, 8 Apr 94 12:16:59 -0400 From: "Alan (Miburi-san) Wexelblat" <wex@media.mit.edu> Subject: Secret... not so secret

[EDUPAGE:]

> A sweepstakes promotion sponsored by Nynex-owned New York Telephone used > replicas of customers' calling cards, including their secret personal > identification numbers, or PINs. The mailing has caused an uproar among > some of the three million recipients, who worry about unauthorized use of > their calling cards. Nynex has offered to change the PINs of customers who > complain and cover any fraudulent charges. (New York Times 4/7/94 A1)

What's wrong with this picture? Well, changing the PINs only of customers who complain is a bad plan -- what if I didn't see the ads and don't know I should change my PIN?

Giving out real data (even card #s, let alone PINs) to a 3rd party (the ad agency) is another bad plan.

Not treating customer data as secure is a third bad plan; it's especially galling since NYNEX sends out these little reminder cards to customers telling us not to divulge our PIN to anyone.

Speaking of galling, how "generous" of them to cover fraudulent charges. As if they didn't already do this. It's a fancy way of saying "we're not going to do anything about this."

The thing that particularly strikes me is that it appears NYNEX is, once again, treating this as a special case. This is a particularly annoying RISK we see over and over again, where incidents are treated as aberrations and the symptoms are treated with no thought given to the structural problems which caused them.

I have no idea how to counteract this particular RISK, except by target educating the relevant people, assuming we can find them.

--Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard Media Lab - Advanced Human Interface Group wex@media.mit.edu 617-258-9168

[Also noted by wb8foz@netcom.com (David Lesher). PGN]

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

Date: 9 May 1994 (LAST-MODIFIED) 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. Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact <risks-request@pica.army.mil> (Dennis Rears). UK subscribers please contact <Lindsay.Marshall@newcastle.ac.uk>. Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to <risks-request@csl.sri.com> (not automated).

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. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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.

ARCHIVES: "ftp crvax.sri.com<CR>login anonymous<CR>YourName<CR> cd risks:<CR> Issue j of volume 16 is in that directory: "get risks-16.j<CR>". For issues of earlier volumes, "get [.i]risks-i.j<CR>" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye<CR>" logs out. CRVAX.SRI.COM = [128.18.30.65]; <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info.

FAX: ONLY 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 .

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

End of RISKS-FORUM Digest 16.07 ************************