Subject: RISKS DIGEST 15.56

Subject: RISKS DIGEST 15.56
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Thursday 17 February 1994 Volume 15 : Issue 56

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:
Smart Cards for London Buses (Mich Kabay)
NII Testimony (Robert Ellis Smith)
Losing ATM transactions (N.S. Youngman)
Telephone charges fail to fit the bill (Marcus Marr)
Re: E-mail risks (Bill Fitler, Rex Black)
737 crash near Panama (Tim Steele)
Re: YAMIC [Yet Another Mistaken Identity Case] (Jim Cook)
Who says the Clipper issue is complicated? (D.J. Bernstein)
Re: Classified justifications; escrowed keys (Carl Ellison)
CFP, First Smart-Card Research & Advanced Application Conference (JJVandewalle)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: 16 Feb 94 22:41:04 EST
From: "Mich Kabay / JINBU Corp." <[email protected]>
Subject: Smart Cards for London Buses

Electronic card system launched on London's buses

--United Press newswire 02/15 1027 via Executive News Service (GO ENS) on
CompuServe.

LONDON (UPI) -- London Transport Minister Steven Norris Tuesday launched
an 18-month trial of an electronic ticketing system on the city's buses.
More than 200 buses operating in the Harrow district of northwest London
have been fitted with a contactless "Smartcard" reader that validates bus
tickets. Government officials said the trial will be the largest of its
type in the world.

The article states that the credit-sized card will be activated by proximity
sensors without requiring any physical contact with the reader. The card is
expected to make boarding the buses easier and faster as well as reducing
fraud.

Perhaps the most significant sentence in the article is the following:

"... the card will help reduce fraud and give bus operators more
information about who is using their services."

I wonder if the system includes audit trails which record details of who rode
which bus when. If so, I hope the software development team uses adequate
quality assurance. RISKS readers will recall that Ross Anderson recently
described a case in the U.K. in which a policeman was convicted of fraud for
having the temerity to complain about what he claimed were unauthorized
withdrawals from his bank account. The court ruled that the bank's electronic
records, which _failed to support_ the defendant's arguments, were sufficient
to convict the suspect.

Any system which records information about personal movements poses risks when
the information is accurate; but inaccurate information can cause even more
trouble.

Can a RISKS reader in the U.K. follow up on this story?

Michel E. Kabay, Ph.D., Director of Education, National Computer Security Assn

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

Date: Thu, 17 Feb 94 09:28 EST
From: Robert Ellis Smith <[email protected]>
Subject: NII Testimony

PRINCIPLES OF PRIVACY
FOR THE NATIONAL INFORMATION INFRASTRUCTURE

Robert Ellis Smith
Publisher, PRIVACY JOURNAL, and Attorney at Law

Before the NII Task Force Working Group on Privacy
January 26, 1994

1. Any analysis of the National Information Infrastructure
must recognize that privacy includes more than an
expectation of confidentiality. The right to privacy also
includes (1) freedom from manipulation by others and (2) the
opportunity to find safe havens from the crassness and
commercialism of daily life.

2. The infrastructure must be an INFORMATION-TRANSFER
medium, not a SALES medium. It must be primarily an
INFORMATION medium, and only secondarily an ENTERTAINMENT
medium. (Will the information superhighway be only another
way to exploit couch potatoes?)

3. It must have different levels of security and
confidentiality so that some sector in it allows for
confidential communications. These communications could be
intercepted by law enforcement only under current Fourth
Amendment guidelines. Aside from that, in the confidential
portion of the infrastructure, there must be strict
penalties for the interception of any PERSONAL data without
the consent of BOTH the sending party and the person who is
the subject of the data. And for aggrieved individuals and
organizations there should be a right to sue for breaches of
confidentiality.

4. There must be some portion of the infrastructure free
from commercial messages and free from the commercial uses
of the names and electronic mail addresses of the users.
Even though it is commercial-free, this sector need not
necessarily be operated by the government or a non-profit
entity.

