precedence: bulk
Subject: RISKS DIGEST 19.67
RISKS-LIST: Risks-Forum Digest Tuesday 14 April 1998 Volume 19 : Issue 67
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, caveats, etc. *****
Contents: [**Parts of USENET missing RISKS-19.65,66. PLEASE CHECK.**]
Cypherpunks break GSM digital cell phone encryption (Declan McCullagh)
More on GSM crack ... (Declan McCullagh)
AT&T frame-relay network down (Doug Montalbano, Leslie Howard)
Starbucks flames out (Mark Richards)
Critical mass or critical mess? (John Fleck)
NASA Finds Problems In EOSDIS Flight Operations Software Development
(Ron Baalke)
L.A. County pension fund $1.2 billion shy (Steve Bellovin)
Ruminations on MS security (A. Padgett Peterson)
AOL Long Distance electronic billing (Steve Klein)
'Inverse Y2K'? (Streaky_Bacon)
Daylight Savings Time disaster (Henry Spencer)
UK considers universal CV database (Wendy Grossman)
Lexis-Nexis archives don't match print versions (Jorn Barger)
Tamagotchi revisited: Driver saves virtual pet, kills cyclist (Fred Ballard)
House Cat Kills Power to Dhaka Commercial District (Zachary Tumin)
Inaccurate study quoting (Fred Cohen)
Map maker sued in Dubrovnik T-43A crash (Matt Welsh)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Mon, 13 Apr 1998 06:03:07 -0700 (PDT)
From: Declan McCullagh <
[email protected]>
Subject: Cypherpunks break GSM digital cell phone encryption
TIME Magazine, April 20, 1998
http://www.pathfinder.com/time/magazine/1998/dom/980420/
notebook.techwatch.levit24.html
CODEBREAKERS
CRACKED. Thought your new digital cell phone was safe from high-tech
thieves? Guess again. Silicon Valley cypherpunks have broken the
proprietary encryption technology used in 80 million GSM (Global
System for Mobile communications) phones nationwide, including
Motorola MicroTAC, Ericsson GSM 900 and Siemens D1900 models. Now
crooks scanning the airwaves can remotely tap into a call and
duplicate the owner's digital ID. "We can clone the phones," brags
Marc Briceno, who organized the cracking. His advice: manufacturers
should stick to publicly vetted codes that a bunch of geeks can't
crack in their spare time. --By Declan McCullagh/Washington
From POLITECH -- the moderated mailing list of politics and technology.
To subscribe: send a message to
[email protected] with this text:
subscribe politech
More information is at
http://www.well.com/~declan/politech/
[Also noted by others. *The New York Times* article (14 Apr 1998)
included this sentence, along with discussion of its implications:
``What was even more intriguing than the security threat, however, was
that cracking the code yielded a tantalizing hint that a digital key
used by GSM may have been intentionally weakened during the design
process to permit government agencies to eavesdrop on cellular
telephone conversations.''
This case should once again renew suspicions about arguments that
trapdoored key-recovery systems will be perfectly safe for everyone to
use and will allow only the government to have legitimate access. PGN]
------------------------------
Date: Tue, 14 Apr 1998 10:01:30 -0700 (PDT)
From: Declan McCullagh <
[email protected]>
Subject: More on GSM crack ...
http://cgi.pathfinder.com/netly/continue/0,1027,1898,00.html
The Netly News, April 14, 1998
Our report yesterday that GSM cell phones can be cloned has some
affected companies crying foul. Terry Phillips, public affairs
director for Omnipoint Communications, calls the crack "interesting
but not significant. It's not news." Phillips claimed that digital ID
sniffing cannot be done over the air -- which, of course, contradicts
what eminent cryptographers and security experts say. Phillips did
correctly point out, however, that we said there are 80 million GSM
phones "nationwide," when we meant worldwide.
Phillips also sniped at the motivations of the merry band of cypherpunks who
cracked the proprietary encryption code. He suggested that they're acting on
behalf of and being paid by the competition; they've been working on this
for years; they're aiming for a million-dollar prize; they never actually
broke the algorithm.
Their response: Not so, on each count. "We weren't funded by anyone," says
Marc Briceno. "The entire project was done in my spare time with a budget of
less than $100." It took only two months, Briceno says, and besides, the
million-dollar prize was just 100,000 Deutschmarks and has long since been
withdrawn anyway. Qualcomm engineer Phil Karn, whose company supports a
rival standard, says he didn't participate in the crack and was asked only
to comment on it in the press release: "Those guys did it all on their own
and deserve all the credit." As for the formerly secret algorithm, check it
out yourself at scard.org.
[Declan's Politech mailing also appended Ross Anderson's item,
GSM hack -- operator flunks the challenge, from RISKS-19.48,
5 Dec 1997 <
[email protected]>. PGN
------------------------------
Date: Tue, 14 Apr 1998 10:09:11 -0700
From:
[email protected]
Subject: AT&T frame-relay network down
Service was interrupted Monday afternoon on AT&T's frame relay network, a
specialized system used throughout the country by businesses that conduct
large numbers of transactions for business customers and was not fully
restored yet on Tuesday. The outage was caused by a problem in the
interaction between two switches within the network. [_USA Today_ (13 Apr
1998) reports that 6,000 companies use frame relay
networks; AT&T has about 40 percent of the market.]
See <
http://www.techserver.com/newsroom/ntn/info/041498/info9_8325_.html>.
------------------------------
Date: Tue, 14 Apr 1998 14:45:06 +0200
From:
[email protected]
Subject: AT&T frame relay network down
AT&T Corp. said Monday its frame relay network was experiencing ``service
interruptions,'' apparently nationwide, affecting an undisclosed number of
business customers. AT&T spokeswoman Ruthlyn Newell told Reuters by phone
late Monday afternoon that the problem in the frame-relay network, a
high-speed data network, began about 1500 EDT/1900 GMT and was ongoing as of
just before 1800 EDT/2200 GMT. [Source: Reuters, 13 Apr 1998.]
[Anecdotal reports I have heard indicate a 75% to 80% nationwide outage.]
Les Howard, Software Engineer, Harbinger Corporation
[email protected]
[The problem was reported by AT&T to have been diagnosed and repaired
within 24 hours. Sounds a little like the propagation effects of the
mammoth long-distance collapse on Martin Luther King Day, 15 Jan 1990,
going back to RISKS-9.61. PGN]
------------------------------
Date: Tue, 14 Apr 1998 11:42:49 -0400
From: "Mark Richards" <
[email protected]>
Subject: Starbucks flames out
I don't know all the details yet, but our "local" Starbucks here on
Washington Street in Boston was dark this morning - as dark as their "COD"
brew. An employee informed me that their central computer crashed, the
result being all stores "unable to open the cash register". (Across the
entire country??) Obviously, they are without redundancy and business common
sense. Giving away free coffee in this situation is far better than
shutting off the lights and looking foolish.
The risk: Crashing of other mission-critical systems throughout the city
due to sleepy, caffeine-starved personnel.
<<zzzz>>
Mark Richards <
[email protected]>
[Well, to many people the missing cup of coffee is more
important than the frame-relay network outage elsewhere. PGN]
------------------------------
Date: Fri, 03 Apr 1998 13:18:57 -0700
From: John Fleck <
[email protected]>
Subject: Critical mass or critical mess?
From the Department of Energy's Operating Experience Weekly Summary 98-12
http://tis.eh.doe.gov/web/oeaf/oe_weekly/oe_weekly_98/oe98-12.html
Regarding a Feb. 26,1998, incident at Los Alamos National Laboratory in
which a software problem caused two uranium assemblies in a criticality
facility to accelerate toward one another:
"On February 26, the operator was closing the two stacks in slow speed when
the stepping motor unexpectedly switched to full speed. The joystick control
quit responding to the operator, and the scram button on the joystick did
not respond. The operator pressed the panel-mounted scram switch, and the
two stacks separated back to their starting positions as designed. The
activation of the scram placed the assembly in a safe configuration. The
configuration of the assembly was such that it would have remained
subcritical even at full closure of the two stacks. Facility personnel
conducted an assessment to ensure that the assembly was not damaged.
Engineers troubleshot the control circuitry and discovered problems with the
software and flaws in the communication between the joystick controls and
the central processing unit. They determined that when the joystick
interface did not respond, a subroutine returned an ASCII (American Standard
Code for Information Interchange) character "?" to the main program for the
potentiometer settings that controlled the stepping motor speed. The main
program was never developed to deal with a question mark and translated this
value to the number equivalent of an ASCII "?" (the number 63). The number
63 corresponded to a large negative position (beyond closure of the stacks)
that caused the stepping motor to drive in at full speed when it was
selected for movement."
John Fleck, science writer, Albuquerque Journal
PO Drawer J, Albuquerque NM, 87103 (505) 823-3916
[email protected]
------------------------------
Date: 10 Apr 1998 21:45 UT
From:
[email protected] (Ron Baalke)
Subject: NASA Finds Problems In EOSDIS Flight Operations Software Development
David E. Steitz, Headquarters, Washington, DC (202/358-1730)
Allen Kenitzer, Goddard Space Flight Center, Greenbelt, MD (301/286-2806)
RELEASE: 98-60, April 10, 1998
NASA FINDS PROBLEMS IN EOSDIS FLIGHT OPERATIONS SOFTWARE DEVELOPMENT
NASA has found software performance problems with ground system software
required to control, monitor and schedule science activities on the Earth
Observing System (EOS) series of spacecraft.
Officials believe these problems will delay the software which will impact
the launch date for the Earth Observing Spacecraft AM-1. The launch,
originally planned for late June 1998, from Vandenberg Air Force Base, CA,
will be delayed at least until the end of the year.
The Ground Control Software, called the "Flight Operations Segment" (FOS)
software, is part of the Earth Observing System Data and Information System
(EOSDIS), the ground system responsible for spacecraft control, data
acquisition, and science information processing and distribution for NASA's
Earth Science enterprise, including the EOS flight missions.
The problem is with the EOSDIS control center system FOS software that
supports the command and control of spacecraft and instruments, the
monitoring of spacecraft and instrument health and safety, the planning and
scheduling of instrument operations, and the analysis of spacecraft trends
and anomalies.
What was supposed to have been the final version of the software was
delivered to NASA by Lockheed Martin on March 31, to support integrated
simulations with the EOS AM-1 spacecraft. Testing of this software delivery
revealed significant performance problems. Program managers expect it to
take several weeks to clearly understand whether correcting the current
software or taking other measures is the best approach.
"We're concurrently looking at commercial off-the-shelf technology that was
not available when this software system initially was designed," said Arthur
"Rick" Obenschain, project manager for EOSDIS at NASA's Goddard Space Flight
Center, Greenbelt, MD. "If for some reason the current software problems
cannot be fixed, we have a backup plan."
Prior to the March 31 delivery, there were three previous incremental
deliveries of the software in August 1997, December 1997 and February 1998.
Previous versions of the software successfully demonstrated real-time
commanding functions with the AM-1 spacecraft. In the new version, however,
a number of problems identified in the previous software deliveries were not
corrected as expected, and significant problems were found in the new
capabilities. Problems include unacceptable response time in developing
spacecraft schedules, poor performance in analyzing spacecraft status and
trends from telemetry data, and improper implementation of decision rules in
the control language used by the flight team to automate operations.
Government/contractor teams have been formed to evaluate options for
correcting these problems to minimize impact on the AM-1 launch. A recovery
plan is being developed and will be reviewed during the last week of April.
The FOS is being developed by Lockheed Martin under subcontract to Raytheon
Information Systems Company under the EOSDIS Core System contract. The
Flight Operations Segment of the EOSDIS software has cost $27.5 million as
of February 1998.
THE EOSDIS and EOS AM-1 are part of NASA's Earth Science enterprise, a
long-term research program designed to study Earth's land, oceans,
atmosphere, ice and life as a total integrated system. Goddard manages the
development of EOSDIS and EOS AM-1 for NASA's Office of Earth Science,
Washington, DC.
------------------------------
Date: Wed, 08 Apr 1998 22:47:27 -0400
From: Steve Bellovin <
[email protected]>
Subject: L.A. County pension fund $1.2 billion shy
A pair of computer errors made in 1977 have resulted in the Los Angeles
County pension fund having $1.2 billion less than it should. There is no
immediate danger -- the fund's stock market investments have done very well
in recent years -- but the county will have to spend $25 million extra per
year to make up for the shortfall. And if the stock market had not
performed so well, the mistakes could have proved "catastrophic". [Source:
an AP wire story quoting the *L.A. Times* of 8 Apr 1997.]
------------------------------
Date: Fri, 10 Apr 1998 14:48:53 -0400 (EDT)
From: "A. Padgett Peterson Information Security" <
[email protected]>
Subject: Ruminations on MS security
Before I launch this commentary, I need to make a couple of things clear:
1) Speaking for myself only as a private individual
2) Think the wizards at Redmond have produced some marvelous products but that
like the certain letter agencies, their agenda is not necessarily the same
as mine. At least letter agencies seem to have fewer lawyers.
Do have some experience with the second since 1990 when sent a letter to the
software giant that a simple routine placed into IO.SYS would eliminated all
known MBR and boot sector viruses. The response was that it was not in their
business interest.
(Routine was simple - check the byte at 0000:004F for a value equal to or
greater than C0 - if below, "Redmond, we have a problem". I generally use
something a bit more sophisticated but was all that was needed. Note: this
works only before the operating system - any operating system - loads.)
Since then we have been granted such features as the ability to create word
macro viruses and a server operating system that was rated NCSC C2 so long
as it was not connected to a network. However the new crop of offerings are
even more innovative.
Suffice it to say that for years we have been able to tell users that "you
cannot get a virus just by opening E-Mail". Well, that bug is being fixed.
It seems that with the default installation of the just-released mail-reader
product coupled with the 98 version of the operating system (at least the
current beta which contains a necessary .DLL), all of the factors needed to
accomplish the above are present.
In fact, in recent days I have been able to drop an executable file both on
c:\ and into the startup directory just by opening the mail reader
("preview", which includes script execution for some reason, is a default
feature),
True, a warning screen is presented if the applet is unsigned (have heard
that signatures are already floating around the internet), but the same
screen is presented if word is opened as well, so I suspect it may become as
quickly ignored as other such mechanisms have been in the past (like all
security annoyances, there is an easy way to turn it off).
I have little expectation that the manufacturer will see the error of their
ways and remove the single necessary construct. It is probably required for
PUSH. It is entertaining though to find in the on-line language reference
the statement that the scripting language has no File I/O. I'm sure that in
some obscure legal language, that must be syntactically correct or it would
not be there; however, I found it remarkably simple to drop an executable
file on the hard disk that executed on the next boot. Times are about to
become "interesting". Caveat Y'all.
Padgett
------------------------------
Date: Thu, 9 Apr 98 00:10:09 -0400
From: Steve Klein <
[email protected]>
Subject: AOL Long Distance electronic billing
A long-distance telephone service called "The Phone Company" has recently
begun marketing its service through America Online, doing business under the
name AOL Long Distance. For those with long memories, this is the same
company that, a few years back, agreed to pay AOL $100 million for exclusive
marketing rights to the AOL customer database.
One way they keep their costs down is that they don't mail out bills. To
get a detailed listing of one's calls, the subscriber is supposed to sign on
to America Online, and click a button labeled "Show me my bill." The
problem? It doesn't work for Mac users who connect to AOL via an ISP. The
button links to a secure web page which fails to load in the AOL browser. I
also tried Netscape Navigator 4.04.1, and Internet Explorer 4.0a. No luck.
(It took them a week from when I first reported the problem for them to
determine just what the problem is.)
Their solution? I'm supposed to call them once a month, and request that
they e-mail my bill to me. (Ironically, they tout electronic bill retrieval
as a "convenience." Hmmm.) So today I called and asked them to mail me my
bill. Guess what? It's an HTML file, and my mail client doesn't do HTML.
(And no, they didn't ask me for ANY identifying information before
discussing my account, except my phone number.)
They refused to say when, if ever, the problem will be fixed.
[...] "The RISKS are obvious..."
Steve Klein, Your Mac Expert, Macintosh Consulting
[email protected]
248 YOUR-MAC or 248 968-7622 fax: 248 968-2769
------------------------------
Date: Fri, 10 Apr 1998 09:20:04 +0100
From: "Streaky_Bacon" <
[email protected]>
Subject: 'Inverse Y2K' ?
Wine broker Bordeaux Index has spent a fortune making sure its computers can
handle the Millennium bug. Yesterday it had no trouble shifting a magnum of
Chateau Margaux 1900 for GBP9,000 - but trying to log the sale proved more
difficult. No matter how hard they tried, the computer kept changing the
description to Ch. Margaux 2000. "We are stumped," says a spokesman. "We
can't get it to register the proper name." [Source: UK *Daily Telegraph*
(City Diary) 9 Apr 1998]
The RISKS are obvious!
[Perhaps I must suppress such aphorisms! But a Hamming code on the year
might help. Then we could ask how much would a Margaux Hamming Weigh? PGN]
------------------------------
Date: Mon, 6 Apr 1998 15:31:19 -0400 (EDT)
From: Henry Spencer <
[email protected]>
Subject: Daylight Savings Time disaster
A friend works for a large institutional employer, which has one of the
usual fancy phone systems including voice mail. Apparently they had a
problem making the daylight-saving-time switch yesterday; today everyone
got e-mail saying:
"We regret to inform you that while attempting to adjust the time on our
[name deleted] telephone and voice mail systems, the [company deleted]
technician inadvertently transposed the month and date resulting in the
voice system deleting messages that had been previously heard. We are
currently in the process of [determining] if the data can be restored..."
The most obvious fix is to automate the DST transition, as many systems now
do. One can perhaps argue about that, given the complexity of the rules and
the way they change from place to place and even from year to year. But if
it's not automated, one would at least hope for a less error-prone interface
to handle the highly predictable requirement of moving the time forward or
back one hour, especially given the apparently severe consequences of
getting it wrong.
(For that matter, one would hope for a less error-prone interface for
setting the date when that's needed, given the long-known ambiguity of
dates like 11/04... to say nothing of 11/04/01, which is not far away.)
Henry Spencer
[email protected] (
[email protected])
------------------------------
Date: Thu, 2 Apr 98 21:41 BST-1
From:
[email protected] (Wendy Grossman)
Subject: UK considers universal CV database
According to this morning's *Independent* newspaper, Tony Higgins, the chief
executive of the University and Colleges Admissions Service (this is a
centralized clearinghouse for college/university applications that acts as a
matchmaker between kids and schools in a mad six-week summer scramble), is
to suggest a scheme for a database of every citizen in the UK that will hold
all their educational and other achievements. The article goes on to
outline the uses to which such a database could be put: proof of
qualifications for entry to university or employment, checking on the state
of student loans. "Eventually," education editor Judith Judd writes
enthusiastically, "they might also contain pupils' results from the age of
five." The idea is that the existence of the profile will encourage people
to continue learning throughout their lives. Ha Ha. Ministers are supposed
to be considering giving everyone a NUMBER to attach to their profiles.
There are so many risks involved in this that it's impossible to list them
all. I just hope it works out that the most significant risk is to Higgins:
that he gets so thoroughly ripped to shribbons for this that it deters all
government ministers in future.
------------------------------
Date: Thu, 9 Apr 1998 09:59:56 -0500
From:
[email protected] (Jorn Barger)
Subject: Lexis-Nexis archives don't match print versions
The Columbia Journalism Review has an online piece at:
<URL:
http://www.cjr.org/html/98-03-04-archive.html>
called "How Accurate Are Your Archives?" by Bruce William Oakley in which he
describes comparing the Lexis-Nexis versions of published articles with the
actual hardcopy:
I compared articles in the commercial electronic archives, such as
Lexis-Nexis or DataTimes, of four newspapers to the paper versions from
their national and local fronts on arbitrarily chosen dates. Not one
archived version flawlessly matched newsprint. The errors ranged from
incorrect punctuation to incorrect headlines and bylines.
The most striking example almost led to a lawsuit, when a public figure was
accused of having served time, in the Lexis-Nexis version-- a research error
that had been corrected in the final proofs before publication, but never
got transmitted back to the archived version.
URL:
http://www.mcs.net/~jorn/html/weblogs/weblog.html
------------------------------
Date: Thu, 09 Apr 1998 09:54:14 -0500
From: Fred Ballard <
[email protected]>
Subject: Tamagotchi revisited: Driver saves virtual pet, kills cyclist
The following was forwarded to me, source unspecified. Fred Ballard
MARSEILLE, France _ A French driver killed a cyclist and injured another
after she took her eye off the road trying to save her Tamagotchi virtual
pet, police said Wednesday. The 27-year-old woman became distracted when
the electronic pet, which was attached to her car key ring, started to send
out distress signals. She asked a companion in her car to attend to the
Tamagotchi but in the confusion she failed to notice a group of cyclists on
the road ahead and slammed into the back of them. One died instantly and
another was taken to hospital. Police said the woman was arrested after
Sunday's accident near the southern city of Marseille. [See RISKS-19.36-37.
PGN]
------------------------------
Date: Sun, 12 Apr 1998 11:09:58 -0400
From: "Zachary Tumin" <
[email protected]>
Subject: House Cat Kills Power to Dhaka Commercial District
An Associated Press report from Dhaka, Bangladesh today reported that large
parts of the Bangladeshi capital lost power and fell dark Saturday, April 11
when a cat, who had walked into the control room of a power station, stepped
on some wires and caused a short circuit. The cat died immediately, but
power was out for two hours Saturday from Dhaka's principal shopping
district. Power was restored only after the cat's remains were removed and
the equipment cleaned.
[If you'll pardon my French, this was
"Un chat" in the dark. PGN]
------------------------------
Date: Thu, 2 Apr 1998 17:40:38 -0800 (PST)
From: Fred Cohen <
[email protected]>
Subject: Re: Inaccurate study quoting (Perillo, RISKS-19.65)
I think that Robert Perillo's two points are extremely important. In
essence, the reports assert that law enforcement won't benefit much by
improved ability to read all electronic messages and that the only real
benefit is in cost savings.
On the other side of the coin, the financial impact of the release of
information leading to the breaking of sophisticated cryptographic keys can
be extremely high. For example, cryptography is used to cover the vast
majority of interbank transfers (trillions daily), in stock trading (similar
magnitude), and in credit card transactions (a big number as well). The
risks in these financial arenas is so severe that legal export of high
quality cryptographic hardware for electronic banking applications has been
done for many years.
As we move increasingly toward electronic commerce the risks of breakable
cryptography are far higher than the benefit in cost reductions to law
enforcement. Indeed, if codes could be broken for law enforcement purposes,
the defense could assert that law enforcement planted the information using
its ability to break the codes. Even if this were not technically true for
some particular cryptosystem, the increased litigation costs associated with
prosecuting cryptography-related cases could be far higher than the savings
that breaking cryptography would seem to generate. But I have digressed a
bit.
My main point is that these conclusions seem to lead very directly to the
need for a cost/benefit analysis of breakable crypto vs. unbreakable crypto.
It's all well and good to hear claims on both sides of the crypto issue, but
since the issue identified in the government's study seems to be one of
money - and not one of whether we can catch and successfully prosecute
criminals or whether individual privacy is more or less important than law
enforcement - it would seem a valuable exercise to figure out whether and
where it is more cost effective to have breakable crypto than unbreakable
crypto. Unless it can be clearly demonstrated to be more cost effective to
have breakable crypto, the debate should be over as far as law enforcement
is concerned.
FC
Fred Cohen & Associates:
http://all.net -
[email protected] - tel/fax:510-454-0171
------------------------------
Date: 3 Apr 1998 20:24:25 GMT
From:
[email protected] (Matt Welsh)
Subject: Map maker sued in Dubrovnik T-43A crash
From CNN Online at
http://www.cnn.com/US/9804/03/brown.crash.suit.ap/ :
Jeppesen Sanderson, a Colorado map company, is being sued by the families of
some of those killed in the April 1996 crash of a military B737-200 (T-43A)
in Dubrovnik, Croatia. Among those killed was U.S. Commerce Secretary Ron
Brown.
The suit claims that "the Jeppesen chart listed a minimum descent altitude
for the approach which was too low and put ... the aircraft on a collision
course with the mountain". The chart allegedly also failed to warn pilots
that two NDB's where required for the approach and which NDB stations should
be used.
M. Welsh, UC Berkeley,
[email protected]
------------------------------
Date: 31 Mar 1998 (LAST-MODIFIED)
From:
[email protected]
Subject: Abridged info on RISKS (comp.risks)
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Alternatively, via majordomo,
SEND DIRECT E-MAIL REQUESTS to <
[email protected]> with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
INFO [for unabridged version of RISKS information]
.MIL users should contact <
[email protected]> (Dennis Rears).
.UK users should contact <
[email protected]>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to
[email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available:
ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
[volume-summary issues are in risks-*.00]
[back volumes have their own subdirectories, e.g., "cd 18" for volume 18]
or
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
get illustrative.PS
------------------------------
End of RISKS-FORUM Digest 19.67
************************
