Subject: RISKS DIGEST 17.32

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

RISKS-LIST: Risks-Forum Digest Weds 6 September 1995 Volume 17 : Issue 32

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

***** See last item for further information, disclaimers, etc. *****

Contents:
Mispelcorekters (Thiomir Glowatzky via Martin Virtel)
Bogus check for $95,093.35 deposited and retained! (Alan Wexelblat)
Voting by Phone in the Netherlands (Alex van Es via Clive D.W. Feather)
Automated bridge risk (Erkka Sutinen)
Another "Units" crash... (David Lesher)
Mass Pike Electronic Toll Collection Update (Rich Lethin)
MS-Word "Find File" feature scales poorly with MAE/NFS (Jeff Anderson-Lee)
10 Arguments Against Commercial Key Escrow (CKE) (Marc Rotenberg)
Pittsburgh HOV Follow-up (Chuck Weinstock)
White house "hack" (Martin Virtel)
US White House Hacked? sendmail or SMTP? (Matt Bishop)
Re: newspaper risks (Dan Gillmor)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: Wed, 6 Sep 95 8:01:30 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Mispelcorekters

Martin Virtel wrote a wonderful article "Fehler, Fehler, Feler" in
Die Zeit (Nr. 33, 11 Aug 1995, page 49) observing the 10th anniversary
of RISKS. The following item came to him as a response from a
German teacher, Thiomir Glowatzky, of Bamberg. I include the German,
with "u umlaut" being represented as "|", but the essence of it is simply
that the spelling corrector wanted to replace

Kafka, Musil and Schnitzler

with

Kaffee, M|sli, and Schnitzel.

It must have been from Hungery. PGN

>From: [email protected] (Martin Virtel, tel/fax +49-8421-80995)

"Die auf dem PC getippte Arbeit setzte mein Sch|ler einem
Rechtschreibprogramm aus, ohne die darin vorkommmenden Schriftstellernamen
Kafka, Musil und Schnitzler ins Programm aufzunehmen. Er wunderte sich,
als beim Ausdruck 'Kaffee', 'M|sli' und 'Schnitzel' auftauchten."

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

Date: Wed, 6 Sep 95 10:39:51 -0400
From: Graystreak <[email protected]>
Subject: Bogus check for $95,093.35 deposited and retained!

RISKS readers may be interested in the story to be found on the web at
http://www.dnai.com/g-think/$$tablecontents.html

It tells of a man (Patrick Combs) who, according to himself, deposited into
an ATM a "check" for $95,000. This "check" was one of the authentic-looking
come-on gimmicks that we so often receive in our junk mail. In this case,
it was a solicitation for a get-rich-quick scheme and the "check" was
purportedly an "example of the kind of money" one could earn using this
scheme.

The "check" bore a valid signature and account number as well as a realistic
amount ($95,093.35). The only indication that it was not a valid document
was the phrase "not negotiable for cash" inconspicuously placed in a corner.
More interestingly, the "check" met all nine of the legal criteria for a
valid bearer document.

Apparently, the warning message was not seen and the amount was credited to
Mr Combs' account. The amount remained in his account for several weeks
and, after repeated inquiries to the bank Combs withdrew the money in the
form of a cashier's check, which he then placed in a safe-deposit box.

Throughout the story, Combs maintains that he had/has no fraudulent intent.
The fact that he has not spent a cent of the money despite ample opportunity
to do so lends credence to his claim. Eventually, of course, the bank
detected the error and demanded its money back. Its method of treating Mr
Combs will be familiar to many of us who have had to deal with inflexible
financial institutions.

However, the story is complicated by the fact that (by both law and many
legal precedents) Mr Combs is now legally entitled to keep the money. Banks
must refuse payment within a fixed time period and must serve notice in a
specific manner, both of which Combs' bank has failed to do. The story
details his research into the legal side of it, as well as his negotiations
with the bank.

In reading this story, a number of RISKS-related issues came to my mind:
- Combs apparently ascertained that none of the bank tellers would
be held liable for the fault, since the "check" was deposited into
an ATM. But *someone* had to open those envelopes and verify the
data.