5. In the sectors of the infrastructure available for use
by individuals, there must remain opportunities for
ACCESSING (non-personal) data anonymously (as exist in a
library situation now). Whether
to permit anonymous MESSAGE-SENDING in these sectors
remains, for me, an open question. To deny this will
deprive the network of much of its spontaneity, creativity,
and usefulness; however, to permit anonymous message-sending
runs the risk of having these sectors dominated by obscene,
inaccurate, slanderous, racially and sexually-insulting
chatter - and worse.

6. Privacy interests are less compelling, to me, in two
other sectors of the proposed infrastructure. In those
sectors transmitting proprietary business information and
sensitive business dealings, the organizations using the
network will see to it themselves that security meets there
needs, and they will have the resources to pay for it. By
the same token, in those sectors providing point-of-sale
services (presumably from the home), companies offering
these services will provide adequate security or risk losing
customers.

7. The infrastructure ought not become a means for large
conglomerates to transfer personal information between and
among subsidiaries where the data-handling is regulated
(credit bureaus, cable companies, medical providers) and
entities where the data-handling is not regulated (telephone
providers, brokerages, credit-card processors,
telemarketing).
___________

Rather than proposing specific safeguards -- which can be
drafted later -- the task force can be most effective in
1994 by establishing the DOMINANT THEMES of the
infrastructure: information-transfer, not commercialism;
democratic access not corporate dominance; diversity (in
usage as well as in levels of security) not conformity.

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

Date: Wed, 16 Feb 94 13:34:28 GMT
From: [email protected]
Subject: Losing ATM transactions

Recently I moved my bank account to Telephone bank PLC (names changed to
protect the guilty :-), a subsidiary of Traditional bank PLC. Amongst the
apparent advantages of this arrangement is the ability to use Traditional
bank's ATMs.

I had a substantial amount in my current account after the transfer, much
of which had come from a savings account, which gave substantially more
interest than the current account does. naturally when the ATM offered me
a transfer between accounts as one of its functions I elected to transfer
this cash to my savings account with Telephone bank.

Nearly two weeks later I checked the balance and find that nothing had been
transferred. Telephoning the bank the operator said "It doesn't allow you
to do that". I offered the opinion that the ATM shouldn't offer functions
it can't provide. The operator said that it couldn't be changed "otherwise
the machine wouldn't recognise your card." She did however agree to look
into whether there were any warnings in the banks literature (I read
everything in their welcome pack and i did not see any).

The risks are obvious, but as I hate people leaving it at that, I will
enumerate those that are obvious to me.

1 Loss of interest.
2 My balance isn't what I thought it was (they wouldn't reall bounce
my cheques would they 8-)
3 Can I trust the other facilities provided by the ATM (ordering
statements, cheque books, etc.)

[email protected] [email protected]

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

Date: Thu, 17 Feb 94 16:21:34 GMT
From: Marcus Marr <[email protected]>
Subject: Telephone charges fail to fit the bill

The latest issue of New Scientist includes an article on the overcharging of
some BT customers. The full article gives more details on the scope of the BT
investigations, the perceived extent of the problem, and the steps that have
been taken to notify business customers. I've tried, though, to extract the
paragraphs which may be of interest to RISKS readers. There only risk I can
think of is that of trusting computers, so those who cheque their phone bill
should not be at risk. In my opinion, there is no risk to domestic customers
since a jump of \pounds 420 in a quarterly phone bill should be noticed by the
monitoring system, and if it isn't, then surely the customer would notice!

Reproduced (without permission) from New Scientist, 19th February
1994, page 18:

``British Telecom has been overcharging some of its customers because
its computers cannot subtract one number from another reliably.
..
BT is conducting two investigations, one to find out why the
computer-generated bills were wrong by such a large amount, and the
other to discover why the errors were not spotted by a separate
computer system designed to trap gross billing errors.

BT charges calls by units (4.2 pence plus VAT). Meters at the local
exchanges that log the units used on each line are read each quarter.
BT's billing computer subtracts the figure for the last reading from
the current reading to give the number of units it charges for.
..
In each case [of overcharging discovered], simple subtraction of the
two meter readings gave a result which was wrong by 10,000 units.
In one bill, four separate mistakes were discovered:
18497 - 2964 = 25533
14295 - 2096 = 22199
11030 - 1824 = 19206
3 - 1 = 10002
These four mistakes added \pounds 1680 to a bill of \pounds 3908.

