RISKS-LIST: Risks-Forum Digest Monday 5 June 2006 Volume 24 : Issue 31
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.31.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Feds Continue Push For Mandated Internet Data Retention (Lauren Weinstein)
Re: Government-mandated data retention (Chris D.)
243,000 Hotels.com credit-card numbers stolen (Robert Heuman)
Data files erased at Aznar Government systems (Miguel A Gallardo)
Spam King Settles With Texas, Microsoft (Monty Solomon)
Risks of formulaic sanitization (Geoff Kuenning)
Re: NASA's DART spacecraft smashes into satellite (Peter B. Ladkin)
Re: $8 million for self-parking charge (Gabe Goldberg)
Re: Nationwide's Website Refuses Customer Feedback (Michael Hogsett)
REVIEW: "Software Configuration Management Using Vesta", Heydon et al.
(Rob Slade)
REVIEW: "Perfect Passwords", Mark Burnett (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Fri, 2 Jun 2006 08:28:06 -0700 (PDT)
From: Lauren Weinstein <pfir@private>
Subject: Feds Continue Push For Mandated Internet Data Retention (R-24.29)
http://www.latimes.com/technology/la-fi-internet2jun02,0,622125.story?coll=la-home-headlines
"The Justice Department said Thursday that it was not seeking to have the
contents of e-mail archived, just information about the websites people
visit and those with whom they correspond."
"Sounding the Alarm on Government-Mandated Data Retention"
http://lauren.vortex.com/archive/000175.html
This is a critical topic. The impracticality and cost issues associated
with the new DOJ Internet data retention proposals are relatively obvious.
It's difficult to even understand who would be required to comply with such
demands. Only the big Web service companies? ISPs? (via packet tracking of
their subscribers running their own servers?) Every small firm,
organization, or even individual who operate their own e-mail and Web
servers? Are the existing privacy policies of such entities instantly
negated if they conflict with the DOJ wish list or data retention
legislation?
It's also obvious how e-mail contact information could be abused. But
there's something even more insidious in this situation. In the recent DOJ
vs. Google case, Google and most unbiased observers correctly noted that
"Web destinations" (URLs) frequently contain all manner of personal and
private information. Names, addresses, social security numbers, dreams,
hopes, interests, fears, medical queries -- all manner of details of our
lives are embedded in the URLs we submit to search engines and other Web
sites.
For all practical purposes, URLs in the Web context are very much like the
content of phone calls in the conventional telecom context, judging by the
level of detailed data that URLs provide and their ability to allow complete
tracking of our every related Internet action in most cases.
If Internet users must live in fear that their actions on the Net are
subject to retrospective analysis -- not only based on today's criteria but
potentially on tomorrow's as well -- the effects on how we view and use the
Net will be drastic, with vast unintended negative consequences that strike
to the heart of our democracies.
This issue is ultimately more important than network neutrality, Internet
governance, or most (if not all) of the other technically-related concerns
that we bandy about here in IP or in most other forums, because it strikes
to the very core of basic privacy concerns and personal freedoms.
Government-mandated Internet data retention could be the most potent single
technological move in recent history toward enabling future tyranny against
both individuals and groups.
We must not allow this issue to be "managed" through private meetings
requested by government officials, or as a mere footnote in the public
discourse or hastily passed legislation -- to be treated as a fait accompli
by this or future administrations.
Lauren Weinstein +1 (818) 225-2800 http://www.pfir.org/lauren
PRIVACY Forum - http://www.vortex.com DayThink: http://daythink.vortex.com
------------------------------
Date: Sat, 03 Jun 2006 20:51:48 +0100
From: "Chris D." <e767pmk@private>
Subject: Re: Government-mandated data retention (RISKS 24.29)
> ...understand the horrible collateral damage that their proposals would do.
Here in the UK (where plans for ID cards are well advanced), it's difficult
to avoid the feeling that legislators and their backers **do** know that
their proposals may well have undesirable side-effects, but they feel that
these are worthwhile in the fight against child pornography, international
terrorism, financial fraud, or whatever, and anyone who suggests caution
(such as pointing out the RISKs of large-scale IT projects) and a
more-considered approach is accused of wantonly obstructing their efforts.
A cynic may feel that legislators are often inclined to brush objections
aside just to show how tough they are being in dealing with serious
problems, and as governments want to be seen to be doing something and
people (voters) like to be reassured, intrusive but ineffective measures are
favoured over effective but discreet ones. The deeper trouble seems to be
modern politicians' liking for legislation as a fix for every problem; few
people probably want to live in a country like 1970s East Germany, but some
of us seem to be getting there anyway.
------------------------------
Date: Sat, 03 Jun 2006 10:07:29 -0400
From: RsH <robert.heuman@private>
Subject: 243,000 Hotels.com credit-card numbers stolen
CNNMoney reports that about 243,000 Hotels.com credit-card numbers were
stolen back in February via the theft of a laptop computer. They believe
that the theft was of the computer, with no idea of the information on the
hard drive, and, likely as well, no intention of using the information on
the hard drive. That it takes from February to June to determine what was on
the hard drive is difficult to accept, however, and leaves unanswered what
MIGHT have happened in the intervening three months respecting identity
theft or misuse of the credit cards. Lots of unanswered questions, but
typical of the problem when a laptop gets stolen... [Source: CNNMoney.com,
2 Jun 2006]
------------------------------
Date: Sun, 4 Jun 2006 11:20:36 +0200
From: "Miguel A Gallardo O WWW.CITA.ES" <miguel@private>
Subject: Data files erased at Aznar Government systems
Aznar Government deleted all the Spanish Government Presidency computer
systems in "La Moncloa" Official Palace after the elections (3 days after
the terrorism attacks in Madrid-Atocha train station). There is a 12
thousand Euros bill just for deleting everything, even data back-ups.
We are trying to find ways to ask for political and criminal
responsibilities, and right now we need international cases, news, and
references of official data deleted in government systems. As far as we
know, in USA is not possible to do anything like that, and even Henry
Kissinger files will be known in the years to come. I mean that USA
presidents can encrypt and legally protect that information, but they can
not erase as Aznar did.
You can find a lot of information (in Spanish) and our criminal accusation
at http://www.cita.es/borrado
We expect expensive lawyers fees and a bail in order to keep the case alive
in a Spanish Court of Law, so we need financial help and international media
broadcasting. We found some support in archivists from several Spanish
speaking countries already and I shall appreciate any help or expert
witnessing support in order to explain to the judge how serious is the case
documented at http://www.cita.es/borrado
Please do not hesitate to contact me for further information and forward a
copy of this message to anyone you consider more appropriate.
Miguel A. Gallardo O., Engineer, Criminologist and Forensic Cryptologist
President of APEDANICA at www.cita.es/apedanica
CV con fotos en http://www.cita.es/conmigo
Skype: m.a.g.o. Tel: (+34) 914743809 móvil 619776475
www.cita.es Apartado (P.O. Box) 17083-28080 Madrid, Spain
------------------------------
Date: Sun, 4 Jun 2006 11:06:13 -0400
From: Monty Solomon <monty@private>
Subject: Spam King Settles With Texas, Microsoft
Associated Press item, 3 Jun 2006
One of the world's most notorious spammers has settled lawsuits with the
state of Texas and Microsoft Corp. that cost him at least $1 million, took
away most of his assets and forced him to stop sending the nuisance e-mails.
Ryan Pitylak, 24, who graduated from the University of Texas last month, has
admitted sending 25 million e-mails every day at the height of his spamming
operation in 2004.
http://www.quote.com/home/news/story.asp?story=58948931
------------------------------
Date: 04 Jun 2006 22:34:33 -0700
From: Geoff Kuenning <geoff@private>
Subject: Risks of formulaic sanitization
I just ordered copies of my free annual credit report from
www.annualcreditreport.com. One of the new options is to hide the last 4
digits of your Social Security Number in the report output. That's mildly
nice, in case the printed report falls into the wrong hands.
At least one of the three major credit-reporting companies who participate
in the web site, Equifax, also hides details of account numbers by blanking
the last four digits. Again, a nice touch: somebody who gets your report
can't get a list of all your credit-card numbers.
Problem 1: most other credit-card handlers (e.g., Web vendors) blank all BUT
the last four digits. I frequently get invoices and packing lists saying
"card ending in 1234". So between one of those and the credit report,
nothing is hidden.
Problem 2: I have some student loans with Sallie Mae. It turns out that
their account numbers are formed by appending 3 digits to the end of the
SSN. So despite Equifax's kind blocking of 4 digits of my SSN, in reality
only 1 digit is hidden from anybody who acquires my copy of the report.
Needless to say, if I print the report it'll get shredded when I'm done with
it, and my on-disk copy will be encrypted. But what about my
non-security-savvy neighbor?
Geoff Kuenning geoff@private http://www.cs.hmc.edu/~geoff/
------------------------------
Date: Fri, 02 Jun 2006 10:31:08 +0200
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: Re: NASA's DART spacecraft smashes into satellite (RISKS-24.29,30)
PGN reported on the DART-satellite collision (Risks-24.29) and Robert
Schaefer (Risks-24.30) noted that ITAR restrictions may have been a
contributing cause. The incident took place on April 15, 2005, so the report
comes a year later.
Frank Morring, Jr. reported extensively on the investigation in Aviation
Week and Space Technology, May 22, 2006, pp37-8. An on-line report by
Morring, freely available, may be found by searching www.aviationnow.com for
the two words "DART morring". For those who like to paste pieces together,
the URL is
http://www.aviationnow.com/avnow/search/autosuggest.jsp?docid=600549&url=http%3A%2F%2Fwww.aviationnow.com%2Favnow%2Fnews%2Fchannel_space_story.jsp%3Fview%3Dstory%26id%3Dnews%2FITAR05176.xml
A U.K. firm, Surrey Satellite Technology Ltd., supplied the DART prime
contractor Orbital Sciences Corp. with the primary GPS receiver used for the
rendezvous manoeuvre. The GPS receiver registered a spacecraft velocity in
error by about 0.6 m/sec. This led to a significant difference between
estimated and measured positions, which led to the DART spacecraft resetting
its position computations, with the biased data, which led through the same
discrepancy to repeated resets, because the feedback "gain" was such that
the estimated and measured positions could not have converged. "The anomaly
caused excessive consumption of the spacecraft's ... fuel. It also led to
the collision with the target satellite,..." (Morring, Avweek op.cit. p37)
The bias in the Surrey GPS receiver was known, but the software fix for it
had never been implemented by the DART team, and the bias was not reflected
in the software model simulating the GPS receiver in preflight testing, so
this simulation failed to elicit the reset problem, says the report
(Morring, op.cit, p37-8).
Morring's article, and the report, also consider the human, organisational
and developmental weaknesses and failures that led to this anomaly arising
in operations. The redacted summary of the report says "In the case of
DART, the MIB concluded that insufficient technical communication between
the project and an international vendor due to perceived restrictions in
export-control regulations did not allow for adequate insight" (op.cit.,
p.37). (I read this to mean restrictions *derived from* export-control
regulations.)
Peter B. Ladkin, Causalis Limited and University of Bielefeld
www.causalis.com www.rvs.uni-bielefeld.de
------------------------------
Date: Sun, 04 Jun 2006 09:15:01 -0400
From: Gabe Goldberg <gabe@private>
Subject: Re: $8 million for self-parking charge (Kuenning, RISKS-24.30)
Geoff Kuenning reported an *LA Times* humor photograph featuring a self-pay
parking kiosk with a mis-set date of 16 May 1943, showing an amount due of
$8,082,022.84.
And he commented, "Sanity checking, you ask? Not bloody likely. An
auxiliary display shows the fee in larger characters; it reads 8.1E+6. When
you have an programmer so clueless as to calculate money values in floating
point, there is little hope for subtleties like sanity checking."
And continued, "As a side point, I'm fascinated that things like parking
kiosks now use chips powerful enough to have floating-point support, at
least as a library. A 4-bitter would be adequate for the task, though it's
not clear to me that this particular programmer could have written the code
needed to compute the fee on a 4-bit machine."
Assuming that the photo is genuine, it seems at least plausible that the
programmer used a software library for calculating cost based on elapsed
time rather than explicitly using floating point. Regarding the chip's
bitness, unless the programmer is writing assembler code (risky business for
such a mundane application), it seems unlikely that modern programming
languages are supported by 4-bitters.
Sanity check? Sure, programming insanity is easily detected in
hindsight. The kiosk should have refused a date earlier than some epoch. But
what was the 1943 date? The kiosk's "current" date? The date a car was
supposedly parked? The fee calculation might have refused to present an
amount greater than some number. But what specs was the programmer coding
from? What government agency requirements were the specs derived from? Why
didn't a simple test case involve feeding the kiosk a prehistoric date?
I guess the computer risk is debugging and proposing a solution based on a
photograph of an incorrect result, not to mention blaming the anonymous
programmer for (perhaps) just coding to design. And the manufacturer for
using current technology vs. (perhaps) obscure and hard-to-program
minimalist hardware.
Though, of course, there's likely a big-city market (New York, certainly)
for parking meters displaying fees in floating point.
[Similar comments from Ray Blaak. PGN]
------------------------------
Date: Thu, 01 Jun 2006 14:33:44 -0700
From: Michael Hogsett <michael.hogsett@private>
Subject: Re: Nationwide's Website Refuses Customer Feedback (Brady, R-24.30)
I get these all the time. All spam that is caught going to our
mailing lists is forwarded to me and appropriately filed away
automatically. I get about 3000 spam messages a day. I got 6
identical phishing emails for some bank today and forwarded one of the
messages to both abuse@domain and security@domain. Those addresses
often exist. I don't bother looking up addresses at their sites.
------------------------------
Date: Fri, 02 Jun 2006 08:42:05 -0800
From: "Rob, grandpa of Ryan, Trevor, Devon & Hannah" <rMslade@private>
Subject: REVIEW: "Software Configuration Management Using Vesta", Heydon et al.
BKSWCMUV.RVW 20060514
"Software Configuration Management Using Vesta", Allan Heydon et al.,
2006, 0-387-00229-4, U$59.95
%A Allan Heydon
%A Roy Levin roy@private
%A Timothy Mann
%A Yuan Yu
%C 233 Spring St., New York, NY 10013
%D 2006
%G 0-387-00229-4
%I Springer-Verlag
%O U$59.95 212-460-1500 800-777-4643 matthew.giannotti@private
%O http://www.amazon.com/exec/obidos/ASIN/0387002294/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0387002294/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0387002294/robsladesin03-20
%O Audience s Tech 3 Writing 1 (see revfaq.htm for explanation)
%P 262 p.
%T "Software Configuration Management Using Vesta"
The preface tells us that Vesta is a system for version and build control
suitable for projects of all sizes, from the small, to those large and
distributed to such an extent that the standard software management tools
are inadequate.
Part one provides a general description of Vesta. Chapter one is an
introduction, both to the common versioning (and related debugging and
testing) problems, and to the principles of Vesta: versioning of source code
and tools (with automated handling of relevant object code), "immortal"
storage of all versions, and storage of complete system model descriptions
of all builds and options used in compilation. ("Sources," in Vesta, are
not limited to source code: tools introduced into the system are treated in
similar ways. In addition, immortality is limited to source code: when a
derived entity; one that is built or compiled; is unused for some period it
may be weeded.) Various development related concepts from UNIX are listed
in chapter two. The reason for this is not completely clear, but some of
the ideas are used in chapter three, which describes Vesta at an abstract
level.
Part two outlines the view of a Vesta user: the perspective of the
programmer or developer. Chapter four reviews the management of versions
and sources. The notion of a name space is similar to the UNIX file system
or the Internet's domain name system (which it partially uses), with
additional linking and restrictions on reuse. There is no specific support
for merging of changes, in Vesta, but the tools can be modified to call for
a merge utility from another source. Chapter five outlines the System
Description Language (SDL), a scripting language for specifying "building"
in Vesta. An example of the use of the language is given in chapter six.
Part three looks inside Vesta. Chapter seven examines internal operations
of the repository. The Vesta evaluator is essentially responsible for
compilation of the software project: chapter eight reviews the
characteristics that allow it to manage complex development efficiently,
reusing as much prior material as possible as the changes are made
incrementally. The weeder attempts to deal with the issue of a system that
can expand forever on a finite disk: the algorithms for making the balance
between keeping too much (running out of space) and keeping too little
(having too spend to much time recreating needed parts) are given in chapter
nine.
Part four allows us to assess Vesta. Chapter ten reviews some competing
systems: RCS (Revision Control System), CVS (Concurrent Versions System,
Make, and a few CASE (Computer Aided Software Engineering) tools.
Performance, in terms of various speeds, memory loads, and storage
requirements, are examined in chapter eleven. The data is, unfortunately,
not from recent projects that used the system, but does show that Vesta
convincingly outperforms Make, even for relatively small projects.
(Suggestions are also given for enhancements to improve the system even
further.) The conclusion, in chapter twelve, repeats much of the material
in the preface.
An appendix provides a reference manual for the SDL. Vesta is available as
an open-source tool at the www.vestasys.org Web site.
The authors admit, in chapter twelve, that there would be a learning curve
involved in persuading developers to use the Vesta programming environment:
Vesta does work in ways that would, initially, be mysterious to coders
familiar with the currently popular tools. In addition, there would be some
overhead involved in teaching programmers to use SDL. (On the other hand,
new programmers would probably take to it quite readily.)
The book is intended as a research report rather than a user manual
(although part two can be used to get started with the system). Much of the
material concentrates on the internals of the system, and the aspects that
assist in the excellent performance: these operations will never be seen by
the user, although the system response will be satisfying. The authors have
made no attempt to understand the information (and writing style) that would
be helpful to developers attempting to use the system, and managers trying
to decide whether or not to implement it. Open source devotees wanting to
understand and extend the project will find this an invaluable resource.
Researchers in the fields of software development and system performance
will also find much of interest in these pages.
copyright Robert M. Slade, 2006 BKSWCMUV.RVW 20060514
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: Mon, 05 Jun 2006 10:57:41 -0800
From: "Rob, grandpa of Ryan, Trevor, Devon & Hannah" <rMslade@private>
Subject: REVIEW: "Perfect Passwords", Mark Burnett
BKPRFPWD.RVW 20060420
"Perfect Passwords", Mark Burnett, 2006, 1-59749-041-5,
U$24.95/C$34.95
%A Mark Burnett
%C 800 Hingham Street, Rockland, MA 02370
%D 2006
%G 1-59749-041-5
%I Syngress Media, Inc.
%O U$24.95/C$34.95 781-681-5151 fax: 781-681-3585 amy@private
%O http://www.amazon.com/exec/obidos/ASIN/1597490415/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1597490415/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1597490415/robsladesin03-20
%O Audience i- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P 181 p.
%T "Perfect Passwords: Selection, Protection, Authentication"
Those of us in the security field know that users are generally bad at
creating passwords, and that passwords that are easily guessed or
found account for huge numbers of security incidents. Therefore, I am
in full sympathy with a book that attempts to lay out some guidance on
password choice. However, Burnett's work calls to mind the old joke
that lists all kinds of restrictions on password selection, and
finally admits that only one possible password actually fits the
criteria, and will all users please contact tech support to be issued
with that password.
Chapter one tells us that people choose weak passwords, and gives a
number of lists of such poor choices, without an awful lot of
explanation. (Burnett also states that the choice of strong passwords
provides non-repudiation, which is a rather strange position. One
could make a case that the deliberate choice of a vulnerable password
would allow the user to later claim that their account had been
hacked, and therefore assist with repudiation, but the reverse doesn't
necessarily hold.) Various types of password cracking techniques are
given in chapter two. This begins to show the inconsistencies and
contradictions that plague the text: at one point we are told that any
password less than fifteen characters is "immediately" available to
attackers, but elsewhere it is suggested that a ten character password
is a wise choice. (Although brute force cracking is discussed
extensively, there is, oddly, no mention of the implications of
Moore's Law.) There is a good discussion of the vital issue of
randomness in chapter three, although there are numerous gaps, and,
again, erratic suggestions. Chapter four covers character sets and
address space. Unfortunately, it is rather impractical (as are other
areas of the manual) due to a lack of recognition of character
restrictions. Password length is addressed in chapter five, covering
many of the same concepts as in four. It is also the most useful of
the material to this point in the book, suggesting ways to lengthen
and harden passwords already chosen and preferred. (Some of the
advice is suspect: bracketing is easy to add to automated password
cracking programs, and even Burnett admits that "colorization" is a
weak idea due to the limitations on selection.) Chapter six takes an
extremely terse and abbreviated look at password aging, but all that
is really said is that it is inconvenient. Miscellaneous advice about
using, remembering, storing, and managing passwords is given in
chapter seven. Chapter eight provides password creations tips, but
these are, after some of the previous material in the book, rather
weak, and typically boil down to the use of passphrases and long
passwords. Five hundred weak passwords are listed in chapter nine,
but the purpose of the list is not clear. As with chapter one, the
passwords are not analysed for strength in any way, and, even if you
want to check your favourite against the list, it isn't in
alphabetical order. Additional password creation tips are in chapter
ten, these slightly more useful. We are told, in chapter eleven, to
make complex passwords, uncommon passwords, and not to tell anyone our
passwords. Chapter twelve suggests having a regular "password day"
set aside to concentrate on changing passwords and creating strong
ones. Other forms of authentication are discussed in chapter
thirteen.
While the advice and information given in the book is not bad, it
seems to posit a fairly ideal world. A number of practical items can
assist users with password choice, but a number of realistic
considerations are ignored. Readers may also be confused by the lack
of constancy in the recommendations. Certainly the structure of the
text could use work: concepts are repeated in different chapters, and
the advice seems to be aggregated and presented at random.
There is good advice in this manual, but it lacks focus. The average
computer user would probably receive a lot of benefit, but is unlikely
to purchase or read anything this size on this topic. (A pocket sized
volume, along the lines of the O'Reilly "Desktop Reference" series
would be ideal.) System administrators would be able to understand
and use the material in the book, although much of the content is
either known or available. On balance, I would recommend that this
primer is important, but definitely needs work.
copyright Robert M. Slade, 2006 BKPRFPWD.RVW 20060420
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.31
************************
This archive was generated by hypermail 2.1.3 : Mon Jun 05 2006 - 14:22:34 PDT