- Combs comments that he was under the impression that checks of
greater than a certain amount were subject to additional
verification. That clearly did not happen here. Why? No
information is given in the story as to what part of this process
is manual and what is automatic.

- Through a bit of social engineering, Combs claims to have traced
the flow of the money: apparently his bank got the money from the
clearinghouse bank in Chicago (which also missed the
non-negotiable warning). It was not until the "check" was sent to
the Federal Reserve bank that it was rejected; the money was then
retrieved by the Chicago bank from Combs' bank which no doubt
assumed it could get the money back from Combs. However, they
waited 16 days from the time they received notice of their error
and by that time the money was gone from Combs' account. Who was
responsible for generating notice to Combs? How did they fail to
take action? Again, it is unclear how much, if any, of the bank's
procedures are automated.

- There is also a social RISK in that the bank's treatment of Combs
has clearly exacerbated the problem and generated a good deal of
cost and negative publicity for the bank (as well as the obvious
monetary loss). Banks, despite being in a customer service
business, have gained a widespread reputation for inflexibility
and for gouging customers for ever-increasing charges and fees.
Combs asks readers to suggest what he should do, and opinion is
clearly against the bank. As new digital technologies make cash
and location less important, banks RISK putting themselves out of
business altogether if they are not seen to be serving their
customers.

It seems clear that a large number of procedures must have broken down in
this story. It is also interesting that the Federal Reserve, which deals
with a much larger volume of paper, was able to catch an error that two
local banks did not catch. I confess that I voted for Combs to keep the
money or give it to charity, in large part because of my reaction to the way
the bank treated him and how I have been treated by banks in the past.

I hope RISKS readers find the story interesting and worth their time to
investigate.

Alan Wexelblat, Cyberspace Bard, MIT Media Lab - Intelligent Agents Group
617-253-9833 [email protected] http://wex.www.media.mit.edu/people/wex/

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

Date: Wed, 6 Sep 1995 09:49:57 +0100 (BST)
From: "Clive D.W. Feather" <[email protected]>
Subject: Voting by Phone in the Netherlands

Seen in Telecom Digest (aka comp.dcom.telecom):

