Risks Digest 22.19

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Monday 19 August 2002  Volume 22 : Issue 19

   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.19.html>
and by anonymous ftp at ftp.sri.com, cd risks .

  Contents: [Back from long trip.  PGN]
Name filtering affects police officer (Fuzzy Gorilla)
Massive ATM fraud after security problems due to Sept 11 (Tom Van Vleck)
A universal Turin machine? (PGN)
Win32 API utterly and irredeemably broken (Monty Solomon)
Microsoft EULA asks for root rights -- again (Monty Solomon)
FTC Stamps Microsoft's Passport (Monty Solomon)
Keystone SpamKops (Edward W. Felten)
Re: Listen to TCAS, not the controller (Peter B. Ladkin)
An automation-related AIRPROX incident (Peter B. Ladkin)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Thu, 15 Aug 2002 18:41:31 -0400
From: "Fuzzy Gorilla" <fuzzygorilla () euroseek com>
Subject: Name filtering affects police officer

It is not clear that we will ever solve the problem of computerized
filtering based on "lewd" names when even humans can't get it right.

The badge of El Paso police officer Christine Lynn O'Kane (and her e-mail
address) identified her as C. O'KANE (which unfortunately looks like
'cocaine').  After leaving the force for personal reasons and later
reapplying, she was denied reinstatement on the grounds that her name was
inappropriate -- despite her good service record that included an explicit
recommendation her work file supporting her reinstatement.  Although her
appeal to the Civil Service Commission resulted in her being rehired, she 
has now reverted to her maiden name (Whitaker).
  [Source: Cop In Trouble Over Name, AP, 12 Aug 2002; PGN-ed]

http://dailynews.yahoo.com/news?u=/ap/20020812/ap_on_fe_st/c__o_kane_1

------------------------------

Date: Mon, 5 Aug 2002 20:18:08 -0400
From: Tom Van Vleck <thvv () multicians org>
Subject: Massive ATM fraud after security problems due to Sept 11

http://fr.news.yahoo.com/020805/5/2pe9c.html
  [This is in French, but not yet reported in English.  
  Translation with the help of Babelfish.  thvv]

4000 people are suspected of taking a total of $15 million in ATM overdrafts
from the NY Municipal Credit Union, whose computer system was damaged by
9/11 attacks and the phone and electric outages that followed.  The CU chose
to allow withdrawals of up to $500/day without checking.  Word got around.
One person withdrew over $18,000 in 54 transactions.

------------------------------

Date: Mon, 19 Aug 2002 15:06:53 PDT
From: "Peter G. Neumann" <neumann () csl sri com>
Subject: A universal Turin machine?

Seeing the number 4000 in the foregoing message from Tom Van Vleck reminded
me of an article I read 12 days ago in *The Herald Tribune* Italian edition
supplemental highlights from *Corriere della Sera* in English, 7 Aug 2002:
Police probe credit card scam.  Turin police obtained a cigarette-pack-sized
machine that been used by an up-scale restaurant to make about 4000
perfect-copy credit cards from cards used by customers, including mag
stripes.  The Clone Arranger Strikes Again.  (The Shrewd of Turin?)

------------------------------

Date: Mon, 19 Aug 2002 12:44:53 -0400
From: "monty solomon" <monty () roscom com>
Subject: Win32 API utterly and irredeemably broken

Thomas C Greene in Washington, 7 Aug 2002 

Windows might possibly be the most insecure piece of viral code ever to
infect a computer, according to Chris Paget who's found a fascinating hole
in the Win32 Messaging System which he believes is irreparable, and which
he posted to the BugTraq security mailing list.

The research leading to this discovery was inspired by MS Veep Jim Allchin,
who testified to the effect that if flaws in the Windows Messaging System
were sufficiently understood, national security would be deeply compromised,
CRUISE missiles would be launched remotely, and /bin/laden would most likely
find some novel way of raping your daughter with his big bad mou Paget has
brought at least some of Allchin's fears to fruition ...

  http://www.theregus.com/content/55/25883.html

------------------------------

Date: Sun, 4 Aug 2002 23:03:51 -0400
From: Monty Solomon <monty () roscom com>
Subject: Microsoft EULA asks for root rights -- again

Andrew Orlowski in *The Register*, London, 2 Aug 2002