BT's backup system is designed to monitor the billing computer and
register any unprecedented peaks of activity on a line. But the
system failed to notice any errors later spotted by subscribers.
..
Insiders say that modern digital exchanges use solid-state metering
which feeds data directly into BT's billing computer. They believe
that BT has a bug in its accounting software and that the problem is
thus much more widespread than has so far been recognised.''

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

Date: Wed, 16 Feb 94 16:51:53 pst
From: [email protected]
Subject: Re: E-mail risks: appalling grammar/notoriety (mathew, RISKS-15.55)

Mathew has identified the risk of poor grammar and spelling in e-mail
messages, namely that the originator of a message will be judged as much (or
more) by its form as by its content. I firmly believe that etiquette has
evolved in social interactions to manage the risks of those interactions - and
that the e-mail media is still young enough to be defining "proper" etiquette.

As to Mathew's comments on notoriety, several stories come to mind. Recent
RISKS articles describe the flood of e-mail to Bill Gates mailbox, as well
as to WHITEHOUSE.GOV. An older story describes the e-mail trials and
tribulations of DEC's Ken Olsen, whose mailbox was deluged with mail, some
from people who would never dare to talk to him in the hall but felt
perfectly at ease taking him to task in an e-mail message.

I would greatly appreciate any pointers from RISKS readers to more
information on the developing etiquette of e-mail.

-Bill Fitler [email protected]

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

Date: Wed, 16 Feb 94 09:24:34 CST
From: [email protected] (Rex Black)
Subject: Re: E-mail risks: appalling grammar/notoriety (mathew, RISKS-15.55)

I agree with Mathew, FWIW. As a manager, I insist on the use of proper
English by all the Software Quality Assurance folks that I supervise. Why?
Because, in the minds of many, as Mathew noted, hearing or reading improper
English reflects poorly on the education and intellect of the person
communicating. In addition, I feel that sloppy communication is a symptom of
a larger problem of carelessness and lack of attention to detail, something I
find inappropriate in a professional setting. How one chooses to express
one's ideas is indicative of the value one places on them. Interestingly, I
have worked with a number of people for whom English was a second language,
and they put more effort into doing it properly--often with better
results--than many who grew up speaking and writing it.

Rex

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

Date: Thu, 17 Feb 1994 18:38:14 +0000
From: [email protected] (Tim Steele)
Subject: 737 crash near Panama

This is NOT a definitive account, just my hazy recollections from
having watched a "Horizon" documentary shown on the BBC this week.

Apparently, a 737 crashed near Panama about two years ago; all on board (about
47) were killed. The fault was identified by the investigating team as a
probable loose wire from the gyros to the flight deck which caused the
artificial horizons to "stick" in one position from time to time without any
indication to the pilots that there was a fault.

The aircraft was flying at night during a storm, and the investigators thought
that a 1G roll would be undetectable to the crew; therefore, they surmised,
they had no way of knowing the plane's true attitude. The resulting wild
maneuvers as the pilots tried to make the stuck artificial horizons show a
level attitude led directly to break-up from aerodynamic forces at about
10,000 feet.

The switches which control the artificial horizon displays were found to be
set to "BOTH ON VG1" which denied the pilots information from the backup
gyros. The reason for this was unknown.

The cockpit voice recorder was recovered, but proved to contain only a
recording of an earlier flight; it used magnetic tape (as opposed to wire) and
the tape had snapped some weeks previously. As the recorder was sealed, the
tape doesn't get checked. The flight data recorder (also tape based) worked
properly.

The programme implied that the team could not in the end identify the faulty
wire, and had made no recommendations on modifications or checks on other 737
aircraft to prevent a reoccurrence, although they felt improved crew training
might be beneficial.

Can someone post more information on this? Tim

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

