RISKS-LIST: Risks-Forum Digest Saturday 12 February 2005 Volume 23 : Issue 71
ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
<http://catless.ncl.ac.uk/Risks/23.71.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Australian Frigate reversed onto rocks by computer override (Anton Lak)
More uses of satnav/GPS (David Magda)
Urology medical student residency "matching" process failure
(Daniel Kahn Gillmor)
Congressman Ron Paul R-TX Understands Risks and Countermeasures (Larry Sudduth)
Flexibility destroys identity uniqueness: Implementing of IDN (Jon Lingard)
Exploding cell phone shocks 911 dispatcher (Keith A Rhodes)
RFID Tagging Elementary School Children (Peter H. Coffin)
The risk of high-speed CD/DVD-rom drives in current-day PCs (Henk Langeveld)
You type Zuerich and I type Zurich... A brief note (David G. Bell)
Another MS Word info leak (Richard Akerman)
High Risk Vulnerabilities in Eudora for Windows (NGSSoftware via Monty Solomon)
Re: U of Calgary adding spam and spyware (Hendrik, Matthew Holmes)
Re: Food via inkjet printer (Brian Reynolds)
Minireview: Bill Neugent, No Outward Sign (PGN)
REVIEW: "A History of Computing Technology", Michael R. Williams (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 10 Feb 2005 11:17:02 +1100
From: <anton_lak@private>
Subject: Australian Frigate reversed onto rocks by computer override
Computer overrides the crew and reverses the Frigate onto rocks, a classic
risk of such automation.
http://www.news.com.au/story/0,10117,12204297-26618,00.html
Frigate on the rocks, By Ian McPhedran, 10 Feb 2005
The [Royal Australian] navy's newest $500 million warship was driven
backwards on to Christmas Island after crew error caused computers to take
control of the frigate. A series of errors prompted the computer system to
over-ride manual commands and the ship's company had to stand by and watch
as HMAS Ballarat backed on to the rocky shoreline. The 3600-tonne high-tech
Anzac class frigate, delivered last April, carries a missile-armed
helicopter and has a 127mm gun, torpedoes and missiles.
The 22 Jan incident damaged both propellers and the rudder and left
taxpayers with a bill of about $2 million and the navy with a major
headache. The debacle began when the ship was conducting a boat transfer
during a planned U-turn manoeuvre. It was operating in "port echo" or
economy mode at the time.
*The Daily Telegraph* has been told the move was supposed to take the
warship inside a buoy which had another ship's mooring line attached to it.
As the ship approached the buoy it became clear to the crew on the bridge
that it would not make it and would pass over the line, so they attempted to
make an urgent "three-point" turn. This was when things started to go
seriously wrong.
Because the ship had only one of its three engines running, the crew tried
and failed to run one propeller forward and one astern to conduct the
radical turn. Such a move is impossible with just one engine running. At
this point the control system froze, the ship's computer took over and
placed both propellers into reverse. It shut down the engine soon
afterwards, but by that stage the ship was travelling in reverse at a couple
of knots.
[Essentially the same article, with *The Daily Telegraph* replaced with
*The Courier-Mail* (Brisbane) was submitted by David Tombs. PGN]
http://www.couriermail.news.com.au/common/story_page/0,5936,12199057%255E953,00.html
------------------------------
Date: Sat, 12 Feb 2005 10:05:15 -0500
From: David Magda <dmagda@private>
Subject: More uses of satnav/GPS
BBC news is reporting [1] that British Rail is thinking of use sat-nav / GPS
to help keep trains running on time.
I hope they realize that GPS may be shut off by the US government during
emergencies or terrorist acts (see RISKS 23.62). Hopefully someone will at
least think about using Galileo [2] as a back up, or even better, use
inertial guidance [3] as the primary system with satellite navigation as the
backup system.
The same concerns are applicable to any transportation system (e.g., cars,
boats, airplanes).
[1] http://news.bbc.co.uk/2/hi/science/nature/4247721.stm
[2] http://www.esa.int/export/esaNA/galileo.html
[3] http://en.wikipedia.org/wiki/Inertial_navigation
------------------------------
Date: Tue, 1 Feb 2005 01:52:43 -0500
From: Daniel Kahn Gillmor <dkg@private>
Subject: Urology medical student residency "matching" process failure
Source: http://blogborygmi.blogspot.com/2005/01/selection-dysfunction.html
Medical students don't just apply for residency positions at graduation --
they "match" into them. The students rank their favorite programs, the
hospitals rank their favorite students, and everyone hopes for the best as
an algorithm puts them together. This process, more or less unchanged for
decades, across many specialties, went terribly wrong last week during the
urology match ...
Basically, they had to run the match again (with different outcomes) a few
days after announcing the first results. This is huge in the lives of the
prospective doctors because a residency determines where you will live and
what you will do for many years.
According to the discussion boards, the AUA (American Urology Association?)
has blamed the mismatch on a misconfigured computer algorithm, which was
only discovered because some top-ranked residency programs were unfilled,
which supposedly never happens.
So, why wasn't a human reviewing the results of the match for reasonableness
before publication? Why aren't the algorithms used in the match process
freely available? What safeguards are there on the data-entry step (since
GIGO continues to apply)? Why isn't there an audit process in place?
[It could have been worse. Suppose someone was matched who was reportedly
an expert in Eurology (e.g., an economist in Brussels)... PGN]
------------------------------
Date: Thu, 10 Feb 2005 18:42:33 -0500
From: Larry Sudduth <sudduthlm@private>
Subject: Congressman Ron Paul R-TX Understands Risks and Countermeasures
As early as RISKS-6.73, consequences of automated sharing of driver license
information have been discussed. While the appropriateness of
countermeasures levied against risks has been a fundamental element of
RISKS since its inception, the mention in RISKS-2.20 of Mann's article
(http://www.theatlantic.com/doc/prem/200209/mann) marked the beginning of a
(still nascent) popular tendency to review countermeasures for
appropriateness, all the more so since the Patriot Act and successors.
I'm happy to learn that at least one congressman, Dr. Ron Paul, (R) TX, gets
it. I'm unhappy that it is not one of my congressmen -- I'm from Virginia
-- but maybe mine will learn from their Texas colleague!
H.R. 418, the "Immigrants ID bill" or "REAL ID Act of 2005," is advertised
in part as establishing and rapidly implementing "regulations for State
driver's license and identification document security standards, to prevent
terrorists from abusing the asylum laws of the United States, to unify
terrorism-related grounds for inadmissibility and removal." (See
http://thomas.loc.gov/cgi-bin/bdquery/z?d109:h.r.00418:)
The Honorable Dr. Paul characterizes HR 418 as a National ID Card bill
masquerading as immigration reform. The clarity and brevity of his comments
merit reading, both from an infosec perspective as well as a countermeasures
perspective (http://www.house.gov/paul/congrec/congrec2005/cr020905.htm,
excerpted and LMS-ed below:
" ...this bill will do very little to make us more secure. It will not
address our real vulnerabilities. It will, however, make us much less
free. In reality, this bill is a Trojan horse. It pretends to offer
desperately needed border control in order to stampede Americans into
sacrificing what is uniquely American: our constitutionally protected
liberty."
"This bill establishes a massive, centrally-coordinated database of highly
personal information about American citizens: at a minimum their name,
date of birth, place of residence, Social Security number, and physical
and possibly other characteristics ... that will be shared with Canada and
Mexico!"
"This legislation gives authority to the Secretary of Homeland Security to
expand required information on drivers' licenses, potentially including
such biometric information as retina scans, finger prints, DNA
information, and even Radio Frequency Identification (RFID) radio tracking
technology."
"There are no limits on what happens to the database of sensitive
information on Americans once it leaves the United States for Canada and
Mexico - or perhaps other countries. Who is to stop a corrupt foreign
government official from selling or giving this information to human
traffickers or even terrorists? Will this uncertainty make us feel safer?"
Security practitioners know better than most the aptness of the saying, "err
in haste, repent at leisure." I hope Representative Paul's common-sense
proves to be contagious before HR 418 comes to a floor-vote.
Larry Sudduth 703.845-5-eight-33
------------------------------
Date: Thu, 10 Feb 2005 05:39:23 +0000
From: Jon Lingard <j.lingard@private>
Subject: Flexibility destroys identity uniqueness: Implementing of IDN
It is now possible to spoof the URL displayed in the address bar, SSL
certificate, and status bar of a browser, due to the increased flexibility
brought about by the IDN (International Domain Name) implementation, which
allows using international characters in domain names. This can be
exploited by registering domain names with international characters that
resemble commonly used characters.
See security details here: http://secunia.com/advisories/14163
http://www.sapstrategy.com/
[This is another old topic in RISKS, but as Jon points out, it is
now even easier to fool more people. For example, see
Evgeniy Gabrilovich and Alex Gontmakher, The Homograph Attack,
*Communications of the ACM*, vol 45, no 2, Feb 2002,
netscape http://www.csl.sri.com/~neumann/insiderisks.html#140
which has normally been
netscape http://www.csl.sri.com/neumann/insiderisks.html#140
but a massive reorganization of the CSL Web structure is underway
at the moment, and the usual URLs and cross-links do not seem to be
working yet today. (If internal links fail, stick in the tilde.)
PGN]
------------------------------
Date: Thu, 10 Feb 2005 08:25:16 -0500
From: "Keith A Rhodes" <RhodesK@private>
Subject: Exploding cell phone shocks 911 dispatcher
http://news.com.com/Exploding+cell+phone+shocks+911+dispatcher/2100-1039_3-5570105.html?tag=nefd.top
How ironic that this would happen to a 911 dispatcher.
http://news.com.com/Symantec+flaw+leaves+opening+for+viruses/2100-1002_3-5569811.html?tag=nefd.top
and the hits just keep on coming.
------------------------------
Date: Fri, 11 Feb 2005 20:17:05 -0600
From: "Peter H. Coffin" <hellsop@private>
Subject: RFID Tagging Elementary School Children
http://www.msnbc.msn.com/id/6448213/did/6942751/
The only grade school in Sutter, California is requiring students to wear
radio frequency identification badges that can track their every move. Some
parents are outraged, fearing it will rob their children of privacy. The
badges introduced at Brittan Elementary School on 18 Jan 2005 rely on the
same radio frequency and scanner technology that companies use to track
livestock and product inventory.
While similar devices are being tested at several schools in Japan so
parents can know when their children arrive and leave, Brittan appears to be
the first U.S. school district to embrace such a monitoring system.
Civil libertarians hope to keep it that way. [PGN-ed]
I trust no one reading RISKS has any troubles imagining many ways to
foil this system. "Karen, I wanna ditch. Carry my tag in your backpack?"
[That's why they will be embedded in babies' navels at birth. PGN]
------------------------------
Date: Wed, 02 Feb 2005 22:54:00 +0100
From: Henk Langeveld - risks digest <risks@private>
Subject: The risk of high-speed CD/DVD-rom drives in current-day PCs
I've had the nasty experience to have lost four CD's to newer high-speed CD
and DVD-drives within a year.
The current state of technology will run CDs and DVDs at high speeds, and
the centrifugal force of the drive increases the risk of any scratch on the
media to result in one broken CD, and one ruined drive.
[Drew Dean commented to me on this: ``I believe programs such as Exact
Audio Copy (EAC) do slow down the drive, and most CD/DVD burning software
can write at slower speeds, but I'm not aware of any interface to tell an
OS to always slow down reading.'' PGN]
------------------------------
Date: Thu, 10 Feb 2005 09:18:24 +0000 (GMT)
From: dbell@private ("David G. Bell")
Subject: You type Zuerich and I type Zurich... A brief note
There's been one of those idiosyncratic discussions in rec.arts.sf.fandom on
the details of library catalogues and author's names, and the most recent
issue of RISKS has sort of bounced off it.
Zuerich is, I understand, a quite correct "english" version of the Swiss
placename.
Most english-speakers will type "Zurich", similar to the native version but
using an ordinary ASCII "u", just as all sorts of other accent marks get
missed from European-language names.
And now Unicode allows computers to store all the variations as unique
codes, which is good for typesetting, but has potential for confusion
between visually similar characters. Not everyone will be exploiting that
confusion for entertainment, as happened in "Monty Python and the Holy
Grail".
But will search engines and indexes get tripped up by the differences, both
correct alternatives and mistakes? Google does suggest alternatives to some
spelling errors and variants, but how far do you go?
David G. Bell -- SF Fan, Filker, and Punslinger.
[But do American search engines handle Zürich properly? PGN]
------------------------------
Date: Fri, 4 Feb 2005 14:05:48 -0400 (AST)
From: Richard Akerman <rakerman@private>
Subject: Another MS Word info leak
Just another example of the risks of Word features. Not quite in the league
of the 'dodgy dossier' but still.
'The press release looked pretty unremarkable at first. The McGill
University Health Centre announcing an increased risk of heart attack in
elderly people with no prior history of heart attack who use the painkiller
Vioxx (which is now off the market).
The writing is a bit technical, but pretty clear.
But when press release writers compose these things, they have to run a copy
past the scientist involved. His comments in the margin of the final draft
were inadvertently sent out to everyone on the mailing list. They're meant
to be "blind" -- visible only to a specified reader -- but they were in fact
visible on computers with Windows XP and Microsoft Word 2003.'
Fortunately for everyone involved, the scientist didn't say anything
particularly controversial.
Source: "Secret comments that everyone can read", Tom Spears, Ottawa Citizen,
3 Feb 2005.
http://tinyurl.com/43dhg
http://www.canada.com/ottawa/ottawacitizen/news/story.html?id=d694b933-e82f-44b9-8732-97ef135d116f
Richard Akerman http://www.akerman.ca/
------------------------------
Date: Tue, 8 Feb 2005 21:42:44 -0500
From: Monty Solomon <monty@private>
Subject: High Risk Vulnerabilities in Eudora for Windows
http://www.ngssoftware.com/advisories/eudora-01.txt
John Heasman of NGSSoftware has discovered multiple high risk
vulnerabilities in the Windows version of Eudora.
Versions affected include:
Eudora 6.2.0 and below
The flaws permit execution of arbitrary code via:
1) previewing or opening a specially crafted e-mail
2) opening specially crafted stationary or mailbox files
These issues have been resolved in Eudora 6.2.1 as detailed at
http://www.eudora.com/security.html
It can be downloaded from:
http://www.eudora.com/products/
NGSSoftware are going to withhold details of this flaw for three months.
Full details will be published on the 2nd of May 2005. This three month
window will allow users of Eudora the time needed to apply the patch before
the details are released to the general public. This reflects NGSSoftware's
approach to responsible disclosure.
NGSSoftware Insight Security Research
http://www.databasesecurity.com/
http://www.nextgenss.com/
+44(0)208 401 0070
------------------------------
Date: Fri, 11 Feb 2005 10:54:34 +0900
From: Hendrik <hiz--asa4@private>
Subject: Re: U of Calgary adding spam and spyware (Slade, RISKS-23.70)
The risk of not learning what needs to be learned!
It's about time this was done! :-)
In 1992 I found a small book in a bookstore in Saudi Arabia, that had been
published by the German "Kaos Computerclub". In this book the authors
explained how viruses worked, from an angle of approach of how to write
viruses (at that time we had to deal mostly with DOS boot sector viruses).
The authors further described how they had approached major software
companies with this information, none of whom was the least bit interested
in the information or in any cooperation with people who knew how to write
viruses. Some of the approached companies had furthermore warned the
authors against publishing the information about viruses they had on hand.
I am not impressed, to say the least, that 13 years after the Kaos
Computerclub had the right idea, in a world awash in viruses, worms, and
spam, with a world-wide deployed home computer OS that seems to have less
security than the front door of my house, we still have not made any
progress in regards to how we deal with knowledge about malware.
In the the CBC article that Rob Slade refers to, Aycock (the "virus teacher"
at UofC) is quoted as saying "[S]ome companies have said they're not going
to hire [our] graduates because they don't like the perception of having
someone on board who has written viruses."
Well, I imagine reading the following in Time Magazine: "The White House
official said, 'We are not going to hire body guards who have been trained
at school X because we don't like the perception of having someone on staff
who has been trained to kill.'" Would you forgive me for laughing?
Rob Slade further writes:
>I can vaguely see a dim advantage to having students write viruses in order
>to understand them (rather inefficiently, in terms of time spent), but
>getting them to write a spamming program in order to understand how to fight
>spam seems even less effective.
Not all approaches to learning something are equally effective, and in an
area where something is being pioneereed, the first steps may not be quite
in the right direction or not as effective as future approaches. But that
alone is not a good reason to abolish a certain curriculum. My question
would be "What would make this training more effective?"
>As previously noted, John Aycock doesn't seem to have any credentials in
>security or malware [...]
Assuming this is relevant (it may be but need not be - i would suggest that
anybody who is a well-trained programmer and has the requisite imagination
has in principle the necessary credentials) why not call for a more
qualified professor for that course, then, instead of suggesting this
training is a bad idea?
I hope one day we will see malware courses in all university computer
science programs - then i would have reason to be more optimistic that the
"security mess" we are finding ourselves in might be cleaned up.
Creativity, more than anything else, is what we need to deal with the
future, and anybody who fosters and harnesses such creativity has my vote.
:-)
[RISKS readers should see George Ledin's article,
Not Teaching Viruses and Worms Is Harmful
in the Inside Risks column space of the January 2005 issue of the
*Communications of the ACM*, vol 48, no 1. This article is also available
online on my Web site
http://www.csl.sri.com/~neumann/insiderisks05.html#175
The normal URL has always been
http://www.csl.sri.com/neumann/insiderisks05.html#175
PGN]
------------------------------
Date: Sat, 12 Feb 2005 11:23:26 -0500
From: "Matthew Holmes" <matt@private>
Subject: Re: U of Calgary adding spam and spyware (Slade, RISKS-23.70)
> ... John Aycock doesn't seem to have any credentials in security or
> malware ..., so why he, and the university, chose to do this, other than
> pure self-promotion, is completely beyond me.
Hmmmm - who does have "credentials" in these fields? Is there a "mal-ware"
certification board? I must have missed it.
I did survey Aycock's professional literature, much of which is available
on-line, and I notice that a great deal of it centers on reverse-engineering
methodology, compiler/parser theory, etc. These are in fact the tools of the
virus writer - the real ones, not the script kiddies and buffer-overflow
people.
Why the snippy tone in a RISKS article?
------------------------------
Date: Thu, 10 Feb 2005 12:07:55 -0500
From: Brian Reynolds <bfr@private>
Subject: Re: Food via inkjet printer (Re: Scrivner, RISKS-23.70)
These setups have been around for years. The last time I saw this was
several years ago on the old leben.com epson-inkjet list. The printer was
a standard Epson model. There were warnings not to use standard inks in a
printer intended for food printing.
One method of doing this involves printing the image onto a potato starch
sheet using the food color inks and then affixing the sheet to the food item
(e.g., a cake). Here in the USA Baskin & Robbins offers a service to print
an image to be put on one of their ice cream cakes.
------------------------------
Date: Fri, 11 Feb 2005 20:53:58 PST
From: Peter G Neumann <neumann@private>
Subject: Minireview: Bill Neugent, No Outward Sign
Bill Neugent
No Outward Sign
2002
IUniverse.com
ISBN 0-595-25749-6
http://www.amazon.com/exec/obidos/ASIN/0595257496
Bill Neugent's web site is at www.TaleCatcher.com.
e-mail: wneugent at mitre.org
Bill (in his work at MITRE) has been on the inside of computer security for
many decades. I just finished reading his novel, and found it delightful,
and excellent piece of cybersecurity fiction. It is a well-written
page-turner. It is soundly based on things that have happened or could
easily happen, but threads them all together very nicely through a twisty
plot. It twits the oxymoron of computer security, and brings together
good-hacker motivations, government bureaucracies, international
cyberthreats, short-sighted optimizations, and many other issues familiar to
RISKS readers.
The book is now available apparently only on the Internet, so I have
included a URL.
------------------------------
Date: Fri, 11 Feb 2005 08:32:32 -0800
From: Rob Slade <rslade@private>
Subject: REVIEW: "A History of Computing Technology", Michael R. Williams
BKHSCMTC.RVW 20041018
"A History of Computing Technology", Michael R. Williams, 1997,
0-8186-7739-2, U$64.95/C$104.95
%A Michael R. Williams
%C 10662 Vaqueros Circle, Los Alamitos, CA 90720-1314
%D 1997
%G 0-8186-7739-2
%I IEEE Computer Society Press
%O U$64.95/C$104.95 714-821-8380, 800-CS-BOOKS c.baltes@private
%O http://www.amazon.com/exec/obidos/ASIN/0818677392/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0818677392/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0818677392/robsladesin03-20
%O tl i rl 4 tc 3 ta 4 tv 4 wq 4
%P 426 p.
%T "A History of Computing Technology"
Yet another timeline from the Pascaline to Babbage to ENIAC? Not so. How
refreshing, and fascinating, to see a history that really tells us how we
got here.
Chapter one talks about the development of numeration itself, and the
various forms of representing numbers (as well as a few systems of
calculation). Early aids to calculation, starting with fingers and moving
through to slide rules, are described in chapter two. Throughout the book,
Williams has included frequent references to how calculating tools and
techniques have given rise to common phrases. The definition of "point
blank" is particularly fascinating, involving not only a particular gunnery
instrument, but also the distrust of the Arabic numeral zero, which paranoia
would have been uniquely strong at that specific time. Mechanical
calculators are discussed in chapter three, covering much more than the
usual reference to the Pascaline. Chapter four outlines Babbage's machine;
noting that he was more social than is usually thought, and that he
succeeded in a number of fields (inventing, for example, the cow catcher);
explains why the Difference Engine is known as such, and further mentions
that it was hardly a failure, but spawned a bit of a building spree that
lasted over twenty years. Analog, rather than digital, computers are often
neglected, but chapter five notes a number of significant devices. The
large mechanical or electro-mechanical machines of the 1940s are frequently
seen as the beginning of the computer revolution, so it is interesting that
the book is half complete before chapter six takes a look at the Zuse
machines, the Bell relay machines, and Aiken's line. Chapter seven moves
into the electronic world with reviews of the Atanasoff/Berry computer,
ENIAC, and the Colossi. Given the importance of the work at Bletchley Park
in terms of character manipulation (in cryptanalysis) it is interesting that
other forms of text manipulation technology have not been addressed up to
this point. The early computers dealing with stored programs are reviewed
in chapter eight. As could be expected, the development of memory
technologies is a major component of this material. Chapter nine finishes
off with a review of some other early mainframe type computers.
We tend to pass over the history of computing with varying degrees of
interest. Having a detailed examination of the development of both ideas
and technologies of the basics of computing is both fascinating and helpful.
Those who ignore the history of computing are likely to buy it again,
repackaged under a new name. Professionals willing to understand the
foundations of the industry and operations of the machinery will be in a
much better position to judge what will (and what will not) be of importance
in the future.
copyright Robert M. Slade, 2004 BKHSCMTC.RVW 20041018
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: 29 Dec 2004 (LAST-MODIFIED)
From: RISKS-request@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. Mailman can let you subscribe directly:
http://lists.csl.sri.com/mailman/listinfo/risks
Alternatively, to subscribe or unsubscribe via e-mail to mailman your
FROM: address, send a message to
risks-request@private
containing only the one-word text subscribe or unsubscribe. You may
also specify a different receiving address: subscribe address= ... .
You may short-circuit that process by sending directly to either
risks-subscribe@private or risks-unsubscribe@private
depending on which action is to be taken.
Subscription and unsubscription requests require that you reply to a
confirmation message sent to the subscribing mail address. Instructions
are included in the confirmation message. Each issue of RISKS that you
receive contains information on how to post, unsubscribe, etc.
INFO [for unabridged version of RISKS information]
.UK users should contact <Lindsay.Marshall@private>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
<http://www.CSL.sri.com/risksinfo.html>
The full info file may appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risks@private with meaningful SUBJECT: line.
*** NOTE: Including the string "notsp" at the beginning or end of the subject
*** line will be very helpful in separating real contributions from spam.
*** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
<http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
Lindsay 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/> .
==> 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 23.71
************************
This archive was generated by hypermail 2.1.3 : Sat Feb 12 2005 - 22:02:11 PST