RISKS-LIST: Risks-Forum Digest Weds 15 February 2006 Volume 24 : Issue 16
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.16.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Ameriprise's stolen laptop had data on 230,000 (PGN)
Another example of missing plausibility checks: $8M tax bill (Jeremy Epstein)
Video of my "Internet and Empires" talk at Google (Lauren Weinstein)
E-mail glitch hides $3.98 billion in Air Force deals (Scott Peterson)
New U.S. grant system excludes Mac users (Rick Weiss)
Hacker attacks on Danish websites (Klaus Brunnstein)
A List of Spreadsheet Errors (Gene Wirchenko)
Re: "NSA on redacting Word and PDF documents" (Matt Jaffe)
Re: "NTSB report on Southwest Airlines crash" (Peter B. Ladkin, dwikstrom)
Gary McGraw on Software Security (PGN)
REVIEW: "Information Security: Principles and Practice", Mark Stamp
(Rob Slade)
REVIEW: "Ending Spam", Jonathan A. Zdziarski (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sun, 29 Jan 2006 20:35:47 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Ameriprise's stolen laptop had data on 230,000
Ameriprise Financial said that lists containing the personal information of
about 230,000 customers and advisers had been compromised. A security
breach occurred in late December 2005, after a company laptop was stolen
from an employee's parked car. The laptop contained a list of reassigned
customer accounts that was being stored unencrypted, and treated in
violation of various Ameriprise rules. [PGN-ed from *The New York Times*,
26 Jan 2006]
[Thanks to Doug McIlroy for spotting this one. Doug remarked on the bad
(but seemingly very common) practice, and noted that "a scapegoat has been
sacrificed for the company's sins." Also, Bob Heuman cited an item
http://ct.enews.eweek.com/rd/cts?d=186-3144-17-83-67263-367596-0-0-0-1
that gave the number of affected clients as 158,000. PGN]
------------------------------
Date: Sat, 11 Feb 2006 08:14:43 -0500
From: Jeremy Epstein <jeremy.epstein@private>
Subject: Another example of missing plausibility checks: $8M tax bill
AP is reporting that a house in Valparaiso, Indiana (a town of moderately
priced homes) received an $8 million tax bill on a house actually worth
$121,900, but appraised at $400 million. This sort of thing isn't unusual,
but there were some interesting wrinkles:
1. The change in value was made by a person not authorized to make changes.
2. The value change occurred because the person typed one incorrect letter
to access the assessment change application (R-E-R vs. R-E-D to perform
the intended action)
3. The assessment change application was (theoretically) no longer in use,
having been replaced by a newer version
4. Since tax rates are set as a function of the total assessed value of the
property in the community (and an extra $400 million was enough to
seriously throw off calculations in this locality), the local government
is now significantly short of income, and is laying off staff.
This is a great example of a cascading failure - if any one of these steps
hadn't occurred (or had a cross-check - such as an audit trail that detected
the use of the old assessment program), the problem would not have occurred.
The county treasurer says that his office noticed & fixed the error, but
somehow it propagated elsewhere too.
Article at http://www.cnn.com/2006/US/02/10/overpriced.house.ap/index.html
------------------------------
Date: Fri, 10 Feb 2006 08:22:30 -0800
From: Lauren Weinstein <lauren@private>
Subject: Video of my "Internet and Empires" talk at Google (1/24/06)
A little over two weeks ago, I was invited to Google's Los Angeles area
facilities in Santa Monica to give an informal talk ("Internet and Empires")
on a range of Internet-related topics. Video of that presentation is now
available, and since it touched on a large number of our favorite discussion
issues in RISKS, I thought it might be of some interest here.
The topics naturally included a number of the controversial issues related
to Google, but also more generally privacy, free speech, ISPs, data
retention, government and legal issues, censorship, network neutrality, and
more.
The talk ran about an hour and the video will reportedly become available
soon as one of Google's "Tech Talks" (
http://video.google.com/videosearch?q=Google+techtalks ).
Since the video is not currently online there (and for people who need or
prefer other video formats), I have a Windows Media version available now
(my thanks to Google for providing me with a video master for processing).
Please note that all of the opinions expressed in this talk of course are
mine, and should naturally not be construed to represent the views of
Google, Inc.
Video:
http://www.vortex.com/lauren-google-2006-01-24.wmv (Download / ~36MB)
http://www.vortex.com/lauren-google-2006-01-24.asx (Streaming)
Audio Only (MP3):
http://www.vortex.com/lauren-google-2006-01-24.mp3 (MP3 Audio / ~15MB)
Lauren Weinstein lauren@private lauren@private http://www.pfir.org/lauren
International Open Internet Coalition - http://www.ioic.net +1 (818) 225-2800
------------------------------
Date: Tue, 14 Feb 2006 13:29:27 -0800
From: Scott Peterson <scottp4@private>
Subject: E-mail glitch hides $3.98 billion in Air Force deals
The U.S. Air Force said a new employee's e-mail error kept the Pentagon and
the public in the dark about nearly $4 billion of its contracts in December.
The DoD addresses were dropped from e-mail about more than $1.57 billion for
Northrop Grumman Corp., $1.22 billion for Boeing Co. and almost $509 million
for Lockheed Martin Corp., involving remotely piloted Global Hawk aircraft
and F-22A fighter jets among other contracts. The Defense Department is
supposed to announce each business day at 5 p.m. EST contracts valued at $5
million or more for its units, including the armed services. [Source: Jim
Wolf, Reuters, 14 Feb 2006; PGN-ed]
http://cwflyris.computerworld.com/t/296929/664274/9136/0/
------------------------------
Date: Mon, 13 Feb 2006 16:49:00 -0500 (EST)
From: "Peter G. Neumann" <neumann@private>
Subject: New U.S. grant system excludes Mac users (Rick Weiss)
A new U.S. federal government system Grants.gov already costing tens of
billions of dollars over its five-year development cycle is intended to be
used for all grant applications submitted to NIH, Housing and Urban
Development, and 24 other grant-giving agencies, typically giving out
something like $400B per year. However, its scheduled widespread use will
be postponed because the Windows-based software is not Mac-compatible. In
the interim, some applications will require proposals to be submitted from
MS systems. One blogger is quoted: "this would be the same government that
spent a lot of time and money pursuing Microsoft for its anti-competitive
behavior?" [Source: Rick Weiss, *The Washington Post*, 13 Feb 2006; PGN-ed]
http://www.washingtonpost.com/wp-dyn/content/article/2006/02/12/AR2006021200942.html?referrer=emailarticle
------------------------------
Date: Thu, 9 Feb 2006 10:59:54 +0100
From: "Klaus Brunnstein" <brunnstein@private-hamburg.de>
Subject: Hacker attacks on Danish websites
According to the largest Danish newspaper, Jyllands Posten (known for having
first published 10 drawings related to end religion founder Mohammed, in
September 2005), the number of attacks on Danish websites esp. for smaller
enterprises and private owners raised 10-fold, with more than 900 websites
affected in one week.
http://www.jp.dk/itogc/artikel:aid=3546652/
(edition: Thursday February 9, 2006)
The "simple forms of attacks" (details not given) were accompanied with
pro-Muslim statements esp. against publication of Mohammed drawings.
Btw: evidently, Jyllands Posten's website is still alive, although some
access problems have been reported when the issue was reported in worldwide
news (probably shortage of bandwidth).
[This is not surprising. However, I think RISKS will stay out of the
ensuing brouhaha as being not computer related. PGN]
------------------------------
Date: Sun, 29 Jan 2006 16:06:51 -0800
From: Gene Wirchenko <gene@private>
Subject: A List of Spreadsheet Errors (Re: Art T, RISKS-24.15)
Re: E-mail and the courts
> ... compendium of legal cases in which e-mails play a significant role.
> http://arkfeld.blogs.com/ede/email/
And here is one where spreadsheets have caused trouble.
http://www.eusprig.org/stories.htm
------------------------------
Date: Sun, 29 Jan 2006 13:10:02 -0700
From: Matt Jaffe <jaffem@private>
Subject: Re: "NSA on redacting Word and PDF documents" (Magda, RISKS-24.15)
What to me seems an obvious risk was not mentioned, namely the risk of
trusting untrusted software to perform downgrade at all, regardless of the
parameterization (e.g., Track Changes disabled) and combination of
operations (deletion, overlay, copy) performed. The COMPUSEC field has
known and published for decades that software that can downgrade must be
trusted and, of course, running on a TCB trusted to the necessary extent as
well. Microsoft has perhaps made some progress in the realm of trusted
software in the last few years but I doubt that Word or Windows yet meets
anyone's notion of highly trustworthy. Curious, I went to one of the
references cited, NSA Report # I333-015R-2005, Redacting with Confidence:
How to Safely Publish Sanitized Reports Converted From Word to PDF
http://www.fas.org/sgp/othergov/dod/nsa-redact.pdf
There was a caveat included there to the effect that, "Using original source
formats, such as MS Word, for downgrading can entail exceptional risks; the
lengthy and complicated procedures for mitigating such risks are outside the
scope of this note." Well and good (although it's not the format per se
that is the problem but the software that processes it and the TCB it
executes on), but there were no references provided in the NSA report to
additional sources discussing the inherently "exceptional" risk of relying
on untrusted software for downgrade operations, no matter how detailed and
convoluted and (one hopes) well tested the redaction operations are.
I still think we're misleading people with these band-aid approaches. In the
original RISKS article, for example, dmagda states, "these steps give the
highest confidence that sensitive information is not hidden in the released
document." I don't know why dmagda feels that these techniques provide
"highest confidence". Perhaps he or she merely meant that there's nothing
better around and these steps are better than nothing. But do they really
provide much in the way of confidence in the overall safety of the process?
Only to the extent that one trusts Word and Windows to be free of
undisclosed Trojan Horses. To not at least more clearly highlight that fact
and provide a reference to further literature is a shortcoming in the cited
NSA report and the risk is that people may naively assume that since the NSA
has published it, it can be relied on with "highest confidence".
------------------------------
Date: Tue, 31 Jan 2006 23:27:37 +0100
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: Re: "NTSB report on Southwest Airlines crash" (Thompson, R-24.15)
Joe Thompson suggested in RISKS-24.15 that the NTSB has "reported on the
cause of the Southwest Airlines crash in Chicago" (SWA 1248, Chicago Midway
airport, 8 Dec 2005).
The NTSB has not reported on "the cause", and probably will not do so for a
while (it is likely that there are many causes, not just one. I see at least
four from the facts known so far. See below). The investigation is still
under way. The NTSB has released a recommendation, A-06-16, concerning the
means of calculating landing distances on contaminated runways. I recommend
reading A-06-16 at http://www.ntsb.gov/Recs/letters/2006/A06_16.pdf
The aircraft landed on a snow-contaminated runway at MDW and overran the
runway. It went through a blast fence and onto a public road, where it
collided with two cars and killed a young child in one of them.
The pilots had used an "on-board laptop performance computer (OPC)" to
calculate landing distances to determine whether they could land at MDW in
the snow-stormy conditions. The crew inputted weather data and entered
runway braking conditions as "WET-FAIR" in the OPC. The OPC calculated that
the airplane would be able to land and completely stop with 560 feet of
runway remaining. However, "the OPC is programmed to assume that the engine
thrust reversers will be deployed on touchdown" and they were not so
deployed. They deployed 18 seconds after touchdown. "If the reverse thrust
credit had not been factored into the stopping distance calculations made by
the OPC, it would have indicated that a safe landing on runway 31C was not
possible under a braking condition of either fair or poor" (op. cit. p3).
In other words, an implicit assumption made by the OPC program led to the
OPC indicating to the pilots that they could land safely on runway 31C when,
under the conditions that actually obtained during the landing, the OPC
program would have indicated that they could not do so without overrunning.
The reasons for the delayed deployment of reverse thrust have not yet been
publicly determined by the Board.
I have pointed out before in this forum (e.g. RISKS-24.03) that, although
the supposedly safety-critical computer systems on commercial aircraft have
not yet been implicated in any accident during 18 years in service, the
supposedly non-safety-critical computer systems have been causally involved
in many fatal accidents. This accident appears to be yet another example.
The four causes obviously indentifiable so far are: the weather conditions,
the OPC calculation that led the crew to believe that they could land safely
on 31C, the crew's decision to land on 31C, and the delayed deployment of
reverse thrust. And here we can already see part of the reason why these
supposedly non-safety-critical computer systems can continue to be
relatively so deadly. There is a crew decision and action interposed between
the computer actions (in this case, informational output) and the fatal
result. Somehow, we allow greater chances of systems misleading a crew into
taking fatal actions than we do that the airplane behaves differently from
that which is expected from the crew's control inputs.
Put like this, it is hard to see what may justify such apparently
incompatible attitudes. But when one looks at the development, it is easier
to see how the anomaly comes about. The OPC is probably a much more useful
and convenient tool than the paper performance charts which it
replaces. There is a legally-blessed principle called GAMAB in France and
MGS in Germany which says that one may use a (sub)system B as a replacement
for a (sub)system A when one can demonstrate that, in all circumstances of
deployment, the risk of using A is at least as great as the risk of using B
(usually phrased in terms of the safety of B being at least as great as the
safety of A, but "safety" here means the inverse of risk, and there is lower
likelihood of misunderstanding if one phrases the principle using the word
"risk".) The OPC likely was taken to satisfy the GAMAB/MGS principle in
comparison with the paper-based performance charts.
Note that, for all we know so far, the accident could well have happened
even if the assumption of immediate reverse-thrust had been explicit; for
example, the crew had been using paper charts on which the assumption of
immediate thrust reverse had been printed. The NTSB focused on the
pernicious assumption, not on the means by which it entered the calculation.
Peter B. Ladkin, University of Bielefeld, Germany <www.rvs.uni-bielefeld.de>
------------------------------
Date: Sun, 29 Jan 2006 21:50:36 -0500
From: dwikstrom@private
Subject: Re: "NTSB report on Southwest Airlines crash" (Thompson, R-24.15)
IMO the conclusion of "automatic" Thrust-Reverser failure is premature --
and probably totally inaccurate.
There is yet no reported evidence that the aircraft Thrust-Reversers
malfunctioned at all.
Human error by the pilot, not failure of an "Automatic" system -- is the
likely cause of late deployment of the Thrust-Reversers in that Chicago,
Boeing 737 accident.
The NTSB merely stated that the aircraft flight-recorder showed the
Thrust-Reversers deployed 18-seconds after touchdown. There was no statement
of actual or suspected failure of the Thrust-Reverser system --- only later
than expected activation during landing.
The pilot should have 'manually' activated Thrust-Reversers at touchdown.
NTSB also states: "During post-accident interviews, the captain stated that
he attempted to immediately deploy the thrust reversers but that he was
unable to do so. According to the first officer, at some point during the
rollout, he noticed that the thrust reversers were not deployed, and he then
reached over and deployed them.."
Since pilot-error is generally the primary cause of any & all aircraft
accidents -- IMO it's quite likely the captain failed to deploy
Thrust-Reversers... because the co-pilot easily did so, shortly afterward.
Perhaps in hindsight the captain honestly believes he "attempted" to deploy
the Thrust-Reversers ... or maybe he's now is trying to cover his error by
an alleged system malfunction ??
Note that the NTSB has issued neither a preliminary or final report -- only
an advisory related to flight planning & Thrust-reversers ... so full
details are unavailable. Newspaper reports tend to blur important
considerations in summarizing the NTSB advisory.
Here's the only NTSB reference:
http://www.ntsb.gov/Recs/letters/2006/A06_16.pdf
------------------------------
Date: Sun, 29 Jan 2006 20:35:47 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Gary McGraw on Software Security
Gary McGraw: Software Security: Building Security In
Addison-Wesley, 2006
ISBN: 0-321-35670-5
This book is a "hands-on, how-to guide for software security" for software
security professionals. It completes a trilogy together with McGraw's
Building Secure Software (Addison-Wesley, 2001) and Exploiting Software
(Addison-Wesley, 2004), but it also stands alone as a useful book. It
considers best practices for software security in detail, as a fundamental
part of the development lifecycle. It is very much in the spirit of what
RISKS has promulgated in the past 20.5 years.
------------------------------
Date: Wed, 15 Feb 2006 08:16:42 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "Information Security: Principles and Practice", Mark Stamp
BKINSCPP.RVW 20051112
"Information Security: Principles and Practice", Mark Stamp, 2006,
0-471-73848-4
%A Mark Stamp stamp@private
%C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8
%D 2006
%G 0-471-73848-4
%I John Wiley & Sons, Inc.
%O U$74.95/C$96.99 416-236-4433 fax: 416-236-4448
%O http://www.amazon.com/exec/obidos/ASIN/0471738484/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0471738484/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0471738484/robsladesin03-20
%O Audience i+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P 390 p.
%T "Information Security: Principles and Practice"
The preface stresses that the material in this book is intended to provide
not only the formal concepts for security, but also advice for the real
world. Security is addressed overall, but the work concentrates on
cryptography, access controls, and software issues. (The author also adds a
discussion of protocols. It is hard to see this as a separate issue, rather
than simple implementation details of the other concepts.) The audience is
not explicitly stated, but both security professionals and the idea of using
the volume as a course text are mentioned.
Chapter one is an introduction. Stamp will strike a very sympathetic chord
with many support and security people when he adds a requirement to the
normal list of security questions: can the system survive "clever" users? A
set of problems are given at the end of the chapter. In contrast to the
usual "reading checks," these are thoughtful items, intended to determine if
the reader has understood the underlying concepts, and to start discussion.
Part one addresses cryptography. Chapter two provides the basics, outlining
some terms, theory, and history. Functions and algorithms of symmetric key
cryptography are explained in chapter three, including some discussion of
the controversy over the National Security Agency's role in the development
of the Data Encryption Standard. (Stamp points out the weaknesses in the
conspiracy theory. It is worth noting that Stamp used to work for the NSA
:-) There are some fascinating additions to the usual material for this
topic. Asymmetric algorithms and concepts, again with some interesting
notes, are given in chapter four. Chapter five deals with hash functions
and related topics (and also has a brief mention of steganography).
Advanced cryptanalytic attacks are outlined in chapter six. (Those wanting
to pursue this topic *will* have to brush up on their math.)
Part two looks at access control. Chapter seven provides a reasonably
complete look at direct authentication issues and technologies. The
material on authorization, in chapter eight, extends the normal view of that
topic by pointing out the advantages of capability lists and the fact that
our basic security models are actually those of authorization. However,
Stamp also includes some technologies, such as firewalls and intrusion
detection systems, that have only a tenuous connection to authorization.
Part three examines protocols. Chapter nine discusses simple authentication
schemes, most relying on some kind of challenge- response system and
encryption of some type. Although the writing is clear (and even amusing),
Stamp dives into mathematics, sometimes at crucial moments and without fully
explaining the base concepts. For real world security protocols, chapter
ten looks at SSL (Secure Sockets Layer) and Kerberos, and also examines
IPSec and GSM in some depth, pointing out the weaknesses in design.
Part four deals with software. Chapter eleven explains buffer overflows and
other attacks, and also discusses malware. (Stamp makes a rather odd
mistake in calling the third type of malware detection "anomaly detection"
rather than the more usual activity monitoring. However, the definition of
the term fits activity monitoring properly.) Tamper resistance and software
testing are legitimately part of software security, but chapter twelve also
deals extensively with digital rights management (DRM) which seems to apply
more to data protection. The DRM theme is extended in chapter thirteen
which addresses operating system security functions, but also discusses
Microsoft's upcoming Next Generation Secure Computing Base, which many feel
is more applicable to DRM than any real security needs.
An appendix provides an overview of networking, particularly TCP/IP, and
network security issues.
While not a complete coverage of security, this book has some excellent
material on the subjects it covers. With limited exceptions, Stamp's
writing is clear, and frequently amusing. (Unlike all too many works that
try to inject humour into the security topic, Stamp's quips are not
irrelevant or distracting, but often help to address or solidify concepts.)
The cryptography section is particularly good, providing items of fairly
contemporary cryptological history. The references are well chosen, and a
great many are available on the Web, furnishing a rich source of items for
further study, or general resources. I can easily recommend this text for
those interested in cryptography, and it makes some good points with regard
to software security, as well.
But you can't have my copy. This one I'm keeping.
copyright Robert M. Slade, 2005 BKINSCPP.RVW 20051112
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: Thu, 19 Jan 2006 08:16:23 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "Ending Spam", Jonathan A. Zdziarski
BKENDSPM.RVW 20051029
"Ending Spam", Jonathan A. Zdziarski, 2005, 1-59327-052-6,
U$39.95/C$53.95
%A Jonathan A. Zdziarski
%C 555 De Haro Street, Suite 250, San Francisco, CA 94107
%D 2005
%G 1-59327-052-6
%I No Starch Press
%O U$39.95/C$53.95 415-863-9900 fax 415-863-9950 info@private
%O http://www.amazon.com/exec/obidos/ASIN/1593270526/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1593270526/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1593270526/robsladesin03-20
%O Audience s+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P 287 p.
%T "Ending Spam"
The preface states that the book is for those seriously interested in spam
identification technologies, and concentrates on Bayesian and related
statistical filtering.
Part one is an introduction to spam filtering. Chapter one reviews
the history of spam, although many of the early entries are simply
annoyances or chain letters rather than the commercial or fraudulent
items considered under the banner today, and the author does not seem
to realize that 419 scams predated email by a considerable margin. A
look at the development of spam filtering (excluding Bayesian) is
presented in chapter two, along with some non-filtering. Bayesian
analysis is explained in chapter three, and the statistical filtering
basis is outlined in chapter four.
The fundamental actuarial core is expanded in part two. Chapter five covers
message coding. Tokenization, chunking characters into identifiable items,
is examined in chapter six. Tricks spammers use to evade filters, and the
solutions finding spam despite the deceptions, are outlined in chapter
seven. Storage and performance issues raised by the data rules required by
statistical filters are addressed in chapter eight. Chapter nine looks at
aspects of scaling to systems supporting large numbers of users.
Part three deals with advanced concepts in statistical filtering. Chapter
ten delves into testing which, because of the individual and adaptive nature
of Bayesian filtering, presents unique challenges. Tokenization is
revisited in chapter eleven, in more advanced forms. Markovian
discrimination, with its examination of stateful entities, is explained in
chapter twelve. Having noted many kinds of features in the book, chapter
thirteen explores ways to reduce the items used (and data required) while
maintaining accuracy. Collaborative rule-building with other users,
groups, or systems is reviewed in chapter fourteen.
As the preface implies, this is *not* a book for users who just want to
install POPFile (although that and other programs are explored in an
appendix). For those who are seriously involved in managing and developing
spam filtering, however, the book does provide very useful advice, pointers,
and research.
copyright Robert M. Slade, 2005 BKENDSPM.RVW 20051029
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
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.16
************************
This archive was generated by hypermail 2.1.3 : Wed Feb 15 2006 - 17:04:06 PST