RISKS-LIST: Risks-Forum Digest Monday 10 June 2002 Volume 22 : Issue 12
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. *****
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/22.12.html>
and by anonymous ftp at ftp.sri.com, cd risks .
Contents:
Is there a law that says you have to watch commercials? (NewsScan)
Dim STARS (Peter B. Ladkin)
Questions about new STARS air-traffic computer system (Ian Macky)
COTS versus Bespoke ATC Systems (Peter B. Ladkin, Nancy Leveson)
Re: Swanwick (Peter B. Ladkin)
*NY Times* new zero-security password system (Martin Ward)
Tracking subway users by electronic fare card (Ngiam Shih Tung)
Kazaa users inadvertently share their private files (Nathan Good)
Web glitch exposed Fidelity accounts (Monty Solomon)
Hacker threat posed by Excel spreadsheets (Patrick O'Beirne)
Re: More on typos and homographs (Martin Wheatman, Scott Nicol)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Fri, 07 Jun 2002 09:31:29 -0700
From: "NewsScan" <newsscanat_private>
Subject: Is there a law that says you have to watch commercials?
Surely there isn't -- says Rep. Rick Boucher (D-Va.) in his support for a
consumer lawsuit seeking to confirm that users of Sonicblue's ReplayTV
system have the lawful right to skip commercials when they record TV
programs for later viewing. The suit has been filed in the same federal
court in Los Angeles that is hearing a complaint from movie and television
studios that ReplayTV allows customers to violate their copyrights, arguing
that skipping commercials amounts to stealing. Sonicblue's position is:
"Basically we believe that consumers have 'fair-use' rights, and everything
consumers do with a ReplayTV is covered with 'fair use'." [Reuters/*USA
Today*, 6 Jun 2002, http://www.usatoday.com; NewsScan Daily, 7 June 2002]
------------------------------
Date: Fri, 07 Jun 2002 19:15:36 +0200
From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
Subject: Dim STARS
The US gave up on its Advanced Automation System (AAS) for air-traffic
control in the mid-90's, for the "usual" reasons: large cost overruns and
schedule slippages. The UK, however, whose 2MLoC [million lines of code]
NERC system was approximately half (1MLoC) AAS code, decided to continue
with development. The US instead went for a series of targeted solutions,
starting with the Display Replacement System (DRS) for its en-route centers
(those dealing with traffic en-route) in the late 90's, and continuing with
new hardware for its HOST system, which drives the en-route displays. Among
the major systems still under development is the Standard Terminal
Automation Replacement System (STARS), which was to be installed at some
170+ (now 160+) locations, for departing and arriving traffic at TRACONS
(Terminal Area Control facilities, controlling airspace around major
airports), to replace the aged ARTS systems. A full list of FAA ATC systems
under development may be found in [1].
STARS was contracted in 1996 to be delivered in 1998. The full software is now
scheduled to be delivered in 2002. STARS is described as a "commercial
off-the-shelf" (COTS) system (see [2]), quite the buzzword nowadays, and was
the type of thing the US wanted to try instead of the "bespoke" AAS that was
canceled in 1994. STARS was budgeted at $940m, including installation costs
at some 170+ TRACONs. John Mica, Chair of the House Aviation Subcommittee,
said in March 2001 [2] that the cancellation of the AAS "[cast] aside 11 years
of development work and, according to GAO, [wasted] more that $1.5 billion of
taxpayer money."
This supposedly COTS system was restructured by the FAA and the supplier,
Raytheon, into a "major redevelopment program" in 1998, because the COTS
system "proved to be inadequate", being "[unable to] handle the high volumes of
traffic required", with a corresponding $1.4b price tag (Mica [2]). STARS is
about 960 KLOC of core system i.e., that part of the software that is common
to other STARS installations, such as in Germany and elsewhere (Marchilena,
Executive VP of Raytheon, [2]) and about 400KLOC of "bespoke" code (Mead, DOT
Inspector General, [2]).
In February 2002, Kenneth Mead, Inspector General of the US Department of
Transportation, said that STARS "is already 4 years late and is now
estimated to cost $600 million over the original estimate of about $1
billion. [...] Delays with STARS causes FAA to take stopgap measures for
some facilities. FAA spent $85 million to purchase and install Common ARTS
systems [developed by Raytheon rivals Lockheed Martin Air Traffic Systems,
formerly Loral, formerly IBM Federal Systems. PBL] at large facilities to
replace aging equipment. FAA has spent about $660 million on the STARS
program but has only two Early Display Configuration systems in operation,
which provide new controller displays, but rely on older software. The Early
Display Configuration should not be confused with Full Service STARS (Full
STARS), which includes both new equipment and a complete replacement of
older software." [1] Inspector General Mead has recently reported that STARS
will cost at least $1.7 billion, "an 80 percent increase over the initial
estimate" [3]. Mead had testified before the Transportation Subcommittee of
the House Appropriations Committee on March 13, 2002 that there were 258
open critical trouble reports for STARS, having grown from 171 in September
2001. The FAA indicated, however, that there were only 50 open critical
trouble reports. Mead reviewed FAA documentation (the STARS Biweekly Report
for March 7, 2002) and concluded that the figure of 258 was correct [3]. (A
trouble report is open until closed, meaning a fix has been identified,
documented, verified and validated. "Critical" open trouble reports are
"those that would prevent or preclude the performance of a mission,
jeopardize safety or security, or adversely affect a mission-essential
capability." [3])
The FAA is aiming for the first installation of Full STARS at Philadelphia in
November 2002. They are aiming for a product that is "not perfect, but
acceptable", that is, to fix the "potential show-stoppers". As of May 2,
there were 221 open critical trouble reports. The FAA now distinguishes
between "critical" otr's and "truly critical" otr's. Mead calls the distinction
"not self-defining and [..] vague" [3, p3].
Apparently, to stay on schedule for November 2002 deployment in Philadelphia,
the FAA has deferred independent testing. They were going to conduct the tests
on Full STARS in Memphis in August 2002 to identify and correct glitches before
installation in Philadelphia. But because of delays in development, Full STARS
has not been installed in Memphis and independent testing will be performed
after (!) Full STARS installation in Philadelpia [3].
Further, "in order to stay on schedule for Philadelphia, the contractor
increased monthly spending (the "burn rate") in fiscal year 2002 to an
unsustainable level [....] [to] about $10 million per month on average this
year [...] an increase from a monthly average of $8 million to $9 million in
the 3 prior fiscal years." [3]
Mead concludes "We have little doubt that STARS hardware and software can be
"installed" by November, but, in our opinion, it is doubtful that it will be
operationally suitable by November to control live air traffic in Philadelphia
and replace ARTS." [3]
One might compare also the news reports by Bruce Nordwall in Aviation Week
in March 2002 [4], and the AP brief in the International Herald Tribune on
June 6, 2002 [5]. However, the IHT thinks that Mead said 71 open critical
trouble reports, rather than the 258 that Mead says he said [3], and Nordwall
says Mead said 175. Caveat lector.
References
[1] Status on the Federal Aviation Administration's Major Acquisitions,
Memorandum from the DoT Inspector General, February 22, 2002.
http://www.oig.dot.gov/item_details.php?item=701
[2] Minutes of the House Aviation Subcommittee Meeting of March 14, 2001, at
www.house.gov/transportation/aviation/ 03-14-01/03-14-01memo.html
[3] Follow-up Memo to FAA on STARS Acquisition,
Memorandum from the DoT Inspector General, June 3, 2002.
http://www.oig.dot.gov/item_details.php?item=806
[4] FAA Faulted for Slow Progress In ATC Modernization, Bruce D. Nordwall,
Aviation Week and Space Technology, 18 March 2002, available to subscribers
at www.awstonline.com
[5] New air traffic system under fire, Association Press, International
Herald Tribune, Thursday June 6, 2002, available at www.iht.com
Peter B. Ladkin, University of Bielefeld
http://www.rvs.uni-bielefeld.de
------------------------------
Date: Wed, 5 Jun 2002 14:10:15 -0700 (PDT)
From: Ian Macky <ian.mackyat_private>
Subject: Questions about new air-traffic computer system
There are some highly scary quotes in this article regarding the new
STARS (Standard Terminal Automation Replacement System) which is
supposed to replace the hodge-podge of old air-traffic control systems:
http://www.cnn.com/2002/TRAVEL/NEWS/06/05/faa.airtraffic.ap/index.html
Players are the FAA Union (representing the flight controllers), the
FAA technicians who are trying to roll out the new system, the equipment
builder, Raytheon Co., and the DOT (Department of Transportation). [...]
"DOT Inspector General Kenneth Mead ... said there were 71 specific software
problems that could prevent the system from operating as designed, or could
threaten safety or security. "
"Mead said controllers in El Paso had to track airplanes manually because
the computer system didn't properly display the flights."
Union vice president Tom Brantley: "They don't believe it's operationally
suitable," Brantley said. "It's failing. It has a lot of errors. They
can't verify that it works because it fails a lot of the tests."
FAA spokesman Scott Brenner said the only problems are the normal bugs (!)
that accompany any new technology. [Ship it!]
"When the [FAA] technicians refused to certify the system in Syracuse,
New York, the FAA invoked a never-before-used [emergency] clause in its
contract with its employees and ordered them to approve the equipment.
The Syracuse system was turned on Monday night."
Brantley: "The emergency clause was never intended for something like this.
That was intended if there were an actual emergency."
Blanche Necessary (!), a spokeswoman for the equipment builder, Raytheon Co.,
said the system was working well in El Paso and Syracuse.
etc., etc. The RISKS are painfully familiar.
Feel safer flying?
------------------------------
Date: Fri, 07 Jun 2002 19:17:18 +0200
From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
Subject: COTS versus Bespoke ATC Systems
I have noticed that people talking about air-traffic control system software
like to make a distinction between "commercial off-the-shelf" (COTS)
systems, and bespoke systems (for example, [1]). I have long found this
distinction unimportant in this domain, because of the amount of bespoke
tailoring required for any ATC installation. But its usage seems to me to be
increasingly prevalent. So I'd like to quantify my view with two examples.
The UK NERC system is an en-route system with 2MLoC software, which is about
half common software (well, common with the now-defunct US AAS) and half
bespoke. Development was budgeted at roughly GBP 500M (roughly $750M) in
the time frame 1992-1996. It finally came on-line in January 2002, with
significant cost overruns. (How expensive the development effort really was
depends on how one does the accounting. My estimates of 1998 turn out to
have been fairly accurate. [2]) Schedule slippage was 6 years on 4 years
planned.
The US STARS system was bought as a "COTS" system. STARS has undergone $660m
of development work to date and a schedule slippage of 4 years (to an
original schedule of 2 years until first installation in 1998), and is about
two thirds code in common with other installations (e.g. in Germany), that
is, 960 KLOC, and one third bespoke, 400+ KLOC. Full STARS software is thus
two thirds as large as NERC software. Development has cost $660 million so
far, for a November 2002 first (full) deployment.
So the difference between "COTS" and "bespoke" appears to be one-sixth (the
difference between two thirds and one half), and buying "COTS" systems does
not necessarily save one from comparable cost overruns or schedule
slippages. The LOC count for STARS is about two thirds that for the NERC
software; the development costs to first deployment seem also to be
comparable (NERC has only one installation, compared with STARS's planned
160+, so total program costs for STARS are higher than for NERC). And
schedule slippages are roughly the same magnitude (if strict proportionality
is your thing, total:planned time yields 9:4 for NERC and 6:2 for STARS).
I conclude that "COTS" and "bespoke" is not a helpful predictive distinction
for ease and comparative cost of development and deployment of ATC systems.
References
[1] Minutes of the House Aviation Subcommittee Meeting of March 14, 2001, at
www.house.gov/transportation/aviation/ 03-14-01/03-14-01memo.html
[2] Memorandum to the Transport Sub-Committee on the Costing of NERC, 26
November 1998, Memorandum FN 12 in (UK) House of Commons, Session 1998-99,
Environment, Transport and Regional Affairs Committee, Third Report, The
Future of National Air Traffic Services, pp52-55. Also available as
RVS-S-98-02 of 26 November 1998, at www.rvs.uni-bielefeld.de -> Publications
-> Special Reports
Peter B. Ladkin, University of Bielefeld
http://www.rvs.uni-bielefeld.de
------------------------------
Date: Fri, 07 Jun 2002 19:16:26 +0200
From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
Subject: Re: Swanwick (Brady, RISKS-22.09)
Chris Brady notes that the UK's New En-Route Center (NERC) at Swanwick, which
came on-line in January 2002, crashed "yet again" on May 17th.
Well, it did, but that's the first time, to my knowledge. Other recent
outages, including one on March 27 in which I was caught, reported in
RISKS-21.98 by Alistair Macdonald and Simon Waters, involved the National
Airspace System (NAS) in West Drayton, which processes flight plan data
which is fed to the NERC (Martyn Thomas, RISKS-22.02). When this data is
generated and manipulated by hand, as during a NAS failure, many fewer
aircraft are allowed into the system.
The NERC is an airspace management aid. It is essentially a display system
for data which comes from other systems (radar feeds, NAS, and so
forth). The worst kind of outage is one in which the system fails in use. As
far as I know, this has not happened. The BBC reported that engineers failed
to bring the system fully back up after a system upgrade. A number of
controller workstations were inoperative ( http://news.bbc.co.uk and search
for "Swanwick") and service was restored fairly quickly (a matter of
hours). As failures go, that is technically relatively benign, and
completely benign as concerns safety. Of course, one would prefer not to
have any.
Brady says that the upgrade rendered "half the air traffic controllers'
computer screens inoperable". The BBC reported that six out of twenty
displays did not come up.
Brady wonders how much all this outage is costing the airlines. The answer
is: more than one might think, for the airlines also own and manage NATS.
In a second note concerning difficulties some controllers are having in
reading data on the screens at the NERC, Brady says "Obviously no-one
thought to ask the controllers if they could actually read the screens
clearly".
On the contrary, controllers were evaluating and training on the system for
at least two years before it went live in January, and it is public
knowledge that they were very active with their feedback. NATS recognised in
1998 the need for a transition period more extended than the originally
planned six months (I suspect they knew it well before that, but there would
have been constraints on their replanning).
Brady says that the NERC is "a disaster waiting to happen". It is unclear to
me how he reaches this conclusion. He seems to think that one outage
portends disaster. The record could equally well be taken as evidence for a
well-managed and well-functioning system: one glitch in a system build in
four months, and no live crashes. Reader's choice (along with any position
in between).
That all said, it is appropriate to wonder, as Brady does, why there is now
a cluster of system slowdowns and outages, after years of successful NATS
systems operation, including times when various systems have been strained
to and even over what was thought to be their capacity and have proved much
more resilient than most people had imagined. John Stuart Mill's Method of
Differences would lead us to look for causal factors around what has
recently changed, and the most obvious recent large change is the
introduction of the NERC in January into the live airspace management
system. In so far as there is a risk obvious to everybody, that was it. The
management of this change will have affected other subsystems of the
national airspace management, including NAS of course.
One should not underestimate the technical challenge involved in switching
to this new system. ATC systems are built in an environment in which
requirements constantly change; they are safety-related and hard-real-time;
and every one has components adapted from other systems and components
unique to itself. All the system-engineering bad apples in one basket,
except one: ATC system design has traditional employed "graceful
degradation" in the guise of a radio-only reversion mode (which will
sometime no longer pertain when traffic is allowed to become sufficiently
dense, whereupon the ATC system will become safety-critical rather than
safety-related). The airspace NERC covers includes some of the busiest in
the world, and it is to my knowledge the largest live ATC system anywhere
(2MLoC), though not the most expensive (that honor belongs to the deployment
of STARS in the US, as far as I know). I imagine management of this
enterprise has been learning by doing. And unavoidably so.
For what it's worth, the NERC is a system Brits made work after America gave
up. In the last few years, I have found myself puckishly drawn to two
images. One is Dr. Johnson's "... dog walking upon his hind legs. It is not
done well; but you are surprised to find it done at all." The other is that
of old American cars in Cuba (the NERC uses a token ring architecture, after
all). However, the US got its replacement systems (the 1.3 MLoC STARS, inter
alia) no more quickly, by no means less expensively, and apparently with no
less trouble (see [1] and [2]). Again, reader's choice.
References
[1] Dim STARS, Peter B. Ladkin, 7 June 2002. [RISKS-22.12]
[2] COTS versus bespoke ATC systems, Peter B. Ladkin, 7 June 2002.
[RISKS-22.12]
Peter B. Ladkin, University of Bielefeld, Germany
http://www.rvs.uni-bielefeld.de
[Incidentally, Nancy Leveson reports that she was told STARS has 5MLoC,
although that may represent different code boundaries from the smaller
numbers. PGN]
------------------------------
Date: Fri, 07 Jun 2002 14:16:12 -0400
From: Nancy Leveson <levesonat_private>
Subject: COTS versus Bespoke ATC Systems (Re: Ladkin, RISKS-22.12)
> NERC has only one installation, compared with STARS's planned 160+
This is an important point... In the U.S., every ATC facility does things
differently, often significantly differently. The problem of trying to
develop and install 160 different systems with each different than the
others is orders of magnitude more difficult from both a software
engineering and installation standpoint.
I was involved with a software tool that simply assisted TRACON controllers
with arrival traffic. That software (about 500 KLOC of C code) contained
50,000 KLOC of what was called "adaptation data" that was needed for the
Dallas/Ft. Worth installation with which I was involved. The experimental
software was designed originally for DFW, with the intention of changing the
adaptation data for other TRACON facilities. That has proven to be more
difficult (and expensive!) than expected.
------------------------------
Date: Wed, 5 Jun 2002 11:33:05 +0100 (BST)
From: Martin.Wardat_private (Martin Ward)
Subject: *NY Times* new-zero security password system
*The New York Times* has recently switched their paid user accounts from a
reportedly hard to use and unreliable password system called Qpass to a new
system. They then sent an e-mail message to all account holders:
Now enter the following Member ID and password which we have created
for you and click the "Log In" button. You will need to use this
Member ID and Password to access your NYTimes.com premium products
in the future.
Member ID: ZZZZ
Password: Your password is your Qpass User Name.
The member id (ZZZZ above) is in the form firstname_lastname and Qpass user
names are easily guessable, often repeated across many sites, and often not
kept as secrets (for instance, message board posts are often tagged by
username).
*The New York Times* response to complaints about this system was that you
could always change your password if you found yourself concerned about
security.
See http://www.oreillynet.com/cs/weblog/view/wlg/1482 for the full story.
Martin.Wardat_private http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
[An item by Marc Hedlund on this problem was noted by Peter Tonoli:
http://www.nytimes.com/ref/membercenter/help/qpass_redir.html
PGN]
------------------------------
Date: Tue, 28 May 2002 22:01:19 +0800
From: Ngiam Shih Tung <stngiamat_private>
Subject: Tracking subway users by electronic fare card
*The New York Times* (2 Apr 2002) recently reported that investigators
trying to determine how a New York woman had contracted Anthrax during last
year's bioterrorist attack had used subway computer records and her fare
card to trace her movements in the city prior to her death.
Admittedly, the victim was dead and privacy rights are generally
recognised to be extinguished on death, but if a dead person's subway
rides can be tracked, so can a live person's.
Does anyone know what is the legal position on fare card records in New
York and elsewhere ? Is there any legal barrier or policy that would
prevent a transit authority from releasing fare card records to any law
enforcement agency, or to anyone ?
None of the media reports mentioned how far back in time the
investigators were able to trace Nguyen's movements. Can anyone hazard a
guess on how long New York's MTA keeps fare card data ?
------------------------------
Date: Wed, 5 Jun 2002 17:10:02 -0700
From: Nathan Good <ngoodat_private>
Subject: Kazaa users inadvertently share their private files
We have just finished a study that shows how user interface design flaws
allow users on Kazaa to share their personal files without their
knowledge. In a laboratory user study, only 2 out of 12 subjects were able
to correctly determine that Kazaa was sharing their entire hard drive. We
looked at the current Kazaa network and discovered that many users are
sharing personal information such as email and data for financial programs
such as Microsoft Money.
To see if other users on Kazaa were aware of this and taking advantage of
users ignorance, we ran a Kazaa client for 24 hours with dummy personal
files. During this time, files named "Inbox.dbx" and "Credit Cards.xls"
where downloaded from our client by several unique users.
The tech report can be accessed here:
http://www.hpl.hp.com/shl/papers/kazaa/KazaaUsability.pdf
or from our lab web page at
http://www.hpl.hp.com/shl/
Nathan Good, Information Dynamics Lab, HP Laboratories ngood @hpl.hp.com
1501 Page Mill Road, Palo Alto, CA 94306, USA 1-650-236-4437
------------------------------
Date: Mon, 3 Jun 2002 01:57:08 -0400
From: Monty Solomon <montyat_private>
Subject: Web glitch exposed Fidelity accounts
Canadian account holders information was accessible, AP, 29 May 2002
A design flaw at a Fidelity Investments online service accessible to 300,000
people allowed Canadian account holders to view other customers' account
activity. The problem was discovered over the weekend by Ian Allen, a
computer studies professor at Algonquin College in Ottawa. Fidelity said it
had fixed the problem and was offering customers the option of changing
account numbers.
http://www.msnbc.com/news/758979.asp
------------------------------
Date: Wed, 29 May 2002 15:56:36 +0100
From: "Patrick O'Beirne" <yg02at_private>
Subject: Hacker threat posed by Excel spreadsheets
http://www.silicon.com/a53624
Tuesday 28th May 2002 11:20am
A security hole in Excel XP spreadsheets which could lead to a hack attack
has been exposed. The discovery was made by independent security expert
Georgi Guninski, who said on his Web site: "Excel XP tries to play with new
technologies like XML and XSLT. Unfortunately the Excel seem so flawed that
if the user opens a .xls file and chooses to view it with xml stylesheet
arbitrary code may be executed. As script kiddies know this may lead to
taking full control over a user's computer." Guninski, who has posted a
sample of the code in his site, said users should not use XML stylesheets.
------------------------------
Date: Fri, 7 Jun 2002 09:44:20 +0100
From: Martin Wheatman <martin.wheatmanat_private>
Subject: Re: More on typos and homographs (RISKS-22.11)
I have been informed by Malcolm Pack that I was wrong about the protection
of the .co.uk domain, which involves no checks whatsoever. The protected
ones with stringent requirements are .ltd.uk and .plc.uk (which are private
and publicly listed companies in the UK) and .sch.uk for schools and .ac.uk
for academic institutions. <http://www.nic.uk/rules/rup1.html>
[This message is a combination of Martin's and Malcolm's items. PGN-ed]
------------------------------
Date: Thu, 06 Jun 2002 22:04:38 -0400
From: Scott Nicol <snicolat_private>
Subject: Re: More on typos and homographs (Wheatman, RISKS-22.11)
Are you sure [about llyodstsb.com]? You may want to change your password:
whois lloydstsb.com gives
Registrant:
Lloyds Bank Plc (LLOYDSTSB2-DOM)
Network Services
64 Hopton Street, London SE1 9JQ
United Kingdom
whois llyodstsb.com gives
Registrant Contact:
FastNet Corporation
Kwai Wei Suh (fastnet22at_private)
852-4326-7127
339 Huan Shi Dong Road
Guangzhou, AL 510098
CN
------------------------------
Date: 29 Mar 2002 (LAST-MODIFIED)
From: RISKS-requestat_private
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 e-mail requests to <risks-requestat_private> with one-line body
subscribe [OR unsubscribe]
which requires your ANSWERing confirmation to majordomoat_private .
If Majordomo balks when you send your accept, please forward to risks.
[If E-mail address differs from FROM: subscribe "other-address <x@y>" ;
this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
Lower-case only in address may get around a confirmation match glitch.
INFO [for unabridged version of RISKS information]
There seems to be an occasional glitch in the confirmation process, in which
case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
.MIL users should contact <risks-requestat_private> (Dennis Rears).
.UK users should contact <Lindsay.Marshallat_private>.
=> 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 risksat_private 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 21" for volume 21]
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
Lindsay Marshall has also added to the Newcastle catless site a
palmtop version of the most recent RISKS issue and a WAP version that
works for many but not all telephones: http://catless.ncl.ac.uk/w/r
http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
http://www.csl.sri.com/illustrative.html for browsing,
http://www.csl.sri.com/illustrative.pdf or .ps for printing
------------------------------
End of RISKS-FORUM Digest 22.12
************************
This archive was generated by hypermail 2b30 : Fri Nov 22 2002 - 23:52:13 PST