Subject: RISKS DIGEST 16.50
REPLY-TO:
[email protected]
RISKS-LIST: RISKS-FORUM Digest Tuesday 25 October 1994 Volume 16 : Issue 50
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), disclaimers *****
Contents:
Another way for computer failure to delay trains (Mark Brader)
Bank Robber Foiled by Security Screen (Paul Gillingwater)
Re: Ignorance in Computer Science (Roy Maxion)
Re: Don Norman and the Power switch (William Hugh Murray)
Re: deadly risk (Scot E. Wilcoxon)
Re: Cell Phone Fraud Countermeasures (Bill Hensley)
Re: Badly designed interface in MS Mail (Russell Stewart)
Re: Inadvertent postal forwarding (Kent J Quirk)
Re: Data security in Iceland (Curtis Jackson)
Mailing lists risk critical-mass spamming (Benjamin A Ostrowsky?)
Sears takes digitized signature for CC transactions (Steve Holzworth)
Re: CNID (Lauren Weinstein, Michael D. Sullivan, Tim Duncan,
B.M. Cook, J. Eric Townsend, Michael Jampel, Mark Stalzer,)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: Tue, 25 Oct 1994 18:15:21 -0400
From:
[email protected] (Mark Brader)
Subject: Another way for computer failure to delay trains
Operational notices for the US passenger rail service Amtrak are now being
posted to rec.railroad, and I spotted this item in one of them:
Termination of Train 352(19) at Detroit, MI
1045pm, ET train 352(19) diesel 359, CC 9649, 3 cars, arrived
Detroit on time. Train was terminated due to no engineer was
available to handle train to Toledo due to a Crew Management
System failure. Regular man had called in at 245pm, ET, and
advised was having automobile trouble and would not make train and
marked off. Crew Management advised was having computer failure
but engineer had marked off prior to the computer system outage.
Investigation to be scheduled. Passengers were handled via
alternate transportation to Toledo. Equipment was deadheaded to
Toledo when relief engineer was called.
Delay: 352(19) term. passengers delayed 1'05"
Notations: MI = Michigan, ET = Eastern Time, 352(19) = train number 352
on the 19th of the month, engineer = driver, 1'05" = 1 hour 5 minutes.
Mark Brader SoftQuad Inc., Toronto
[email protected]
[Presumably, the relief engineer was not a grateful deadhead. PGN]
------------------------------
Date: Wed, 26 Oct 1994 00:20:16 +0100
From: Paul Gillingwater <
[email protected]>
Subject: Bank Robber Foiled by Security Screen
A New Zealand newspaper, "Waikato Times", for Sept. 2, 1994, reports a
coroner's court finding that a bank robber in Sydney (Australia) died after
being trapped for more than 15 minutes by a 250-kg steel security screen,
which rose to the ceiling and trapped him by the throat.
The screen had been activated by staff in July 1991, whilst the robber was
crawling across the counter. The robber, Steven Kovacs (age 37), died of
asphyxiation.
The risk? When designing control systems for steel bullet-proof security
screens that actuate in less than half a second, consider what happens if
someone is in the way!
[email protected] (Paul Gillingwater) :: Home Office in Vienna, Austria
[I suppose this would be more computer-related if it were
triggered automagically, but it is still certainly RISKful. PGN]
------------------------------
Date: Tue, 25 Oct 94 19:11:44 EDT
From: Roy Maxion <
[email protected]>
Subject: Re: Ignorance in Computer Science (Goland, RISKS-16.49)
> ... we have no such thing as 'human engineering classes', 'interface design
> classes', or 'software management' classes. ...
I hope you will be pleased to note that here at Carnegie Mellon I am teaching
just such a course. It's called Dependable System Design, and it's mission is
to teach students how to design/implement/evaluate dependable systems so that
we see fewer problems of the kind recently described in RISKS. Excerpts from
the course description follow:
System dependability has been a major concern since the dawn of the
electronic computer age. Dependability, taken in its broadest context,
includes metrics such as reliability, availability, testability,
maintainability, usability, mean time to failure, etc.
...
The goal of dependable system design is to ensure that the system continues
to deliver its specified service to the client even in the face of error on
the part of the user, the system or the environment.
...
User interfaces, while just as critical for dependability as reliable
hardware and software, have received little attention from the dependability
and fault-tolerance community. Because the philosophy of dependable system
design crosses the boundaries of hardware, software and user interfaces, a
major portion (but not all) of the course will focus on the most recently
critical aspect of dependable systems: user interfaces and user-system
communication.
...
Upon completion of this course, the student should be able to: acquire
system requirements, develop system specifications embodied in one or more
dependability metrics; critique an initial design; identify weak portions of
a design; suggest a variety of alternatives to improve dependability; use
contemporary techniques to evaluate, compare and contrast alternative
designs, conduct system-evaluation experiments, and produce balanced,
cost-effective system designs.
...
Topics include: Theory and practice of traditional dependability; robust
benchmarks and fault injection; dependable user interfaces; experimental
design; concepts of reliability and validity; system evaluation techniques;
requirements acquisition; human error and reliability - causes, effects and
mitigation; system monitoring, diagnosis and data analysis; task analysis.
Dependability Motto:
Anyone can build something that works when it works.
But it's how it works when it doesn't work that counts.
Roy Maxion Computer Science Dept. Carnegie Mellon University
[And WHO'S counting? PGN]
------------------------------
Date: Tue, 25 Oct 94 15:21 EST
From: William Hugh Murray <
[email protected]>
Subject: Don Norman and the Power switch
Don's tale of woe reminded me of my colleague who was assigned the task of
standardizing keyboards across IBM.
And they wonder why we security people cannot decide on safe defaults.
William Hugh Murray, New Canaan, Connecticut
[DeFault is easy to assign. But don't
Pin the Tale on the Don Quixote.
BTW, Don Norman says he has NEVER had so many responses to any of his
previous RISKS submissions as he had on the power-switch posting.
He must have pushed a lot of your buttons. PGN]
------------------------------
Date: Sun, 23 Oct 94 17:38 CDT
From:
[email protected]
Subject: Re: deadly risk
>... electrocauterizer had apparently corrupted the software of her micro-
>processor-controlled pacemaker ... I believe the risk here is pretty obvious.
Yes, it is obvious that the woman might be in danger whenever she is near loud
music. I hope they don't really use AUDIO tones.
A less deadly risk is assuming that experienced RISKS readers can only find
one risk.
Scot E. Wilcoxon
[email protected] +1 612-936-0118
------------------------------
Date: Sun, 23 Oct 1994 00:48:49 -0500 (CDT)
From:
[email protected] (TRW)
Subject: Re: Cell Phone Fraud Countermeasures
A recent post described a TRW effort to use technical means of defeating
cellphone fraud, and was described as voice print recognition. FYI, the
actual method stores the electronic signature of the telephone instrument
transmitter. A cloned phone will have a different transmitter signature and
calls from that phone will be blocked. This system has been described in some
detail in Communications Week, and several other trade journals (that's where
*I* get my info :)
Bill Hensley, TRW Oklahoma City Engineering Office
[email protected]
[email protected] 405.732.3433 (v) 405.737.2043 (f)
------------------------------
Date: 24 Oct 1994 19:08:14 GMT
From:
[email protected] (Russell Stewart)
Subject: Re: Badly designed interface in MS Mail (Astoorian, RISKS-16.46)
>... Since "New Password" and "Re-Enter New Password" were both
>empty (and thus matched each other), pressing OK set her password to the
>null string without her realizing what had happened.
This is extraordinarily stupid on Microsoft's part.
I have only been programming for about 6 months now (and only with Visual
Basic), but one of my fundamental rules is to NOT allow the user to leave
a dialog box until he or she has supplied all required information (or,
in the case of something ambiguous, like an empty password, at least ASK
the person before moving on).
If anyone finds the programmer responsible for that mistake, he should be
taken out and shot (and then dug up and shot again).
------------------------------
Date: Sat, 22 Oct 1994 00:13:52 -0400
From:
[email protected] (Kent J Quirk)
Subject: Re: Inadvertent postal forwarding (Bove, RISKS-16.48)
In RISKS-16.48, V. Michael Bove Jr. writes about a post-office forwarding
problem. We had a similar problem once. My wife once ran a small business
called Engineering Services Group. When we moved, she forwarded mail to our
new address. One of the mailing lists she was on was at Hewlett-Packard (HP).
HP got the change of address notice, and (apparently) maniacally changed
*every* occurrence of Engineering Services Group in their list to our new
address. As you might imagine, several companies have an ESG as an internal
group -- something like this:
H. Dilbert Gweep
Graphic Doodler
Engineering Services Group
Habeas Corp.
Anytown, OH, 00666
All 25 of these people suddenly stopped getting their 6-color HP spreads on
90-pound stock. All 25 copies suddenly started arriving in our mailbox with
disconcerting regularity, each one with a different name.
The hard part was getting HP to turn the bloody thing off. The 800 numbers
printed on the literature were useless. I finally found a person named on the
masthead of some "magazine", and called her directly. After several
cross-country phone calls, she eventually managed to reach someone who could
(and did) make it stop.
The risks? Besides the danger of herniated homeowners and mail carriers,
there are 25 people out there who are no longer on a mailing list they might
have actually wanted to be on. I doubt HP kept their old addresses lying
around. Imagine if her company had been named "Engineering Department", or
worse yet, "Craig Shergold".
Kent
(For the urban-legend-impaired, Craig Shergold is the now-grown English boy
who no longer wishes to receive a world-record number of postcards.)
Kent Quirk 7 MacLeod Lane Acton, MA 01720 508-263-8344
[email protected]
------------------------------
Date: Sun, 23 Oct 1994 00:38:33 GMT
From:
[email protected]
Subject: Re: Data security in Iceland (Haynes, RISKS-16.47)
}... If only we could get the story to be spread and repeated as well as the
}Craig Shergold plea and the gold star tattoo urban legend!
If you could, it might make a difference to the small business people, but
might not make a difference to an individual.
Back in the "good old days", hard drives were small enough that backup to
floppies was feasible on a regular basis, and it was therefore cheap.
Today, I have a 1GB external disk on my Mac that I use for all my work,
including lots of transitory data that I don't care about, and I backup the
things I do care about to my internal 230MB drive. If my computer is stolen, I
will certainly lose everything.
Am I naive? Stubborn? Stupid? Well, possibly. But my motivation in this case
is cost. Unlike IBM-compatible PCs, sizeable removable media backup systems
for Macintoshes are extremely costly. It is *much* cheaper to simply keep
buying bigger and bigger hard drives, and use the older smaller one for backup
and the newer larger (and faster) one for main use.
I am choosing not to "pay for full coverage insurance" for cost reasons; I am
protected if my main hard disk dies an untimely death, but not if all of my
computer equipment is stolen.
Consider it a RISK of one technology far outstripping another technology on
which the first is dependent. Non-removable media cost per MB, speed, and even
reliability have far out- paced that of removeable media.
Curtis Jackson
[email protected]
------------------------------
Date: Sat, 22 Oct 1994 00:37:13 -0400
From: <
[email protected]>
Subject: Mailing lists risk critical-mass spamming
At what point is it worth a lawyer's time to spam the net? A certain
size of audience must be reached, and easily. Public mailing lists risk
presenting an easy way to spam.
Many lists accept posts from non-subscribers. One need only know
that the list exists and where to send contributions. It would be a simple
task to poll ten thousand LISTSERVs for a list of lists. Having compiled
such a listing, one could then send one's advertisement into several
hundreds of thousands of mailboxes.
A more pointless exercise, and one which would cause even greater
havoc, is to set up a LISTSERV list on one's own system which would link
every list to every other list. It takes no imagination at all to see
how quickly this would create a logjam.
------------------------------
Date: Tue, 25 Oct 1994 07:55:55 -0400 (EDT)
From: Steve Holzworth <
[email protected]>
Subject: Sears takes digitized signature for CC transactions
A few days ago, I was in the local Sears store (Cary, N.C.). I was purchasing
a few items and decided to charge them against a Visa card. The clerk
dutifully rang in the charges. While she was doing that, I noticed that a
small digitizing tablet was attached to the register. I had a feeling I new
what was coming next...
She pulled the receipt out of the register, slid it under a hold-down on the
tablet, and instructed me to sign within the little plastic guide. I refused,
stating that I would gladly sign the receipt, but not on the tablet.
Apparently, I was the first to refuse :-) She had to look up a magic phone
number, ominously entitled "Loss Prevention", to determine what to do. The
person on the other end OK'd my signing without having my signature digitized.
Some might argue that my refusal was meaningless because Sears could always
scan my signature from the receipt. Maybe so, but nothing says I have to make
it easy for them. Small encroachments eventually lead to large losses.
Steve Holzworth SAS/Macintosh Development Team SAS Institute Cary, N.C.
[email protected]
------------------------------
Date: Fri, 21 Oct 94 20:46 PDT
From:
[email protected] (Lauren Weinstein)
Subject: CNID (numbers vs. names)
The assertion has been made that perhaps calling number ID would be more
acceptable if something other than numbers were sent. In fact, that is
already part of the CNID spec (calling name delivery), though it is not
implemented in all CNID systems. In most implementations I've seen *both*
name and number are delivered--which rather kills the idea of delivering "who
is calling" info rather than "where are they calling from" info.
There isn't much enthusiasm among the commercial end-users for name-only
delivery. The reason is obvious--you can't collect phone numbers for return
sales calls when you're just handed a name. While the telcos have touted CNID
as being for individuals, the real focus has always been on commercial use as
the real money maker.
At this point, the CNID controversy boils down to the seemingly simple
question, "Since it is mandated that everyone must have per-call blocking
available, why can't per-line blocking be made available?" Once again, I
think the reason is obvious. Most people aren't on PBX systems that are
easily programmed to dial the three digit blocking code on each call, nor will
most people want to spend money for add-on gadgets to do this. So the hope of
the telcos is that most people will forget or won't bother to use the per-call
code most of the time. If per-line blocking were available (and surveys show
most subscribers would want it--people want to know who's calling, but don't
want other people to always know *their* number!) then CNID's commercial value
would be significantly lowered.
--Lauren--
------------------------------
Date: 22 Oct 1994 02:44:36 -0400
From:
[email protected] (Michael D. Sullivan)
Subject: Re: CNID (Preece, RISKS-16.47, Klossner, RISKS-16.48)
Andrew Klossner objects to the proposal to assign each phone a second unique
number solely for CNID; This would be accessible only through an 800 number.
Klossner claims this would be impractical because "Almost all area codes in
North America are more than half populated. In order to double the number of
phone numbers, most area codes would have to be split." This does not present
a major obstacle, however. The pseudo-number would not have to be a valid
phone number. [This was also pointed out in a subsequent message by Scott
Preece himself. PGN] Such a number could fit within the existing CNID
transmission system if it utilized the same number of digits as a valid US
number (10 digits), but there are no valid 10-digit numbers beginning with 0
or 1 (20% of the numberspace), no valid 10-digit numbers with 0 or 1 as the
fourth digit (20% of the numberspace, overlooking overlap with the foregoing),
no valid 10-digit numbers with 11 as the second and third digits (reserved for
911, 411, and other service codes) (1% of the numberspace), no valid numbers
with 11 as the fifth and sixth digits (same reason) (1% of the numberspace),
no valid numbers with 00 as the fifth and sixth digits (to avoid confusion
with 800, 900, etc.) (1%), no valid numbers with 200, 300, 400, or 600 as the
leading digits, etc. Over 40% of the numberspace is reserved, and the
remaining 60% is far from fully occupied -- only recently have a handful of
area codes with 0 or 1 in the middle been assigned (20% of the numberspace
remains relatively vacant), and likewise phone numbers with a 1 or 0 as the
fifth digit (i.e., in the middle of the NXX "exchange" group) have been
assigned only in major urban areas. It is very unlikely that anywhere near
50% of the numberspace is actually assigned -- keep in mind that there are 10
billion unique numbers available in a ten digit numberspace.
Clearly, then, it would be technically possible for the foreseeable future to
assign each telephone number in the North American Numbering Plan a unique
second number. This number would not be usable as a telephone number, but it
would only work through an "800" number, which would decode it.
Moreover, there is no reason why such a non-dialable number should be uniquely
assigned to each number. The telephone companies could use the non-dialable
subset of 10-digit numbers as a pool of codes for one-time use in each area
code. The real dialable number is actually transmitted between central
offices, but is not transmitted to the end user. If the "privacy" bit is
toggled on, the central office could store the real number and transmit a
non-dialable number from a one-time pad, and it would only be mapped to the
real number for a limited time, such as 48 hours, if keyed into the "800"
number associated with the same telephone company and dialed from the number
that was called (i.e., from the phone that received the non-dialable number).
There is no reason for a permanent association between the non-dialable number
and the real number; in fact, that would defeat the purpose of CNID and
unpublished numbers. Calling the pseudonumber, through the 800 gateway, would
be a one-time deal. There's no major technical obstacle to that.
Michael D. Sullivan | INTERNET E-MAIL TO: |also:
[email protected] |
Washington, D.C. |
[email protected] |
[email protected] |
[Various astute messages from
[email protected] (Paul T. Keener),
"john (j.m.) clarke" <
[email protected]>,
George Swan <
[email protected]>,
and others tend to make similar observations, and are omitted. Please
forgive me if I have oversimplified the points made by the omitted plethora
of messages. I think you would all be overwhelmed if I included
everything. PGN]
------------------------------
Date: Sun, 23 Oct 1994 13:18:42 +0000 (GMT)
From: Tim Duncan <
[email protected]>
Subject: Re: CNID and Don Norman -- CNID can be private (Wells, RISKS-16.48)
|> [Don Norman] suggests that other information should be sent instead of a
|> telephone number. ...
This is currently being tested by British Telecom in Edinburgh. Subscribers
have been given the option of submitting their own identifying string (16
characters) instead of the default which is their name as it appears in the
phone book.
Tim Duncan, AI Applications Institute, Univ. of Edinburgh, 80 South Bridge,
Edinburgh EH1 1HN, Scotland, UK Tel: +44 31 650 2747 Email:
[email protected]
------------------------------
Date: Tue, 25 Oct 1994 09:26:24 +0000 (GMT)
From: "B.M. Cook" <
[email protected]>
Subject: Calling Number ID - in the UK
We're about to get calling number ID in the UK, too - from British
Telecommunication (BT) at least. It is being promoted on the benefits to the
subscriber, e.g. "This service has already been available in North America for
some time, where it has had a major impact on malicious and fraudulent
calls.".
The fact that lines for which information has been previously withheld
(ex-directory numbers) will send information is hard to spot in the
literature!
The features listed in DIGEST 16.46 appear to have implemented, but not well
publicised - I get the distinct feeling that the service will be of most
benefit to companies who want to create lists of 'phone numbers!
We will be getting -
1. Per-line blocking - FOC, just call and ask for it.
2. Per-line unblocking - the default unless you change it.
3. Per-call blocking - dial 141 before the number you want.
4. Per-call unblocking - dial 1470 before the number you want.
1. and 2. need a phone call but it costs nothing.
3. is advertised in the literature.
BUT 4. took some discovering! I want to block outgoing ID by default and
allow it only on certain calls (e.g. friends, certainly not businesses who
will record it, sell the lists etc.) so per-line blocking with per-call
unblocking is the answer.
This option is not mentioned in the literature, I phoned the further
information freefone number to be told that what I wanted is not possible.
Rather than give up here, as I guess most people would, I asked them to record
my requirement so that if enough other people also wanted it they might think
about providing it. They said they'd get someone to call me back which they
did the next day. A very pleasant call from Edinburgh from someone who knew
rather more about the system (it had been on trial in Scotland before being
introduced elsewhere). No problem, he said, we already have what you require,
just have the line blocked and put 1470 in front of calls you want to unblock -
I'll put the line block on for you. The next day we had confirmation, by mail,
that it had been done.
So, it looks as though we will be getting a decent service (it goes live on
November 5th) - but only if you know what you want and work a little to get
the information!
------------------------------
Date: 24 Oct 1994 05:05:25 GMT
From:
[email protected] (J. Eric Townsend)
Subject: Bypassing CNID in an emergency
I see a big RISK in "ignore all phone numbers I don't recognize". At least
once every 6 - 12 months, I get an emergency call at my house from a friend or
family member. The call usually comes from a pay phone, but has originated at
a business or a residential line as well.
By blocking "unknown numbers", I would have missed calls with the following
content in the past year.
- "best friend severly injured in a vehicle accident, come immediately"
- "we broke down coming back from a late nite concert, it's 0230 and
we're stuck in the middle of a really bad section of town with no
transportation. can you come get us?"
- "my flight was canceled, so I caught one that arrives 3 hours earlier
and at a different airport. come get me before I'm bored to death!"
And, most importantly to *me*:
- "Hi, I just got your resume from a friend of yours, and we'd like
you to come in for an interview."
I ended up getting a great job from that one...
I don't see what is signifcantly gained by CNID that isn't gained by
using an answering machine to screen calls. I do see what can be lost
by ignoring calls from numbers one does not recognize, however.
J. Eric Townsend
[email protected] USA 415.335.7463 aka
[email protected]
work:
[email protected] AT&T PersonaLink:
[email protected]
------------------------------
Date: Mon, 24 Oct 94 10:45 GMT
From:
[email protected] (Michael Jampel)
Subject: Caller Number Identification in the UK
British Telecom is starting a CNID (Caller Number Identification) in the UK.
If you do nothing, your number will be sent out every time you make a call.
But if you dial 1471 (I think -- anyway, some 4 digit code) before dialling
the number you want to call, then your number will not be sent out.
Or you can ask for your number _never_ to be sent out. But in this case it is
_not_ possible to dial, say, 1472 to have your number sent out occasionally.
So if you don't particularly want to tell life insurance companies your phone
number, and if you don't trust yourself not to forget to dial 1741
double-bucky, you are put in the situation where you can never send out your
number, which will usually not matter, until the day that it does matter.
I feel that BT are not serving the needs of their domestic customers here:
CNID is great if someone you know is getting dirty phone calls, but otherwise
its main function is to benefit commercial customers. But there is nothing we
can do about it.
Michael Jampel
------------------------------
Date: Mon, 24 Oct 1994 09:03:41 +0800
From:
[email protected]
Subject: Re: CNID and Don Norman -- CNID can be private
It would not take the database miners of the world long to build a cross
reference between user selected call number ids and the real phone numbers.
To keep off the list, you would have to never let a company associate your
real phone number with your id. This would be hard to do if you use credit
cards, mail order outfits, etc. Also, given the penchant for phone companies
to charge a few bucks for every trivial service change, like changing an id,
the cross reference would tend to remain up to date.
Although, I should add that if people conspire to choose the same id,
like PRIVACY, we can give the marketers a real headache.
-- Mark
------------------------------
Date: 20 October 1994 (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
<
[email protected]> (which is 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.
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.
ARCHIVES: "ftp crvax.sri.com<CR>login anonymous<CR>YourName<CR> cd risks:<CR>
or cwd risks:<CR>, depending on your particular FTP.
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;
[email protected] and
WAIS are alternative repositories. See risks-15.75 for WAIS info.
To search back issues with WAIS, use risks-digest.src.
With Mosaic, use
http://www.wais.com/wais-dbs/risks-digest.html.
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 16.50
************************