An addition to Microsoft's End User Licensing Agreement has alarmed
*Register* readers.  Windows XP Service Pack 1 and Windows 2000 Service Pack
3 contain a new condition which asks you to allow Windows to go and install
future updates.  "You acknowledge and agree that Microsoft may automatically
check the version of the OS Product and/or its components that you are
utilizing and may provide upgrades or fixes to the OS Product that will be
automatically downloaded to your computer," is the new bit you'll be
interested in.  ...  http://www.theregister.co.uk/content/4/26517.html

------------------------------

Date: Fri, 9 Aug 2002 18:05:42 -0400
From: Monty Solomon <monty () roscom com>
Subject: FTC Stamps Microsoft's Passport

FTC Stamps Microsoft's Passport

Yesterday Microsoft settled a complaint by the Federal Trade Commission that
its Passport user-ID service had violated its own privacy policy and was
insufficiently secure. Almost every outlet featured the story prominently,
and the Wall Street Journal e-mailed one of its infrequent Technology Alerts
yesterday after the FTC/Microsoft conference call.  ...
  http://newsletter.mediaunspun.com/index000018770.cfm#a86817

------------------------------

Date: Fri, 16 Aug 2002 09:45:06 -0400
From: "Edward W. Felten" <felten () CS Princeton EDU>
Subject: Keystone SpamKops

I recently set up a web site at www.freedom-to-tinker.com.  It's a weblog
containing my commentary on various issues.  Earlier this week, my ISP shut
off the site, because the site had appeared on a list of "spammers"
published by an outfit called SpamCop.

Apparently, this happened because one person, whose identity I was not
allowed to learn, had sent SpamCop an accusation saying that he had received
an unwanted e-mail message, which I was not allowed to see, that did not come
from me but that did mention my web site.  On that "evidence" SpamCop
declared me guilty of spamming and decreed that my site should be shut down.
Never mind that I had never sent a single e-mail message from the site.
Never mind that my site was not selling anything.

Naturally, I was not allowed to see the accusation, or to learn who had
submitted it, or to rebut it, or even to communicate with an actual human
being at SpamCop.  You see, they're not interested in listening to
complaints from spammers.

With help from my ISP, I eventually learned that the offending message was
sent on a legitimate mailing list, and that the person who had complained
was indeed subscribed to that list, and had erroneously reported the message
as unsolicited.  Ironically, the offending message was sent by someone who
liked my site and wanted to recommend it to others.  Everybody involved (me,
my ISP, the person who filed the complaint, and the author of the message)
agreed that the report was an error, and we all told this to SpamCop.
Naturally, SpamCop failed to respond and continued to block the site.

Why did my ISP shut me down?  According to the ISP, SpamCop's policy is to
put all of the ISP's accounts on the block list if the ISP does not shut
down the accused party's site.

Note the similarities to the worst type of Stalinist "justice" system:
conviction is based on a single anonymous complaint; conviction is based not
on anything the accused did but on favorable comments about him by the
"wrong" people; the evidence is withheld from the accused; there is no
procedure for challenging erroneous or malicious accusations; and others are
punished based on mere proximity to the accused (leading to shunning of the
accused, even if he is clearly innocent).

Note also that the "evidence" against me consisted only of a single unsigned
e-mail message which would have been trivial for anyone to forge.  Thus
SpamCop provides an easy denial of service attack against a web site.

The only bright spot in this picture is that our real justice system allows
lawsuits to be filed against guys like SpamCop for libel and/or defamation.
My guess is that eventually somebody will do that and put SpamCop out of
business.

  [By the way, there is more discussion of this incident on my blog site at
     http://www.freedom-to-tinker.com
  EWF]

------------------------------

Date: Thu, 15 Aug 2002 11:38:00 +0200
From: "Peter B. Ladkin" <ladkin () rvs uni-bielefeld de>
Subject: Re: Listen to TCAS, not the controller (Morell, Risks 22.18)

In RISKS-22.13, Bob Morell discusses the midair collision on 1 Jul 2002 over
Southern Germany, in which a Bakshirian Airlines Tupolov 154, operating as
BTC 2937, collided with a DHL Boeing 757-200, operating as DHX 611, although
both were using ACAS II-compliant collision-avoidance systems, namely
Honeywell TCAS II Version 7 systems [1] (TCAS is "kit"; ACAS II is the
international designation for a requirement which TCAS II Version 7
fulfills).

