RISKS-LIST: Risks-Forum Digest Tuesday 17 May 2005 Volume 23 : Issue 87
ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
<http://catless.ncl.ac.uk/Risks/23.87.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Prius cars shutdown at speed (Edwin Slonim)
The Downside of Wired Hospitals (Ken Knowlton)
Medical Usability: How to Kill Patients Through Bad Design (Dan Jacobson)
REAL ID (Bruce Schneier)
US Government to alter RFID passport regulations (Avishai Wool)
Good old-fashioned physical security (Joseph Shead)
Social security number seeding (Pekka Pihlajasaari)
IT forecast from Dave Patterson (Marcus H. Sachs)
Car breakins using bluetooth (Andrew Nicholson)
Don't blame the messenger (Paul Tomblin)
Re: PDF not a good format for redacting classified documents (Bob Blakley)
Re: Amtrak's Acelas (Philip Nasadowski, Martin Ward, Derek P Schatz)
Train anomaly (PGN)
Comair: Bound to Fail (Craig S. Bell)
What Search Sites Know About You (Joanna Glasner via Monty Solomon)
Re: BofA agent gives out personal information (Brent J. Nordquist)
SecurID: bad compared to what? (Rick Smith)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 17 May 2005 13:19:35 +0300
From: "Edwin Slonim" <eslonim@private>
Subject: Prius cars shutdown at speed
The U.S. National Highway Transportation Safety Administration has 13
reports of Toyota's Prius gas-electric hybrid cars (2004 and early 2005)
stalling or shutting down at highway-driving speeds, which Toyota
attributes to software problems. [Source: Toyota Attributes Prius
Shutdowns To Software Glitch Sholnn Freeman, *The Wall Street Journal*, 16
May 2005; PGN-ed]
I have always feared losing power, brakes and steering at high speed - with
a helpful dashboard indication of "internal error 687, please reset". Looks
like it is starting to happen. Of course we need to put this into
proportion - how many cars stall at high speed with a fuel blockage, or
swerve with a blowout.
Edwin Shalom Slonim, eslonim@private Minols Ltd, 83 Moriah Blvd,
PO Box 7360, Haifa 31072 Israel +972-4-826-6583
------------------------------
Date: Fri, 29 Apr 2005 19:29:59 EDT
From: Ken Knowlton <KCKnowlton@private>
Subject: The Downside of Wired Hospitals
"Computers are making hospitals more dangerous, new research suggests.
Computer keyboards fester with colonies of bacteria, which can easily spread
from the medical personnel who use them to the patients they treat. Some
hospitals now have computers in every patient room, creating even more
opportunities for contamination. Researchers at Northwestern Memorial
Hospital in Chicago found that the types of bacteria commonly found in
hospitals -- some resistant to antibiotics -- could survive on a keyboard
for 24 hours. Simply cleaning the computers with soap and water didn't make
a difference. Using a strong disinfectant did kill the germs -- but it also
damaged the computers. 'The difficulty with keyboards is you can't pour
bleach on them,' Dr. Allison McGreer of Toronto's Mount Sinai Hospital tells
The Canadian Press. 'They don't work so well when you do that.' Because
it's nearly impossible to keep keyboards sterile, researchers say, the onus
is on doctors and nurses to wash their hands vigorously and often."
[Excerpted from *The Week*, 29 May 2005]
------------------------------
Date: Mon, 02 May 2005 08:48:36 +0800
From: Dan Jacobson <jidanni@private>
Subject: Medical Usability: How to Kill Patients Through Bad Design
http://www.useit.com/alertbox/20050411.html
------------------------------
Date: Sun, 15 May 2005 03:39:20 -0500
From: Bruce Schneier <schneier@private>
Subject: REAL ID
[PGN-Excerpted from CRYPTO-GRAM, May 15, 2005
Counterpane Internet Security, Inc.]
<http://www.schneier.com><http://www.counterpane.com>
The United States will get a national ID card. The REAL ID Act establishes
uniform standards for state driver's licenses, to go into effect in three
years, effectively creating a national ID card. It's a bad idea, and is
going to make us all less safe. It's also very expensive. And it all
happened without any serious debate in Congress.
I've already written about national IDs. I've written about the fallacies
of identification as a security tool. I'm not going to repeat myself here,
and I urge everyone who is interested to read those essays (links at the
end). Remember, the question to ask is not whether a national ID will do
any good; the question to ask is whether the good it does is worth the cost.
By that measure, a national ID is a lousy security trade-off. And everyone
needs to understand why.
Aside from the generalities in my previous essays, there are specifics about
REAL ID that make for bad security.
The REAL ID Act requires driver's licenses to include a "common
machine-readable technology." This will, of course, make identity theft
easier. Already some hotels take photocopies of your ID when you check in,
and some bars scan your ID when you try to buy a drink. Since the U.S. has
no data protection law, those businesses are free to resell that data to
data brokers like ChoicePoint and Acxiom. And they will; it would be bad
business not to. It actually doesn't matter how well the states and federal
government protect the data on driver's licenses, as there will be parallel
commercial databases with the same information.
(Those who point to European countries with national IDs need to pay
attention to this point. European countries have a strong legal framework
for data privacy and protection. This is why the American experience will
be very different than the European experience, and a much more serious
danger to society.)
Even worse, there's likely to be an RFID chip in these licenses. The same
specification for RFID chips embedded in passports includes details about
embedding RFID chips in driver's licenses. I expect the federal government
will require states to do this, with all of the associated security problems
(e.g., surreptitious access).
REAL ID requires that driver's licenses contain actual addresses, and no
post office boxes. There are no exceptions made for judges or police --
even undercover police officers. This seems like a major unnecessary
security risk.
REAL ID also prohibits states from issuing driver's licenses to illegal
aliens. This makes no sense, and will only result in these illegal aliens
driving without licenses -- which isn't going to help anyone's security.
(This is an interesting insecurity, and is a direct result of trying to take
a document that is a specific permission to drive an automobile, and turning
it into a general identification device.)
REAL ID is expensive. It's an unfunded mandate: the federal government is
forcing the states to spend their own money to comply with the act. I've
seen estimates that the cost to the states of complying with REAL ID will be
tens of billions. That's money that can't be spent on actual security.
And the wackiest thing is that none of this is required. In October 2004,
the Intelligence Reform and Terrorism Prevention Act of 2004 was signed into
law. That law included stronger security measures for driver's licenses,
the security measures recommended by the 9/11 Commission Report. That's
already done. It's already law.
REAL ID goes way beyond that. It's a huge power-grab by the federal
government over the states' systems for issuing driver's licenses.
REAL ID doesn't go into effect until three years after it becomes law, but I
expect things to be much worse by then. One of my fears is that this new
uniform driver's license will bring a new level of "show me your papers"
checks by the government. Already you can't fly without an ID, even though
no one has ever explained how that ID check makes airplane terrorism any
harder. I have previously written about Secure Flight, another lousy
security system that tries to match airline passengers against terrorist
watch lists. I've already heard rumblings about requiring states to check
identities against "government databases" before issuing driver's licenses.
I'm sure Secure Flight will be used for cruise ships, trains, and possibly
even subways. Combine REAL ID with Secure Flight and you have an
unprecedented system for broad surveillance of the population.
Is there anyone who would feel safer under this kind of police state?
Americans overwhelmingly reject national IDs in general, and there's an
enormous amount of opposition to the REAL ID Act.
If you haven't heard much about REAL ID in the newspapers, that's not an
accident. The politics of REAL ID was almost surreal. It was voted down
last fall, but was reintroduced and attached to legislation that funds
military actions in Iraq. This was a "must-pass" piece of legislation,
which means that there was no debate on REAL ID. No hearings, no debates in
committees, no debates on the floor. Nothing. And it's now law.
We're not defeated, though. REAL ID can be fought in other ways: via
funding, in the courts, etc. Those seriously interested in this issue are
invited to attend an EPIC-sponsored event in Washington, DC, on the topic on
June 6th. I'll be there.
Text of the REAL ID Act:
<http://thomas.loc.gov/cgi-bin/bdquery/z?d109:h.r.00418:>
Congressional Research Services analysis:
<http://www.eff.org/Activism/realid/analysis.pdf>
My previous writings on identification and national IDs:
<http://www.schneier.com/crypto-gram-0404.html#1>
<http://www.schneier.com/crypto-gram-0402.html#6>
<http://www.schneier.com/crypto-gram-0112.html#1>
Security problems with RFIDs:
<http://www.schneier.com/crypto-gram-0410.html#3>
My previous writings on Secure Flight:
<http://www.schneier.com/crypto-gram-0502.html#1>
Resources:
<http://www.epic.org/privacy/id_cards/>
<http://www.unrealid.com/>
EPIC's Washington DC event:
<http://www.epic.org/events/id/savethedate.html>
------------------------------
Date: Fri, 6 May 2005 17:18:40 +0300
From: Avishai Wool
Subject: US Government to alter RFID passport regulations
Responding to fears raised by privacy advocates that new electronic
passports might be vulnerable to high-tech snooping, the State Department
intends to modify the design so that an embedded radio chip holding a
digitized photograph and biographical information is more secure.
[Source: Bowing to Critics, U.S. to Alter Design of Electronic Passports
Eric Lipton, *The New York Times*, 27 Apr 2005]
http://www.nytimes.com/2005/04/27/politics/27passport.html
[requires registration]
On a personal (self-congratulatory) note, it seems that a recent
paper by Ziv Kfir and myself:
"Picking virtual pockets using relay attacks on
contactless smartcard systems"
http://eprint.iacr.org/2005/052
was used as ammunition in the campaign to pressure the state
department to rethink the e-passport design.
RISKS readers may find interest in this letter from the Berkeley Law School
to the Office of Passport Policy, on behalf of an impressive list of
computer scientists and security experts, explaining what was wrong with the
previous design:
http://www.law.berkeley.edu/cenpro/samuelson/papers/other/ElectronicPassport_Comments_DOS.pdf
Curiously, I saw somewhere recently (I don't have the URL handy) that the
only country in the world that was ready with the (now defunct) e-passport
was Belgium(?). The US was not ready to meet its own deadline... I bet some
people in Brussels are less than happy with the news...
Avishai Wool, Ph.D., School of Electrical Engineering, Tel Aviv University,
Ramat Aviv 69978, ISRAEL http://www.eng.tau.ac.il/~yash
------------------------------
Date: Sat, 7 May 2005 14:05:02 -0500
From: "Joseph Shead" <Joe@private>
Subject: Good old-fashioned physical security
Lost items puzzle nuclear research lab: The U.S. federal Idaho National
Laboratory nuclear-reactor research lab cannot account for more than 200
missing computers and disk drives that may have contained sensitive
information. The computers were among 998 items costing $2.2 million
dollars that came up missing over the past three years. Lab officials told
investigators that none of the 269 missing computers and disk drives had
been authorized to process classified information. But they acknowledged
there was a possibility the devices contained ''export controlled"
information -- data about nuclear technologies applicable to both civilian
and military use. [Source: AP item from *The Boston Globe*, 7 May 2005,
PGN-ed]
------------------------------
Date: Wed, 27 Apr 2005 11:28:56 +0200
From: Pekka Pihlajasaari <pekka@private>
Subject: Social security number seeding (Re: RISKS-23.85 et al.)
Many articles documenting the risks of exposure of personally identifiable
information bemoan the possibility of compromise. There seems to be very
little quantitative information on the number of cases where the information
is used inappropriately.
If a selection of unused social security numbers were identified as probes,
these could be used by credit bureaux and other large databases as proxies
for compromise. Any use of these numbers would be positive confirmation of
breach of the related database, and an indication of the rate at which
harvested numbers are utilised. While this does pollute the datasets with
incorrect data, this provides an in-band mechanism to detect misuse. The
practise has been in use by mailing list rental companies to count the
number of times a list is used.
The low occurrence of the probes makes wholesale harvesting easy to detect
and difficult for the harvester to protect themselves against. This risk, of
course, is that the list of probe numbers is compromised!
Pekka Pihlajasaari pekka@private +27 (11) 728-0899 Data Abstraction Ltd
------------------------------
Date: Wed, 11 May 2005 21:53:10 -0400
From: "Marcus H. Sachs"
Subject: IT forecast from Dave Patterson
"The history of IT is littered with companies that lost substantial leads in
this fast-changing field. I see no reason why it couldn't happen to
countries. Indeed, at the recent International Collegiate Programming
Contest of the Association for Computing Machinery, four Asian teams
finished in the top dozen, including the champion, while the best U.S.
finish was 17th, the country's worst showing ever. If current U.S.
government policies continue, IT leadership could easily be surrendered to
Asia."
[ACM President David Patterson gave testimony before a Congressional hearing
last week. PGN]
http://news.com.com/Surrendering+U.S.+leadership+in+IT/2010-7337_3-5701653.html
------------------------------
Date: Fri, 6 May 2005 11:35:08 -0700
From: Andrew Nicholson <andrewn@private>
Subject: Car breakins using bluetooth
I recently lost our rental car in one of the huge parking lots of Disney
World. The color and license plate entry on the rental car tag were
incorrect and we couldn't remember the color and we had the row wrong.
Eventually security drove us around while I pushed the "panic" button on the
remote key fob at any likely looking vehicle. Security knew roughly where
the cars were parked based on the time that you caught the shuttles. Once
we found the car that was it - no further checks.
During the search I asked about car theft from the parking lots given that
they are huge and there is little sign of security patrols etc. The claim
was that they don't have many car thefts, but they do have 4 to 5 break-ins
every day where the contents of the cars are stolen.
Here's the interesting part: every break-in in the past month had involved a
laptop with internal bluetooth. Apparently if you just suspend the laptop
the bluetooth device will still acknowledge certain requests allowing the
thief to target only cars containing these laptops.
------------------------------
Date: Fri, 6 May 2005 21:38:27 -0400
From: Paul Tomblin <ptomblin@private>
Subject: Don't blame the messenger (Re: Blakley, RISKS-23.86)
In RISKS-23.86, Bob Blakley attacks the Italian newspaper who discovered
that they could use cut and paste to see "blacked out" text as "having
allies whose press is eager to publish information which will endanger your
troops".
He's not the only one, as evidenced by the discussion in the Slashdot
article he referenced.
It's an incredible mistake to think that America's enemies are so
unsophisticated or stupid that they couldn't figure this same method out
themselves if the Italian newspaper hadn't published it. Underestimating
your enemy is a sure way to lose.
Paul Tomblin <ptomblin@private> http://xcski.com/blogs/pt/
------------------------------
Date: Fri, 6 May 2005 12:25:03 -0500
From: Bob Blakley <bob.blakley@private>
Subject: Re: PDF not a good format for redacting classified documents
What's most interesting to me about this is that it will undoubtedly
generate all sorts of proposals for wildly expensive and demonstrably
ineffective fixes.
My prediction is that the preferred proposals will be:
1. A proprietary mil-spec word processor which is guaranteed to delete what
it redacts, to be developed bespoke.
2. A complicated PDF file filter which searches for classified information
at specified levels and strips it out.
These would be multimillion dollar projects with a customer base of - say -
five, and would be predictably behind schedule and ineffective.
The problem, of course, arises because the appearance of the document on the
screen does not correspond to its deep structure. However it's easy and
cheap to fix this problem.
The $100 solution would be to designate a redacted-document-release server
and configure it so that it only accepts uploads via FAX.
To get documents onto such a server, you'd need to go through the analog
hole, which would automatically guarantee that the document's appearance IS
its deep structure. Voila.
------------------------------
Date: Tue, 26 Apr 2005 22:49:45 -0400
From: Philip Nasadowski <nasadowsk@private>
Subject: Re: Amtrak's Acelas (RISKS-23.85)
Actually, Acela's problems are a bit deeper:
* The trainset was built 4 inches wider than it was supposed to. Nobody
really knows or will fess up as to why. as a result, it can't tilt on
trackage owned by Metro-North, which is the curviest part of the system.
Elsewhere, it can't tilt as much as it was supposed to.
* The trainsets are built to the US DOT's 'Tier II' standards, which require
strength standards roughly 5 times that of UIC (European) railcars. The
result is an enormous increase in weight - the unpowered Acela coaches are
nearly as heavy as the TGV's locomotives (!).
* The above weight issues result in the train being unstable at running
speeds, a problem never totally solved. In addition, the curve speeds must
be lower (because of the weight).
* TGVs use their locomotives for a large amount of the total braking on the
train (easily 33%). Acelas can't do this because they're so heavy. Thus,
higher use of friction braking.
* Lower curve speeds mean slowing down more after a straight run...
* And that means more, heavier use of the brakes.
* Unwillingness on the part of Amtrak and the US DOT to adopt a distributed
setup where every car is powered meant additional weight (locomotives at the
ends) and only 4 axles with regenerative braking, i.e. braking with the
motors.
The real issue is that Amtrak and the DOT insisted on a custom, untested
design based on a design concept that was out of step (180 degrees!) with
every other high speed train built in modern times. Had Amtrak simply
purchased a modified form of the X-2000 tested here in the early 90's, we
wouldn't have this fiasco today. Ironically, the X-2000 was cleared for
higher curve speeds than the Acela can achieve safely...
Sometimes reinventing the wheel isn't a good idea...
------------------------------
Date: Fri, 29 Apr 2005 14:10:04 +0100
From: Martin Ward <Martin.Ward@private>
Subject: Re: Amtrak's Acelas (Harrison, RISKS-23.85)
> It seems that old-fashioned mechanical engineering is not immune from the
> ills commonly ascribed to its software counterpart.
Of course not. Its just that when it happens in mechanical engineering, the
result is news stories, lawsuits and (usually) action taken to prevent
recurrence of the problems.
In software engineering, these problems are accepted as normal business
practices.
Martin.Ward@private http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/
------------------------------
Date: Wed, 4 May 2005 10:18:07 -0700
From: "Schatz, Derek P" <Derek.P.Schatz@private>
Subject: Re: Amtrak's Acelas (Harrison, RISKS-23.85)
Lack of replacement brake parts is interesting, but what's the
computer-related risk here?
["Risks to the Public in the Use of Computers and Related Systems." We
keep stressing the importance of systems in the large. Also, the
maintenance problem of letting essentially all of the trains fall apart
with no spare parts is symptomatic. PGN]
------------------------------
Date: Sat, 30 Apr 2005 20:46:43 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Train anomaly
I was on a "baby bullet" train last week that goes at the same speed as the
regular trains but only stops a few times over the stretch from SF to SJose,
and "the door is closing" recording kept playing between Palo Alto and
Mountain View while the train whizzed past two stations with the door in
front of me wide open. A conductor finally heard the repeated recording
after about 5 minutes and tried to close the door manually with no success.
I asked him if that happened often, and the answer was, with a shrug,
``Well, it does happen now and then.''
------------------------------
Date: Tue, 3 May 2005 17:27:44 -0700 (PDT)
From: "Craig S. Bell" <craig_s_bell@private>
Subject: Comair: Bound to Fail
Followup to the Comair incident:
*CIO Magazine* offers timeline. Stephanie Overby
http://www.cio.com/archive/050105/comair.html
The crash of a critical legacy system at Comair is a classic risk management
mistake that cost the airline $20 million and badly damaged its reputation.
------------------------------
Date: Thu, 28 Apr 2005 23:34:32 -0400
From: Monty Solomon <monty@private>
Subject: What Search Sites Know About You (Joanna Glasner)
[Source: Article by Joanna Glasner, Wired.Com, 5 Apr 2005]
For most people who spend a lot of time online, impulsively typing queries
into a search engine has become second nature.
Got a nasty infection in an embarrassing spot? Look up a treatment on
your favorite search site. Obsessing about an ex? Try Googling his or
her name. Chances are the queries will unearth some enlightening
information.
But while search engines are quite upfront about sharing their knowledge on
topics you enter in the query box, it's not so clear what they know about
you. As operators of the most popular search engines roll out more services
that require user registration, industry observers and privacy advocates say
it's become more feasible to associate a particular query with an
individual.
"You should think about what you put in that search box, because it may not
be as anonymous as you think," said Danny Sullivan, editor of
SearchEngineWatch.com.
It has long been standard practice, Sullivan noted, for search sites to
employ cookies, which track activity on a computer's internet browser. But
cookies don't identify a person by name. If two people access a site on the
same browser, the cookie wouldn't distinguish between them.
However, when people provide personal information to register for services
offered by search engine companies, such as free e-mail accounts, news
alerts or personalized homepages, they're no longer anonymous. ...
http://www.wired.com/news/privacy/0,1848,67062,00.html
------------------------------
Date: Tue, 19 Apr 2005 07:48:53 -0500
From: "Brent J. Nordquist" <brent@private>
Subject: Re: BofA agent gives out personal information (Dickson, RISKS-23.84)
Given that the agent is using a BofA computer application in the course of
providing service, doesn't this seem like a problem you could solve with an
expert system? Design the BofA app. to require the agent to quiz the caller
on the standard birthdate, mother's maiden name or security password, last 4
of SSN, etc. authenticators, and enter that data before *any* identifying
data is displayed back to the agent. If the agent can't see it, they can't
violate (what I hope are) BofA's policies not to disclose it to someone who
isn't authenticated.
Brent J. Nordquist <brent@private> N0BJN
Other contact information: http://www.nordist.net/contact.html
------------------------------
Date: Sat, 07 May 2005 15:27:22 -0500
From: Rick Smith <smith@private>
Subject: SecurID: bad compared to what? (McLellan, RISKS-23.86)
Lest people discount Vin McLellan's comments about SecurID by accusing him
of being a shill for RSA, let me offer an independent observation. I made a
detailed study of token technology a few years back while working for a
competing vendor (Secure Computing, owner of the SafeWord token line) and
while writing a book on authentication technology (aptly named
"Authentication").
First, the typical alternative to SecurID's clock-based key fobs are "event
based" key fobs, like SafeWord, in which the user must push a button to
retrieve the next one time password. The effective differences between the
two systems are minor, assuming they use comparable crypto. SafeWord tokens
are based on DES technology and 56-bit keys, while traditional SecurID
products used an internally-developed crypto algorithm with 64-bit keys.
The real difference today, however, is that the newer, high-end SecurID
products are based on AES with 128-bit keys. I don't know what key size is
used in the E*Trade token - none of the reports on this, including
Gartner's, have identified the token's key size.
Second, I agree with Vin's opinion regarding USB tokens. While I hope that
they're the wave of the future, they don't work with most of today's
authentication transactions, which tend to involve passwords embedded in web
pages. It's much easier to retrofit a web site to support a key fob's one
time password than it is to update both ends of the system to support
USB-based authentication.
Third, I agree with Vin that you can't fault E*Trade for providing a back
door so that users can still access their accounts after misplacing their
key fob. It may be lousy security, but it's what the user community needs.
Rick Smith, University of St. Thomas/Cryptosmith, Minnesota
------------------------------
Date: 29 Dec 2004 (LAST-MODIFIED)
From: RISKS-request@private
Subject: Abridged info on RISKS (comp.risks)
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Mailman can let you subscribe directly:
http://lists.csl.sri.com/mailman/listinfo/risks
Alternatively, to subscribe or unsubscribe via e-mail to mailman your
FROM: address, send a message to
risks-request@private
containing only the one-word text subscribe or unsubscribe. You may
also specify a different receiving address: subscribe address= ... .
You may short-circuit that process by sending directly to either
risks-subscribe@private or risks-unsubscribe@private
depending on which action is to be taken.
Subscription and unsubscription requests require that you reply to a
confirmation message sent to the subscribing mail address. Instructions
are included in the confirmation message. Each issue of RISKS that you
receive contains information on how to post, unsubscribe, etc.
INFO [for unabridged version of RISKS information]
.UK users should contact <Lindsay.Marshall@private>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
<http://www.CSL.sri.com/risksinfo.html>
The full info file may appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risks@private with meaningful SUBJECT: line.
*** NOTE: Including the string "notsp" at the beginning or end of the subject
*** line will be very helpful in separating real contributions from spam.
*** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
<http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
Lindsay has also added to the Newcastle catless site a palmtop version
of the most recent RISKS issue and a WAP version that works for many but
not all telephones: http://catless.ncl.ac.uk/w/r
<http://the.wiretapped.net/security/info/textfiles/risks-digest/> .
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
<http://www.csl.sri.com/illustrative.html> for browsing,
<http://www.csl.sri.com/illustrative.pdf> or .ps for printing
------------------------------
End of RISKS-FORUM Digest 23.87
************************
This archive was generated by hypermail 2.1.3 : Tue May 17 2005 - 15:46:00 PDT