RISKS Forum mailing list archives

Risks Digest 22.30


From: RISKS List Owner <risko () csl sri com>
Date: Tue, 15 Oct 2002 14:00:45 PDT

RISKS-LIST: Risks-Forum Digest  Tuesday 15 October 2002  Volume 22 : Issue 30

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

  Contents:
$34M fails to fix DC payroll computers (David L. Matthews)
Man dies after playing computer games non-stop (Mike Hogsett)
My dishplayer and my digital phone don't play well together (William Colburn)
Pac*Bell menu (Dave Stringer-Calvert)
The democratic principle and "client-side" denial-of-service (Andrés Silva)
Hazards of online translation and plagiarism (George Mannes)
Lying 'Lie Detectors' (William Safire via Monty Solomon)
Risk of chaining substitutions (Mich Kabay)
Nigerian use of technology in elections (Fuzzy Gorilla)
Re: Butterfly ballots and electronic counting (George Russell, 
  Toby Gottfried, anon123, Tony Finch, David Damerell, Scott Nicol)
Re: Weak encryption kills wolves (Ulf Lindqvist, Erling Kristiansen)
REVIEW: "Information Warfare", Michael Erbschloe (Rob Slade)
DIMACS Workshop on Software Security (Gary McGraw)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 14 Oct 2002 09:51:59 -0400 (EDT)
From: "David L. Matthews" <dlm () wam umd edu>
Subject: $34M fails to fix DC payroll computers

Washington DC officials spent more than $20 million transferring payroll
data for city employees cutting over to a new computer system (Comprehensive
Automated Personnel and Payroll System) from a 33-year-old system that had a
long history of inaccurate and late paychecks.  After a year, the new system
was no better, so they then spent another $14 million reverting back to the
old system.  [PGN-ed]   http://www.washingtonpost.com/wp-dyn/metro/

  [This saga is not atypical of other cases noted here previously,
  but RISKS readers will find many lessons of what NOT to do in the
  *Post* article.  PGN]

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

Date: Wed, 09 Oct 2002 18:21:56 -0700
From: Mike Hogsett <hogsett () csl sri com>
Subject: Man dies after playing computer games non-stop

A 24-year-old South Korean man (identified only as Kim, a very common
Korean name) was found dead in an Internet cafe after playing computer games
nonstop for 86 hours, apparently without sleep or meals.  [PGN-ed]
  http://www.smh.com.au/articles/2002/10/10/1034061260831.html

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

Date: Mon, 14 Oct 2002 14:29:36 -0600
From: William Colburn <schlake () nmt edu>
Subject: My dishplayer and my digital phone don't play well together

For my telephone needs I have a Nokia 6190 with firmware V5.53.  For my
television needs I have Dishnetwork Dishplayer running at whatever version
they last pushed to it.  I have known for a while that my telephone and my
dishplayer have an "interaction".  When I am about to receive a call, the
audio on my television has a modem-like sound buried in it.  Similar sounds
come up periodically when the telephone is sitting idle as well, probably
some kind of background communication between it and the tower.

Yesterday, while I was watching the Discovery Channel, an emergency came up
and I had to make some phone calls.  I moved into the next room with my
telephone.  After a little while of talking on the phone, and making several
different calls, my phone suddenly synchronized with the Discovery Channel.
The audio track that I could hear from the next room was also being played
over my telephone.  I tried telling the person I was talking to what had
happened, but when I talked the telephone amplified my own voice over its
speaker (but not on the television).  I I hung up and redialed, but my
telephone continued to play the Discovery Channel to me.  I had to power
cycle my telephone to make it stop.  The person I was talking to knew that I
had hung up on them, but hadn't heard anything unusual.

If it happens again, I think I'll try changing channels on the television to
see what happens.  Maybe I can get the audio track to a channel I'm not
subscribed too!  :)

The risks here, are that wireless devices could someday/somehow use the
wrong radio signal and do bizarre and unexpected things.

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

