|
Risks Digest 16.38
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 Friday 2 September 1994 Volume 16 : Issue 38
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:
Football interference without penalty? (PGN)
RFI and "winchcraft" (Mich Kabay)
Drawbridge controls -- fail-safe? (Steve Summit)
Chile: "Multicarrier" telephone system collapses (Patricio Poblete)
Anarchist files linked to child mutilation (Mich Kabay)
Poulson Pal Pinched (Mich Kabay)
Barclays Bank's new computer system (Steve_Kilbane)
Risks of living abroad (DelleraK)
Re: Changeable `constants' (George W Dinolt, Joseph H Presley, Mark Brader,
Bob Frankston, Steve Kilbane, Lars-Henrik Eriksson, James Cottrell,
James Carlson, Mark Nelson)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: Fri, 2 Sep 94 8:47:48 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Football interference without penalty?
National Football League coaches will have radio transmitters this year to
send plays in to their quarterbacks. RISKS readers may suspect that unless
the communications are encrypted, the opposing coaches will be able to
listen in. However, a different security problem must also be solved. The
last time this was tried in the World Football League, quarterbacks
sporadically picked up signals from local radio stations and air traffic
controllers. You can imagine a situation in which the flight instruction
just happened to coincide with the name of a play. Well, apparently the
NFL techies believe they have solved the interference problem this time
around; perhaps they resorted to the Playfair Cipher. [Thanks to Tom
FitzGerald in the San Francisco Chronicle, 2 Sep 1994, p. E6, for reminding
me of this risk.]
------------------------------
Date: 02 Sep 94 07:40:26 EDT
From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
Subject: RFI and "winchcraft"
The _Globe and Mail_ newspaper in Canada for 94.09.02 (p. A8) reports on
radio-frequency interference with building-construction cranes and other
devices:
Breaking the spell of `winchcraft'
by Mary Gooderham, Applied Science Reporter
....Without warning--and with no obvious electrical or
mechanical fault--the Kroll K-154 crane would shut itself
off, sometimes while hoisting a bucket filled with a
couple of thousand kilograms of concrete. Two transmissions
blew, their gears suffering when the machine's emergency
braking system stopped the bucket in mid-air. The crane
sputtered, losing power last week to the point where it
could lift loads only slowly, only a few metres off the
top of the building.
The article explains that these problems caused major delays in the
construction site at Simcoe Place in Toronto. Investigation revealed that the
equipment was being disrupted by radio-frequency interference (RFI), probably
from nearby microwave relay dishes and broadcasting stations.
Workers with experience at the Scotia Plaza site built during the late 1980s
recalled similar problems there; intermittent problems began once cranes were
raised above the 60th story and depended on the orientation of the
cranes--apparently because the cranes acted like antennas. In that case,
engineers figured out that the RFI was disturbing "the wiring on the cranes'
direct-current motors."
Significantly, the Simcoe Place crane also has a new DC motor, whereas the
other, unaffected crane uses an AC motor.
The engineers installed some metal-coated foam usually applied to ductwork.
The problems stopped. A lead shield is now being installed for more secure
isolation.
According to the contractors erecting the outer walls of Simcoe Place, their
laser level "started acting funny when it was used above the 20th floor."
The receiver that picks up the laser signal beeped when
the laser was off-target or wasn't even turned on. Wrapping
all but its tiny electronic eye with the aluminum foild that
usually keeps sandwiches fresh in the workers' lunch boxes
seemed to solve the problem.
M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle, PA)
------------------------------
Date: Fri, 2 Sep 1994 08:59:31 -0700
From: [email protected] (Steve Summit)
Subject: Drawbridge controls -- fail-safe?
The Evergreen Point Floating Bridge across Lake Washington in Seattle (SR 520)
has been notorious for its control problems -- either it gets stuck open or
stuck closed, or opens partially for no reason (which has led to one death and
one serious injury, on two separate occasions). The draw span has been
rebuilt this summer, although the following account (from the Seattle Times of
September 1) of the new controls will perhaps not be as reassuring to RISKS
readers:
To ensure that the center lift span never again pops up accidentally, the
old mechanical system has been replaced and is now controlled by a
computer with a series of safety features that must be overseen by the
bridge operator.
"You have to push buttons to make the gates go down, the lights come on
and the [actuating hydraulic] pumps to start," [project engineer Jay]
LaVassar said. "Every step has to be completed before you can go to the
next step."
Steve Summit [email protected]
------------------------------
Date: Fri, 2 Sep 1994 18:15:07 GMT
From: [email protected].cl (Patricio Poblete)
Subject: Chile: "Multicarrier" telephone system collapses
MULTICARRIER TELEPHONE SYSTEM COLLAPSES AFTER 4 DAYS--
A telecommunications system that allows callers to choose their own
long-distance telephone company, called the multicarrier, collapsed only 4
days after its inauguration. The system failed because callers were using
codes obsolete with the start-up of the multicarrier, confusing the
system. Talca and Curico, the first cities to have the multicarrier
installed, were the first to experience problems. The entire country will
be hooked up by late October. (La Epoca, p. B6)
------------------------------
Date: 02 Sep 94 07:40:34 EDT
From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
Subject: Anarchist files linked to child mutilation
The Montreal _Gazette_ for 94.09.01 reports on page E1 about a pipe-bomb
explosion related to computer bulletin board anarchist files:
Boy loses 3 fingers in pipe-bomb explosion:
Kirkland youngster, 13 and 15-year-old friend
were following instructions on a computer.
by Ann Carroll, _The Gazette_
A 13-year-old Kirkland boy lost three fingers on
one hand and his 15-year-old friend was seriously
injured last week when a pipe bomb they were making
--following instructions on a home computer disk--
accidentally exploded.
The article states that the boys had "decided to try an experiment they had
picked up from a computer information network." The little idiots ignited the
"high-powered flare" and it exploded in the hands of the 13-year-old. The other
boy is undergoing continuing treatment to remove shrapnel from his hand.
The mutilated victim's mother destroyed the diskette containing the instructions
but does not know the information's source.
{Comments by MK:
Discussion at HoHoCon 94 in Austin, Texas:
Q: "What about the Alansky case in Hartford where the cops
are attacking a BBS for having bomb-making info?"
A: [Deth Vegetable answers] I wrote those files when I was
15; and the files are in the news again in Montreal.
Some kids used my files and blew up their fingers.
I feel bad about that. However, anyone stupid enough
to use the files to make bombs deserves what they get.
It's like Darwin, you know? In Canada they don't have
guaranteed free speech, so the cops are taking boards
down for having this stuff on them. Alansky got 28
onths in jail. His lawyer said he didn't want to get
involved with the First Amendment. So Alansky
plea-bargained and then went to jail. There were other
irregularities; e.g., they didn't inform the lawyer of
the location for the indictment.
Q: [MK, loudly] "Why publish such files at all?"
[Furious faces circle on me from all quarters;
people recite, "Information Wants to be Free" and snarl,
"There was nothing illegal about it" and "He had a
right to post it."]
A: [Someone hands me a note written by Voyageur]
"We provide the files in order to protest our rights
to the freedom of information. If we voluntarily
censor ourselves, we do as much as if the government
were doing it itself. We maintain our rights through
the exercise and use of our rights. In addition, many
adults enjoy pyrotechnics as a recreational activity.
Quality information provided at low or no cost greatly
reduces the risk of pyrotechnic experimentation
resulting in unfortunate accidents."
....
Discussion about posting bomb files with Deth Vegetable
and others:
[Would you like to be called Mr Deth or Mr Vegetable?]
Most people call me, "Veggie."
[Why did you post the bomb-making files?]
"The government has the power; so publishing the anarchy
files is important. It's as if one day the revolution
will come and these files will arm the masses to rise up
against the establishment. Anyway, it was funny to me
at the time [when he was 15, 4 years ago]".
[What about now?]
"I wouldn't do it now. I can't say exactly why. I'm a
different person now.... Anyway, who's to say if it's
right or wrong?"
[MK, seizing D.V.'s shirtfront and slowly drawing him
to an inter-nose distance of 1 inch: "Who's to say if
it's right or wrong? _YOU_ are. _I_ am. [sweeping arm
to indicate entire room] _We_ are. We live in a society
of human beings who have responsibilities to each other.
We don't live in an anarchic paradise where you can
ignore the consequences of your actions by appealing
to a vapid ideology of non-involvement."]
\set disgust = on
I wonder if the fools who posted the pipe-bomb information have any shred of
self-respect. "If it's legal it must be OK" is a prescription for amoral
anomie. The National Computer Ethics and Responsibility Campaign sponsored by
the National Computer Security Association and the Computer Ethics Institute
includes a discussion of this attitude; we call it the "video-game syndrome."
The syndrome entails assuming that if something is feasible it must be
acceptable; "after all, if the game designers meant to forbid pressing
CTL-ALT-7 to shortcut to the winning frame, they should have programmed the
game to prevent it." The next stage is, "If the system administrator wanted
to keep us out of the medical records, she should have put up better
security." And then "If it were wrong to [name of reprehensible act], it
should be impossible to accomplish it.
set disgust = off\
M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle, PA)
------------------------------
Date: 01 Sep 94 13:22:37 EDT
From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
Subject: Poulson Pal Pinched
The Reuter newswire for 30 Aug 1994 issued a report on the capture of Justin
Petersen, a criminal hacker involved in Kevin Poulson's radio-station contest
fraud in Los Angeles:
HACKER NABBED AFTER NEARLY A YEAR ON THE LAM
LOS ANGELES, Aug 30, (Reuter) - After nearly a year of
searching, the FBI nabbed a computer hacker who pleaded
guilty to tapping radio station phone lines to win
contest prizes, a federal prosecutor said Tuesday.
Justin Petersen, 34, was arrested after an agent spotted
him getting out of a car in West Los Angeles on Monday,
Assistant U.S. Attorney David Schindler said. Petersen
tried to flee, but was apprehended after a brief foot pursuit.
The article explains that Petersen admitted June 1993 to having committed
"computer fraud, conspiracy and illegally accessing computer files of a credit
rating agency...." in connection with his nefarious deeds as a close
collaborator of the notorious Kevin Poulson.
At his October 31 sentencing, he could receive 40 years of jail and be fined up
to $1.5 million.
Although he cooperated with law enforcement officials in tracking down other
criminal hackers, Petersen disappeared from view and an arrest warrant was
issued for him.
Petersen called himself "Agent Steal" and boasted about how much he was being
paid by the FBI to inform on his pals at hacker conferences.
M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle, PA)
------------------------------
Date: Wed, 31 Aug 1994 14:51:00 +0000
From: [email protected] (Steve_Kilbane)
Subject: Barclays Bank's new computer system
Barclays Bank in the UK have a new computer system, and are currently inviting
customers to check their records, in groups. This week, customers with
surnames beginning with J-M are asked to check their records. So I did.
I gave my surname and postcode to the assistant, who promptly brought up my
records on a pretty Motif interface (used to be Windows, as I recall).
Numerous records needed updating. Some were rather dubious. The first recorded
how long I had held an account with them. This hadn't been altered since the
last time I gave them this information, two years ago. It's bad enough telling
them how long they'd had a record of me when they first got the earlier system
going, but they don't seem to update this information at all, and it doesn't
seem to be a time reference. sigh.
The other dubious field was my salary, which occurred in two places (general
form, and employment form), and needed updating in both places. Why is there
this duplication?
A couple of other things bothered me about all this. The first was that I
wasn't asked for any more proof of identity other than my surname and
postcode, and I got to play with all the fun figures that affect my life. I
know this information about at least one friend who banks with Barclays, and
their surname's further down the alphabet. :-> More seriously, this
information is pretty easy to obtain. I raised it with the assistant, and she
informed me that these two pieces of information were considered more secure
than an account number. Sigh. I wasn't even asked to produce an physical ID.
The other problem didn't occur to me until I started writing this. The
assistant turned the screen towards me, and away from all the other people in
the bank. Unfortunately, this also means that she turned it towards the large
wall-like window, and all the people in the street. :-(
[email protected]
------------------------------
Date: Fri, 02 Sep 1994 18:08:48 +0100
From: DelleraK <[email protected]>
Subject: Risks of living abroad
I have discovered that living outside the US puts you in the
database-never-never-land of People with Foreign Addresses.
I now expect to have to follow up several times after giving my address to
just about any US business: the first time to be told "we can't mail out of
the country" (read: "we can't make the computer mail out of the country"); the
second time to talk to a supervisor, who checks the procedure and tries to
enter the address; the third time to call back and discover it was somehow
mixed up (frequently as an American address with the German postal code as the
ZIP); the fourth time to request a resend with the correct additional postage,
which often must be hand-carried to the mail room... you get the picture.
With luck, I eventually receive a tattered envelope bearing several layers of
metered postage stickers, US postal reject stamps and some handwriting from
the Bundespost employee who managed to successfully interpret the address once
the letter finally crossed the ocean.
Then there are the firms like the credit reporting agency that told me the
only way to fix my garbled address was to contact each of the companies listed
on my credit report...which of course couldn't be mailed out of the country.
The risks? As usual, computerization can greatly streamline handling of the
routine, but can also eliminate the flexibility to handle exceptions. And, in
an increasingly international world, not everybody has a ZIP code.
------------------------------
Date: Thu, 1 Sep 1994 19:10:07 +0800
From: [email protected] (George W Dinolt)
Subject: Re: Changeable `constants' (RISKS-16.37)
Re James Ashton's comments in RISKS-16.37 on changing the value of constants
in Fortran compilers, it was indeed possible to do so on some Fortran and
other compilers. I demonstrated this to my students in the fall of 1972 using
one of the Fortran (I think it was either G or H) compilers on MTS (the
Michigan Terminal System, a time sharing system using IBM 360 tools).
The compiler would not let you assign a new value to a constant directly. One
had to pass the constant as an argument to a subroutine. Inside the
subroutine, one referenced the argument as a variable and hence one could
assign new values to it. Since subroutine arguments were passed by reference,
the value was changed by the assignment and subsequent references to the
constant at any later time and in any procedure reflected the new value.
My guess is that this trick would have worked on any IBM 360 system using the
same compiler. Other compilers would flag the assignment line in the called
subroutine, complaining that one was changing the value of an argument of the
subroutine.
The issues arising from overwriting supposedly constant memory with new and
``useful'' information have been discussed many times in Risks. This example
is more insidious than some because both the calling and called procedure
appear to be ``correct'' as stand-alone modules. It is the glue (calling
mechanism) which causes the problem. My application of this particular
compiler ``feature'' is just another example of what happens when the
``equivalence'' between algorithms and implementations fails in obscure and
hidden ways.
George Dinolt, Loral WDL
[The rest of this issue continues this thread. My inconstant
moderation allowed me to let the following items through the filter. PGN]
------------------------------
Date: Thu, 1 Sep 94 15:24:08 EDT
From: [email protected] (Joseph H Presley)
Subject: Re: Changeable `constants' (Ashton, Risks-16.37)
On the IBM 1130 system (circa 1970 for me), constants were kept in
memory. The following would output 1 + 1 = 4 as the answer:
CALL X(1)
I = 1 + 1
WRITE (6, 10) I
10 FORMAT (1H1, 7H1 + 1 =, I2)
STOP
END
SUBROUTINE X(I)
I = 2
RETURN
END
Additionally, floating point operations were done via subroutines. One night
during "student time", I exchanged the + and - subroutines (actually entry
points in one routine) on the system disk for about an hour.
Joe Presley [email protected]
------------------------------
Date: Thu, 1 Sep 1994 16:30:49 -0400
From: [email protected]
Subject: Re: Changeable `constants' (Ashton, Risks-16.37)
Some years ago when I was at university I heard about a student who had
tried a similar statement in whatever language they were working in at
the time (I think it was a COBOL dialect) and it had worked. The student
showed the program to a more knowledgeable person with great concern --
in case the program had "broken the 3 in the computer."
Mark Brader, [email protected] SoftQuad Inc., Toronto
------------------------------
Date: Thu, 1 Sep 1994 21:24 -0400
From: [email protected]
Subject: Re: Changeable `constants'
Fortran wasn't so bad as to allow "4=3". The problem is that parameters were
always passed by reference, including constants. so that if you had a
subroutine that incremented its parameter, calling it would increment the
constant. This was worse than "4=3" since you couldn't tell by inspection that
CALL SCORE1(3)
would change the constant. There would normally be a single copy of the
constant in memory since machines like the IBM 7094 didn't have inline
constants.
------------------------------
Date: Thu, 1 Sep 1994 08:18:41 +0000
From: [email protected] (Steve_Kilbane)
Subject: Re: Changeable `constants'
Believe it or not, there *is* a useful application for this sort of thing.
The IEC1131-3 compiler generates object code where all data objects are stored
in a lookup table, with constants and variables being virtually
indistinguishable. One reason for this is that while commissioning control
systems at site, field engineers often have to tune "constant" values to get
maximum results from the system. The object file format allows the engineer to
change what the programmer originally considered as a constant.
Ok, so I'm talking about changing the constants after compilation is complete
- the compiler won't allow the programmer to write to a constant - but it's
near enough.
steve <[email protected]>
------------------------------
Date: Thu, 1 Sep 1994
From: [email protected]
Subject: Changeable `constants' (Ashton, RISKS-16.36)
... Statements like `3=4' could then cause the chaos that you might expect.
This is syntactically incorrect and should not work. However, the
following fragment could have the effect of changing 3 to 4.
CALL ASSIGN(3,4)
.....
SUBROUTINE ASSIGN(I,J)
I=J
END
Lars-Henrik Eriksson, Swedish Institute of Computer Science
Box 1263 S-164 28 KISTA, SWEDEN [email protected] +46 8 752 15 09
------------------------------
Date: 1 Sep 1994 09:03:51 -0500
From: "James Cottrell" <James_Cottrell@qmbase.mitre.org>
Subject: Changeable `constants'
While at RCA in the early 80's I was developing Fortran code for PDP/11-70's
and showed a colleague an example of what you described. I believe the
example you cite is incorrect since the compiler could determine that the
left hand side of the equation contained a constant making the statement
illegal. The procedure that would work, turning the constant '3' into any
other value is as follows.
Subroutine Foo
call change (3)
printf (I5)3
return
Subroutine Change (I)
Integer I
c change the value of 3 for routine Foo
I=4
Return
In subroutine Foo after the call to change, the compile time constant '3'
would be equal to the value assigned in subroutine change. This change
occurs because PDP Fortran parameter passing was call by address. I believe,
and with age my memory is getting dimmer on the technical details, the PDP
Fortran compiler would gather all constant declarations in a subroutine and
allocate memory for the constants and load the constants in the memory. I
don't remember if this memory was in the code space of the routine or in the
data space. If the memory was allocated in the code space, the modification
of '3' would remain until the subroutine was overlayed. If the memory was
allocated in the data space, the modification of '3' would remain until the
program stopped.
This problem would not modify the value of the constant '3' in other
subroutines, since the compiler would generate a new (local) copy of all
constants for each subroutine.
!The opinions expressed here are mine and may conflict with my employer,
!wife or any other person.
------------------------------
Date: Thu, 1 Sep 94 10:55:54 EDT
From: James Carlson <[email protected]>
Subject: Changeable "constants" in Fortran
Close -- the actual problem was a bit more obscure. I know; I've been bitten
by it.
Years ago (about 1983), I worked on Finite Element Analysis software at a
small company in Pittsburgh. Of course, all of this stuff is done in Fortran
since the original public-domain SAP-IV and PLOT-10 packages were in highly
condensed and uncommented Fortran.
We ran into a problem with the "constant" zero occasionally assuming other
values in one particular module on a Prime 750 running PRIMOS. The problem
was caused by a sequence of statements of the form:
call somefunction(iargument,0)
...
call anotherfunction(0)
The first callee looked something like this:
subroutine somefunction(iarg,icount)
integer*4 iarg,icount
...
icount = icount + 1
...
return
end
Of course, Fortran uses call-by-reference rather than call-by-value, so it has
to push an address on a stack instead of a literal value. To do this with a
constant, like 0, it has to dump the constant into a literal pool and pass the
address of the literal pool entry to the subroutine. The compiler "optimized"
the other zero-value references in the same module to refer to this
"convenient" constant. Then, when the subroutine modified the value of zero
in the literal pool, the optimized references were then subtly wrong. The
following call passed a value of 1 instead of 0 to the next function,
resulting in a skipped element in an array.
Fortunately for my sanity, PRIMOS had a superb debugger, and I knew enough
assembly to figure out what had happened. (Playing with memory- to-memory
only architectures like the Westinghouse W2500 -- a machine with core memory
and a RAM scratchpad -- in my misspent youth also helped. ;-})
James Carlson <[email protected]> Annex Software Support / Xylogics, Inc.
53 Third Avenue / Burlington MA 01803-4491 +1 617 272 8140
------------------------------
Date: Thu, 1 Sep 94 18:20:57 EDT
From: Mark Nelson <[email protected]>
Subject: Re: Changeable `constants'
I've never seen a Fortran compiler that allowed assignments of this form, as
this should be easily detected by the parser. However, code similar to the
following has worked on every Fortran I've ever tested it on (various DEC,
CDC, Cray, and Sun compilers, at least);
program modify
c attempt to modify the value of a constant
c output will probably be 987.654, not the expected 123.456
call modif(123.456)
print *,123.456
stop
end
subroutine modif(x)
real x
x = 987.654
return
end
Tricks like this generally don't work with small (absolute value) integer
constants, as most machines provide instructions to load such values into
registers without accessing memory. But as Mr. Ashton noted, other constants
are often stored as literals in memory, with the compiler efficiently reusing
the same location for each use of a particular value.
Mark Nelson, Department of Computer and Information Sciences,
University of Delaware [email protected]
------------------------------
Date: 31 May 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>
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.38
************************
|
|