> Date: Mon, 4 Sep 1995 16:36:54 +0200
> From: [email protected] (Alex van Es)
> Subject: Voting by Phone in the Netherlands
>
> Every four year there are elections in the Netherlands, and because of
> different reasons (bad weather or having to work) many people never
> even bother to go to the polling booth. In order to make voting easier
> the Dutch government made it possible last year for people who live in
> the city of Utrecht to vote at the railway station, so they would be
> able to do it on their way to work. Yet, many people don't travel by
> train to work, and even if they do, they might not have the time at
> the railway station to stand in line. Therefor the government is
> currently considering the option of voting by phone. People who decide
> to vote by phone will have to call a special access number. The
> number will be one of a 06 (900 type) kind, leading to the call
> factory in Rotterdam. The call factory is a special exchange for
> handling up to 1,6 million phone calls an hour. At this moment most
> time is invested in making sure the system is safe, and fraud will not
> be possible. If this system is going to be used in the future, the
> Netherlands will be the first country to make televoting for
> parliamentary elections possible.
>
> Alex van Es [email protected], Apeldoorn, The Netherlands +31-55-421184
>
> [TELECOM Digest Editor's Note: Suggestions -- and for that matter, full-
> bodied, substantial proposals -- regarding 'vote by phone' have been
> made here in the USA also, but nothing has come of it. All the usual
> excuses ('there would be too much fraud', etc) have been tossed out as
> reasons it would not work, even though fraud prevention techniques have
> been provided. Then there were the privacy freaks who insisted that
> the tighter the fraud controls, the more likely there would be massive
> invasions of privacy in the 'voting booth' if controls were established
> identifying the phone number being used and some other personal identifier
> such as social security number, etc. They can't seem to understand that
> there *are* ways to identify the user and validate his *right to vote*
> without necessarily examining the vote being cast. Nor can they seem to
> understand that there are competent programmers who share a love for
> their country and a sense of patriotism which would develop the needed
> software in an instant -- as fraud-proof and fool-proof as the present
> manual system if not more so -- if it meant that more Americans would
> participate in the process. They would do so with a sense of integrity
> and ethics which would *never* willfully violate anyone's privacy.
>
> Even starting on a small scale for 'beta testing' purposes seems to be
> out of the question. The Chicago Board of Election Commissioners (an
> independent government agency responsible for administering elections of
> all sorts within the city) has been shown how telephone voting, either
> with modem and computer or by touch tone buttons alone) would work quite
> well. They have been shown how, with the cooperation of the banking
> network, voting could be done at any ATM machine. Of course *not everyone*
> has an ATM card, and of course *not everyone* has a computer and modem,
> but these would be two additional ways of 'getting out the vote'. They
> have been shown how even in conventional voting booth arrangements, a
> terminal hooked to their central computer could be used to eliminate a
> huge amount of manual tabulating required, and the fraud that can accompany
> same, to say nothing of being able to eliminate many of the 'middle-man'
> election judges found at each polling place.
>
> They'll hear none of it ... which is odd, considering how desperate they
> are getting to find voters these days. They do registrations now at all
> sorts of places -- even at the Cook County Jail where they always get
> *thousands* of voters each year for selected candidates -- just to round
> up anyone they can who is willing and wants to bother to vote. They keep
> harping on the fraud problem using phone voting, but believe me you,
> nothing compares to the fraud we have here now with the crooked election
> judges and the low-level Democratic politicians who hang around the
> polling places on election day, bringing in voters by the bus load from
> old-people's homes, etc. We could have had tele-voting here years ago had
> they wanted it. As they say in Chicago, 'vote early and often!' PAT]

Clive D.W. Feather, Demon Internet Ltd, 322 Regents Park Road, Finchley,
London N3 2QQ [email protected] Tel: +44 181 371 1000

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

Date: Thu, 31 Aug 1995 21:26:34 +0300 (EET DST)
From: Erkka Sutinen <[email protected]>
Subject: Automated bridge risk

(I was absent of the town at the time of this event, so there may be some
errors, but the core is solid.)

This week Kuopio, a small town in Finland faced sudden problem with
automated bridges.

The town is located in the middle of a lake district, wonderful
transportation method during past centuries but a problem if you use cars
instead of boats. The only way from the town to north (to airport among
other places) is through one bridge, which has one (small) openable bridge
for boats.

Suddenly one morning the bridge, which (as you may have guessed) is
computer-controlled, opened without any reason in the middle of the morning
rush. No-one going to work could get anywhere in the north side of the town.
The bridge was not manned (since it was not in use at that moment) and it
took some time to get anyone there. The bridge computer didn't do anything
and there was no manual button to force closing of the bridge(!!!!!).