Morell is right in saying that more comment is due on this accident.
However, his comment is misleading, particularly because of its superficial
plausibility.  Most misleading of all is the title suggestion that the crew
of BTC 2397 (BTC CRW) should have listened to TCAS rather than the
controller.  To the contrary, their cognitive model may well have been such
that prioritising the controller's advisory over the Resolution Advisory
(RA) from TCAS would have been the most rational decision to make, as I note
below.

An extended version of my comment is available as "ACAS and the South German
Midair", RVS-Occ-02-02, on http://www.rvs.uni-bielefeld.de

First, a brief explanation of how TCAS II avionics operates [2,3]. TCAS II
broadcasts signals on the radar-interrogation frequency, and receives
responses from other aircraft's transponders. A Mode C transponder is a
device which responds to radar beams of a certain frequency with information
on the aircraft's identity and its "pressure altitude" - the altitude at
which it would be flying in an "international standard atmosphere" at the
measured outside air pressure. Additionally, the Mode S transponder used
with TCAS II may receive and transmit messages, a facility used essentially
in TCAS II.

TCAS II gives two types of advisories, Traffic Advisories (TAs) and
Resolution Advisories (RAs). It displays the approximate relative position
and separation of conflicting traffic visually on a display screen, and
announces the advisory via simulated voice. TAs alert a crew to the presence
of a potentially conflicting aircraft (determined by presence within a
specified volume of surrounding airspace), and attempts to predict
time-to-go to collision (TTG). When TTG reaches a certain threshold, a TA is
generated; when TTG reaches a lower threshold, an RA is generated upon
negotiation with the other aircraft's TCAS II, if it is so equipped. A TA is
just a warning; pilots are not expected to manoeuvre in response to a TA. An
RA is an advisory to climb, or to descend. An algorithmic negotiation
between the TCAS II avionics on both aircraft ensures that one aircraft of a
TCAS-II-equipped conflicting pair receives a climb RA and the other a
descend RA.

Morell speculates whether BTC CRW made a "mistake" or not, and suggests that
the descent decision and action "if the reports on the Russian training are
correct, was not, technically speaking, a mistake on the pilot's part...."

It is not clear to me what Morell's concept of a "mistake" is. First, any
pro forma operational suitability of BTC CRW's actions is determined by
German aviation law and associated approved procedures in German airspace,
not by any "Russian training". Second, in private correspondence, Morell
suggested that the RTC CRW action was "obviously" a mistake, since the two
aircraft collided. I don't know what it would mean for the action to be a
mistake, but at the same time not to be "technically speaking" a mistake.
Besides, the criterion offered is clearly insufficient: DHX CRW action led
just as inexorably to the collision, but it would be anachronistic to refer
to this action as a "mistake".

I feel such speculation about possible pilot error without a careful
analysis of the interactions in the cockpits, as contained on the cockpit
voice recorder (CVR), is unwarranted. The CVR often provides the only means
of assessing the quality of CRW decision making, and in this menage a trois
equipes in which four of the five participants are dead, I think such
analysis is essential.

Morell says, astoundingly, that "TCAS is a highly tested system with a
flawless record", apparently not counting this midair as a failure. On the
contrary, the TCAS avionics were a causal factor in this accident: had
neither aircraft been so equipped, the accident would not have happened (DHX
CRW would have maintained altitude as cleared; BTC CRW would have descended
as cleared and as they did; the aircraft would have missed each other by
600ft).

The TCAS system, like most complex systems which depend essentially on human
action, does not have a "flawless record", even previous to this
accident. There are significant operational issues with previous TCAS
versions (such as 6.02 and 6.04a), which remain (while reduced) with TCAS II
Version 7. Eurocontrol training materials say that TCAS "... cannot
eliminate all risks of collision. Additionally, as in any predictive system,
it might itself induce a risk of collision" [4, p17].  The Eurocontrol ACAS
Operational Evaluation indicates a substantial history of false positives
("unnecessary RAs") [5]; the latest version, Version 7, shows a "40%
reduction in unnecessary RAs" [6].