Date: Wed, 16 Feb 1994 10:35:05 +0500
From: [email protected] (Jim Cook)
Subject: Re: YAMIC [Yet Another Mistaken Identity Case]

The indicated article stated that in month that the victim was held, his van
and its contents were sold.

It would seem a second lawsuit would be indicated here for improper procedure
violations. I would think that while his assets could be seized, they
couldn't be sold except after conviction or a motion for a court order at
which time the defendant would allowed to object.

C. James Cook, Epoch Systems, Inc., 8 Technology Drive, Westboro, MA 01581
508-836-4711x385 [email protected]

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

Date: Tue, 15 Feb 1994 01:13:48 -0800
From: "D. J. Bernstein" <[email protected]>
Subject: Who says the Clipper issue is complicated?

``I would like to caution people about signing the petition,'' Dorothy
Denning said. ``The issues are extremely complex and difficult.''%1

Clipper (by which I mean EES/Skipjack/Clipper/Capstone collectively)
does raise some mildly tricky issues, which I'll discuss later. But
those are _side_ issues. The basic argument%2 against Clipper is simple
and deserves emphasis.

Clipper is bad because it is unfair competition in the crypto market.

Who has paid for the design and implementation of Clipper over the past
decade?%3 The taxpayers. Who has paid for ramping up Clipper production
at Mykotronx? The taxpayers. Who pays for the lawyers and accountants
keeping Clipper on course, and the NSA-FBI team which visits Bell Labs
and other locations to promote Clipper? The taxpayers. Who will pay for
the key escrow ``service,'' probably an agency with dozens of people,
including armed guards? The taxpayers.

I resent being forced to pay for Clipper's development and adoption.

Is this Clipper subsidy the only way that the government is interfering
in the market? Not at all. Consider, for example, export controls. A
private company, even if it doesn't see a foreign market for its
encryption products, has to register as an arms dealer and take
precautions to avoid selling crypto to non-citizens. These restrictions
have been dramatically reduced for Clipper.%4

Are these points a matter of dispute? Is this just my view? No. The
government knows full well that Clipper is unfair competition.

In fact, unfair competition is the goal of Clipper policy. According to
Jerry Berman, ``the reason [for various Clipper-related actions] was
stated bluntly at the [4 Feb 94 White House] briefing: to frustrate
competition with Clipper by other powerful encryption schemes by making
them difficult to market, and to "prevent" strong encryption from
leaving the country...''%5

Now, here's the problem: The government talks about Clipper's market
interference as a _good_ thing.

Of course, I see it as a bad thing. America's need for data protection
would be fully served by a healthy encryption industry; let's eliminate
crypto export controls! If you agree with me---if you want a free crypto
market---then you should oppose Clipper. There's nothing complicated
about this.

Let me close by briefly addressing a few side issues, mostly reasons
that Clipper is risky when compared to other crypto available today.

1. There is a RISK that the Skipjack algorithm is, intentionally or
unintentionally, weak. Suppose that in 1986 an NSA cryptanalyst noticed
a subtle but wide hole in Skipjack, which was relatively new at the
time. Why would it be in NSA's interest to divulge this information?
Denning points out that we don't _know_ of any holes, but that's
axiomatic---Clipper would be dead otherwise. One cannot deny the _risk_,
exacerbated by secrecy, of a hole.

2. There is a RISK that Clipper will be easier to break than the basic
Skipjack algorithm. Given two encryption algorithms one can (carefully)
compose them to produce a ``double encryption'' which is strong even if
one of the algorithms is weak. Clipper also has two encryption steps,
but for a different reason---one encryption is transparent to the user,
the other transparent to the FBI. If either of these different%6 steps
is weak then Clipper is weak. ``Half encryption,'' I'd say.

3. There is a RISK that key escrow security will be compromised, either
by bribes from the outside or by corruption from the top. It is highly
dangerous to keep so many keys under the control of such a small group
of people.

