|
Risks Digest 16.52 - Telephone game glitch (Julian
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
RISKS-LIST: RISKS-FORUM Digest Monday 31 October 1994 Volume 16 : Issue 52
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: [Apologies to those not included. This closes a few topics.]
Telephone game glitch (Julian Meadow)
The Sinking of the USS Gitarro (Mike Crawford)
Re: FEC Voting "Standards" (Rebecca Mercuri)
No Real Risks of Seemingly Similar Interfaces (Roger Carasso)
There are risks and then there are risks (Alan Wexelblat)
Re: Security screen (Bank fences, power keys, etc.) (Frederick B. Cohen)
Re: More on backspace problems (Esther Filderman, Russell Stewart)
CAPS-LOCK (Paul Barton-Davis, P. Kevin Parker, Rick Cook, Phil Keys,
Doug Siebert)
Re: AOL (Greg Lindahl, Mike Crawford)
Re: Half a degree is better than none? (Curtis Jackson)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: Mon, 31 Oct 1994 16:54:14 +0000 (GMT)
From: Julian Meadow <[email protected]>
Subject: Telephone game glitch
Computer Lied When It Said All Callers Were Winners
New Zealand's *Dominion* newspaper, 29 Oct 1994,
The hundreds of people told they had won $100 after a glitch in the telephone
TV Trivia game last weekend will not get the money. The telephone game began
awarding $100 prizes to all callers during the weekend after a computer
glitch caused by a power surge on Sunday evening. Callers said as soon as
they pressed the number 1 on their telephones to start playing, a recorded
message told them they had won.
But News Media (Auckland), which runs TV Trivia, yesterday said it would not
pay the estimated 500 callers. The company said it was quite satisfied that
all the callers who rang the 0900 number during the weekend were aware of the
nature of the game. The company said the game involved participants using
their skill and knowledge and if they were successful, they were rewarded. It
was not covered by the Gaming and Lotteries Act 1977.
It was clear the 500 callers had not been asked any questions: they did not
compete and so could not win. However, the company said it would reimburse
the callers for the cost of their calls. The Consumers Institute said the
legal issue was whether callers realised they were not playing the game
properly. If they knew there was a glitch they would not have much of a case.
------------------------------
Date: Sun, 30 Oct 1994 00:02:42 -0700
From: Mike Crawford <[email protected]>
Subject: The Sinking of the USS Gitarro
I just read the section on defense in *Computer-Related Risks* and was
reminded of the following incidents:
During 1967 and 1968 I lived on Mare Island Naval Shipyard, a submarine
maintenance station just off the North end of San Francisco Bay, across a
channel from Vallejo, California. Until recently most submarine repair
(nuclear, conventional, attack and missile) for the Pacific fleet was done
here; it has since been moved to Bremerton Washington; MINSY is being closed
down.
Sometime during 1968, the USS Gitarro (sp?) was being repaired. The front
sonar cover was taken off, and a hatch was left open so the repair crew
could get out to work on it. The Gitarro was floating in the water, raised
high to expose the sonar to the air.
A test engineer, who had nothing to do with the sonar people, wished to
perform a test of some mechanism that required the submarine to be level.
He went to the bridge (in the middle of the ship, far from the front) and
let some water in the ballast tanks at one end of the ship, until the
submarine was level, then closed off the tank... but he neglected to consider
inertia. The submarine continued to settle for a bit after he closed the
valve.
He did not take the obvious route of blowing some air back into the tank.
Apparently he did not know how to raise the submarine, only lower it.
(Perhaps this was all that was given in his test plan; I don't know).
Instead, he let water in the ballast tanks at the other end. Again he
overshot, and again, and again... until he wiggled the open sonar hatch under
the water.
Sea water came rushing in the front. Now, this would not be such a disaster
under ordinary circumstances, as military ships are always compartmented so
that whole sections of a ship can be flooded without sinking the ship. But
this ship was in for repair, and temporary pipelines, hoses, and power cables
had been run through the pressure hatches that were meant to close the
compartments. Sailors tried to use fireaxes to cut through live power cables
in order to close the hatches, but to no avail: the valiant Gitarro sank to
the bottom of Mare Island Channel.
I don't know if anyone was killed or injured - I think not. Damage was
mitigated somewhat by a quick thinking tugboat operator who saw the "sail"
starting to roll over into the water. He rammed his tugboat up against the
sail and kept pushing against it until a floating crane was brought in the
next morning. Even so, damage came to $30 million.
In another incident, the radioactive coolant water was being drained from a
reactor. This submarine (not the Gitarro) was in drydock. The usual
procedure is to cut a hole in the hull and run the water out a pipe into a
cement mixer. The radioactive water is used to make cement and trucked to
Hanford, Washington (about 800 miles) for "disposal".
The pipe from the reactor reached out to the hull, where it was connected
via a flange to the pipe leading to the cement mixer. Only one time they
forgot to bolt the flanges together; as the water was pumped out it showered
upon a shipyard worker walking on the drydock below.
I understand that the shipyard worker not only survived but was still working
at the shipyard during the '80s - but the clothes he was wearing at the time,
and the patch of drydock he was standing on at the time are buried at
Hanford. Also, this fellow exceeded his lifetime allowance for radiation
exposure during this "hot shower", and is not allowed inside the nuclear
yard.
In still another incident, the above mentioned cement mixer was stolen by the
truck driver assigned to deliver the radioactive concrete to Hanford. He was
caught - after he had used the mixer to pour a backyard patio at his house.
But wait, there's more! The Navy contracted with a private manufacturer to
build a piece of equipment that would be installed in a room aboard a
submarine. The Navy gave the manufacturer plans to this room. When the
equipment was delivered, a hole was cut in the hull of the submarine, and the
equipment was lowered in by a crane. Because submarines are very cramped
there was not much room and the designers used up every bit of available
space for their machine. When it was lowered into the submarine, it was
found that this device did not fit! The Navy made all sorts of accusation's
about the manufacturer's incompetence, but in the end it was found that the
manufacturer did meet the specifications; the Navy's mechanical drawing had
an error in which "1/2 inch" was written where "1/4 inch" was intended.
(Note that one of the factors that limits the life of a submarine is the
number of times holes have been cut in its hull. After a while the hull is
weakened so much that the submarine has to be scrapped.)
And finally, a note about the circumstances in which I lived at the base, and
the importance of unambiguous language in giving commands. I lived there at
the height of the Vietnam War, while my father was an instructor in the
antiaircraft missile school there. I spent the third and fourth years of my
life living on a military base at the height of a war; I remember tanks
rolling by and trucks and trains loaded with bombs. Being a small child I
regarded this with the wonder and curiousity any childhood would have for his
playground.
My parents sternly ordered me never to cross the street - but by walking some
distance down my street and crossing an open meadow, I could freely enter
the Marine Corps rifle practice range. Being three feet tall, my friends and
I could easily walk unobserved in the culverts along the road. I remember
watching the men firing their M16's, and one time I sat in a bunker below
the targets - one could lower a paper target into the bunker to replace it
or tally the score - watching bullet holes appear in the targets above.
The Marines did catch us, many times in fact, and always sternly warned us to
stay away, but they never did tell my parents. I never felt I was doing
anything wrong as I did not cross the street.
I did cross the street once, though... and the next street beyond, and snuck
under the fence into the shipyard area itself, walking right past heavily
armed sentries - remember all the riots were happening in Berkeley just 20
miles away, so I'm sure they were on the lookout for saboteurs. They just
didn't think to look for intruders that didn't reach up to their knees! I
remember quite clearly looking up into the cranes used to lift heavy
equipment off of railroad cars, and all manner of heavy equipment that would
have ground a four-year old boy into hamburger. [...]
Mike Crawford [email protected] [email protected]
------------------------------
Date: Mon, 31 Oct 1994 16:54:28 +0500
From: [email protected] (Rebecca Mercuri)
Subject: Re: FEC Voting "Standards" (Jones, RISKS-16.52)
[CC of message to Doug Jones,]
I was forwarded your E-mail, which was posted in RISKS on-line. I wanted
to comment on a few errors in your message.
First of all, the FEC Voting "Standards" do not "mandate" anything. These
are not standards, they are merely suggested guidelines. The guidelines are
just that because of "states rights." This is the right of states to have
certain choices in a variety of matters. There is precedent for the federal
government to mandate some things regarding voting. One of these is who can
vote (as in women, blacks, people over the age of 18). But currently the
federal government, although it oversees federal elections, does not MANDATE
any STANDARDS regarding voting machines. The FEC document you appear to have
been reading is just guidelines. Some of the states have adopted these
guidelines, and then they become a part of those states laws. But many
states have not.
Secondly, you should know that these FEC guidelines were created with
extensive assistance from voting machine vendors and other service
providers. It was in no way a balanced group. What I and others have tried
to point out in the years since the publication of these guidelines is that
there are already good STANDARDS for assuring accuracy and integrity in
computer-based systems. These standards are the "orange-book" system that
the federal government uses for other federally-used computation systems.
(Voting machines are exempt from the 1987 Computer Security Act and are not
required to conform to these standards.) Within these standards is a system
and organization for certifying secure systems at various levels. We would
hope that eventually states (or the federal government) would enact laws
that would bring voting machines into this system, and they could be
examined for conformity. The FEC guidelines fall far short of the NIST
standards, and we would like to see this changed.
I am not in any way suggesting that even the NIST standards would be
sufficient to ensure accurate and secure electronic vote tabulation. I am
just mentioning all of this here, because you are misled regarding the
stringency of the FEC guidelines and of their application.
Rebecca Mercuri
------------------------------
Date: Sat, 29 Oct 94 19:38:32 PDT
From: carasso@inference.com (e.e.)
Subject: No Real Risks of Seemingly Similar Interfaces
RISKS should be a forum for real risks, not pet peeves, not minor
inconveniences, not for harmless mistakes. I am amazed by the amount of
whining in this forum.
If you hit you Mac's power switch trying to eject your floppy, you obviously
just got your Mac, there's little of value on it, and it's unlikely that
anything damaging will *really* happen. There is very little real risk. You
are whining about a SELF-FIXING-PROBLEM. You won't do it again. And if you
do, it's called natural selection. Stupidity is its own reward.
If you accidentally push a wrong ATM button and get out $40 when you didn't
mean to, there is NO RISK. Just take the little envelope, deposit the $40
back in, and I'm sure you won't do it again. And if you do, it's called
natural selection. Stupidity is its own reward.
If these were nuclear warheads, municipal power stations, or something
important, fine. Write about it. But for Heaven's Sake, leave your whining
at the Gate.
roger
------------------------------
Date: Sun, 30 Oct 94 14:52:04 -0500
From: "Girls & Boys" <[email protected]>
Subject: There are risks and then there are risks (ETS) (McEvilly, RISKS-16.51)
Carlos McEvilly tells of his friend who was denied a semester at school
because of an interface problem with the computer-administered GREs.
While I sympathize with his friend's plight, it seems that blaming the test
administrators (ETS) seems too easy and too simple-minded. As with other
cases, we should bear in mind that there is a system and a whole process in
place, with several opportunities for human intervention.
For example, the problem would never have been seen had the friend not
chosen to take the computerized version in order to give himself more study
time. The risks of failure to plan in advance seem to apply here.
The college's use of the GRE score as a binary decision-making factor is
itself fraught with risks. First off, ETS itself advises against this --
the risk of using a product in a way it was not intended to be used.
Second, my friends who are college professors all tell me that the best
predictor of how good a student someone will be is not a standardized test,
but rather the person's past performance as a student.
The college already had one semester's worth of evidence for this student's
abilities, but they ignored it -- the risk of not considering all the
evidence as well as the risk of ignoring the opinions of qualified experts.
I could go on, but let me just state my main point: We've all gotten to the
stage where when we hear a so-called explanation like "Pilot error" or
"computer error" we know to dig deeper. We know that there are processes
involved, that there are opportunities for people to intervene, and that
focussing solely on one event/incident/problem tends to obscure other
possible causes. But we continue to apply this kind of shallow analysis to
other situations.
In this case, while I can see the error in the ETS software as being a
contributory factor, I can hardly give it primary, let alone sole importance.
Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard MIT Media Lab,
Intelligent Agents Group [email protected] 617-253-9833 Pager: 617-945-1842
------------------------------
Date: Sat, 29 Oct 1994 08:29:18 -0400 (EDT)
From: "Dr. Frederick B. Cohen" <[email protected]>
Subject: Re: Security screen (Bank fences, power keys, etc.)
It seems to me that one of the risks of robbing a bank is getting
killed by the guards, the security system, or the people you are taking money
from. I am not convinced that we should try to make robbing banks safe.
Re: On-Off Switch on Macs ...
I don't really understand this issue at all. It seems to me the
solution is not a better on-off switch, but a better operating system. My
Unix box doesn't seem to need an on-off switch, but every DOS, Windows, and
MAC system I have ever seen can't get along without one.
Re: Pacemaker failure ...
I appreciate that if my pacemaker fails, I will die, but I don't
understand why that justifies not using a pacemaker. Without it, someone who
needs it will die with P=1. With it, they have P=.001 or whatever. We seem
to overlook the issues of cost and probability in the risks forum when it
comes to accidental risks, and frankly, this is a big mistake.
Re: CMU course on dependable system design ...
The description sounds interesting, but it also sounds like it
ignores a great deal. I think that one of the problems with universities is
what we expect of them. It has taken me many years of full time effort to
gain the knowledge I have in the fields I explore. In a university, you get
9 hours per week (if you work hard) for 15 weeks on any particular subject.
135 hours on dependability is admirable, but that's about the same as 2-3
weeks of experience (depends on how many hours you work per week) in the
field. Still, as a leading complainer about the lack of attention to
information protection in our educational system, I should support the CMU
initiative. The only problem I have with the course description is that it
seemed to ignore the malicious aspects of risks in favor of accidental ones.
Of course, we certainly have a lot of accidents to worry about.
Re: The risks of reading risks
Somehow, the news reader on this system, (tin) seems to believe that
it is the only program users should ever run. It takes about 15 minutes to
examine every news group that has ever existed, and after offering me a wide
selection of new ones I have not previously asked not to get, finally allows
me to read the risks forum. Of course, this process cannot be interrupted
by the normal Unix interrupt character, and there don't seem to be options
to have it simply read the risks forum and leave me alone. Perhaps this
should be a class project at CMU's new class on dependability. While they
are at it, they should look at the Elm email system, which insists that I
answer the same questions every time I read mail, even though I always give
the same answers. No, there is no way to default them - or at least I
haven't found one.
------------------------------
Date: Fri, 28 Oct 1994 19:57:02 -0400 (EDT)
From: Esther Filderman <[email protected]>
Subject: Re: More on backspace problems
In RISKS-16.51 John Vilkaitis describes trying to get Netcom to understand
that his system is showing intermittent problems connecting to Netcom, and
that it is -not- failures of his "terminal software". At the end, he
concludes,
> The RISK of not fixing intermittent problems is having to increase your
> marketing budget. Same for not understanding English.
Understandable, but I suggest that the more frightening RISK is the following:
> They then repeatedly tell me to put STTY ^H in my .login file,
which they have already done WITHOUT my permission!
I will run the risk (no pun intended) of offending my fellow systems
administrators by saying that we all have heard horror tales of
"well-meaning" systems and/or support folks screwing up users by editing
their files without their permission, or without their understanding of the
changes. They're generally making more work for themselves.
Esther Filderman [email protected]
System Mangler Library Automation Carnegie Mellon University
------------------------------
Date: Mon, 31 Oct 1994 14:17:49 -0500
From: [email protected] (Russell Stewart)
Subject: NETCOM Backspace Problem ["terminal software"] (javilk,RISKS-16.51)
> Our technical support staff has diagnosed this kind of problem
> innumerable times.... it is in our opinion clear [?] that any
> remaining problem is the fault of your terminal software.
"It can only be attributable to human error." -HAL 9000
Russell Stewart Albuquerque, New Mexico [email protected]
------------------------------
Date: Fri, 28 Oct 1994 17:07:20 -0700
From: [email protected] (Paul Barton-Davis)
Subject: CAPS-LOCK considered harmful
[email protected] (Barton C. Massey) writes of various problems with
CAPS-LOCK. There's another, even more infuriating problem that CAPS-LOCK has
a risk of creating, and already has on certain keyboards.
Under the X Window System, it is possible to remap the keyboard in any way
you choose. This includes getting rid of CAPS-LOCK altogether, or so you
might hope. I do this routinely to deal with some of the problems Barton
mentioned, by mapping it be just another control key.
This works fine at work, on a DEC keyboard. When I get home, however,
there's a problem. The keyboard on my NCD X terminal considers the "lock"
attribute of this key to be a hardware feature, and thus regardless of what
I map it to under X, it always behaves like a CAPS-LOCK in terms of latching
and unlatching. Since I map the key to be a control key, you may be able to
imagine my frustration when I accidentally press the key and find that my
emacs-editing-supported shell goes haywire as I try to type alphabetic
characters. It sometimes take me quite a while to realize why nothing I type
works.
One day, I'll figure out a better way to remap it. In the meantime, even if
we're stuck with CAPS-LOCK, please hardware types: don't make the latching
feature a function of the keyboard electronics, but leave it software
controlled, where if its broken, some of us can fix it.
-- paul barton-davis UW CS Laboratory
------------------------------
Date: 28 Oct 1994 17:17:44 -0700
From: [email protected] (P. Kevin Parker)
Subject: Follow up to CAPS-Lock and MS Natural Keyboard (Massey, Alvarez)
Interesting that these two posts should appear one after the other:
> CAPS-LOCK Considered Harmful (Barton C. Massey) <[email protected]>
> Microsoft Natural Keyboard (Don Alvarez) <[email protected]>
The RISK of the CAPS-Lock is eradicated--in Windows only--by this keyboard.
Using the software provided by Microsoft, a user can disable CAPS-Lock
entirely.
P. Kevin Parker [email protected] [email protected].edu
------------------------------
Date: Sat, 29 Oct 1994 02:29:53 -0400 (EDT)
From: [email protected]
Subject: CAPS-LOCK Key Harmful?
While I can sympathize with the contributor who dislikes the CAPS-LOCK key
(my own keyboard has it placed cleverly just to the left of the space bar --
sure-fire sabotage), I'd like to point out that there is a growing group of
people for whom it is vital. Those are the people who don't have the
physical ability to press two keys at once.
For that reason I think CAPS-LOCK is a Good Thing and should remain standard
on keyboards.
--Rick Cook [email protected]
[There are other cases as well, for example, in programming languages that
REQUIRE UPPER CASE, as noted by Brian T. Schellenberger, [email protected],
who also notes the problems caused by the absence of a CAPS-LOCK indicator.
PGN]
------------------------------
Date: 29 Oct 94 05:55:03 EDT
From: Phil Keys <100213.1013@compuserve.com>
Subject: RE: CAPS-LOCK Considered Harmful
On 10/25, Bart Massey posted an article on the risks associated with the use
of the CAPS-LOCK key on a keyboard & challenged manufacturers to come up with
a better method. Whether it's better or not can be debated, but in Japan, AT
compatible machines running bilingual (Japanese/English) DOS (called DOS/V)
have adopted a convention where, to toggle the CAPS-LOCK key, you have to
press both the Shift key & the DOS/V key at the same time. Personally, I
don't like this since it forces you to remove your hand from the keyboard to
toggle CAPS-LOCK, but, it does make it less likely that you will toggle
CAPS-LOCK by mistake, thus reducing this risk.
Just thought I'd let you know that at least somebody, somewhere has been
thinking about this issue too.
Phil Keys [and appropriately named for this discussion, too! PGN]
------------------------------
Date: 30 Oct 1994 21:53:34 GMT
From: [email protected] (Doug Siebert)
Subject: Re: CAPS-LOCK Considered Harmful (Massey, RISKS-16.51)
NeXT did this right in at least the revision of the keyboard I have on my
color slab. The command key held down while hitting the shift key toggles
caps lock on/off (and toggles the LED that is in both shift keys) That way
the control key can be in the IMHO correct place, left of the 'A' key.
Doug Siebert [email protected]
------------------------------
Date: Sat, 29 Oct 1994 16:01:55 -0400
From: Greg Lindahl <[email protected]>
Subject: Re: AOL (RISKS-16.51)
> I presume the newsgroup stuff ages just as rapidly [as E-mail]. PGN
Actually no -- it seems to stay for months, so you'll see AOL users restarting
month-old flamewars by responding to something that's expired everywhere else.
[Ah, that suggests virtual time travel and multiple virtual realities.
Deja vu all over again. PGN]
------------------------------
Date: Sat, 29 Oct 1994 23:08:14 -0700
From: Mike Crawford <[email protected]>
Subject: Re: America Online Offlines America
An official from AOL was quoted in the San Francisco Chronicle Business
section today, 29 Oct 1994, denying that AOL was losing mail. This fellow
(might have been the president, I'm not sure) went on to invite the Internet
Community to "flood" AOL with mail.
Now, it's one thing to shoot your own self in the foot, but inviting the net
to spam AOL.com in the national press is likely to have the added effect of
overloading all the routers from here to there.
I'd like to suggest that the folks at aol ought to think twice before saying
such things.
Mike Crawford [email protected] [email protected]
------------------------------
Date: Sun, 30 Oct 1994 12:57:12 -0500
From: [email protected]
Subject: Re: AOL Offlines America (RISKS-16.51)
It appears to be the Macintosh AOL software that has the 22K limitation on
messages which prevents seeing an entire issue of Risks at one time. Even
so, the entire issue can be read; you just cannot keep more than about 22K
of it around at one time. This has the unfortunate consequence that you
have to stay on-line for the time it takes to read it, rather than saving it
to a file and reading it later off-line. The Windows AOL software does
allow one to read the entire issue at one time, and to save it to a file for
later reading.
[Stuff on deletion deleted. Also, clarification that comp.risks
came up at the same time as other newsgroups on AOL.]
AOL's newsgroup access is indeed limited (note that I had to edit the subject
heading to abbreviate America Online!), but it's not quite as bad as your
postscript made it sound. [TNX. PGN]
------------------------------
Date: Sat, 29 Oct 1994 02:08:01 GMT
From: cjackson@adobe.com
Subject: Re: Half a degree is better than none? (Brader, RISKS-16.49)
}Or rather, it tries to. Somehow, wherever the character 1/2 is
}supposed to occur, instead there is a degree sign!
As Mark Brader, the poster of the above, can intimately attest from the work
of both of us in certain international standards committees, this is a
primary area of concern when one is defining standards for font use and
especially font/glyph substitution. Our classic example in our ISO committee
was of the American who sends in a bid on a bit of business in the UK, only
to have his electronically-transmitted bid (these are the fast-moving '90s,
after all) printed out with the '$' replaced by the UK pound symbol. Quite a
hefty automatic bid increase, that one. Curtis Jackson
[email protected].com
------------------------------
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
<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, 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.52
************************
|
|
