Risks Digest 21.41

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

RISKS-LIST: Risks-Forum Digest  Wednesday 23 May 2001  Volume 21 : Issue 41

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

  Contents:
A Hard Left-Cruise Ship's Autopilot blamed for sharp turns (Kelly Bert Manning)
Another backhoe reminder (Bernd Felsche)
New Bell Canada service: free calls (Dave Isaacs)
The Faith-Based Missile Defense (What's New via David Farber)
Time to bury proposed software law (Dan Gillmor via Monty Solomon)
NZ Electoral Web Site (Richard A. O'Keefe)
Osprey, cont'd (Peter B. Ladkin)
Our software is *never* wrong (Erann Gat)
Risks in scuba equipment (Carl Page)
More on that college network/spam (Danny Burstein)
Apple Powerbook 'bomb' shuts Burbank airport (Monty Solomon)
Re: Space Station software problems predicted four years ago (Bob Frankston)
The new Taiwan $1000 bill got the globe backwards (Dan Jacobson)
Police frequencies and fake calls (William Colburn)
Power safety (Marcus L. Rowland)
Ship to Internet (Donn Parker)
2002 ACM Symposium on Applied Computing: SAC '2002 (Cliff Jones)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 21 May 2001 13:06:10 -0400 (EDT)
From: bo774 () freenet carleton ca (Kelly Bert Manning)
Subject: A Hard Left-Cruise Ship's Autopilot blamed for sharp turns

Over 70 people were injured, 13 requiring treatment, when the ship docked in
Victoria, British Columbia. Some refused to get back on board but did so
after the US Coast Guard investigated and cleared it to continue without
using the autopilot. Two injured passengers remained in Victoria for care.

  http://www2.mybc.com/news/fs.cfm?source_id=CP&id=851308

  "It was like the Titanic. People were flying around in chairs. The gift
  shop was destroyed."  USA Coast Guard Lt. j.g. Scott Casad is reported to
  have said that the autopilot malfunction appeared to have been caused by a
  computer error.  The investigation will also look into whether the
  autopilot should have been used in the Strait of Juan de Fuca.

It will be interesting to see exactly what sort of "computer error" this
was. A crew member disengaged the autopilot after the second turn.

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

Date: Fri, 18 May 2001 10:48:03 +0800 (WST)
From: Bernd Felsche <bernie () innovative iinet net au>
Subject: Another backhoe reminder

[from http://www.abc.net.au/news/newslink/nat/newsnat-18may2001-35.htm]

  Telstra [Australia] estimates 50 to 80 per cent of customers
  affected by yesterday's phone outage in New South Wales have had
  their phone services restored and says the remainder should be fixed
  very soon.

  Technicians have worked through the night to fix a cable which was 
  severed by a backhoe on the central coast yesterday, cutting phone 
  services from North Sydney to the Queensland border.  Initially,
  Telstra hoped to have the cable repaired early yesterday afternoon
  but the company says the damage was worse than first thought.

  Spokesman Paul Levins says the delays are due to the complex nature 
  of the cable repairs.  "Inside the encasement are thousands of tiny
  hairlike fibre optics," he said.  "It's like knitting each one of
  those back together, it is like microsurgery and it is highly
  technical.  But they've got to get the sequencing right so you
  don't end up attempting to ring your mother down the street and wind
  up at the pizza shop."

Bernd Felsche - Innovative Reckoning, Perth, Western Australia

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

Date: Mon, 21 May 2001 13:56:06 -0400
From: "Dave Isaacs" <davei () ottawa com>
Subject: New Bell Canada service: free calls

According to an articles in *The Toronto Star* and *Wired* 
(http://www.wired.com/news/business/0,1367,43967,00.html), 
Bell Millennium payphones users were given a rare treat last week: 
free access to Telehop's Dialaround low-charge long distance service.

A glitch in the access software allowed anyone who entered 10-10-620 into a
Bell Millennium pay phone to make unlimited free calls to anywhere in the
world.  Word spread quickly on Internet newsgroups, until people were
literally camping out by the phones to wait their turn.

It is interesting that the hole was known by the public for 6 days before it
was fixed.  Why the delay?  Did it take 6 days to discover the problem?
According to the article, Bell didn't start monitoring the network closely
until [a] store containing the pay phones called to complain that the crowds
were disrupting their business.  I also wonder if Bell and Telehop knew
about the problem for some time, but did not count on the exploit being
described on the Internet.

Dave Isaacs

   [Also noted by Aaron PooF Matthews.  PGN]

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

Date: Sat, 12 May 2001 21:27:17 -0700
From: David Farber <dave () farber net>
Subject: The Faith-Based Missile Defense (What's New for May 11, 2001)

1. WEEKLY DISASTER REPORT: THE FAITH-BASED MISSILE DEFENSE

Last week, you will recall, President Bush called for a global missile
shield, including space-based elements, but he was pretty short on specifics
(WN 4 May 01).  This week, Defense Secretary Donald Rumsfeld called a press
conference to talk about military uses of space.  Many of us expected he
would fill in some of the missing details from the President's speech.  He
didn't.  Rumsfeld devoutly believes that an effective missile defense is out
there somewhere, but neither he nor the President seems to have any idea of
what the shield would involve or any evidence that such a thing is even
feasible, much less what it would cost, when it might be deployed or whether
it even has to work.  Rumsfeld wanted to talk about the management and
organization of a new national-security space initiative; it would be given
the task of filling in the missing details.  Not a bad strategy -- opponents
of a missile shield are left with nothing specific to attack.

  [For IP archives see: http://www.interesting-people.org/ ]

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

Date: Sun, 13 May 2001 18:14:02 -0400
From: Monty Solomon <monty () roscom com>
Subject: Time to bury proposed software law (Dan Gillmor)

UCITA, the ``Uniform Computer Information Transactions Act,'' is the
technology industry's version of Dracula. It's designed to suck money from
overmatched consumers, and it keeps emerging from the coffin.  Just about
every serious pro-consumer official and organization has denounced UCITA, a
proposed uniform state law that would tilt the balance in software
transactions strongly toward the seller.  But UCITA's backers, mostly in the
computer industry, are not giving up -- and they may be on the verge of
getting help from key public officials who, acting in good faith, would harm
the people they're sworn to protect.  [Dan Gillmor, Time to bury proposed
software law, *San Jose Mercury*, 13 May 2001
  http://www.siliconvalley.com/docs/opinion/dgillmor/dg051301.htm]

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

Date: Wed, 23 May 2001 14:25:42 +1200
From: "Dr Richard A. O'Keefe" <ok () atlas otago ac nz>
Subject: NZ Electoral Web Site

There's a saying in Australia and New Zealand: "when the Americans have a
'cute' idea, we wait a couple of years until they've proven that it's really
really dumb, and THEN we copy it."

*Otago Daily Times*, 22 May 2001, front page.

  Voters will be able to enrol on the electoral roll and update their
  details online using services on an elections web site.  Associate Justice
  Minister Margaret Wilson said the service would be particularly useful for
  people living in remote areas or overseas, as well as the disabled.  She
  also hoped it would encourage young people to enrol to vote.  The site is
  www.elections.org.nz.

I just hope the "disabled" people she has in mind are not the ones with poor
visual acuity, because in Netscape 4.7x or Amaya on a SPARCstation, the page
is unreadable; in Netscape on a Mac it is unreadable, and while it is
marginally readable in iCab, it somehow managed to kill iCab.

The site is slow and confusing.  I have made repeated attempts today to view
my own record, and always arrived at a page saying who was eligible to
enrol.

What would anyone reading comp.risks confidently predict would be used to
identity a potential voter, so that no-one else can scribble on your record?
SSN (which we call Tax File Number, TFN, and do NOT use except for tax
purposes).  Nope.  It's better than that.

Full name and date of birth.

Maybe the fact that I can't get to my record even _with_ that
information is the security feature I was hoping for....

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

Date: Thu, 17 May 2001 07:36:52 +0200
From: "Peter B. Ladkin" <ladkin () rvs uni-bielefeld de>
Subject: Osprey, cont'd [Ladkin, Risks 21.33, 21.38}

I advised RISKS readers in Risks 21.33 and 21.38 of three documents
concerning the troubled V-22 Osprey tilt-rotor development and deployment
program - the briefing material from the US GAO review of the program, the
briefing transcript concerning the results of the investigation into the
December 2000 crash, and the report of the Blue Ribbon Panel appointed by
then-Secretary of Defence Cohen to evaluate the program.

The briefers on the accident investigation (the JAG report) into the
December crash pointed unambiguously to a software problem, what they called
a "software anomaly". They said that the Primary Flight Control System
(PFCS) did not behave as it should have (namely, that in a particular
situation, it commanded significant control system changes when it should
have done "nothing") and that this was due to the software. [Ladkin,
RISKS-21.33]

The Blue Ribbon Panel report devoted less than a page to software
reliability. Their recommendations focused on methods effective for
determining the characteristics of complex control systems in their
operational environment, and did not include certain standard methods for
assessing and repairing safety-critical software known to contain
errors. [Ladkin, RISKS-21.38]

Define a software error to be a failure of the software implementation to
meet the design specification, or a failure of the software design to meet
PFCS requirements. The JAG briefing indicated that a software error had been
discovered; the Blue Ribbon Panel report led me to suspect whether this had
indeed been the case.

I spoke with Professor Eugene Covert, one of the four members of the Blue
Ribbon Panel, on Tuesday, 15 May 2001, and I put to him the argument of my
RISKS-21.38 note. Although a significant amount of his information is
privileged, he was able to confirm that no software error as above had been
implicated in the December accident and that the range of scenarios I
suggested in RISKS-21.38 broadly represented likely scenarios for the
genesis of the control behavior exhibited.

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

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

Date: 17 May 2001 09:52:48 -0700
From: Erann Gat <gat () flownet com>
Subject: Our software is *never* wrong

The other day I got an e-mail from my on-line credit-card company telling me
that my e-mail preferences had been updated.  Trouble is, I hadn't logged in
to my account for weeks, and I could not remember ever setting any e-mail
preferences.  So my risk radar said, "Hack!" and I called the company.

The rep assured me that my account had not been broken into.  How did they
know, I asked.  "I've got your account right here and I can tell that no one
has tried to break in."  Yes, but *how* can you tell that?  Well, because if
someone had tried to break in it would have said so, and it didn't, so no
one has.

I explained to the rep about the e-mail that I got which could only be
explained by either someone breaking in or a bug in their software.  And if
there was a bug in their e-mail software there might also be a bug in their
hack-detection software.  It should come as no surprise that this made
little impression on the rep.

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

Date: Fri, 11 May 2001 20:34:00 -0700
From: "Carl Page" <carlp () findpage com>
Subject: Risks in scuba equipment

Scuba divers make a fetish out of safety, for good reason.
I found the list of problems identified by testing by this outfit to be
instructive, and perhaps generalizable.
Thought you might enjoy it for RISKS digest.

http://www.scubadiving.com/gear/scubalab.shtml
Revelations: ScubaLab tests have led to many important revelations, including:

a. A regulator that actually shut off the air supply (a voluntary recall
   by the manufacturer was initiated).

b. Regulators that were advertised as upgraded and yet actually had
   increased work of breathing.

c. Regulators that could not deliver adequate air flow below 100 feet.

d. Regulators that were not adequately prepared for use as delivered.

e. Add-on fittings for regulators, such as swivels, that changed a
   regulator's performance from acceptable to unacceptable.

f. BCs that were supposedly improved with new airways or weight systems,
   but that actually performed worse on tests.

g. BCs with advertised buoyant lift capacities that were significantly
   different from the actual values.

h. BCs with mismatched inflator and ambient hose lengths, disabling the
   remote exhaust function.

i. BCs with excessive inherent buoyancy.

j. BCs with excessive body squeeze.

k. A dive computer that "lost" four minutes during decompression.

l. Dive computers that allowed continuous deep bounce diving.

m. Dive computers that caused compasses to read incorrectly.

n. Hoseless dive computers that lost their signal when other electronics
   were used.

o. Dive computer PC interfaces that did not work.

p. Dive computer instructions that were not correct.  

Setting the Record Straight

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

Date: Fri, 11 May 2001 22:16:48 -0400 (EDT)
From: danny burstein <dannyb () panix com>
Subject: More on that college network/spam (tls, RISKS-21.39)

In RISKS-21.39, of 11-May-2001, your correspondent, tls () panix com, discussed
the problems with the way a local university had recently set up an open
802.11 (wireless) network.

He commented that while this was an arguably defensible decision for a
university, he was quite concerned about its potential use by spammers. To
quote him:

> The RISK?  Their campus mail-handling machines will relay mail to
> any inside or outside destination if it's received from an address
> "inside" their campus network.  The network architecture they've
> chosen for their wireless deployment dictates that anyone can walk
> onto their (large,  urban) campus, or even just park his car outside,
> and spam away freely  with hundreds of megabits per second of
> bandwidth to most points on the Internet.

Having tried exactly what tls () panix com describes (except that I sat in an
air-conditioned van and only sent some test messages...).  I can confirm
that this university's mail servers work as he fears.

Furthermore, any mail coming through them will have an envelope indicating
it came from a well known and trusted source. Meaning not only would people
be more likely to let it through their filters (whether computerized or the
Mark One Eyeball method of glancing at the "from" and "subject" line), but
they're also far more likely to open it.

Meaning this type of service can easily be used to spread all sorts of
nastiness. And not just limited to e-mail viruses and trojans.

Getting back to spamming: this system doesn't block outgoing "port 25"
access, meaning a spammer could set up their own mail server and
pseudo-anonymously engage in all sorts of socially deviant activities.

The RISK? If you leave your front door open on the Internet, you're
leaving everyone else's front door ajar.

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

Date: Sun, 13 May 2001 18:11:09 -0400
From: Monty Solomon <monty () roscom com>
Subject: Apple Powerbook 'bomb' shuts Burbank airport

http://www.theregister.co.uk/content/2/18438.html

Apple Powerbook 'bomb' shuts airport, article by Drew Cullen, 23 Apr 2001

A California airport was closed for six hours [20 Apr 2001], following a
bomb scare.  And the 'culprit'? Step forward the Titanium Powerbook
G4. Operators of an x-ray machine installed at Burbank airport were unable
to get a high-enough res look at a machine trundling through security. They
called in back up for some chemical analysis. Swabs revealed "residues"
which caused some concern The police and the FBI were called in, flights
were cancelled, and hundreds of customers were left milling the booking
hall.

After six hours, the police determined that the Powerbook was indeed
a Powerbook and not a bomb - its hapless owner was released from 
questioning, and the airport was free to return to its business.

The scare was blamed on the titanium used in the laptop casing -
officials said this could have given a false reading

Let's hope this mix-up had something to do with the x-ray machine,
rather than some magical shielding properties possessed by the
Titanium PowerMac G4. If somehow it's the latter, Apple could have an
awful lot of product liability suits on its hands. 

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

Date: Sat, 5 May 2001 00:16:09 -0700
From: "Bob Frankston" <rmf2gRisks () bobf Frankston com>
Subject: Re: Space Station software problems predicted four years ago
   (Gross, RISKS-21.39)

Given that I'm in a plane and have time to catch up on old reading (but not
follow URLs -- at least until Boeing deploys their IP-to-the-Seats
infrastructure!), I might as well continue to take the contrarian role and
defend the value of risk. There is no way to escape risk so might as well
revel in it.

In this case, I can't resist wondering how one can debug complex software
before deploying it. The danger is more in assuming one can and not
preparing for failure than in not doing complete debugging. This doesn't
mean one should not do any testing, just that the limits must be recognized.

I'm a great admirer of MIR -- the ability to keep it going with just the
"chewing gum and bailing wire" (to use an old metaphor) impresses me more
than a design which is "perfect".

In general those who can experiment and survive have a major advantage over
those who must put their energy into trying to avoid risk. If one never
fails, one never succeeds.

In the case of the Space Station, the real question is how the overall
system is architected. Do point failures propagate or are the quenched? What
are the fallback procedures? Is there an attempt at efficiency that tends
towards depending on each module doing what it is supposed to do or is there
the necessary mutual distrust.

I fear that a procurement process that is overly specific actually increases
the risk by making it more difficult to learn by doing.

Bob Frankston  Curmudgeon () Bobf Frankston com  http://www.Frankston.Com

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

Date: 19 May 2001 08:41:52 +0800
From: Dan Jacobson <jidanni () kimo FiXcomTHiS tw>
Subject: The new Taiwan $1000 bill got the globe backwards

The day I discovered this error, the chief had to call two press conferences
the same day to deny it.  If he admitted it, then he would have had to
recall all the bad bills and print new ones (I suppose not to confuse
counterfeit detection systems).  It would not be possible to admit errors
without revising the note.
  http://www.geocities.com/jidanni/1000xinxintaibi.htm

http://www.geocities.com/jidanni Tel886-4-25854780

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

Date: Sat, 12 May 2001 15:32:55 -0600
From: Schlake (William Colburn) <schlake () nmt edu>
Subject: Police frequencies and fake calls (Re: Hutto, RISKS-21.39)

I am a volunteer Field Coordinator for the New Mexico State Police (District
11).  The Albuquerque Metropolitan area (District 5 SP) has been plagued by
problems like this, but from cell phones and FRS (Family Radio Service)
radios, not on police frequencies.  Even so, police frequencies are nothing
special.

The quote "The police department's emergency radio system uses two sets of
security identification codes and a computer to prevent unauthorized
access." sounds like media hype to make it sound like something special was
done.  All police frequencies are well known, they are available from the
FCC web page.  The "identification codes" are most likely the sub-audible
tones which tell the repeater how to process the signal.  These are also
well known.  If I were to take my radio to Denver, I could probably be
operating on their frequencies within a matter of minutes.

The "modification" of the radio is also media hype.  Almost any radio,
except those purchased from Tandy, can be modified without any effort.  You
open the back of the radio, and (in most major brands) you will see a single
copper wire amongst preprinted circuit boards.  Anyone want to guess what
happens if you cut the wire?  The FCC laws require commercial radios to be
fixed frequency.  These laws were made for crystal radios, and shouldn't be
on the books anymore.  Most manufacturers make one radio, and just pack and
wire it differently in different cases for different applications.

The computer is most likely just the data link between the cars and the
dispatcher that uploads and downloads information to the in car computers.

As for bogus radio calls, we have had a veritable plague of fake distress
calls from FRS radios and cell phones.  Most cell phones will call 911
without a service provider or SIM card, which allows anonymous untraceable
crank calls.  SAR teams and emergency personnel have responded to crashed
airplanes, automobile accidents, lost hikers, and lots more.  They solved
this problem by asking for a phone number that they can call to verify the
callers identity.  One real hiker was saved because he refered us to the car
company that he rented his car from.  A woman "lost in the mountains" was
ignored because she wouldn't give her name, a name of a friend or relative,
or a phone number where anyone who knew her could be contacted.

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

Date: Sat, 12 May 2001 23:28:24 +0100
From: "Marcus L. Rowland" <mrowland () ffutures demon co uk>
Subject: Power safety (RISKS-21.36)

I said

> A couple of years ago we rebuilt two labs and were able to replace two
> of these units with normal earth leakage and circuit breakers; there
> has since been no trouble, nobody has been electrocuted, and we have
> never had any loss of power in those labs. I'm now trying to get the
> rest replaced.

And as if by magic I've just heard that they're going to be fixed in the
next holiday, apparently because my complaints finally convinced the
school management that the cure is worse than the disease. Many thanks
to everyone who made suggestions on this in e-mail.

One point did arise in several messages, a suggestion that we have
separate ring mains put in for the computers. Apart from expense, there
was a serious safety issue with this; as mentioned in the original post,
the room is running with the electrical supplies at about -110v
negative, +110v positive, rather than the 0 negative, 220-230v positive
of normal UK ring mains. If a separate supply was put in it would run at
the normal voltage, and possibly a different phase, which could lead to
much more serious problems if the two systems were ever linked.

Marcus L. Rowland

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

Date: Sat, 12 May 2001 09:27:36 EDT
From: Donn Parker <Donnlorna () aol com>
Subject: Ship to Internet

Some cruise ships (Renaissance R Two) now have Internet cafes using
satellite services.  I was able to do all of my e-mail work 24/7 for two
weeks ($100 fee) in the Mediterranean from Venice to Barcelona -- except for
one day in Naples Harbor.  On that day, the ship was in a position that
precluded the dish line-of-sight to the satellite.  The funnel was in the
way.  I received no refund.  Donn Parker (retired in the nick of time and
glad of it).

  [That would be known as A Napoli Day.  Clearly, A Napoli Day Keeps the 
  Internet Away.  But there should also be a Napoli Woods in honor of the 
  late movie actress.  PGN]

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

Date: Mon, 21 May 2001 10:24:49 +0100
From: Cliff Jones <cliff.jones () ncl ac uk>
Subject: 2002 ACM Symposium on Applied Computing: SAC '2002

   2002 ACM Symposium on Applied Computing (SAC '2002), CALL FOR PAPERS
                      Madrid, Spain, 10-13 March 2002
        Special Track on Inter-disciplinary Approaches to the Design
                   of Dependable Computer-Based Systems
             http://www.dai.ed.ac.uk/homes/rnp/sac2002/cfp.html
           All submissions must be received by September 1, 2001.

A special track on inter-disciplinary Approaches to the Design of Dependable
Computer Systems will be held at SAC'2002. Society's dependence on
computer-based systems continues to increase. The systems themselves --
embracing humans, computers and engineered systems - become ever more
complex as they feed an insatiable appetite for new and extended
functionality.  Furthermore, these trends coincide with pressure for systems
to be brought to market faster and at lower (and more predictable)
cost. Achieving sufficient dependability in these systems, and demonstrating
this achievement in a rigorous and convincing manner, is of crucial
importance to the whole fabric of the modern Information Society.

Although progress has been made in achieving high dependability in computer
hardware and software, wider systems involving computers, people and business
or social organisations are often disastrously unsuccessful and the cause of
huge financial losses or worse. It has become clear in recent years that
satisfactory resolution of this situation demands an inter-disciplinary
approach targeted at understanding the fundamental problems that arise in
attempts to build systems involving complex interactions amongst numbers of
computers and human beings. Inadequate understanding of the complete
organisational and cultural context of use is often a significant cause of
lack of dependability of major new computer-based systems, and will be a
major focus of this track.

By bringing together computer scientists, psychologists and sociologists who
share an interest in the problems of dependability, the proposed track will
make an important contribution to fostering this inter-disciplinary approach.
Submissions will be invited on (but not limited to) the following themes:

     *  Architecture and organisation of systems, processes and their
        environment, e.g., use of diversity in systems and processes
     *  Work and its relationships with technological systems and artifacts,
        e.g., collaboration and interaction, organizational culture and trust
     *  Reasoning about dependability attributes, e.g., temporal
        predictability  and responsiveness of systems and processes, security
        and confidentiality, formal methods
     *  Socio-technical approaches to systems design and development, e.g.,
        knowledge management and process change, co-evolving work and
        technologies
     *  Assessment and management of risks involved in system development
        and deployment

Original papers from the above-mentioned or other related areas will be
considered. Each submitted paper will be fully referreed and undergo a blind
review process by at least three referees. The accepted papers in all
categories will be published in the ACM SAC'2002 proceedings.

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

Date: 12 Feb 2001 (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 DIRECT E-MAIL REQUESTS to <risks-request () csl sri com> with one-line, 
   SUBSCRIBE (or UNSUBSCRIBE) 
 which now requires confirmation to majordomo () CSL sri com (not to risks-owner)
 [with option of E-mail address if not the same as FROM: on the same line,
 which requires PGN's intervention -- to block spamming subscriptions, etc.] or
   INFO     [for unabridged version of RISKS information]
 .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 20" for volume 20]
 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 21.41
************************