4. There is a RISK that, if Clipper fails to dominate the market, the
government will simply outlaw all non-escrowed encryption. ``This is a
fundamental policy question which will be considered during the broad
policy review.''%7 Alternatively the government could outlaw Clipper
superencryption while requiring Clipper in government procurements, new
phones, and so on. Denning points out that Clipper is voluntary right
now, but the mere fact that the government brought up the possibility
of a Clipper law means that there's a risk.

Footnotes:

%1 To sign the CPSR Clipper petition, send a message to the address
[email protected] with "I oppose Clipper" in the subject header.
%2 This argument was mentioned briefly by Geoff Kuenning, RISKS-15.50,
among a cast of thousands.
%3 See Matt Blaze's message in RISKS-15.48. ``They said ... that
Skipjack began development "~about 10 years ago.~"''
%4 See ftp.eff.org:pub/EFF/Policy/Crypto/harris_export.statement:
``After initial review, key-escrow encryption products may now be
exported to most end users. Additionally, key-escrow products will
qualify for special licensing arrangements.''
%5 See ftp.eff.org:pub/EFF/Policy/Crypto/wh_crypto.eff.
%6 See Roy M. Silvernail's message in RISKS-15.52.
%7 See the initial White House Clipper press release, 930416.

---Dan

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

Date: Wed, 16 Feb 1994 14:31:19 -0500
From: Carl Ellison <[email protected]>
Subject: Re: Classified justifications; escrowed keys (Denning, RISKS-15.52)

In RISKS 15.52, Prof. Denning states (in reply to someone else):
>Certain information relating to foreign intelligence operations is
>classified. Are you saying that decisions should not be based on
>classified information or that foreign intelligence information should
>not be classified?

I am saying that decisions about the encryption I use, as a private American
citizen, must not be based on classified information. I am saying that the
decision must be based on a totally public debate in which we all engage.
There should be no executive session, giving classified agencies an advantage
over the citizenry.

She goes one to state:
>You need a court order to intercept any electronic communications, including
>those on high speed nets. You need a court order to get keys. Although the
>court order is not given to the escrow agents (to protect the identity of
>those under investigation), certification that one was obtained must be
>presented to the escrow agents.

This "protection of the identity of those under investigation" could actually
be protection of agents doing illegal wiretaps. If the escrow agents were to
give not the master key for a chip but a session key and if each request for a
session key included the name of the person being tapped and the court order
authorizing it, then the escrow agents would be in a position to notice the
kind of abuses for which Nixon and Hoover were famous and therefore would be
able to blow the whistle on the offending agency.

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

Date: Tue, 15 Feb 1994 22:45:52 GMT
From: [email protected] (Jean-Jacques Vandewalle)
Subject: CFP, FIRST SMART CARD RESEARCH AND ADVANCED APPLICATION CONFERENCE

CALL FOR PAPERS : CARDIS
FIRST SMART CARD RESEARCH AND ADVANCED APPLICATION CONFERENCE
October 24 - 26, 1994 LILLE FRANCE
Sponsored by IFIP - The International Federation for Information Processing

AIMS AND GOALS

Smart cards or IC cards are becoming a significant part of the information
processing world. Furthermore they are beginning to move towards real
integration into the information systems. They participate in the overall data
management, security and communication processes. But they bring their own
special characteristics. It is very likely that future IC cards will require
many scientific and technical improvements which represent a challenge for the
success of the technology. So far there are many events which are mostly
devoted to the commercial and application aspects of IC cards. There is now an
opportunity to initiate a scientific conference bringing specialists who are
involved in all aspects of design of the future IC cards and related devices
and environment. IFIP - the International Federation for Information
Processing has agreed to sponsor this conference. It will be the first
occasion for the IC card community to start a permanent activity: In addition
to the conference itself there will be discussions about creating a permanent
group within IFIP with possible implication for advancing standards,
publishing and international cooperation.

SUBMISSIONS
Six copies of detailed abstracts of original papers corresponding to one or
several themes for the conference should be sent in English to the program
chairman before May 2, 1994. The submissions will start with a succinct
statement of the problem addressed and their significance, appropriate for a
non-specialist. Technical development directed to the specialist should
follow as needed (at most ten pages).