Date: Mon, 14 Oct 2002 13:13:54 -0700
From: Dave Stringer-Calvert <dave_sc () csl sri com>
Subject: Pac*Bell menu

Less than sane pacbell menu system:

"If you have a dead line, and cannot make calls, press 1"

<press 1>

"If you are calling from the line you are having problems with, press 1,
else press 2"  [...]

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

Date: Thu, 10 Oct 2002 10:50:00 +0200
From: =?ISO-8859-1?Q?Andr=E9s?= Silva <asilva () fi upm es>
Subject: The democratic principle and "client-side" denial-of-service

Extracted from "Hacktivists target trade summit":
http://www.wired.com/news/print/0,1294,43137,00.html

A coalition of cyber-protesters plan to flood 28 websites associated with
this weekend's free trade negotiations at the Summit of the Americas with
page requests and e-mail messages.  ...  Dorothy E. Denning, a computer
crime and security expert at Georgetown University, thought the group
deserved to be regarded as a political, rather than a criminal,
organization. "They operate openly and publicly," Denning said. "They also
try to operate by a democratic principle, meaning lots of people have to
protest to make it effective."  She was impressed when the group cancelled a
cyber-protest over genetic engineering that had failed to get majority
support in an online vote.

In an effort to disassociate themselves from the "server-side"
denial-of-service attacks that took down Yahoo and eBay last year, the
electrohippies call their technique a "client-side" denial-of-service
attack.

The difference, according to an electrohippie essay called Occasional Paper
No. 1, is that client-side actions require thousands of individuals
(clients) using their PCs to participate in order to be effective, while it
only takes one person to launch a server-side attack. This is the
"democratic principle" that impresses Denning.

Andrés Silva
http://www.ls.fi.upm.es/UDIS/miembros/asilva/index.html

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

Date: Wed, 9 Oct 2002 18:30:16 -0400
From: George.Mannes () thestreet com
Subject: Hazards of online translation and plagiarism

The original correction, from a student newspaper at Washington State
University:
http://www.dailyevergreen.com/nn4/news/index.asp?Story_ID=6923&StoryPage=1
                                                                   
 The Daily Evergreen would like to sincerely apologize for an injustice
 served to the Filipino-American, Spanish-speaking and Catholic communities
 on the front page of Thursday's Evergreen.  The story "Filipino-American
 history recognized" stated that the "Nuestra Senora de Buena Esperanza,"
 the galleon on which the first Filipinos landed at Morro, Bay, Calif.,
 loosely translates to "The Big Ass Spanish Boat." It actually translates to
 "Our Lady of Good Peace."
                                                                   
 Parts of the story, including the translation above, were plagiarized from
 an inaccurate Web site.
                                                                   
 October is Filipino-American History Month. Members of the
 Filipino-American Student Association of WSU will hold events to celebrate
 thier history and culture all month. They should be able to celebrate
 without gross inaccuracies and poor coverage by the Evergreen.
                                                                   
 We hope these groups accept our deep regret.                      

The explanation, from the *Seattle Times*:
  http://seattletimes.nwsource.com/html/localnews/134551307_wsublunder09m.html

George Mannes  www.thestreet.com  1-212-321-5208  george.mannes () thestreet com
14 Wall Street - 15th Floor / New York, NY  10005

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

Date: Fri, 11 Oct 2002 17:12:20 -0400
From: Monty Solomon <monty () roscom com>
Subject: Lying 'Lie Detectors'

Lying 'Lie Detectors', William Safire, *The New York Times*, 10 Oct 2002

Longtime readers of this column have noticed some recurring themes: I'm for
personal privacy and have an affinity for the often-betrayed Kurdish
people.  I despise state-sponsored gambling as well as the form of torture
that calls itself the "lie detector."

Win some, lose some. Losses: Lawmakers are playing the slots, and privacy
has been taking a beating from both government and private snoops. But some
wins: The Kurds we protect in northern Iraq are united and ready to join in
a fight for freedom.  And this week, the polygraph -- that hit-and-miss
machine measuring sweat, speedy heartbeat and other signs of nervousness --
has been discredited as the judge of truth-telling.

