[1004] in RISKS Forum
RISKS DIGEST 15.69
daemon@ATHENA.MIT.EDU (RISKS Forum)
Fri Mar 25 19:05:42 1994
From: RISKS Forum <risks@csl.sri.com>
Date: Fri, 25 Mar 94 16:00:22 PST
Reply-To: risks@csl.sri.com
To: RISKS-LIST:;@csl.sri.com
RISKS-LIST: RISKS-FORUM Digest Friday 25 March 1994 Volume 15 : Issue 69
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:
Another ATM failure (with a happier ending) (Mark Connolly)
Bugs hold up farm cheques (Mich Kabay)
Nut behind the wheel (Mich Kabay)
Digital Telephone Switches and Modems (Bob Oesterlin)
Grammatik bug mistaken for racial putdown (Marni Elci via Roy Beimuts)
Re: Denver Baggage Handling (John Gersh, Marcus J Ranum, Bear Giles)
Re: Funny Money article (Sean Eric Fagan, Curtis Jackson, Tobias Ulmer)
Re: RISKs of safe ATMs (M. Hedlund)
Re: Comment on earlier [Don Norman] posting (Marcus J Ranum)
CFP: 2nd ACM Conference on Computer and Communications Security (Li Gong)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: Thu, 24 Mar 1994 08:22:14 -0500
From: connolly@hookup.net (Mark Connolly)
Subject: Another ATM failure (with a happier ending)
Is there any interest in yet another ATM contribution? This one has all the
familiar elements plus a reward for honesty to at least one of the
participants (but not the other). Here are extracts from a newspaper story.
[Mark Connolly, Connolly Design Inc., Waterloo, Ontario, Canada]
Bank machine runs amok; Honest customer returns bag full of cash
SouthamStar Network
EDMONTON -- All Barry Inkster wanted when he slipped his bank card into the
automated teller was $200 to shop for a birthday gift for his wife. Instead he
got a Las Vegas-style payoff when the machine spat out nearly $5,000 in $20
bills ... "I grabbed all the money in a great big wad and walked to a doughnut
shop and asked them to give me a bag."... Inkster said he's been ripped off by
automated tellers in the past, only to be told by bank personnel that machines
don't make mistakes. ... the machine had been causing problems all weekend ...
a number of people complained ... the machine was subtracting their
withdrawals, but not handing out any money. ... No one from the bank was
available for comment. A repair crew worked on the machine Monday morning but
obviously it didn't fix all the problems ... Inkster called the bank, took
the money back and watched the tellers count about $4,800. ... "All I was
concerned about was if the transaction had taken $5,000 out of my account."
The bank assured him it hadn't. Inkster said he was well rewarded with a pen,
key chain and free dinner for his honesty.
------------------------------
Date: 23 Mar 94 09:15:44 EST
From: "Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM>
Subject: Bugs hold up farm cheques
>From the Associated Press newswire via Executive News Service (GO ENS) on
CompuServe
Disaster Checks (By ROBERT GREENE, AP Farm Writer)
WASHINGTON (AP, 22 Mar 1994) -- The glitches stole Christmas from many Dade
County, Fla., growers expecting disaster payments from the Agriculture
Department. Because of processing errors, many checks for those who
suffered losses in Hurricane Andrew have been held up for three months.
The author explains that about 5,000 cheques (a total of about $25 million)
were to have been mailed in December. However, staffers found serious errors
such as a $140,000 overpayment. As a result of procedural and computer bugs,
"Of the $24.8 million in payments, $14 million has been reissued. And so far,
$1.8 million worth of payments has been canceled. Another $11 million in
payments remains on hold."
[It's bad enough to fight bugs in the fields without having to fight bugs in
the banks.]
Michel E. Kabay, Director of Education, National Computer Security Association
------------------------------
Date: 23 Mar 94 09:15:48 EST
From: "Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM>
Subject: Nut behind the wheel
>From the United Press International newswire via Executive News Service (GO
ENS) on CompuServe
Survey: few merchants check conflicting credit-card signatures
written by Peg Byron, edited by Harold H. Martin, in New York
NEW YORK (UPI, 21 Mar 1994) -- Credit-card fraud may get an unintentional
boost from retailers, Money magazine reported Monday in a survey that found
95 percent of clerks and cashiers they tested failed to check signatures on
charged purchases. Money magazine said signatures for purchases that
conflicted with the name on the credit card seldom caused clerks or cashiers
to check for fraud.
The article continues with details of the experiment. Staffers used the wrong
cards or signed false names in 127 cases (they had letters authorizing them to
perform the experiment).
Only 5% of the store employees checked the signatures at all. "In one case, a
male Money editor was not questioned even when he used a woman's card to
charge a $114 meal in a New York restaurant and signed the credit slip `Daffy
Duck.'"
The cost of such fraud, entirely passed on to consumers, is about $55 per card
user in the U.S.
[Human factors control the effectiveness of security measures. We really do
have to insist on PINs for credit cards.]
Michel E. Kabay, Director of Education, National Computer Security Association
------------------------------
Date: Fri, 25 Mar 1994 11:57:09 -0600 (CST)
From: Bob Oesterlin <oester@vnet.IBM.COM>
Subject: Digital Telephone Switches and Modems
Early last month, our local phone company (US West) replaced our "aging"
analog telephone switch with a new digital one, which was designed to bring us
"into the information age".
Well, no sooner was the switch installed, people started having problems
connecting to our dial-in service for home terminal support. The current
system consists of a front-end box (made by Traqnet) and a Cisco terminal
server.
The problems seemed to be widespread but intermittent:
- Dropped connections
- Can't connect at 14.4 KB (drops back to 1200!)
- Can't connect at all
After some lengthy (and still ongoing) investigation, the problem
turned out to be that the time bases of 3 digital switches
involved are not in sync! The 3 are:
- The Rochester switch (run by US West)
- The IBM Rochester Local ROLM switch (local PBX)
- The NPN Switch (which connects IBM to the corp network run by Advantis, Inc)
Comments from our local communications rep:
"I have been told that there are 3 national master clocks. Each phone
company must sync their digital switch with one of these master clocks."
"U.S. West's switch is sync'd with a master, I don't know which."
"NPN's switch is sync'd with a master too, this may be the same master
that U.S. West is sync'ing to but, this is not important yet."
"Our ROLM switch is sync'd with NPN and cannot be changed."
BTW, the problem "seems" to be getting worse as time passes.
It would seem to me that this could become a widespread problem as more DSS's
are used. Is someone causes a master clock to become out of step, then you
could (potentially) disrupt communications over wide areas.
Bob Oesterlin, IBM AS/400 Division, Dept 54T, Rochester MN 55901
oester@vnet.ibm.com (IBM IPNET: oester@rchland.ibm.com) (507)-253-4528
------------------------------
Date: 24 Mar 1994 15:27:50 -0500 (EST)
From: "Roy Beimuts, Melfort Research Station, AGR CA" <BEIMUTSR@skrsme.agr.ca>
Subject: Grammatik bug mistaken for racial putdown
The following letter to the editor appeared in the March 23rd Globe and
Mail; a very eloquent response to what must have been a very upsetting
article.
Another illustration of how the most noble of programming intentions can
backfire in the most unexpected ways due to an unforeseen bug:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Letter header: Software bug led to misunderstanding
I was distressed to read Mark Charendoff's essay Dear WordPerfect:
I'm A Jew (Facts and Arguments -- March 8). Mr. Charendoff expressed
dismay that Grammatik, WordPerfect's grammar and style checker, responded
to the noun "Jew" with the message "Avoid this offensive term."
Mr. Charendoff's dismay is understandable. The message is absurd in
that context. It was intended for "jew" used as a verb (e.g., "he jews
them down"). Grammatik's extensive dictionary contains two entries for
"Jew"; one, capitalized, for the noun, and another, labelled "offensive,"
for the lower-case verb. When "Jew" or "Jews" occurs as the first word of
a sentence, a bug in the program is calling the lower-case entry instead
of the correct upper-case one. Ergo, the message is erroneously output.
The bug will be fixed. Its appearance in a program that I helped
develop and am proud of is upsetting enough. That it resulted from our
sincere efforts to identify and eliminate ethnic slurs troubles the whole
Grammatik development team.
But other aspects of the situation disturb me personally as well.
Please note that the opinions below are my own, not necessarily shared by
WordPerfect Corp.
Mr. Charendoff remarks that many Jews he spoke with about this
argued that "Jew" really is an offensive term. They tried to find some
rationalization for the message. That troubles me. A word which
identifies a whole heritage, a word as valid as "Protestant," "Buddhist,"
"Italian," or "Canadian," does not become offensive just because bigots
use it, whether to demean or even to decimate. When Jews bend to that
point of view, they reflect the confusion of a people that has survived
oppression, only to be left with shame about its identity.
The automatic assumption by Mr. Charendoff and others that the
message was an intentional racial putdown, not a mistake, bothers me too.
Bugs occur often in software programs, especially those as complex as
Grammatik. Parsing English is not easy. Granted, a bug involving one's
religion may be hard to recognize as just an error. Although I wish he
had written to us rather than The Globe and Mail, I cannot really blame
Mr. Charendoff for his indignation.
Grammatik's goal has always been to help users find and fix problems
in their writing. We think we have had good success so far, and we are
constantly working to improve our performance. We are grateful that this
mistake has been found so that we can correct it. But I would like the
record to be clear -- this bug resulted from trying to eliminate
prejudice, not propagate it.
Note: I come from a family of Orthodox Jews. Most of the members
of my family who survived the Second World War now live in Toronto.
Marni Elci, English Linguist at WordPerfect Corp.
Albuquerque, N.M.
------------------------------
Date: Wed, 23 Mar 1994 15:38:17 -0500
From: John_Gersh@aplmail.jhuapl.edu (John R. Gersh)
Subject: Re: Denver Baggage Handling (Alan Wexelblat, RISKS-15.68)
It gets even more interesting...
The 7 Mar 1994 issue of *Aviation Week* has a story on the airport's
yet-again-delayed opening. The hangup is indeed the complex automated
baggage-handling system. The article says that the underlying problem is
simply that system testing has not been completed in time, but it also
describes some specific problems that have arisen. One is that:
"When United ran its tests, ticket counter agents were generating on-line
printed baggage tags too rapidly, causing United's Apollo computer
reservations system to communicate improper data to [the baggage system
manufacturer's] baggage sorting computers. As a result, properly tagged
luggage were being routed to a manual hold station instead of the aircraft,
according to [the manufacturer's president]. 'It was mostly a training
glitch,' he said. After the agents slowed down, the system operated nominally,
he said."
While it's not entirely clear what "generating tags too rapidly" means here
from the limited information given, one can envision various ways in which
problems might arise. For those of us who spend all too much time in airport
waiting lines, though, it's naturally disconcerting to hear that the system
design requires the agents to work more slowly than they would like to!
It's even more disconcerting, however, to hear this described as a "training
glitch," rather than a system design problem. My first reaction was to
classify this as a typical case of blaming the user rather than the builder
for problems in system design or implementation. Consider the following
analogy, though: Airport check-in agents put luggage on a conveyor belt for
dispatch to the baggage-handling area. Suppose there were a problem with
agents "putting bags on the belt too rapidly" (i.e., piling bags on top of
each other so that they fell off the belt or jammed the mechanism). Assuming
that the belt speed was reasonably specified (based on other considerations),
wouldn't it be proper to classify that as a training or procedural problem? Is
that different from the overly-speedy tag printing?
Of course it is, and therein lies the key point. It's visually obvious what
the proper placement of the bags on the belt should be; is it also obvious
when the next acceptable tag-printing moment arrives? Suppose, only for the
sake of argument, that other reasonable design constraints sometimes produce a
significant communications delay between the two systems; that delay might
result in the reservation system being able to print a baggage tag which the
baggage system was not yet able to handle. In that case the real problem lies
in not showing the agents that the overall system was not ready to print a tag
or accept a bag. If, in fact, the agents can "generate tags too rapidly," then
there is almost certainly something other than a "training glitch" at work.
One might think either that the data generation or interchange timing is not
as it should be or that the design of the agents' terminals does not
adequately portray or control the effect of such possible timing problems.
John R. Gersh John_Gersh@aplmail.jhuapl.edu
The Johns Hopkins University Applied Physics Laboratory
------------------------------
Date: 23 Mar 1994 21:51:15 GMT
From: mjr@tis.com (Marcus J Ranum)
Subject: Re: Denver Baggage Handling (Alan Wexelblat, RISKS-15.68)
One thing that's particularly fascinating is that many of the problems
they are facing (conveyor problems, zebra tags getting ripped and damaged,
etc) are problems that Federal Express and UPS have apparently already solved.
I suppose UPS and Federal Express have the advantage that they can enforce
packaging size limits and so forth, but it seems to me that one of the big
RISKS we're seeing here is the ever-present danger of not doing your research.
------------------------------
Date: 23 Mar 1994 20:07:42 GMT
From: bear@tigger.cs.Colorado.EDU (Bear Giles)
Subject: Re: Denver Baggage Handling (Alan Wexelblat, RISKS-15.68)
You won't hear much griping from the politicians because *they* are the ones
to blame for the delay. After the contract was signed, Denver kept asking for
change after change to the luggage system. Nobody can develop a system on
time and on budget if what they're developing keeps getting redefined!
On top of that, Denver made certain technical promises (e.g., a "clean" power
supply) which it has been unable to fulfill. This directly lead to the
failure of some of the early tests; a power surge would blow out circuitry,
overrun motors, etc.
>It'd probably be the usual uninformed pablum about how complex systems
>"always" have a few "small" problems, and no thought given to how the
>problems might have been prevented in the first place.
It's pretty clear that Denver has a lot of airheads at the new airport. My
favorite design flaw was the massive water sculpture directly over the main
power transformers... requiring a large stainless steel catch basin.
Another good one (not directly related to the airport) was the initial
proposal that one-way bus fare from Boulder to the airport would run about
$17. In contrast, the current bus fare from Boulder to Stapleton is about
$2.50. (The increase in distance would be about 30%). Toss in high taxi
fares, and high car parking fees, and most people would choose to have a
spouse or friend drop them off and pick them up. The impact on air quality is
obvious.
Just remember, the mayor of Denver who pushed this monstrosity on us is now
the Secretary of Transportation.
------------------------------
Date: Wed, 23 Mar 94 11:00:13 PST
From: sef@kithrup.com (Sean Eric Fagan)
Subject: Re: Funny Money article in THE SCIENCES (Kabay, RISKS-15.68)
>MK thinking out loud: AI pattern recognition algorithms coupled with a
>library of currency images could permit a smart copier to blank out all
>attempts to photocopy money.
It already exists. Xerox demonstrated it I think within the past year or two.
When given money (both US and many non-US), it ignores it, and you end up with
a blank spot on the paper.
The risks are obvious (to me, at least) and many.
------------------------------
Date: Wed, 23 Mar 94 12:35:04 PST
From: cjackson@mv.us.adobe.com (Curtis Jackson)
Subject: Re: Funny Money article in THE SCIENCES (Kabay, RISKS-15.68)
The new versions of the Canon Color Laser Copiers, the CLC 350 and CLC 550
(replacing the former CLC 300 and CLC 500) have exactly this type of
protection built in, supposedly at the request (?demand?) of the U.S.
government. I have no insight into the method used to prevent the copying of
U.S. currency; I only know that the protection is in place in these products.
Curtis Jackson cjackson@mv.us.adobe.com or dod721@aol.com
------------------------------
Date: Fri, 25 Mar 1994 13:04:27 +0100 (MEZ)
From: zccz1121@rpool1.rus.uni-stuttgart.de (Tobias Ulmer)
Subject: Re: Funny Money (Mich Kabay, RISKS-15.68)
Such photocopiers are already in existence. I remember a demonstration in
the German "Knoff-hoff" TV show (an entertainment show dealing with
popular-science topics; and yes, the name is indeed derived from "know how")
about one or two years ago. On the occasion of the introduction of new
Deutsch-Mark bills at that time, the host explained the techniques that
were used to make the bills counterfeit-proof. He finally concluded the
discussion by taking a bank-note out of his wallet and laying it on a
photocopier that he announced to be one of the latest inventions regarding
the growing problem of counterfeit by use of those rapidly spreading
color copiers. He pressed the button, not forgetting to mention smilingly
that he was only allowed to do so because they had obtained a special
permission and with police officers sitting in the first row of the
audience, watching closely. What the machine produced was a verbatim
copy of the bill but with colors changed to brilliant pop art. The host
then showed a microchip that was the nucleus of the device that was said
to recognize some dozens of bills from various currencies.
I would not expect such a chip to contain any such thing as protection
codes to activate/deactivate the pattern recognition circuit, but instead
a non-alterable read-only memory holding the images of the bills. So the
difficulty isn't to protect the chip against being cracked but to prevent
that its inhibiting output signal be disabled by means of a simple short
cut. This can only be accomplished if some part of the system that is
essential to the copying process is incorporated within that same
microchip. The system has to be designed in such a manner that you cannot
get the copier working without that chip so that it has the power to decide
whether or not to copy. On the other hand, little can be done against a
criminal attempt to replace the entire electronic control circuit board.
A more severe problem seems to be the fact that every once in a while new
bills keep coming up which the device wouldn't yet be able to recognize. This
requires that it is ensured that of every such existing copying machine the
built-in firmware be updated (by replacing the chip with a newer version)
every time when new notes are introduced with (at least) any of the leading
currencies in the world.
Tobias Ulmer (zccz1121@rpool1.rus.uni-stuttgart.de)
Student of Electrical Engineering
------------------------------
Date: 23 Mar 1994 13:14:52 -0800
From: hedlund@teleport.com (M. Hedlund)
Subject: Re: RISKs of safe ATMs (Markowitz, RISKS-15.68)
> "[...] if a thief tries to use a card which has been stolen, our ATMs
> are programmed to lock the doors and call the police. [...]"
>So if you use one of their cards, you had better hope that there are no
>data entry errors when a card with an account number similar to yours is
>reported stolen. [...]
That's not all.....you'd also better hope: (1) you're not inside those doors
when an actual thief tries to use a stolen card, not knowing or not caring
about the "security" measures; (2) no natural nor manmade disasters occur
while you're waiting for release; (3) the police know how to unlock the door;
(4) your boss doesn't walk by the ATM atrium while you're stuck; (5) the bank
installs a restroom (or at least, that you don't happen to need one); (6) the
automated system succeeds in reaching the police and conveying your location;
(7) the bank doesn't decide they're getting better use of your money while
you're penned up.....
M. Hedlund <hedlund@teleport.com>
------------------------------
Date: 23 Mar 1994 22:16:32 GMT
From: mjr@tis.com (Marcus J Ranum)
Subject: Re: Comment on earlier posting (Norman, RISKS-15.68)
>In my defense, however (the never-give-up defense), I still wish to argue
>that spelling errors are a result of what would amount to "poor design"
>were language and spelling actually designed.
How can something that wasn't "designed" be an example of poor design?
Languages evolve (with exceptions like volapuk and esperanto) rather
than being created from whole cloth by some rational process. Obsoleting a
"living" language is a lot harder than fixing a programming language -- the
installed base is potentially huge. Some legacy systems still actively
communicate using Latin.
English, with all its commas and apostrophes and other bits of charm,
is the result of a process of *translation* between the street English of the
day and an approximation of written English. If I tried to write some of the
street speech from my neighborhood in ascii, it might look a lot like,
"yo'm'a, cah yuh spa' me a qua'tuh?" Unlike compiled languages used by
computers, spoken languages don't *NEED* to be designed and probably never
will (the feelings of L'Academie Francaise aside).
Human minds are flexible enough to cope with the vagaries of "badly
designed" languages. Spelling mistakes are a result of inattention to detail,
ignorance, or apathy. The good news is that generally, the listener/reader
will relatively painlessly absorb the error, rather than dumping core or
giving a cryptic error like my compiler does when I forget punctuation.
------------------------------
Date: Fri, 25 Mar 94 15:11:20 -0800
From: Li Gong <gong@csl.sri.com>
Subject: CFP: 2nd ACM Conference on Computer and Communications Security
Call for Papers
2nd ACM Conference on Computer and
Communications Security
Nov 2-4 1994
Fairfax, Virginia
Sponsored by: ACM SIGSAC, Hosted by: Bell Atlantic, George Mason University
High quality unpublished original research and practice papers in the area of
computers and communications security are invited for consideration for the
2nd ACM Conference on Computer and Communications Security. All aspects of
security are relevant, including:-
THEORY AND TECHNIQUES: Access Control, Cryptanalysis, Digital Signatures,
Intrusion Detection, Audit, Cryptosystems, Formal Models, Randomness,
Authentication, Cryptographic Protocols, Hash Functions, Viruses and Worms,
Authorization, Database Security, Integrity, Zero Knowledge.
APPLICATIONS, CASE STUDIES & EXPERIENCES: Cellular and Wireless, LAN Security,
Security APIs, Smart Cards, Electronic Commerce, Network Firewalls, Security
Architectures, Telecommunications Security, Enterprise Security, Open Systems
Security, Security Management, WAN Security.
SOCIAL AND POLICY ISSUES: Cryptographic standards, Information Privacy, Legal
Issues, Technology Export.
PRACTICAL PAPERS DESCRIBING APPLICATIONS, CASE STUDIES OR EXPERIENCES
ARE ESPECIALLY WELCOME.
INSTRUCTIONS FOR AUTHORS:
Format: FIVE copies of your paper (not to exceed 7500 words) in a form
suitable for ANONYMOUS review (no author names, affiliations, obvious
references, etc.) and a cover sheet with author name(s), address, phone and
fax. Where possible all communications to authors will be via e-mail, so
PLEASE PROVIDE an e-mail address.
SUBMIT TO: Prof. Ravi Sandhu, ISSE Dept., MS 4A4, George Mason University,
Fairfax, VA 22030, USA (Ph#: 703-993-1659 E-Mail: sandhu@isse.gmu.edu) or
Prof. Jacques Stern, ENS/ DMI, 45 rue d'Ulm, 75230-05 Paris, France (Ph# 1 44
32 20 29 E-Mail: stern@dmi.ens.fr).
Deadline: Papers must reach us by JUNE 1, 1994. Sorry, we cannot accept late
submissions, and they will be returned unopened.
Authors will be notified of the Program Committee's decision by AUGUST 5,
1994, and will have to submit final camera ready papers by AUGUST 26, 1994.
GENERAL CHAIRS Dorothy Denning, Georgetown U and Raymond Pyle, Bell Atlantic
PROGRAM CHAIRS Ravi Ganesan, Bell Atlantic and Ravi Sandhu, George Mason U
TREASURER Richard Graveman, Bellcore
PUBLICITY CHAIR Li Gong, SRI
EUROPEAN CONTACT & PUBLICATIONS CHAIR Jacques Stern, ENS/DMI
PROGRAM COMMITTEE
Steve Bellovin, AT&T Eli Biham, Technion
Joan Feigenbaum, AT&T Virgil Gligor, U of MD
Li Gong, SRI Rich Graveman, Bellcore
Sushil Jajodia, GMU John Kimmins, Bellcore
Carl Landwehr, NRL Stewart Lee, U of Toronto
David Maher, AT&T Roger Needham, Cambridge
Clifford Neuman, USC ISI Paul Oorschott, BNR
Bart Preneel, KUL P. Samarati, U of Milan
Robert Shirey, MITRE Jacques Stern, ENS/DMI
Byron Stump, Bell Atlantic Paul Syverson, NRL
Bhavani Thuraisingham, MITRE Roger Tjarks, SAIC
Michael Wiener, BNR Raphael Yahalom, Hebrew U
------------------------------
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.
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 15 is in that directory: "get risks-15.j<CR>". For issues
of earlier volumes, "get [.i]risks-i.j<CR>" (where i=1 to 14, j always TWO
digits) for Vol i Issue j. Vol i summaries in j=00. "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.
WAIS and bitftp@pucc.Princeton.EDU are alternative repositories.
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 15.69
************************