The bridge had to be closed by hand, using crank, by several strong men
turning the wheels. Interviewed representative said that the situation
occurred due to "unpredicted combination of events" (what else :-}) if my
memory does not fail me. (What events they were, I haven't heard of.)

The risk is old and well-known on this list: Automation of something
without leaving backup-system.

The good side is that the automatic lights and fences connected to
the bridge-system worked well and warned people that the bridge is
raising, so there was no risk to people.

Erkka Pietari Sutinen University of Oulu, Finland
Dept. of Information Processing Science [email protected] / [email protected]

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

Date: Thu, 31 Aug 1995 10:19:55 -0400 (EDT)
From: [email protected] (David Lesher)
Subject: Another "Units" crash...

The NTSB ruled that human error augmented by fatigue probably caused the
crash of a DC-8 cargo plane Feb. 16 at Kansas City International Airport,
killing all three crew members. [...] The NTSB found the pilot lost
control of the DC-8 on takeoff, mainly because the flight engineer used
the wrong calculations to determine how fast to supply power to the
engines. The engineer based his calculations on Fahrenheit temperatures
instead of centigrade as he should have. [Excerpts from AP reports]

RISKS readers will recall the Gimli incident in Canada where another metric
conversion error led to a shorter-than-expected flight.

As often pointed out by my EE prof's, calculators let you get the
wrong answer 10 times as fast....

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

Date: Thu, 31 Aug 95 13:45:38 EDT
From: [email protected] (Rich Lethin)
Subject: Mass Pike Electronic Toll Collection Update

I was listening to Boston rock-and-roll station last week when I heard an
advertisement criticizing the Mass Pike's RFP for an electronic toll
collection system. I called the company, ATCOMM, based in Marblehead,
Massachusetts and spoke with Mike Greenstein to get details:

Recently, the Mass legislature passed a law requiring the Pike to develop
standards for electronic toll collection. The Pike responded with a Request
for Proposals (RFP) which substantially narrowed the allowable technical
solutions.

The Pike's RFP specifically wants to have a centralized accounting
mainframe. As the driver approaches, an electronic tag (about the size of a
pack of cards) is polled and this is used to debit his account. The user's
balance is displayed by the tool booth as the driver goes through.
Information about the user's movements are entered immediately to the
centralized database.

ATCOMM sells a technology which adds a keypad, microprocessor, and an LCD
display to the tag. The keypad allows the user to ask questions about his
balance at any time, and the LCD displays the remaining balance. ATCOMM's
technology was specifically excluded by the narrow RFP and so the decided to
go to the radio campaign to make their case, alert the drivers and other
stakeholders that this is an issue.

I asked Mr. Greenstein about the motivation for the Pike's RFP and he was
unwilling or unable to speculate.

The Mass Pike is a quasi-independent agency by virtue of its bond contracts
and independent of governmental oversight. The Pike has been a source of
patronage jobs with mutual backscratching between the Democratic party
government officials and the Pike's authorities. However, recently, Gov.
Weld has moved to bring the Pike under government control and this will take
place Summer next year.

According to Mr. Greenstein, there's no concern for privacy of drivers, and
this does not appear to have been the Pike's motivation for issuing the RFP
calling for a centralized database. ATCOMM could be programmed to ensure
privacy, but currently it is not. There's some small benefit to ATCOMM's
technology, because the information about the movements of specific cars
through the tolls is not centralized, but kept at the toll facility.
However, this can be collected periodically so there's little difference
from the centralized scheme. Probably, privacy is not a big selling point
for companies making proposals to governmental RFPs.

Concurrent VLSI Arch. Group 545 Technology Sq., Rm. 610
MIT AI Lab Cambridge, MA 02139 (617)-253-0972

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

Date: Thu, 31 Aug 1995 14:40:54 -0700
From: Jeff Anderson-Lee <[email protected]>
Subject: MS-Word "Find File" feature scales poorly with MAE/NFS

Macintosh Application Environment (MAE) is a product that runs on Sun and
Hewlett-Packard workstations, emulating a Macintosh computer under
X-Windows. It allows 680x0 based Macintosh applications to run on the
workstation accessing the Unix filesystem (including NFS partitions) as if
they were folders and files on the Mac.

Recently, a secretary who was new to the Mac environment tried to access a
file she had saved from her mailer in Unix from MS-Word under MAE. She knew
what the name of it was, but wasn't sure *where* it was, so, when she saw
the "Find File" feature in the "Open File" dialog box thought that she would
try it...

Unfortunately, the workstation was connected to a 256GB NFS fileserver which
MS-Word under MAE dutifully began to search. Furthermore, neither MAE nor
MS-Word made it apparent how to cancel the request once it was set into
motion. (Alt-'.', which often works in a Mac environment did nothing.)
Even stranger, the X11 window manager ceased to respond to requests to
pop-up the window's menu to close it.

Fortunately, there were still some Unix windows around to "kill" the MAE
process--but at a loss of any unsaved information created previously in the
MAE session.

The RISK? Perhaps that scale factors were not considered in the design of
the "Find File" feature. The Mac Style Guide states that all applications
must confirm operations that are either not "undoable" or which may perform
extensive changes. Perhaps a similar rule should apply: all operations
which may take an extensive amount of time to complete should include a
status window with a cancel operation.

Or perhaps, the cancel operation *does* exist, but by the time I got there
the X display server was not refreshing the "exposed" regions on the MAE
window (after having been covered and uncovered) so that only a rapidly
changing filename was visible in the middle of an otherwise blank region of
the screen... In that case, the RISK may be in reliance of X-Windows or
other software emulation to reliably reproduce the emulated hardware
environment.

Jeff Anderson-Lee [email protected]

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

Date: 31 Aug 1995 17:26:59 U
From: "Marc Rotenberg" <[email protected]>
Subject: 10 ARGUMENTS AGAINST COMMERCIAL KEY ESCROW (CKE)

1. Increased network vulnerability. The key escrow configuration
necessarily increases the likelihood of communications compromise and
improper interception by third parties. Computer crime will skyrocket.

2. Policy incoherence. The key management needs of business differ sharply
from the real-time intercept plans of law enforcement. The latter has little
to do with the former.

3. Emergency circumstances taps. The current wiretap law permits the
initiation of a wiretap *without court order* upon a certification that
emergency circumstances exist. If this procedure is built into the CKE
procedure, then there will be *no judicial review* prior to the disclosure
of keys.

4. Complexity. Has anyone really given thought to how many communications
will be encrypted in 20 years and what the key management requirements will
be to develop a unitary key escrow system to satisfy the government's
concerns? Its staggering.

5. Cost-benefit. The Bush White House rejected the original digital
telephony bill for this reason. As time has passed, the argument has
strengthened. The cost to match each new technology with an intercept
capability is rising rapidly. The benefits of wiretap are falling.

6. Intrusiveness. How will the government monitor compliance by escrow
agents and crypto users with statutory requirements? Will separate
penalties exist for escrow agents and key holders who negligently fail to
comply with procedures even though there is no evidence of criminal conduct?
If so, law enforcement could "pull over" anyway on the info highway who is
using crypto (the broken tail light problem).

7. The future of PGP. Will PGP and other non-escrow schemes be permitted if
CKE is adopted? What will be the implications for developers and companies
in the communications industry? The

8. Ability to Defeat. It will be trivial to send non-interpretable
communications in a key escrow network -- foreign dialect, bury text in
graphics, speak in code! The bad guys know all about this. They've assumed
their phones were tapped for years.

9. The Long Term. Where does the CKE policy take us in 20 years? A secure
network where crime is more difficult or a platform for surveillance of
private communications and compromise of business information?

10. Oklahoma City. For more than a year, the White House warned that if
Clipper was not adopted terrible terrorist incidents on US soil similar to
the World Trade Center could not be prevented. Guess what? It happened and
Clipper, CALEA and all these other dumb ideas didn't prevent the deaths of
170 innocent people. The FBI hadn't even bothered to request a wiretap
warrant for this type of threat (arson, weapons, explosives) since the late
1980s.

Marc Rotenberg Electronic Privacy Information Center (www.epic.org)

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

Date: Wed, 30 Aug 95 11:30:58 EDT
From: Chuck Weinstock <[email protected]>
Subject: Pittsburgh HOV Follow-up

A couple of follow-up items regarding the recent head-on crash on
Pittsburgh's HOV lane.

A Pennsylvania Department of Transportation worker has admitted that he made
a mistake and opened the northbound gate before closing the south- bound
gates. There is no interlock of any sort to prevent this. The worker in
question has been fired.

There apparently is still some question as to whether this led to the accident
or not.

I mentioned some dual-use ramps downtown. One of the ramps in question
(near Three Rivers Stadium) actually is a single ramp with an exit and an
entrance. When the entrance is officially closed there is a barrier across
it. To enter erroneously (if the barrier is in place) one has to make an
extremely acute right hand turn onto the exit ramp (or be traveling the
wrong way on the major street surrounding the stadium.) I view this as no
different than the arrangements on many such lanes around the country (e.g.,
the express lanes on the Kennedy Expressway in Chicago.) The other downtown
ramp in question is at Anderson Street, and as best I can tell from the
photos is a true dual use ramp. There is no possibility of a barrier at
this location.

Chuck Weinstock

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

Date: Thu, 31 Aug 1995 06:12:00 +0200
From: [email protected] (Martin Virtel)
Subject: White house "hack" (Re: RISKS-17.31)

Just to clarify: the attack method reproduced on page 185 of the September
1995 issue of C'T (which allegedly lead to forged mail
From: <[email protected]>) is the telnet-to-sendmail-type mail
forgery attack described many times, i.e. in alt.2600.faq available from
[email protected] among others.