After 19 months of study, experts convened by the National Research Council,
an arm of the prestigious National Academy of Sciences, concluded that
"national security is too important to be left to such a blunt instrument,"
and noted pointedly that "no spy has ever been caught [by] using the
polygraph."  ...

http://www.nytimes.com/2002/10/10/opinion/10SAFI.html

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

Date: Fri, 11 Oct 2002 12:17:50 -0400
From: "Michel E. Kabay" <mekabay () cs com>
Subject: Risk of chaining substitutions

OBSERVATIONS: A message to one of my students bounced because his e-mail
service refused the large attachment I had sent him.

He gave me a different e-mail address to use.  I dutifully entered it into
the TO: field in my e-mail client and sent him the file again.

That message bounced and I noticed that it had gone to the original address
instead of to the desired address.

ANALYSIS: Had I simply written the wrong address into the TO field?
Investigation revealed that the e-mail client I am using (Outlook 2000 SR-1
v 9.0.0.4527) cheerfully looked up the e-mail address in my contact list,
found it as his secondary e-mail address, converted the secondary address
into my student's name, then converted the name into his primary address.
These conversions were done entirely without visible notification.  This
sequence of events is repeatable.

WORKAROUND: Right-clicking on the student's name in the TO field did bring
up a little menu that allowed me to force the secondary address to be used.

INTERPRETATION:  My guess is that 
(1) Someone decided that when one types a name into the TO: field, it's
helpful to look up the e-mail address and plug it into place while still
showing the name; thus a name becomes underlined when there's a match.  So
far so good: very useful and unobjectionable.

(2) Someone (else?) decided that the opposite change would also be useful;
i.e., if one writes an e-mail address into a destination field, the program
automatically looks it up and shows the underlined name instead of the
address.  Also reasonable.

(3) Now a tricky bit: someone decided to allow multiple e-mail addresses in
the Contact list.  However, the conversion from a name into an e-mail
address always uses the *referred* address -- and there is no notification
of this choice.  Also reasonable, albeit on shakier grounds.  After all, if
there is a preferred address, we ought to use it, right?  And if we need to
change it, presto! There's a pop-up menus that lets us choose from the
alternate addresses.  Great! Works fine.

(4) Ah, now we hit pay dirt: someone decided to allow steps (2) and (3) to
work in sequence without user intervention.  And there we have it: typing an
alternate address into a destination field silently converts it to the
*wrong address*.

LESSONS FOR DESIGNERS:  
1. If you override your users' inputs and propose to change their entry to
what you think is better, tell them you're doing so and let them refuse the
change.

2. Don't link a series of operations together without thinking about the
consequences of that chain of operations.

M.E. Kabay, PhD, CISSP, AssocProf InfoAssur, Dept CompInfoSys, 
Norwich University, Northfield VT  mkabay(at)norwich(dot)edu

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

Date: Fri, 11 Oct 2002 11:32:32 -0400
From: "Fuzzy Gorilla" <fuzzygorilla () euroseek com>
Subject: Nigerian use of technology in elections

