RISKS-LIST: Risks-Forum Digest Thursday 24 August 2006 Volume 24 : Issue 39
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/24.39.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Pull the Plug on Touchscreens (R. Mercuri)
Re: Pull the Plug on Touchscreens (Avi Rubin)
More on Diebold, Ohio, and Touchscreens (PGN)
Search Engine Privacy Dilemmas, and Paths Toward Solutions (Lauren Weinstein)
Centrelink staff busted invading Australians' privacy (David Shaw)
TiVo Is Watching When You Don't Watch, and It Tattles (Monty Solomon)
The SAFEE Project (Peter B. Ladkin)
Re: LA power outages (Kent Borg)
At least the extension cord worked (Mike Albaugh)
Re: ... Your Dell laptop battery must be OK! (Dave Blake, Brent Kimberly)
"IT Security Project Management", Susan Snedaker (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 22 Aug 2006 13:34:21 -0400
From: "R. Mercuri" <notable@private>
Subject: Pull the Plug on Touchscreens
Forbes Magazine (9/4/6) included a commentary by Aviel Rubin where he
complains about the "Help America Vote Act, which handed out $2.6 billion to
spend on voting machines." Avi's recent recommendation is that voters cast
only optically scanned ballots that will be randomly audited. But does he go
so far as to suggest that voters be allowed to prepare these ballots by
hand? Absolutely not. Although I have publicly recommended the adoption of
only scanned paper systems since at least 2003, Avi continues to recommend
electronic ballot preparation methods, such as described in his Forbes
piece, that require all voters to "make their selections on a touchscreen
machine."
If humans are deemed capable enough to audit ballot counts, they should also
be allowed to directly prepare their own ballots without the intervention of
a computer. Most voters already do this, since some 60% of US counties and a
steadily increasing number of mail-ins (such as in CA, FL and NJ where any
voter can register as a permanent absentee) use hand-prepared paper
ballots. Sure, modern technology must be available to provide assistance for
voters who need or want it, but this does not necessarily have to be limited
to "touchscreen machines." Tactile ballots (endorsed by the United Nations,
see <http://www.electionaccess.org/Bp/Ballot_Templates.htm>) and mechanical
devices (such as the Vote Pad <http://www.vote-pad.us/>) offer inexpensive
alternatives that do not require electricity.
So, will this advice help America's voters avoid the use of unreliable or
insecure voting equipment in 2006, 2007, or even 2008? No, because purchases
(costing in excess of $5B, including state allocations and associated
long-term service contracts) are already in place. Avi's change of heart
(he's previously supported vote-tabulating DREs, see
<http://avirubin.com/vote/eac2.pdf>) now favoring optically scanned ballots
is simply too little, too late, and his ongoing endorsement of touchscreen
voting has made him part of the problem, not its solution.
Rebecca Mercuri
------------------------------
Date: Wed, 23 Aug 2006 13:42:21 -0400
From: Avi Rubin <rubin@private>
Subject: Re: Pull the Plug on Touchscreens (Mercuri, RISKS-24.39)
I need to set the record straight on one point. Towards the end of
her posting, Rebecca states that
"[Avi has] previously supported vote-tabulating DREs, see http://
avirubin.com/vote/eac2.pdf"
I urge anyone who is interested to have a look at what I wrote in my EAC
testimony that she references. It is a scathing critique of DREs. I feel
that accusing me of having supported DREs is like accusing Erin Brockovich
of having supported water pollution. I have done nothing but argue and
fight against DREs from day one. If you read my new book, Brave New Ballot
(Random House, 2006), you will see that I have maintained a steady position
on this all along.
Avi Rubin
------------------------------
Date: Wed, 23 Aug 2006 16:08:56 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: More on Diebold, Ohio, and Touchscreens
A report questioning the accuracy of Diebold Election Systems' e-voting
equipment in a recent Ohio election gives more ammunition to critics who
doubt the viability of electronic voting technology. A study of 467 of
5,407 e-voting machines used in the 2 May 2006 primary election in Cuyahoga
County, Ohio, found that one-third of the booth workers had problems setting
up the machines. 45% had problems closing out machines. 38% had problems
with printers or spools. 90% of the voters liked the new systems. 10% of the
voters reported problems with the machines. [Source: Marc Songini, Paper
Trail Flawed in Ohio Election, Study Finds *Computerworld*, 21 Aug 2006]
http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=13&articleId=9002610
------------------------------
Date: Mon, 21 Aug 2006 21:51:46 PDT
From: Lauren Weinstein <lauren@private>
Subject: Search Engine Privacy Dilemmas, and Paths Toward Solutions
An item in *The New York Times*, 22 Aug 2006 neatly encapsulates the overall
state of search engine query data retention issues.
http://www.nytimes.com/2006/08/22/technology/22aol.html
The observant reader will note that despite the rising tide of concerns
regarding search query privacy, the industry as a whole is still pretty much
in a state of denial, made all the more confusing by various signals from
the U.S. Department of Justice.
This is turning into such a mess that it's becoming difficult to even keep
the various participants and their positions completely clear. There is
every reason to believe that without heroic action by the players involved,
we may be heading toward a privacy, legislative, and judicial nightmare.
But maybe there's a way out.
Let's review:
AOL's release of search query data made obvious to everyone what many of us
knew all along -- that such data contains all manner of personal
information, even when the identity of the party making the query is not
immediately known directly from usage logs. In the AOL case, the individual
query entries were linked by "anonymized" user IDs, but even without such
linkages the query items alone can be highly privacy-invasive. The AOL
release triggered (as did DoJ vs. Google) broad calls for mandated search
query data destruction policies.
The personal nature of the AOL query data serves nicely to liquidate the
DoJ's arguments (again, as in DoJ vs. Google) that such data is not
privacy-invasive so long as the query source is unidentified. The expressed
DoJ reasoning is this regard is obviously faulty.
Search engine companies have been reluctant to voluntarily dispose of query
data on a regular basis. This data has considerable R&D, marketing, and
other value. Since the incremental cost of keeping all queries archived
forever is so low, there is little incentive within the normal business
structure to dispose of this resource, absent overriding considerations.
Even while laudably expressing concerns about the potential for third-party
misuse of query data, search engine firms (e.g. Google) have proclaimed
their intention to keep collecting and saving this data indefinitely. If
AOL actually sets in place an aggressive data destruction schedule, it will
be something of a watershed event that may (or may not) have broad impacts
across the search engine industry. Fears of being placed at a competitive
disadvantage will tend to make unilateral moves toward query data
destruction difficult to propose or implement.
Meanwhile, DoJ is moving in exactly the opposite direction, apparently
preparing to propose long-term (perhaps measured in years) mandated data
retention schedules, requiring the saving of the very data for which
destruction demands are being made in other quarters. DoJ is using child
abuse (and as of late anti-terrorism efforts) as their hooks to justify such
legislation (please see: http://lauren.vortex.com/archive/000186.html ).
This situation has all the elements of a painful and wasteful deadlock,
potentially triggering years of litigation while the overall search engine
issues continue to fester and become even bigger privacy, business, and
political problems.
If we wish to avoid this scenario -- or at least have a good shot of
avoiding it -- we need to act now, and we need to do so cooperatively.
There are policy and technological approaches to the search query dilemma
that can be applied in ways that will serve the interests of all
stakeholders. Cooperation and compromise mean that nobody is likely to get
everything that they'd ideally want, but to paraphrase the great philosopher
Mick Jagger, perhaps we can all get much of what we need.
Therefore, I propose the formation of a high-level Internet working
group/consortium dedicated specifically to the cooperative discussion of
these issues and the formulation of possible policy and technology
constructs that can be applied toward their amelioration. Such a working
group would be as open as possible, though proprietary concerns would likely
necessitate some closed aspects if progress is to be accelerated as much as
possible.
Participation by all stakeholders would be invited. Representatives of the
major search engine firms and concerned government agencies, outside
technologists and other persons involved in privacy and search issues, and
other entities as appropriate would all play important roles.
Of course, it's easy -- especially for large corporate enterprises -- to
simply ignore such efforts and just plow ahead independently. Obviously,
without the participation of the key players, the effort that I'm proposing
would be useless, and I will not continue to promote it if that situation
ensues.
However, I suggest that it will be in the long-term best interests, both
financially and in terms of corporate and organizational responsibility, for
major stakeholders to actively join such a project, since the alternative
seems ever more likely to be somewhere between highly disruptive and
extremely draconian.
Interested? Please let me know. All responses will be treated as
confidential unless the sender indicates otherwise.
Thank you for your consideration.
Lauren Weinstein <lauren@private> +1-818-225-2800 http://www.pfir.org/lauren
Lauren's Blog: http://lauren.vortex.com Co-Founder, PFIR http://www.pfir.org
------------------------------
Date: Wed, 23 Aug 2006 10:31:06 +1000
From: "Shaw, David \(David\)" <dshaw@private>
Subject: Centrelink staff busted invading Australians' privacy
Centrelink (www.centrelink.gov.au) is the Australian federal government's
social security and welfare agency. Staff have access to a wide range of
information about Australians.
Following a two-year investigation nineteen staff have been sacked for
inappropriately accessing the personal information of family, friends and
ex-lovers. More than 100 staff resigned when confronted with similar
allegations. Five cases have been referred to the Australia Federal
Police. The privacy invasions were detected using "specially designed
spyware software."
While highlighting the risk that sometimes the greatest security threats
come from within, at least it's encouraging to see a government department
making an effort to crack down on invasions of privacy.
More info at: http://www.abc.net.au/news/newsitems/200608/s1721505.htm
David Shaw, Senior Software Engineer dshaw@private
------------------------------
Date: Sun, 20 Aug 2006 04:47:40 -0400
From: Monty Solomon <monty@private>
Subject: TiVo Is Watching When You Don't Watch, and It Tattles
TiVo is starting a research division to sell data about how its 4.4 million
users watch commercials - or, more often, skip them: TiVo users spend nearly
half of their television time watching programs recorded earlier, and
viewers of those recorded shows skip about 70 percent of the commercials.
[Source: Saul Hansell, TiVo Is Watching When You Don't Watch, and It
Tattles, *The New York Times*, 26 Jul 2006; PGN-ed]
http://www.nytimes.com/2006/07/26/technology/26adco.html?ex=1311566400&en=143cb4893c1c45a9&ei=5090
------------------------------
Date: Sun, 20 Aug 2006 14:44:06 +0200
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: The SAFEE Project (was: Anti-hijack Software, Sanders, RISKS-24.38)
Nickee Sanders reports from Yahoo that:
A joint European effort is working on software that would enable remote
control of an aircraft that could override any attempts by hijackers to
control the plane, and force a safe landing......... The project is
budgeted for 36m Euros.
Please let us try to get this straight. This comment suggests that the EU is
putting 36m Euros into developing control SW for commercial aircraft. This
is not so, as far as I can tell. The SAFEE project is a *research* project
which is focused on the implementation of onboard threat detection systems
and the provision of reliable threat information to the flight crew. In the
decision making and response management process, secured air/ground exchange
of threat level information is foreseen. SAFEE also anticipates the future
use of the European Regional Renegade Information Dissemination System
(ERRIDS) by all organizations involved in response to acts of unlawful
interference on-board aircraft.
( http://www.safee.reading.ac.uk/about.htm )
Notice that there is no mention of control SW here, but rather of detection
systems and reliable information systems. According to the information
brochure which one may download at
http://www.safee.reading.ac.uk/SAFEE_brochure.pdf there are five
sub-projects. One of the five subprojects is "flight reconfiguration:
includes an Emergency Avoidance System (EAS) and a study of an automatic
guidance system to control the aircraft for a safe return". Notice the
wording: a *study*, not writing control SW.
One of the other subprojects is concerning with secure air-ground
communication. About time. Data exchange between aircraft and ground has
been clear-text-based without effective authentication, and it is about time
this was changed (I regard authentication as essential).
I see one academic partner in the project (the University of Reading) and a
lot of commercial partners. Research work by commercial project partners is
subsidized to a level of 50%, which means that of this 36m (again note: I
haven't checked this figure), roughly half of it will be paid by the
participants themselves (the Uni Reading will get 100%).
So the risk highlighted by this note turns out not to be the reported
one. How to avoid it: check sources before distributing rumors.
Peter B. Ladkin, Causalis Limited and University of Bielefeld
www.causalis.com www.rvs.uni-bielefeld.de
------------------------------
Date: Tue, 22 Aug 2006 15:41:11 -0400
From: Kent Borg <kentborg@private>
Subject: Re: LA power outages (RISKS-24.37,38)
It is *so* hard to do redundancy on an industrial-scale. I.e., for a large
data center. One reason the attempt is so frequently doomed is that is is
*SO* hard to test a critical system.
Here is a true story of such a failure.
I know of a facility has a diesel generator, and even plenty of diesel,
enough for easily powering critical systems for a long time. Wanting to be
safe they test their generator every month.
Time passes. Something goes wrong with the utility power, so the generator
fires up. All is running as expected--until the generator stops.
Problem: All that diesel. It can't all sit in a gravity-fed tank on top of
the generator, most of it is in the big tanks, some distance off, and fed
with a pump.
Specific Problem: The pump was powered off the utility power not the
generator power; works great during monthly tests, but doesn't work well at
all when the utility is down.
------------------------------
Date: Fri, 18 Aug 2006 17:00:31 -0700
From: Mike Albaugh <albaugh@private>
Subject: At least the extension cord worked (Weinstein, RISKS-24.38)
Lauren Weinstein pointed out the risks of power-failure to "bleeding edge"
tech such as VoIP over cable-modem in "Your Cable Company -- powered by the
guy with the extension cord".
Lately AT&T (re-branded SBC) has been running a lot of advertising making the
same point, and pretty much suggesting that you are putting your life in
danger by switching away from them.
Maybe yes, and maybe no. I recently had a 36-hour (_after_ I got home and
reported it) service outage on my POTS (Plain Old Telephone Service), as
provided by SBC. Clear weather, No power outage. Several of my neighbors had
much the same problem, at about the same time, but SBC denied that the truck
they had parked over the neighborhood cable vault had _anything_ to do with
it. It had to be in my internal wiring (yeah, unable to cope with "no
battery", let alone "no dialtone" at the demarcation point).
RISK: Assuming that the risk a competitor tells you about is the only one
that exists. Why any sane person would go for "Triple Play" is beyond me.
Reality: The old "public service" attitude (don't laugh, many PacBell folks
did indeed have it) is dead and buried.
------------------------------
Date: Mon, 21 Aug 2006 16:25:30 +0100
From: Dave Blake <dave.blake@private>
Subject: Re: ... Your Dell laptop battery must be OK! (Miller, RISKS-24.38)
Dan Miller asks what happens when you do enter (correctly) an ID for a
potentially faulty battery into the dellbatteryprogram.com site. The answer
is that the site takes you directly to an order page so that you can request
a replacement battery. At least there is no "Are you sure that you want to
replace your potentially explosive battery" step.
More annoying from my point of view is that I raised a support call with
Dell late last month (21 Jul to be precise) as the battery light on the
laptop which was normally green had begun to flash an intermittent red
light. After a week or so of emails I was basically fobbed off with a
normal-operation-for-a-year-old battery story. I now find that this issue
had already been made public in a number of sources, and I find it
incredible that Dell has been so slow to react.
http://www.signonsandiego.com/news/tech/20060712-1221-cargoplanefire.html
http://www.boingboing.net/2006/07/28/dude_your_dell_just_.html
The BoingBoing story relates how a Dell laptop burst into flames in an
office. So far so frightening, but as I work mainly at home and often leave
the machine on overnight unattended running AV scans or downloads, in the
room next to my daughter's bedroom that I use an office (which of course
does not benefit from any of the anti-fire devices that a normal commercial
office might have) I find the thought of what might have happened absolutely
bloody terrifying.
Then, whilst checking the URLs for this note, I come across the story that
the batteries were manufactured by Sony and that they knew of these
potential problems 10 months ago. Well, after the music CD rootkit fiasco
earlier in the year we all know that Sony seems to have a certain contempt
for its customers but I think that this latest story takes the
biscuit. There's a whole world of difference between compromising the
security of a customer's PC , and potentially killing or maiming
someone. Furthermore Sony management could perhaps be forgiven for failing
to grasp the rootkit issue; they can have no such defence over the rather
simple issue that their product might burst into flames or explode.
http://www.macworld.com/news/2006/08/21/battery/index.php
Lastly, the Macworld story contains the following statement;-
"Fujitsu, Toshiba and Hewlett-Packard (HP) said on Thursday that they use
Sony Li-ion batteries with their systems, but that the batteries are
different from those being recalled by Dell. The companies said they did
not see a fire risk for customers and did not plan on doing a battery
recall."
Anyone feel comforted by that?
------------------------------
Date: Tue, 22 Aug 2006 21:23:11 -0400 (EDT)
From: Brent Kimberley <brent_kimberley@private>
Subject: Re: ... Your Dell laptop battery must be OK! (Miller, RISKS-24.38)
I enjoyed reading Dan Miller's "Your Dell laptop battery must be OK!"
http://catless.ncl.ac.uk/Risks/24.38.html .
A new disclaimer has been added to the Dell battery program website:
https://www.dellbatteryprogram.com/
Please verify you entered your PPID correctly before submitting
Common errors include distinguishing between alphanumeric characters:
letter "O" from the number "0"
letter "S" from the number "5"
letter "l" from the number "1"
[This disclaimer nibbles off a little of the pain. But the battery model
number situation reminds me of license-plate confusions, where similar
caveats are presumably issued to police officers. Or, if this ever became
connected with a serious law-enforcement case, might we expect Congress to
seek legislation that makes certain confusion-causing characters illegal,
such as in O0S51I?]
------------------------------
Date: Mon, 21 Aug 2006 13:43:45 -0800
From: Rob Slade <rmslade@private>
Subject: "IT Security Project Management", Susan Snedaker
BKITSCPM.RVW 20060808
"IT Security Project Management", Susan Snedaker, 2006, 1-59749-076-8,
U$59.95/C$77.95
%A Susan Snedaker info@private
%C 800 Hingham Street, Rockland, MA 02370
%D 2006
%E Russ Rogers
%G 1-59749-076-8
%I Syngress Media, Inc.
%O U$59.95/C$77.95 781-681-5151 fax: 781-681-3585 www.syngress.com
%O http://www.amazon.com/exec/obidos/ASIN/1597490768/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1597490768/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1597490768/robsladesin03-20
%O Audience i- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P 612 p.
%T "IT Security Project Management"
Chapter one is an introduction, but also something of a preface to the book.
In terms of the intended audience, the author states that it is assumed
readers know the basics of project management and also network security.
The text, therefore, is proposed to be an operational framework for
designing an information technology security project plan. However, as the
material goes on to describe the components of such a plan only network
items are listed: physical security, applications security, databases,
business continuity, and a host of other considerations are notable by their
absence, and even the vital element of policy is buried as a minor
ingredient. There is a vague and verbose outline of risk and cost/benefit
analysis, and a list of success factors that range from the glaringly
obvious (management support) to the counterproductive (standard
off-the-shelf infrastructure is recommended even though this practice is
known to increase the likelihood of attacks).
Chapter two defines security projects, but mostly in terms of the sections
of a proposal. Organizing the project, in chapter three, lists various
project management factors, probably the most significant being the
composition of the team that will define the project. (Didn't we do the
definition in chapter two?) Ensuring quality, in chapter four, seems to
consist of knowing requirements and metrics. Chapter five sees the
formation of the project team, which is not the same as the team that
defined the project in chapter three. Standard project planning advice is
provided in chapter six. Chapter seven is supposed to be about managing the
project, but there is little or no mention of the mechanics of management,
with the content concentrating on initiation and changes of specifications.
The termination phase is reviewed in chapter eight.
Chapter nine, entitled "Corporate IT Security Project Plan," is supposed to
be the promised overarching framework. However, after twenty-two pages of
legal advice (and two warnings about giving or taking unauthorized legal
advice), we find a project outline (missing some of the usual steps) and a
haphazard aggregation of project elements, many of which have been covered
previously. (Contrary to the recommendation in chapter six, the outline
lists a number of items of quite different importance all at the same
level.) A random and unstructured collection of security topics makes up
the bulk of chapter ten, which is nominally about general IT security
planning. The lack of pattern and hodgepodge of subjects seems to confuse
even Snedaker: figure 10-1 on page 265 ("Layered Approach to Network
Security") and figure 10-5 on page 327 ("Elements of IT Security
Requirements") are duplicates. Much the same description is true of IT
infrastructure, in chapter eleven, and it also repeats a good deal of the
content. Wireless security, in chapter twelve, does have more substance
that is specifically related to wireless technology and risks, although it
is strange, given the immediacy of other items in the work (there is a
reference to an event that happened on May 24, 2006), that the list of
802.11 protocols does not list 802.11i, which is probably the most secure.
Chapter thirteen, about operations security, does have a bit more
organization, but is fairly standard advice about incident response,
security awareness, and policy.
If it is expected that the reader is thoroughly familiar with project
management, the primacy and amount of space dedicated to the basic project
operations (chapters two to eight, 158 pages) is odd. It turns out that the
limiting of the technical content to network areas is of no particular
importance, since this volume is really only generic project management
advice anyway (and not overly complete, at that). Page 445 notes that
"[o]ur goal is not to push you to use outside consultants," but Snedaker is
a consultant, and owns a consulting firm. The writing in this book is
turgid, the content banal, and the advice incomplete. Given that I am a
selfprofessed professional paranoid, I may perhaps be forgiven for imagining
that someone might write a bad book in the hopes that readers, attempting to
figure out how to do it themselves, would give up in disgust and look around
for someone to make sense of the process for them.
Just a thought.
copyright Robert M. Slade, 2006 BKITSCPM.RVW 20060808
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: 2 Oct 2005 (LAST-MODIFIED)
From: RISKS-request@private
Subject: Abridged info on RISKS (comp.risks)
The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. The mailman web interface can
be used directly to subscribe and unsubscribe:
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.
=> The complete INFO file (submissions, default disclaimers, archive sites,
copyright policy, etc.) is online.
<http://www.CSL.sri.com/risksinfo.html>
The full info file may appear now and then in RISKS issues.
*** Contributors are assumed to have read the full info file for guidelines.
=> .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!
=> 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 24.39
************************
This archive was generated by hypermail 2.1.3 : Thu Aug 24 2006 - 12:55:41 PDT