They should be accompanied by a fact sheet indicating the following:
- Title of the paper with the relevant conference theme(s);
- Author(s) with affiliation, address, phone and fax numbers, E-mail.

Proceedings will be available at the conference.

IMPORTANT DATES

Submission deadline May 2, 1994
Acceptance notification June 17, 1994
Camera ready paper due August 13, 1994
Conference October 24 - 26, 1994

THEMES

TECHNOLOGY
IC architecture and techniques
Memories and processor design
Read/Write unit engineering
Specific co-processors for cryptography
Biometry
Communication technologies
Interfaces with the owner, the service suppliers
Reliability and fault tolerance
Special devices
Standards
SOFTWARE
The operating system
Models of data management
Communication protocols
IC CARD DESIGN
IC cards formal specification and validation
Tools for internal or external software production
Validation and verification
Methodology for application design
SECURITY
Models and schemes of security
Algorithms
Security interfaces
Hardware and software implementation
Security of information systems including cards
Formal verification of transaction sets
IC CARDS, INDIVIDUALS AND THE SOCIETY
IC cards and privacy
Access to his data by the owner
IC cards: political and economical aspects
Is the IC card going to change regulation?
Patents, copyrights
FUTURE OF THE IC CARDS
Innovative technologies
Moving towards the pocket intelligence
Convergence with portable PCs, laptops etc ...
PCMCIA
INNOVATIVE APPLICATIONS
Design methodology of applications
IC cards and the information system
Examples of new applications
Requirements for innovative cards

ORGANIZATION

General Chairman Program Chairman
Prof. Vincent Cordonnier Prof. Jean-Jacques Quisquater
RD2P Universit'e Catholique de Louvain
CHRU CALMETTE Dept. of Electrical Eng. (DICE)
Rue du Prof. J. Leclerc Place du Levant, 3
F - 59037 LILLE CEDEX B - 1348 Louvain-la-Neuve
FRANCE BELGIUM
Tel (33) 20 44 60 47 Tel (32) 10 47 25 41
Fax (33) 20 44 60 45 Fax (32) 10 47 86 67
e-mail: [email protected] [email protected]

Program committee
Mart'in Abadi (Dec Research, USA)
Ross Anderson (Cambridge, UK)
Benjamin Arazi (Ben-Gurion, Israel)
Todd Arnold (IBM, USA)
Jacques Berleur (FNDP, Belgium)
William Caelli (Queensland, Australia)
David Chaum (DigiCash, Netherlands)
Vincent Cordonnier (Lille, France)
Mark Cummings (SRI, USA)
Amos Fiat (Tel-Aviv, Israel)
Andr'e Gamache (Quebec, Canada)
Marc Girault (SEPT, France)
Louis Guillou (CCETT, France)
Joseph Hoppe (TRT Philips, France)
John Kennedy (Cylink, USA)
Philippe Maes (Gemplus, France)
Roger Needham (Cambridge, UK)
Jean-Jacques Quisquater (Louvain-la-Neuve, Belgium)
Laurent Sourgen (SGS-Thomson, France)
Doug Tygar (Carnegie-Mellon, USA)
Michel Ugon (Bull-CP8, France)
Klaus Vedder (GAO, Germany)
Robert Warnar (NIST, USA)

The city of LILLE is about 150 miles away from PARIS. It can be reached : from
Paris by either motorway (two hours) or train (one hour). From most European
countries by train, motorway or plane. The conference will take place at the
University of Sciences and Technology of Lille. Accommodation can be provided
either on the campus or in the center of the Lille. We will provide maps and
help for hotel reservation and travels.

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

Date: ongoing
From: [email protected]
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 <[email protected]> (Dennis
Rears). UK subscribers please contact <[email protected]>.
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 <[email protected]> (not automated).

CONTRIBUTIONS: to [email protected], 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>
GET RISKS-i.j<CR>" (where i=1 to 15, j always TWO digits) for Vol i Issue j.
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 [email protected] 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 [email protected] .

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

End of RISKS-FORUM Digest 15.56
************************