Nigerian officials are investing $30 million in technology (including
BioLink fingerprint scanning) in hopes that next April's presidential
election -- their first under a civilian government in 42 years of statehood
-- will be peaceful.  A trial run in late September resulted in riots after
would-be voters were informed there were no more registration forms
(apparently having been hoarded by lower-level officials -- 70M were printed
for 60M supposed eligible voters), with reports of shootings, lootings and
takeovers of government and business facilities as well.  The fingerprints
will hopefully prevent voters registering more than once, especially with
multiple identities.  [Source: Nigeria Vote: Peace Through Tech?  Michelle
Delio, Lycos/wired.com, 11 Oct 2002; PGN-ed]
  http://www.wired.com/news/politics/0,1283,55702,00.html

  [Perhaps the Nigerians are still using the old African technique of
  putting a pebble into one of several competing jars.  Assuming no
  fraudulent pebbles are introduced and the pebbles are all similarly sized
  if you want to avoid actually counting them, that scheme might actually be
  more trustworthy than all-electronic voting in the absence of any
  assurance that your vote will be counted correctly (as noted previously in
  RISKS).  The pebble scheme is clearly not rock-et science, but the
  opportunities for rocking the ballot box still seem to be considerable.
  But the idea of using biometrics in the voting process may merely move
  fraud around to other parts of the process, especially if the other parts
  are inherently not trustworthy.  PGN]

  [Incidentally, PGN asked our long-time election technology expert on this
  subject to comment.  This was her response:]

    Not only that, but this also brings up a lot of human rights issues.
    Sure, "democracies" might want us to ante up our biometrics to the
    government for the "privilege" of voting.  Makes one almost want to live
    in a dictatorship!  Rebecca Mercuri

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

Date: Thu, 10 Oct 2002 10:54:12 +0200
From: George Russell <ger () tzi de>
Subject: Re: Butterfly ballots and electronic counting (Erickson, RISKS-22.29)

Remind me, how much did the Presidential candidates in 2000 spend on
television advertising again?  Don't you think it might have been better
to have spent, say, 10% of that on getting the votes counted properly?

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

Date: Thu, 10 Oct 2002 19:35:42 -0700
From: "Toby Gottfried" <toby () gottfriedville net>
Subject: Re: Butterfly ballots and electronic counting (Erickson, RISKS-22.29)

That means *millions* of votes have to be counted in a few hours.

"have to be"?

Only because our society (mainly the news media) is obsessed with instant
gratification.

Oh, the horror of going to bed on election night not knowing ... not finding
out until the next morning or the day after that ... the uncertainty ... the
waiting ... what ever would we do ?

Most US elections don't take effect until at least a couple of months later
(November to January for national elections).

Out of those 60 or so days, I could spend the first two or three not knowing
an election outcome.  Unfortunately, the TV news people can't.

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

Date: Wed, 09 Oct 2002 14:31:43 -0700
From: anon123 () japan com
Subject: Re: Butterfly ballots (Russell, RISKS-22.28)

The California Constitution puts the burden for counting votes on the voter,
not the government:
  SEC. 2.5.  A voter who casts a vote in an election in accordance
  with the laws of this State shall have that vote counted.

RISK of poorly worded laws?  "A voter...shall..." vs. "the state shall count
that vote."

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

Date: Thu, 10 Oct 2002 15:09:30 +0100
From: Tony Finch <dot () dotat at>
Subject: Re: Butterfly ballots and other election stuff (Olsen, RISKS-22.29)

In the UK each elected position has its own ballot paper, so you will often
have to mark more than one piece of paper at the polling station. This
allows the votes for each post to be counted in parallel, and it means that
recounts can be done efficiently because counting for the second post does
not mess up the sorting of the ballot papers for the first post.

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

Date: Thu, 10 Oct 2002 12:32:31 +0100 (BST)
From: David Damerell <damerell () chiark greenend org uk>
Subject: Re: Butterfly ballots

Also, look up the population of Florida and compare it with the
population of Britain.

OK... Florida's population is about 16 million. Britain's population is
about 60 million. So I'm not sure what the point is here, especially since
our counting system would scale perfectly well to a population of 600
million.

The solution to the long ballot problem is surely to put the important
selections on a separate ballot that can be easily hand-counted, and let the
(existing, well-understood) machines deal with the assistant dog-catchers
and whatnot.

David Damerell <damerell () chiark greenend org uk>

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

Date: Thu, 10 Oct 2002 00:47:51 -0400
From: Scott Nicol <snicol () apk net>
Subject: Re: Butterfly ballots

The US has about double the per capita GDP of Britain.  If the Brits can
afford it, the US certainly can.  As for trained volunteers, you'd have them
if you recruited and trained them.  It's got to be less effort than what is
put into the census.

  [Scott also noted the relative populations... PGN]

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

