RISKS-LIST: Risks-Forum Digest Thursday 11 May 2006 Volume 24 : Issue 28
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.28.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
The Problem of Test-Induced Failure & the Space Shuttle (Harry Crowther)
BA website discloses passenger passport numbers and DoB (Adam Laurie)
Open Letter to Google on Privacy (Lauren Weinstein)
Fraud in tampering with tamper-proof chip-and-PIN equipment (Nick Rothwell)
Re: Triple DES Upgrades May Introduce New ATM Vulnerability (Jim Daley,
(Bill Cheswick)
NYPD deputy inspector caught rigging crime statistics (Ed Ravin)
Google Captcha (Mark Johnson)
Re: 911 call show wrong address (Ray Arsenault)
Bell inadvertently blocks 1-866 numbers (Rod Davison)
Re: Scarily Prophetic Ad (John Linwood Griffin)
Re: New Private Investigator laws for e-USA (Stanley F. Quayle)
In Wake of SAT Errors, Senator Seeks New Rules on College Testing
(Karen Arenson via Monty Solomon)
Spelling (Richard S. Russell)
REVIEW: "Governance Guidebook", Fred Cohen (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sun, 7 May 2006 13:43:42 -0400
From: "Harry Crowther" <hdcrowther@private>
Subject: The Problem of Test-Induced Failure & the Space Shuttle
NASA managers decided on Thursday to skip a launch pad test of the shuttle
Discovery's redesigned fuel tank because of the risk the test itself could
damage the tank. The test would have entailed filling the shuttle's fuel
tank with cryogenic propellants and testing its systems. The fuel tank has
been the focus of NASA's shuttle safety upgrades since the 2003 Columbia
accident. [Source: Irene Klotz, NASA to skip shuttle tank test ahead of
July launch Reuters, 5 May 2006; PGN-ed]
There must be a better way. When there's doubt or trouble, skip the test
(!?!). There may indeed be some practical wisdom in evidence here, but it
doesn't bode well.
------------------------------
Date: Wed, 03 May 2006 14:43:53 +0100
From: Adam Laurie <adam.laurie@private>
Subject: BA website discloses passenger passport numbers and DoB
In January of this year I reported to British Airways that it was possible
to recover arbitrary passengers' confidential information, including Date Of
Birth and passport details, by simply matching a frequent flier number to a
surname when purchasing a ticket via their website. Since this information
is printed on every boarding pass, any discarded passes can potentially
provide an attacker with the information he needs to access the data via the
website.
The problem exists because of the US Government's requirement for airlines
to provide Advance Passenger Information for all passengers destined for
their shores. It is left to the airlines themselves to administer the data
collection systems, and, therefore, to make their own mistakes in the
security systems that control access to that data. The more airlines that
implement these systems, the more potential security holes will exist.
Full story here:
http://www.guardian.co.uk/g2/story/0,,1766138,00.html
Adam Laurie, The Bunker Secure Hosting Ltd., Ash Radar Station, Sandwich, Kent
CT13 0PL UK http://www.thebunker.net +44 (0) 1304 814800
[Joel Baskin also noted
http://www.guardian.co.uk/idcards/story/0,,1766266,00.html
PGN]
------------------------------
Date: Tue, 9 May 2006 15:50:28 -0700 (PDT)
From: Lauren Weinstein <lauren@private>
Subject: Open Letter to Google on Privacy
An Open Letter to Google:
Concepts for a Google Privacy Initiative
Lauren Weinstein
May 9, 2006
http://www.vortex.com/google-privacy-initiative
Preface: The overall situation relating to U.S. and global
privacy issues is deteriorating rapidly. Recent Congressional
moves toward legislating broad, government-mandated data
retention laws ( http://lauren.vortex.com/archive/000175.html )
are particularly alarming. The manners in which we
collectively choose to address these sorts of issues are
likely to have drastic impacts not only on our own lives, but
also broadly on the shape of society, both today and in the
future.
Greetings. When I was recently invited to speak at Google's Santa Monica
center ( Video at http://lauren.vortex.com/archive/000168.html ), I was
impressed by the quality of the facilities, but even more so by the caliber
of the Google employees I met during my visit. Google's capabilities are
extraordinary. While I have been publicly critical of some Google policies,
my concerns have been focused not on Google today, but rather mainly on how
Google's immense data processing, storage, and related infrastructures might
be abused in the future, particularly by outside entities in a position to
force Google's hand despite Google's own best intentions.
As discussed in my talk, I consider Google to be an incredibly important and
admirable resource with vast potential to do good. But by the same token,
it is largely this very power that increases the risks of serious abuses of
Google capabilities being forced upon the organization, and Google will
likely be unable to mitigate many of these unless it takes major proactive
steps on an immediate and ongoing basis, particularly including
privacy-related efforts.
Increasingly, Internet users are becoming highly sensitized to both
perceived and real risks to their privacy associated with their use of the
Net. While the real risks we face in this arena are serious enough,
people's confidence (or lack thereof) in products and services will in many
cases be shaped primarily by perceptions, and often significantly less by
the underlying realities. This highlights the critical fact that to be
truly successful, efforts to reduce privacy risks must not only have genuine
and ongoing positive privacy effects, but also need to be clearly perceived
by users and the broader public to be in place and fully supported as
primary goals of the organizations involved.
Web-based search engines are an obvious current focus of many privacy
concerns, but as more traditional "desktop" applications migrate to tightly
coupled topologies with user data stored on remote servers not under users'
direct local control (e.g. for PC searches, document preparation, e-mail,
etc.), these issues and related potential risks are rapidly spreading across
the entire computer and Internet spectra.
Fears that users' private information may be increasingly subject to
intrusive perusal by law enforcement or other authorities (often with
minimal and/or questionable cause) are further damaging user confidence in
such services, with a range of issues related to data retention being an
important element at the heart of these concerns. To the extent that
potentially sensitive data is stored for extended periods, particularly in
non-anonymous forms, it is inevitable that outside demands for access to it
-- on ever broader scales -- will be accelerating. While individual court
cases will of course vary in their results, the court system cannot be
relied upon to always render appropriate decisions regarding such matters,
particularly in today's political and legislative environments.
I believe that Google, by virtue of its Internet industry leadership,
technical and human resources, and corporate culture, is in a unique
position. Google can demonstrate how world-class privacy protection
policies and technologies can be developed and deployed in ways that enhance
user confidence in current and future Google services -- by proactively
protecting users' private data without interfering with service operations,
innovation, R&D, or the legitimate concerns of law enforcement. Google
could be the acknowledged global leader in this area, becoming synonymous
with the concept of integrating new and advanced privacy capabilities into
world-class Internet services and products.
Obviously the confidence such efforts would engender in Google's users would
be healthy for Google's bottom line, but more importantly it will provide
genuine and continuing real benefits to the Google user community itself
(i.e. the entire world). Where non-proprietary information is involved,
further benefits to society could be achieved through making publicly
available (via published papers, conferences, etc.) those aspects of
resulting privacy-related R&D technologies that could be deployed by other
entities to the benefit of the global community.
I recommend that Google establish a team explicitly dedicated to the
development and deployment of privacy-related efforts as outlined above.
Such a team would be tasked with establishing the framework of these
projects in a consistent manner, and ensuring to the greatest extent
practicable that all current and future Google products and services would
be integrated (from the outset when possible) with these privacy
technologies and policies. The team would need access to other individuals
within both the development and operational aspects of Google, and ideally
would report directly to high-level management.
To be effective, such a team would need to be significantly
interdisciplinary in its makeup and scope, including a variety of skills.
Some of these would include a broad range of CS capabilities (including
specialized mathematical disciplines related to encryption, among many
others). Experience in dealing with the particular and complex interplay
between technology and societal issues will also be an important component
of such a team.
Google's growing scale and influence suggest that the sorts of privacy
efforts suggested herein could be among the most important non-governmental
privacy-related endeavors for many years to come, and could have vast
positive impacts far into the future not only for Google and its users, but
throughout the commercial, nonprofit, and government sectors.
This document represents a very brief conceptual outline, offered with only
the best interests of both Google and the world at large in mind. Google
and the broader Internet are at a critical crossroads in many respects, and
I believe that Google has the opportunity to do enormous good by initiating
the types of efforts that I've described.
I would welcome the opportunity to discuss these concepts with you in more
detail and to work with Google toward their realization, as you may deem
appropriate.
Thank you very much for your consideration.
Lauren Weinstein lauren@private http://www.pfir.org/lauren +1(818)225-2800
Co-Founder, PFIR People For Internet Responsibility - http://www.pfir.org
------------------------------
Date: Tue, 2 May 2006 12:29:45 +0100
From: Nick Rothwell <nick@private>
Subject: Fraud in tampering with tamper-proof chip-and-PIN equipment
Something of a breaking story (currently being reported by BBC Radio 4's
"You and Yours" news magazine program, http://www.bbc.co.uk/
radio4/youandyours/). Shell UK have withdrawn chip-and-PIN credit card
payment facilities from 160 of their garages, following incidents of
fraud. Chip-and-PIN has been publicised by the vendors as "safer, faster,
more secure" than signature-based authentication (see the publicity at
http://www.chipandpin.co.uk), although the security of the PIN numbers is
the responsibility of the card holders. (This suggests that any fraud which
occurs puts the onus on the card holder to prove that the PIN number was not
divulged; with the old signature method, the onus is on the retailer to
produce the sales slip.)
In this particular case, it appears that the card terminal devices designed
by Trintech, although tamper-resistant (i.e. will fail to operate if
tampered with), were tampered with to commit the fraud. Trintech are
claiming that their equipment is not at fault, and the issue is one of the
"environment" in which they were installed.
I am hoping that this story will be picked up by the science press, so that
we can learn some of the details.
According to You and Yours, there have been previous incidents of
chip-and-PIN fraud where unscrupulous retailers were able to add items to a
customer's bill after the payment transaction.
nick rothwell -- composition, systems, performance -- http://www.cassiel.com
[Pete Mellor noted a BBC item on this:
http://news.bbc.co.uk/go/pr/fr/-/1/hi/england/4980190.stm
noting that this situation "rather dents the claim that the introduction
of chip-and-pin would dramatically reduce the level of 'plastic fraud'."
PGN]
------------------------------
Date: Sun, 7 May 2006 16:11 +0100 (BST)
From: jdaley@private (Jim Daley)
Subject: Re: Triple DES Upgrades May Introduce New ATM Vulnerability (R-24.26)
If it really is only the pin that is being encrypted and it is accompanied
with the account no - then isn't there an even greater risk of the bank's
des keys being considerably more open to attack than in the past?
Effectively you have any number of ciphertext samples each corresponding to
4 digit pins, with repeat pins being easily identified by the account no,
also each ciphertext has a very limited range of equivalent plaintext
(0-9999), and it wouldn't be too difficult to obtain a reasonable quantity
of ciphertext with known plaintext by simply opening accounts in the
compromised bank.
------------------------------
Date: Mon, 1 May 2006 16:27:29 -0400 (EDT)
From: ches@private (ches)
Subject: Re: Triple DES Upgrades (Redspin, RISKS-24.26)
> In stereotypical and steadfastly arrogant fashion, USA banks are refusing
> to move to chip- and-PIN
I have heard briefings from highly-placed people at both MC and Visa
discussing this. They are steadfast and firm: chips will not be implemented
in the US credit cards. There is insufficient justification for the
expense, given the cheap modems and phone system available to retail
outlets.
------------------------------
Date: Wed, 10 May 2006 13:21:45 -0400
From: Ed Ravin <eravin@private>
Subject: NYPD deputy inspector caught rigging crime statistics
The *NY Post* reports that an NY City Police Department (NYPD) deputy
inspector was demoted down to captain after NYPD investigators concluded
that he had rigged crime statistics when he was in charge of a Queens
precinct in 2004. Full story at:
http://www.nypost.com/news/regionalnews/63480.htm
There have been previous reports of police commanders accused of falsifying
the crime statistics (nicknamed "CompStat") in various ways, as they are
under great pressure to show "good numbers", even if the criminals don't
cooperate by committing less crimes. But this time there's a twist - the
former inspector is also accused of "infiltrating the department's CompStat
program to increase archived crime numbers for his precinct from before he
arrived there" so that his ratings would look even better!
I'd love to hear the details about how the NYPD's database was altered - but
the Department is rarely that forthcoming with its dirty laundry. They have
stonewalled every outside investigation of this problem, especially the
Mayor's Commission to Combat Police Corruption, whose chairman quietly
resigned after the NYPD refused to cooperate with the Commission.
Most of the other reports involve rigging the statistics before the data is
entered - felony crimes get "demoted" to lesser categories, and police
discourage reports or "lose the paperwork" so that some crimes don't even
get into the system in the first place. Even the head of the NYPD
Patrolmen's Benevolent Association, the police officer's union, has
complained about this.
*The Village Voice* published an excellent report that compared the police
numbers with similar statistics from local hospitals, showing suspicious
drops in assaults reported by the NYPD even though hospital admissions for
assault were going up:
http://www.villagevoice.com/news/0544,moses,69552,5.htmlhttp://www.villagevoice.com/news/0544,moses,69552,5.html
The RISK? The NYPD (and the many police departments worldwide who copy
them) have become such slaves of their CompStat system that they spend their
effort gaming it rather than doing their jobs and actually reducing crime.
[See also my post in RISKS-13.69 describing how the NYPD plays similar
computer games with a performance metric in their 911 dispatch system,
online at http://catless.ncl.ac.uk/Risks/13.69.html#subj7 ]
[Another review of how the NYPD uses technology (including IBM Selectric
typewriters!) is at:
http://www.baselinemag.com/print_article2/0,1217,a=30781,00.asp
(see the two articles "NYPD Rethinks its Dispatch System" and "The
Disconnected Cop") ]
------------------------------
Date: Wed, 10 May 2006 15:03:15 -0600
From: "Mark Johnson" <mhjohnson@private>
Subject: Google Captcha
Apparently Google has been getting too many "automated" searches on
their main site
http://www.google.com/
or the personalized page at
http://www.google.com/ig/
and has added a "captcha" that you must answer prior to getting to the
search page. However, there seem to be some bugs including:
- repeated prompts for the captcha (about once per hour so far...)
- a frame with customized content is replaced by a Google error
message that indicates your machine is possibly spyware or virus infected
I find it odd that Google would deploy something that prevents users from
seeing all those advertisements that make money from the company (a side
effect of doing searches). It would be interesting to find out the back
story on this problem and why the "solution" is so broken for users of the
search service.
[As a follow up, the captcha appears to have been removed after being
up about four hours.]
------------------------------
Date: Fri, 5 May 2006 18:20:58 -0700
From: "Ray Arsenault" <ray.arsenault@private>
Subject: Re: 911 call show wrong address
I think this is an issue not only with PBX's, but perhaps to a lesser extent
CLEC's as well. I used to work for a business that had a regular need for
interaction with the City Police. In Vancouver (BC), if you need the city
Police to attend anywhere, even if it's not a 911-type emergency, the only
way to reach someone who can actually dispatch a car is to call 911.
Thus, I used to call 911 on a semi-regular basis, explain my issue-du-jour
to the operator, and get the usual "We'll wander a car by when we have a
minute, call us back if it escalates.."
But I also got more than my fair share of calls back saying either "We were
at 401 West Georgia, and we can't find your business there..." or they'd
call back a minute or so later and say "Uh, I thought you guys were over at
(location). Our ANI says 401 West Georgia.."
We were using Allstream (formerly AT&T Canada), and I guess that their
business offices in Vancouver were at 401 West Georgia, and so Telus (the
ILEC) had that show up on ANI from thier trunks. I called Allstream
repeatedly, and they just kept telling me "Well, we have your address as
being (whatever), and so that's what should show up on ANI. There's nothing
we can do about it."
------------------------------
Date: Tue, 9 May 2006 10:02:44 -0400
From: Rod Davison <rod@private>
Subject: Bell inadvertently blocks 1-866 numbers
The 613 area code (Ottawa and eastern Ontario Canada) is moving from seven
digit local calling to 10 digit local calling, a common transition. The
first stage seemed to work okay with the caller id now showing the ten
digits of local callers' numbers instead of the seven, but this morning, a
new glitch appeared.
There is a local 866 exchange so that the phone number 866-1234 (just made
up) is a local call. As of this morning, when I tried to dial
1-866-123-4567 I received the message "This is not a long distance call." as
soon as I pressed the "4" in the sequence. Dialing "866-1234" got me the
message "The mailbox of 866-1234 is full." I'm not really surprised.
In another several months, when full ten digit calling is required, this
clearly will not occur. However, until then, one has to wonder about
several issues:
(1) Why did Bell, or whoever else is involved, not test the possible effect
of this change before it was made in the phone system. It is reasonable to
assume that most 1-866 customers are businesses, which implies that this
could have a a significant impact on those businesses that rely on their
toll free service to receive orders from customers and perform other
business functions. The liability issue alone should have flagged this
change as one that had to be tested thoroughly.
(2) When attempting to contact Bell about this issue, I received one of two
responses. Either the Bell operator placed the call for me without
listening to why I was calling, or they wanted me to schedule a service
call. Finally after a number of attempts, someone at Bell repair finally
"got it" and decided to relay my report to their supervisor. When someone
reports unusual system behavior (and reports they observed it on several
different phone lines) it should raise some sort of red flag.
Rod Davison, Critical Knowledge Systems Inc. (613) 834-7018 rod@private
------------------------------
Date: Tue, 2 May 2006 14:59:01 -0400 (EDT)
From: John Linwood Griffin <griffin2@private>
Subject Re: Scarily Prophetic Ad (Graifer, RISKS-24.27)
For those like me who would like to know more about where a link goes before
clicking on it, this is the ACLU Pizza flash animation. Also, for those
like me who had trouble accessing adcritic's web site, you may go straight
to the source: http://aclu.org/pizza/
------------------------------
Date: Thu, 04 May 2006 19:11:37 -0400
From: "Stanley F. Quayle" <stan-at-stanq-dot-com>
Subject: Re: New Private Investigator laws for e-USA
> Some computer professionals will need to get a Private Investigator license
> just to continue doing their computer work.
The Ohio law requires this already:
The business of private investigation is [...] determine the cause of or
responsibility for [...] damage to property, or to secure evidence for use
in any legislative, administrative, or judicial investigation or
proceeding.
> I imagine this will also apply to accountants and auditors
The law exempts, among other groups, lawyers and accountants.
> We will have to be asking suppliers of firewall, anti-virus, anti-spam,
> anti-spyware etc. if they have a PI license
Ohio law also exempts licensed professional engineers. Ask your supplier if
they employ professional engineers -- after all, your software should follow
sound engineering principles.
My signature line includes "P.E.", which stands for Professional Engineer.
Now I know why I got my license...
The Ohio private investigator FAQ:
http://www.homelandsecurity.ohio.gov/PISG_information/Classes_Licensure.htm
Stanley F. Quayle, P.E. N8SQ 8572 North Spring Ct., Pickerington, OH 43147
Quayle Consulting Inc. http://www.stanq.com/charon-vax.html 1-888-I-LUV-VAX
------------------------------
Date: Wed, 3 May 2006 01:14:16 -0400
From: Monty Solomon <monty@private>
Subject: In Wake of SAT Errors, Senator Seeks New Rules on College Testing
In Wake of SAT Errors, Senator Seeks New Rules on College Testing
[Source: Karen W. Arenson, *The New York Times*, 3 May 2006; PGN-ed]
NY State Senator Kenneth P. LaValle, chairman of the State Senate's higher
education committee, said he would push for stricter government oversight of
the college admissions testing industry, including a requirement that all
questions and answers be disclosed after the exams without charge.
------------------------------
Date: Tue, 2 May 2006 15:15:37 -0500
From: "Richard S. Russell" <RichardSRussell@private>
Subject: Spelling
Several of your recent correspondents seem to need this reminder:
"Lead" (pron. "leed") is present tense; "led" (pron. "ledd") is past
tense; "lead" (pron. "ledd") is a heavy gray metal.
Just to confuse things:
"Read" (pron. "reed") is present tense; "read" (pron. "redd") is past
tense; "red" (pron. "redd") is a color; "Redd" (pron. "redd") is a
guard for the Milwaukee Bucks.
Spell checkers will only flag the last item.
Richard S. Russell http://richardsrussell.livejournal.com/ 608+233-5640
[NOTE: RISKS cannot be responsible for such errors. Your moderator
already fixes many typos, but cannot begin to attempt to overcome the
growing general lack of attention to writing correctness. PGN]
------------------------------
Date: Tue, 09 May 2006 11:53:57 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "Governance Guidebook", Fred Cohen
BKCISOGG.RVW 20051119
"Governance Guidebook", Fred Cohen, 2005, 1-878109-34-0
%A Fred Cohen http://all.net
%D 2005
%G 1-878109-34-0
%I ASP Press
%O http://www.amazon.com/exec/obidos/ASIN/1878109340/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1878109340/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1878109340/robsladesin03-20
%O Audience a+ Tech 1 Writing 2 (see revfaq.htm for explanation)
%P 204 p.
%T "Governance Guidebook"
The very short section one of the Governance Guidebook explains that it is
intended for the CISO (Chief Information Security Officer) of a large
concern. Which is to say that the reader should be experienced in security
and the management thereof. At that point one wonders what such a work
would entail: presumably such a person would already know pretty much
anything you could put into a book. This introduction then goes on to
detail the organization of the guidebook. Section two is an overview of the
structure of a security plan or protection strategy. It also notes that the
illustrations in this section of the text are very busy and cluttered, but
that careful study will make the situation clearer.
All of this is true. This is definitely not your standard security
textbook. It is extremely demanding of the reader, but will amply repay the
effort put into using the volume. And I say "using," rather than merely
"reading": this is a tome that requires application. Bed- time reading it
is not.
This is not a primer to be read quickly in one sitting. The illustrations
are dense, and so is the text, but dense with meaning and import. This is a
work to be worked through, a page or even a paragraph at a time. And then,
when you are finished, work through it again. If you are a CISO it won't
teach you anything--but it will remind you of things, practices, and
procedures that have possibly been forgotten in the press of other
urgencies. This volume becomes, therefore, an aide memoire for the
strategic planning of information protection.
This is not to say that there are no details provided. Section three,
entitled "Drill Down," provides greater depth to a number of the areas (one
example is an intriguing use of the human life span to address personnel and
human resources issues). The content does not deal with specific technical
areas of security, but does provide a very solid overview of security
management--or, if you prefer, governance.
This is a handy and useful guide for those in the CISO position. It is
destined to become well-thumbed, dirty, and dog-eared, over time. Those who
are not yet into a CISO job will not recognize all of the value in its
pages, yet. However, those who aspire to the calling would do well to get a
start on learning from it.
copyright Robert M. Slade, 2005 BKCISOGG.RVW 20051119
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.28
************************
This archive was generated by hypermail 2.1.3 : Thu May 11 2006 - 14:18:57 PDT