False positive RAs are not merely a nuisance; in dense traffic areas, which
is where RAs are most likely to be generated, manoeuvres in accordance with
RAs disrupt ATC planning and generate immediately an unanticipated higher
workload for a controller, which can be a safety risk when a controller is
operating near the limits of higher capacities. There has been a significant
rate of "nuisance" advisories, and one can anticipate pilots' reactions to
the system crying "wolf" too often.  Lincoln Labs apparently reported that
that over 50% of RAs occurring in U.S: airspace are ignored [5, Section 5.3,
p19].

Such operational issues arise with, for example, "stacks" of aircraft
queuing for approach to an airport in instrument meteorological conditions,
and in the European Reduced Vertical Separation Minimum airspace, introduced
this year between Flight Levels 290 and 410 (between 29,000 ft and 41,000 ft
in an "international standard atmosphere").  In both of these cases,
aircraft are operating as cleared with only one thousand feet of nominal
vertical separation. Altitude measuring equipment is allowed to be up to +/-
64 ft deviant in RVSM airspace, and altitude reporting equipment reports in
either 25ft or 100ft increments. Two TCAS-equipped aircraft operating as
cleared may well "see" each other separated by less than 850 ft, sufficient
to generate a "nuisance" TA. Add effects of turbulence, or of a
non-perfectly executed levelling off manoeuvre at a new cleared altitude
("bump up" or "bump down") and a "nuisance" RA can easily be generated [7].

One should not identify an ACAS II-compliant system with the TCAS II Version
7 avionics alone.  The avionics influence an aircraft's flight path only
through the crew's decisions and actions.  The procedures which crew are
advised to follow, and their understanding of the situation (their
"cognitive model") are essential components of the ACAS system.  Not only
that, but it is possible for misleading controller advisories to alter the
cognitive model of one or more of the crew involved, indicating that the
controller's role must be considered in any safety analysis of ACAS
operation.

Facts already available concerning the July 1 midair collision highlight
certain difficulties with ACAS operation, namely that ACAS does not handle
some three-aircraft conflicts well. Consider the situation engendered by the
circumstances on July 1.

We may assume that BTC CRW and DHX CRW knew that there were only two
ACAS-equipped aircraft involved in the conflict. This information would be
displayed; BTC CRW would see DHX at their 10 o'clock position (60 degrees
left of straight ahead). However, at 23:25:03, 7 seconds after the first RA,
BTC CRW were informed by air traffic control that there was conflicting
traffic at their 2 o'clock position (60 degrees right of straight ahead)
[1].  This aircraft was not on their display - indeed was not there; the
controller's advisory was a cognitive mistake. BTC CRW is now faced with the
following situation: there is a conflict with traffic painted by TCAS at
their 10 o'clock position and also with non-painted traffic at their 2
o'clock position. Their cognitive model poses a three-aircraft conflict
situation. (One of these aircraft is a "ghost" but they do not know it.)

The importance of this scenario does not depend on what did or did not
happen in the accident on July 1. We may find out from CVR and other
evidence, or we may not, what BTC CRW's cognitive model actually was. The
importance lies in that it is an ACAS scenario whose components have
actually occurred, and therefore it must be analysed as part of a safety
assessment of ACAS.
 
Let me use "Aircraft A" for the DHX-similar aircraft, "Aircraft B" for the
BTC-similar aircraft, and "Aircraft C" for the aircraft at Aircraft B's 2
o'clock position. Since TCAS is not painting Aircraft C, Aircraft B CRW can
suppose that Aircraft C will not be involved in any RAs. It is hard to say
what cognitive model Aircraft A CRW have, since they might not have heard or
assimilated the controller's mistaken advisory to Aircraft B CRW. So I shall
not consider their cognitive model. Aircraft B CRW do not know whether the
controller is in contact with Aircraft C or not, although it might be
reasonable to suppose so. ATC has issued a descent instruction to Aircraft B
to take Aircraft B out of conflict with Aircraft C. Further, Aircraft B have
received an RA to climb. They can conclude that the RA was negotiated with
Aircraft A, since their TCAS display is painting Aircraft A as the
"intruder", and that Aircraft A has received a descent RA.

There is a clear strategy for Aircraft B CRW to follow when both
controller's advisory and RA agree. They follow it. They then come to be in
further trouble only if Aircraft A manoeuvres in the reverse sense to their
presumed RA.  However, a dilemma is directly posed if the controller's
advisory and the RA do not agree in sense. One rational strategy could be
termed "better the devil you know".  Aircraft B CRW can follow the
controller's advisory to avoid Aircraft C, and attempt to use the TCAS
display information to acquire Aircraft A visually and avoid it. They could
also attempt to reduce speed to give greater TTG until conflict with
Aircraft A.

Risky as this is, I see no more rational strategy available to Aircraft B
CRW.  Not even this meagre strategy is available if they are in Instrument
Meteorological Conditions.

The manoeuvres of BTC CRW on July 1 are consistent with this strategy, which
violates the oft-repeated advice to pilots not to manoeuvre contrary to an
RA. I suggest on the basis of this scenario that this advice is not
universally applicable. Indeed, the benefit of ACAS in this situation to
Aircraft B is in knowing roughly where Aircraft A is - a benefit provided
equally well by TCAS I, which does not generate RAs at all.

I believe this scenario shows that it is illusory to imagine that better or
more uniform training will resolve ACAS operability problems.  Before
solutions can be trained, we first need a solution, and I doubt there is one
for this scenario based on ACAS technology.  I refer to my extended note for
other cases, involving three ACAS-II equipped aircraft, for which it is also
unclear to me that a solution exists.

Peter B. Ladkin, University of Bielefeld, http://www.rvs.uni-bielefeld.de

References

[1] Bundesstelle fuer Flugunfalluntersuchung, Presseinformation,
Zusamme nstoss am Bodensee (available also in English), reviewed July
28th, 2002, http://www.bfu-web.de/aktuinfo-d28.htm

[2] Mitre Corporation, Center for Advanced Aviation System Development
(CAASD), Traffic Alert and Collision Avoidance System,
http://www.caasd.org/proj/tcas/

[3] Honeywell, Inc. Advanced Collision Avoidance Systems, at
http://www.honeywelltcas.com

[4] Eurocontrol, ACAS II Training Manual, Version 2, available from
http://www.eurocontrol.int -> Projects -> ACAS -> Training Materials
-> Training Manual Version 2, May 2000.

[5] Eurocontrol Experimental Center, European ACAS Operational
Evaluation, Final Report, Eurocontrol Experimental Centar Report
No. 316, July 1997, available at
http://www.eurocontrol.fr -> Documents -> (Search) Final Report 316
-> Reports for the Year 1997 -> 316.

[6] Mitre Corporation, Center for Advanced Aviation System Development
(CAASD), Traffic Alert and Collision Avoidance System,
http://www.caasd.org/proj/tcas/

[7] Eurocontrol, ACAS II Operations in the European RVSM Environment,
Project ACTOR, available from
http://www.eurocontrol.int -> Projects -> ACAS -> Training Materials
-> Brochure f11, 2 August 2001.

------------------------------

Date: Thu, 15 Aug 2002 16:07:31 +0200
From: "Peter B. Ladkin" <ladkin () rvs uni-bielefeld de>
Subject: An automation-related AIRPROX incident

On 2 Oct 2000, there was a loss of separation (an AIRPROX incident in
jargon) on the North Atlantic Track E from Europe to North America between
an Airbus A330 and an Airbus A340 aircraft. The aircraft were operating
under Reduced Vertical Separation Minima (RVSM), in which high-altitude
aircraft may use a nominal vertical separation of 1,000 ft from each other
for their operations instead of 2,000 ft, which has been standard. RVSM had
been introduced for trials on the North Atlantic track system, and was
introduced in European airspace in January 2002. RVSM depends essentially on
participating aircraft using Airborne Collision Avoidance System (ACAS)
equipment. Both incident aircraft were using Traffic alert and Collision
Avoidance System (TCAS) Version 6.04 avionics.

I shall describe the incident briefly, omitting some salient observations
made in the report. Since the report is about eleven A4 pages of prose and
data, I recommend reading it in full [1].

The A340 was cleared at Flight Level (FL) 360 (the altitude at which the air
pressure is the same as that at 36,000 ft in an International Standard
Atmosphere), and the A330 at FL 370. The A330 was roughly abeam and slowly
overtaking the A340, when the aircraft encountered clear air turbulence,
described by the A340 captain as severe.

The A340 entered a "zoom climb", and went up to FL384, some 2,400 ft above
its assigned FL and 1,400 ft above the FL assigned to the A330.  Both
aircraft had been receiving Traffic Advisories (TAs) on each other for some
minutes before the incident, and during the incident received TCAS
Resolution Advisories (RAs); the A340 was advised to descend and the A330 to
climb. The A330 captain said that the A340 passed through his FL, some
200-300ft to his left, before he had time to react to the RA. The maximum
rate of climb of the A340 during the incident was recorded to be some 6,000
ft/min.

At the time the first RAs were issued, the aircraft were likely separated by
some 800 ft, and the RAs were "nuisance" RAs due to the turbulence, as
described in [2]. The A340 had not begun its zoom climb. About ten seconds
later, though, the A340s flight control system captured "alpha prot", and
the A340 commenced its climb. "Alpha prot" is a value of a flight parameter
known as the "phase-advanced angle of attack" which triggered a change from
the "normal" flight control law in the Airbus fly-by-wire control system to
the "angle of attack protection" law, or AoA law. When both control
sidesticks remain neutral, AoA law attempts to maintain the angle of attack
(inclination of the aircraft's wing to the air it is flying through; the
major parameter used in controlling lift in flight) at the value it has at
the point of reversion. One may presume that the turbulence encountered had
momentarily increased the angle of attack to a high value at the time that
alpha prot was captured.

Right before alpha prot was captured, the A340's airspeed briefly rose above
its "limiting value" of 0.86 Mach (0.86 times the speed of sound at that
altitude), due to the turbulence encounter. This triggered a Master Warning,
and also disconnected the autopilot. The Fault Warning Computer prioritises
warnings, and the autopilot disconnect warning was suppressed for about six
seconds in favor of the Master Warning. It is surmised that the crew may not
have registered the TCAS RA because of the interference of the other
warnings. The crew responded right away (within five seconds) to the Master
Warning by reducing thrust.

The investigation suggests that, because of the fluctuations caused by the
turbulence, the reversion from normal law to AoA law would likely not have
been sensorily detected. Furthermore, this reversion is not possible under
autopilot control. It is likely that the crew then had, for up to six
seconds, no obvious reason to judge that the aircraft was operating in AoA
law.

The investigators say that "Such was the vigor of the A340's climb in AoA
law, the aircraft could well have climbed through FL 363 (thus provoking a
TCAS RA with revised software version 7.0) in a very short time, even if the
crew had applied nose-down sidestick as soon as they heard the (delayed)
autopilot disconnect warning. The climb to FL 363 would have been sufficient
to generate a TCAS RA in any adjacent aircraft at FL 370 but, if the
intruder aircraft continues its climb, there can be no guarantee that an
aircraft directly above it could respond in sufficient time to avoid a
collision."

The incident raises the issue of operations under RVSM. The investigators
recommended suggested that such an incident is relevant to the safety case
being made at that time for the introduction of RVSM in Europe. The incident
shows that that a combination of a turbulence encounter, automated flight
control, and RVSM could prove deadly, with or without improved versions of
TCAS.

Peter B. Ladkin, University of Bielefeld, http://www.rvs.uni-bielefeld.de

References

[1] U.K. Air Accidents Investigation Branch, AAIB Bulletin 6/2001,
Ref. EW/C2000/10/2,
<A HREF="http://www.aaib.dft.gov.uk/bulletin/jun01/cggwd.htm";>
http://www.aaib.dft.gov.uk/bulletin/jun01/cggwd.htm</A>

[2] Eurocontrol, ACAS II Operations in the European RVSM Environment,
Project ACTOR, available from
<A HREF="http://www.eurocontrol.int";>http://www.eurocontrol.int</A> ->
Projects -> ACAS -> Training Materials
-> Brochure f11, 2 August 2001.

------------------------------

Date: 29 Mar 2002 (LAST-MODIFIED)
From: RISKS-request () csl sri com
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-request () csl sri com> with one-line body
   subscribe [OR unsubscribe]
 which requires your ANSWERing confirmation to majordomo () CSL sri com .
 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-request () pica army mil> (Dennis Rears).
   .UK users should contact <Lindsay.Marshall () newcastle ac uk>.
=> 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 risks () CSL sri com 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.19
************************