Date: Wed, 9 Oct 2002 16:59:07 -0700 (PDT)
From: Ulf Lindqvist <ulf () sdl sri com>
Subject: Re: Weak encryption kills wolves (Fredriksson, RISKS-22.29)

The original article in *Dagens Nyheter* does not mention encryption per se
and there is no indication that any encryption has been broken (the phrase
"broken the code" is probably used in a very generic sense).  The statement
that anyone could triangulate the current transmitters makes me suspect that
they are either (a) not even transponders, but transmit a signal at regular
intervals, or (b) simple transponders that are activated by a simple tone
signal or similar. In case (a), encryption of the signal content would not
prevent triangulation of the radio signal by unauthorized parties.  In case
(b), encryption of the activation signal would make it harder for the
hunters to activate the transponder, unless replay attacks were possible. Of
course, as long as it is active, anyone could triangulate the transponder.

What would be a better system, from the point of view of the wolves and the
researchers?  If the wolves could be fitted with GPS receivers, the
transmitter could use encryption and more advanced radio techniques to send
its position to the authorized receiver, as no triangulation would be
needed.

Ulf Lindqvist, System Design Lab, SRI International, 333 Ravenswood Ave,
Menlo Park CA 94025-3493, USA +1 650 859-2351 http://www.sdl.sri.com/

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

Date: Sun, 13 Oct 2002 20:17:02 +0200
From: Erling Kristiansen <erling.kristiansen () xs4all nl>
Subject: Re: Weak encryption kills wolves (Fredriksson, RISKS-22.29)

It seems to me that encryption is not really the issue here. Encryption
could hide the identity of a particular wolf, but would not hide the radio
signal as such. There is likely to be very few radio transmitters in "wolf
country", so if you find a signal on the right frequency, it is likely to
come from a wolf transmitter.

What is called for is a means to make detection of the signal itself
difficult/impossible. Spread spectrum techniques spring to mind: By
spreading the radio signal over a wide frequency spectrum, detection is
impossible unless you know how the spreading was done, and are able to
"de-spread" the signal. In other words, you hide the signal in the noise for
anybody not having the code to extract it.

Spread spectrum is used in military systems for exactly this reason.  (And
used in mobile telephony, but for other reasons that are not relevant to
this subject)

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

Date: Tue, 8 Oct 2002 12:42:20 -0800
From: Rob Slade <rslade () sprint ca>
Subject: REVIEW: "Information Warfare", Michael Erbschloe

BKINFWFR.RVW   20020721

"Information Warfare", Michael Erbschloe, 2001, 0-07-213260-4, U$29.99
%A   Michael Erbschloe
%C   300 Water Street, Whitby, Ontario   L1N 9B6
%D   2001
%G   0-07-213260-4
%I   McGraw-Hill Ryerson/Osborne
%O   U$29.99 800-565-5758 905-430-5134 fax: 905-430-5020
%P   315 p.
%T   "Information Warfare: How to Survive Cyber Attacks"

In both the preface and the introduction, the author makes a point of
stating that this book is different from others in the field, that it does
not simply use the old military paradigm to analyze information warfare,
and, as a result, will be more useful to business.  It is, therefore, rather
startling to find, in chapter one, background basics that stick strictly to
the military model.  Everything is presented purely from the perspective of
single attacker and single defender, and it's definitely black hat versus
white.  The model thus constructed is weak in several areas, and would not
seem to be able to even address a number of issues.  For example, writers
such as Dorothy Denning (cf. BKINWRSC.RVW) postulate the potential harm that
can arise from corrupted data and other misinformation, which may be used
for purposes ranging from propaganda to degrading decision systems.  And
what do we do about business situations, where today's colleague may be
tomorrow's competitor?  Chapter two uses profligate verbiage to list a few
points about economic impacts that will come as no surprise whatsoever to
anyone with the slightest background in business impact analysis.  In
chapter three, Erbschloe turns to fiction.  He proposes a scenario in which
a gang of cyber-terrorists causes one trillion dollars worth of damage.  In
doing so, the author demonstrates that a) his experience in information
warfare is limited to viruses, b) his experience with viruses is limited to
Loveletter, and c) he believes all the movie stereotypes about "hackers."
Black hat communities are seldom as cosmopolitan as the one proposed.  They
are never as original: multiple viruses based on the model used would
quickly be caught by generic means.  It is also a lot easier to write simple
virus variations than it is to break into specific targeted systems for
specific targeted information.