In my eyes, using the old sendmail on one hand and banning the export of
software capable of message authentification (this is, PGP) on the other
makes up to a pretty bad (this is, risky) policy regarding electronic
exchange of information.

One more thing: does anybody around have a CCopy for me
([email protected]) of a newsgroup posting send through the white
house mail server?

Martin Virtel <[email protected]> tel/fax +49-8421-80995

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

Date: Thu, 31 Aug 1995 14:08:45 -0700
From: Matt Bishop <[email protected]>
Subject: US White House Hacked? sendmail or SMTP? (Kennedy, RISKS-17.31)

The article "US White House Hacked?" describes a series of forged messages
sent to computer users; the sender was supposedly Bill Clinton. It then
describes the reaction to it, including a dispute about whether the White
House computer was broken into and the forgeries sent from it.

What surprised me the most was the assumption that sendmail had been used or
even that a break-in had occurred. Why? In 1985, we forged a letter from
Opus the Penguin at whitehouse.arpa (which didn't exist) to our office staff
asking for more kippered herring heads at our weekly meetings. (Those
meetings were in the bloomin' county ...) All it takes is knowing the SMTP
protocol, and being able to access port 25. So, given the information in
the article, I'd go with Occam's Razor and assume someone did it that way.

['Occam dead, Matt!]

In particular, this part:

He claimed the White House uses an old version of software for electronic
mail handling which is obsolete. This program makes it possible to falsify
mail. Many other System Administrators also use this older version,
leaving the network vulnerable to similar attacks.

was somewhat depressing; I would think the editor of a computer magazine
would know better than to assert mail forgery is due to an "old version of
software" and not due to the nature of the underlying protocols.

Matt

[And Malte Borcherding <[email protected]> sent me a message From:
Bill Clinton <[email protected]> just to remind us that one
does not have to hack the White House. PGN]

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

Date: Wed, 30 Aug 1995 14:17:49 -0700 (PDT)
From: Dan Gillmor <[email protected]>
Subject: Re: newspaper risks

Misdirected stories and headlines are, of course, not new. The Boston
Globe is famous for its headline, over an editorial about then-President
Carter's economic policies, which said: "Mush from the Wimp."

Dan Gillmor, Computing Editor, San Jose Mercury News, 750 Ridder Park Drive
San Jose, CA 95190 [email protected] 408-920-5016 Fax: 408-920-5917

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

Date: 5 September 1995 (LAST-MODIFIED)
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 (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>). 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, THEN please send requests to
the newly automated <[email protected]>, with first text line
SUBSCRIBE or UNSUBSCRIBE
[with option of E-mail address if not the same as FROM: on the same line].
HELP
gives instructions on using the Majordomo listserver in other ways,
although not all are implemented for RISKS. ** UNSUBSCRIBE is not yet
automated for early subscribers, as Majordomo is not yet fully installed.

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.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html [yes, VL = volume, IS= issue]
(Please report any format errors to [email protected] .)

RISKS ARCHIVES: ftp://unix.sri.com/risks if your browser accepts URLs, or
ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP;
Issue J of volume 17 is in that directory: "get risks-17.J<CR>". For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 16, J always TWO
digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>" I and J are dummy variables here. REMEMBER,
Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password. Also ftp [email protected]. WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen. Use wisely.

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

End of RISKS-FORUM Digest 17.32
************************