We are told, in chapter four, that in order to fight against the information
warfare threat, all governments and militaries must get together.  (Can we
hear a chorus of "And do it my way!" swelling in the background?)  Then we
have a relay of military strategies in chapter five.  Supposedly chapter six
turns to corporate strategies, but with the emphasis on terrorists and the
FBI, we seem to be back to the military again.  A number of tables are used
to assert that terrorists and rogue criminals are interested in attacking
various industries.  (Proof of these statements seems to be singularly
lacking.)  Chapter eight lists companies proposed to be in the "information
warfare" reserve: able to provide expertise in the event of an attack.  In
light of the recent business debacles, these lists unintentionally provide
some of the most humorous reading in the book.  (For those who know the
security problems of some of these companies, the lists are even funnier.)

Tellingly, the material on the civilian "casualties" of infowar, in chapter
nine, is the most restricted in the book.  Chapter ten seems to move into
fiction again.  Erbschloe, without much in the way of evidence, says that
the "geek in the basement" brigade is now about to turn pro, en masse.  (He
also states that we are going to have a skilled and active black hat
population of 600,000 by 2005.)  The statement, in chapter eleven, that we
need more skilled law enforcement people is unsurprising, and also
unhelpful.  The conclusion, in chapter twelve, that we need more money and
attention for security is equally useless.

This is a verbose reiteration of minor points that are evident to anyone
with any background in security, let alone specialists in the information
warfare field.  Mind you, the book was probably not intended for experts.
However, readers with no knowledge of data security are likely to be misled.
They will feel that they have been taught about information warfare.  They
haven't.

copyright Robert M. Slade, 2002   BKINFWFR.RVW   20020721
rslade () vcn bc ca  rslade () sprint ca  slade () victoria tc ca p1 () canada com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

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

Date: Wed, 9 Oct 2002 17:20:39 -0400 
From: Gary McGraw <gem () cigital com>
Subject: DIMACS Workshop on Software Security

Dates: January 6-7, 2003
Location: DIMACS Center, CoRE Building, Rutgers University

Organizers: 
  Gary McGraw, chair, Cigital, gem () cigital com 
  Ed Felten, Princeton University, felten () cs princeton edu 
  Virgil Gligor, University of Maryland, gligor () umd edu 
  Dave Wagner, University of California at Berkeley, daw () cs berkeley edu 

Invited Speakers:
* Brian Kernighan, Princeton University: 
  Coding Excellence: Security as a Side Effect of Good Software 
* Michael Howard, Microsoft: 
  The Microsoft Trustworthy Computing Initiative from the Inside
* Dan Geer, @STake:
  Software Security in the Big Picture: Repeating ourselves all over again
  
WWW Information: http://dimacs.rutgers.edu/Workshops/Software/

The security of computer systems and networks has become increasingly
limited by the quality and security of the software running on these
machines.  Researchers have estimated that more than half of all
vulnerabilities are due to buffer overruns, an embarrassingly elementary
class of bugs.  All too often systems are hacked by exploiting software
bugs.  In short, a central and critical aspect of the security problem is a
software problem.  How can we deal with this?

The Software Security Workshop will explore these issues. The scope of the
workshop will include security engineering, architecture and implementation
risks, security analysis, mobile and malicious code, education and training,
and open research issues.  In recent years many promising techniques have
arisen from connections between computer security, programming languages,
and software engineering, and one goal is to bring these communities closer
together and crystallize the subfield of software security.

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

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.30
************************


Current thread: