[RISKS] Risks Digest 25.47

From: RISKS List Owner <risko_at_private>
Date: Mon, 8 Dec 2008 16:03:15 PST
RISKS-LIST: Risks-Forum Digest  Monday 8 December 2008  Volume 25 : Issue 47

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/25.47.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
Chatsworth Wreck May be a Safety Failure (Chuck Weinstock)
Caltrain computer outage causes extensive schedule disruption (PGN)
Water pumps failed in Yorba Linda fire (Jim Geissman)
Dangerous Precedence Set - Federal Criminal Charges for Violation
  of Commercial Online ToS? (Stephen via Dave Farber)
A cyber-attack alarms the Pentagon (Jerry and Virgil Gligor via David Farber)
A secure version of reality (Andy Piper)
The recovery features of botnets (Peter Houppermans)
Fingerprints in South Africa (Heinz M. Kabutz)
Facebook and tracking people (David Magda)
How *not* to improve data quality (Richard O'Keefe)
Israeli Labor primaries postponed: electronic systems fail (Amos Shapir)
Re: Risks of assuming constant hours in a day (Curt Sampson)
Workshop on GENI and Security: Call for Participation (Matt Bishop)
MiniMetricon call for participation (Fred Cohen)
REVIEW: "The History of Information Security", de Leeuw/Bergstra (Rob Slade)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Mon, 8 Dec 2008 17:59:40 -0500
From: Chuck Weinstock <weinstock_at_private>
Subject: Chatsworth Wreck May be a Safety Failure

Off the Newswire at www.trains.com
[Three different spellings of the conductor's name unified.  PGN]

According to the *Los Angeles Times*, conductor Robert Heldenbrand, the lone
surviving crew member of the Sept. 12 Metrolink wreck that killed 25 people,
has told investigators the signal he passed prior to the crash was green.

Trackside signals are programmed to detect the presence of a train or other
equipment within a block and turn red, telling approaching movements to stop
prior to entering. If the signal truly displayed a green aspect when in fact
a Union Pacific freight occupied the block, it would mean a signal
failure. Such failures do occasionally occur, and are known as false clear
indications.

Heldenbrand's account backs up that of three witnesses on the platform of the
Chatsworth depot, who also say the light was green at the time of the
crash. Still, the National Transportation Safety Board is standing by its
account of the crash, saying the train's engineer, Robert Sanchez, passed a
red signal before slamming head-on into the UP freight. It has, however,
questioned how brightly lit the signal was.

Investigators had earlier asked why Sanchez hadn't called out the signal's
indication on the radio, which Heldenbrand would have been required to repeat
back if the signal wasn't green. But a green signal would have meant the two
would not be required to call the signal.

------------------------------

Date: Fri, 5 Dec 2008 14:15:50 PST
From: "Peter G. Neumann" <neumann_at_private>
Subject: Caltrain computer outage causes extensive schedule disruption

On 4 Dec 2008, Caltrain (the commuter line between San Francisco and San
Jose/Gilroy) experienced significant delays due to the computer system that
controls the signal system.  The problem began at the end of the morning
rush hour, and was still ongoing during the evening rush hour.  Trains had
to be controlled manually, including bullet trains overtaking local trains.
Delays were further complicated by construction at Palo Alto's California
Avenue station -- which requires only one train at a time in the station
(even though the long-standing problem of having northbound passengers
cross-over the southbound tracks has finally been resolved in the past week,
with the completion of a northbound platform).

------------------------------

Date: Thu, 27 Nov 2008 13:31:15 -0800
From: Jim Geissman <jimgeissman_at_private>
Subject: Water pumps failed in Yorba Linda fire

The equipment failures caused fire hydrants to run dry in the highest
neighborhood in the city and may explain why firefighters were unable to
protect homes.

Water officials said [on 25 Nov 2008] that pumps designed to push water to
the upper reaches of a hillside Yorba Linda neighborhood failed during a
15 Nov firestorm [so that] firefighters were forced to abandon the area and
let homes burn....

Water officials believe the electric pumps shut off because the fire had
burned through their electrical communication systems. The backup, they
said, failed because of the heat.

Officials said that the reservoir has been on the to-do list since at least
2001, when developer Shapell Industries first submitted plans to build homes
around Hidden Hills. The agency has recognized the need for more reservoirs
in the eastern side of Yorba Linda for 30 years but depends on developers'
building plans to determine where to locate the infrastructure.

[Interesting that residential development occurs before development of the
infrastructure required to support it.]

http://www.latimes.com/news/local/orange/la-me-water26-2008nov26,0,3919612.story

------------------------------

Date: November 27, 2008 12:24:49 PM EST
From: Stephen <sdpoe_at_private>
Subject: Dangerous Precedence Set - Federal Criminal Charges for
   Violation of Commercial Online ToS?

  [From Dave Farber's IP list.  PGN]

A very dangerous legal precedence was set today.

In the case of the 13-year-old who committed suicide supposedly over a
MySpace hoax, the mother involved was found guilty on three federal counts.
What of? Not of a serious criminal act.

She was found guilty on three criminal counts (misdemeanors), in a federal
court, of violating the Terms of Service agreement. So now you can be
accused, tried, and found guilty of a federal criminal offense not for
breaking a Federal or even a state law, but rather for violating the Terms
of Service of a click- through agreement of a commercial site you go to on
the Web.

"Prosecutors alleged that Drew and her employee violated MySpace's "terms of
service," which prohibit using fraudulent registration information,
obtaining personal information about juvenile members, and using the service
to harass, abuse or harm others...

The verdict underscores the complexities of the case. Some legal experts and
civil liberties groups said a felony conviction would mean that millions of
people who violate the terms of service of the Web sites they visit could
become criminally liable. Experts also said that if violating such terms is
a crime, then the sites that write the agreements essentially could function
as lawmakers or prosecutors. " - from *The Washington Post*
http://www.washingtonpost.com/wp-dyn/content/article/2008/11/26/AR2008112600629.html?hpid=topnews

"The case was prosecuted under the federal Computer Fraud and Abuse Act,
originally intended to prosecute hackers. Did Lori Drew effectively hack
MySpace for nefarious purposes? Some people think it's quite a stretch.

``This was a very aggressive, if not misguided, theory,'' said Matt Levine,
a New York-based defense attorney and former federal prosecutor.
``Unfortunately, there's not a law that covers every bad thing in the
world. It's a bad idea to use laws that have very different purpose.''  from
ZDNet @ http://government.zdnet.com/?p=4207

Archives: https://www.listbox.com/member/archive/247/=now

------------------------------

Date: Sun, 7 Dec 2008 09:34:29 -0500
From: David Farber <dave_at_private>
Subject: [IP] Re: A cyber-attack alarms the Pentagon

>From: No-Name <labmanager_at_private>

I've heard a rumor about the way the WORM made it's way into the Pentagon
computer network. If true, it was a simple but brilliantly effective method.
Someone infected thumb drives with the WORM then dropped them around the
Pentagon parking lot. The employees, picked them up, took them into their
offices and plugged them into their office computers to determine the owner
of the drive.  Jerry

Date: December 4, 2008 8:36:03 PM EST
>From: Virgil Gligor <GLIGOR1_at_private>
Subject: For IP: A cyber-attack alarms the Pentagon

Cyberwar: The worm turns, *The Economist*, 4 Dec 2008

A cyber-attack alarms the Pentagon

Battlefield bandwidth is low at best, making networks sticky and e- mails
tricky. American soldiers often rely on memory sticks to cart vital data
between computers. Off-duty, they use the same devices to move around music
and photos. The dangers of that have just become apparent with the news that
the Pentagon has banned the use of all portable memory devices because of
the spread of a bit of malicious software called agent.btz.

This is a "worm", meaning that it replicates itself. If you have it on, say,
the memory card of a digital camera it will infect any computer to which you
upload photos. It will then infect any other portable memory plugged into
that computer (the cyber-equivalent, one might say, of a sexually
transmitted disease). On any computer hooked up to the Internet, this
variant tries to download more nasty stuff: in this case two programs that
access the hard-drive. Was it a humdrum crime of trying to steal banking
details? Or something more serious?  The trail has gone cold.

In any case, the malicious software (malware in the jargon) penetrated at
least one classified computer network. The problem was severe enough for
Admiral Michael Mullen, the chairman of the joint chiefs of staff, to brief
George Bush on it. Officials are saying little more than that.

Kimberly Zenz, an expert on cyberwarfare at VeriSign iDefense, a computer
security company that is investigating the attack, notes that it is not
clear that agent.btz was designed specifically to target military networks,
or indeed that it comes from either Russia or China (two countries known to
have state-sponsored cyberwarfare programmes that regularly target American
government computer networks).

Indeed, she says, by the standards of cyberwarfare, agent.btz is pretty
basic; it is a variant of a well-known bit of malware called the SillyFDC
worm, which has been around for at least three years. By contrast, a
government commission warned Congress last month that "since China's current
cyber operations capability is so advanced, it can engage in forms of
cyberwarfare so sophisticated that the United States may be unable to
counteract or even detect the efforts."

The most remarkable feature of the episode may not be the breach of
security, but the cost of dealing with it. In the civilian world, at least
one bank has dealt with agent.btz by blocking all its computers' USB ports
with glue. Every bit of portable memory in the sprawling American military
establishment now needs to be scrubbed clean before it can be used again. In
the meantime, soldiers will find it hard or outright impossible to share,
say, vital digital maps, let alone synch their iPods or exchange pictures
with their families.

------------------------------

Date: Wed, 03 Dec 2008 12:46:39 +0000
From: Andy Piper <andy_at_private>
Subject: A secure version of reality

A variation on a common RISKS theme, but one I have come across increasingly
often. More and more websites are enforcing "secure" passwords and, it
seems, security questions. For instance two websites I used recently, which
front real services I use (credit card and pet insurance) enforce passwords
that *must* contain at least one upper-case character, one digit and not
bear any resemblance to your user id. So far, so secure. Unfortunately they
also want an answer to a security question as a reminder. Mother's maiden
name is usually the one I pick, but my mother has a double barreled maiden
name and this time I get:

"Answer to security question is invalid, please correct"

Sorry? So the self-evidently correct answer is not, in fact, "correct"
according to the website mafia. Ok, move along to the next one, place of
birth. My place of birth is tripled barreled (one of those quaint English
towns where the name is related to the river that runs through it).

"Answer to place of birth question is invalid, please correct"

Gah! I'm assuming that what the site doesn't like is the hyphen's in both
names (or perhaps that they have two names, although for place names that
seems entirely dubious). The problem is that I am beginning to have to enter
information that is not only wrong, but which I have no hope of remembering
correctly 6 months later. Increasingly the same is true for passwords. I use
systems where the above rules are enforced *and* password aging takes place
*and* the use of an old password is prohibited. So now I have to remember
not only information that is incorrect but also a system for encoding
passwords in my brain for these sites. Increasingly that system fails and I
need to recover the password, but the recovery system is also failing me
now!

Where will this madness end?

------------------------------

Date: Fri, 28 Nov 2008 11:36:17 +0100
From: Peter Houppermans <peter_at_private>
Subject: The recovery features of botnets

Interesting read, was a submission by Thomas Lakofski to a mailing list.

Short summary: botnet code contains a semi-random domain name generator
which it will contact for new instructions.  This makes it impossible to
shut down the controlling domains as the code will simply switch to a new
name for instructions - which differs every single day.  Let me put it
another way: a shutdown is virtually impossible without catching the actual
operator.

http://blog.fireeye.com/research/2008/11/technical-details-of-srizbis-domain-generation-algorithm.html

------------------------------

Date: Fri, 05 Dec 2008 09:57:33 +0200
From: "Dr Heinz M. Kabutz" <heinz_at_private>
Subject: Fingerprints in South Africa

In South Africa, whenever you apply for an ID book, passport or driver's
license, your fingerprints are taken.  In the past, these were used to
prevent identify theft.  Of course, even that is flawed.  I know someone
whose skin flakes off his fingertips when he is under stress.  He had a lot
of trouble renewing his passport, because his fingerprints did not match
what was on file.

It would be fair to say that in South Africa, the Department of Home Affairs
has a database of almost all the fingerprints in the country.  You cannot do
anything without an ID book.

Now someone has had the "brilliant" idea to open up this database to the
police service, who are notorious for their low conviction rate.  It
horrifies me to think how many false positives there will be!  Imagine being
dragged out of bed at 3am by police special forces for murder and rape,
because your fingerprint biometrically matched a serial killer's.  The level
of corruption at the South African Police Service is well known, so this is
probably one of the worst news I have heard in years.

I'm sure fellow RISKS readers will agree ...

http://www.iol.co.za/index.php?art_id=vn20081205053045716C521775

Dr Heinz M. Kabutz (PhD CompSci), Sun Java Champion,
Author of "The Java(tm) Specialists' Newsletter" http://www.javaspecialists.eu

------------------------------

Date: Thu, 27 Nov 2008 16:00:45 -0500 (EST)
From: "David Magda" <dmagda_at_private>
Subject: Facebook and tracking people

Nowadays, once you have someone's name, it can be quite easy to track them
down:

> Leary was left with an unpaid bill for about $520, and little hope of
> recovering his money.
>
> "It was then I remembered that when the group arrived, one of them had
> asked about one of our waitresses who was not working that night," Leary
> said yesterday.
>
> The waitress gave him a name and then he thought of Facebook.
>
> "I searched the name and there he was, large as life," he said. "And he
> was pictured with his girlfriend--the only girl who had been in the
> group.
>
> "The site also gave me his place of employment, which was handy."

http://tinyurl.com/68rfob
http://www.news.com.au/technology/story/0,25642,24714093-5014239,00.html

It turns out the individual in question worked at another restaurant, from
which he's now been fired.

------------------------------

Date: Thu, 4 Dec 2008 16:52:21 +1300
From: "Richard O'Keefe" <ok_at_private>
Subject: How *not* to improve data quality

A few days ago my wife and I bought a 2nd-hand station wagon to replace a
vehicle that needed repairs for which parts are now hard to obtain.  Part of
the process is to change the registration for the new vehicle.  As we were
dutifully filling in all the details on the form, we came to a box for our
phone number, and being unable to think of any reason why we wouldn't want
the licensing authority to be able to reach us, were about to fill it in.
At that point the dealer stopped us and advised us not to.  The reason?  If
your phone number changes (e.g., you drop your mobile in a toilet and have
to get a new one -- happened to me once), you are legally obliged to tell
the LTSA, but only if you told them your number in the first place.  And
most people never remember to do this.

So a rule "You must tell us if your phone number changes" that
was presumably intended to ensure that the data would be more
accurate has had the effect of making the data mostly unavailable.

------------------------------

Date: Mon, 8 Dec 2008 17:12:14 +0200
From: Amos Shapir <amos083_at_private>
Subject: Israeli Labor primaries postponed: electronic systems fail

This is primary elections season in Israel, when political parties vote for
their nominees for the upcoming general elections in February.  The Labor
party tried a fully electronic voting scheme which failed miserably, forcing
them to delay the election by several days and go back to the old fashioned
paper ballot method.

Full story at: http://www.ynetnews.com/articles/0,7340,L-3631836,00.html

Despite that, today the Likud right-wing party also held its primary
elections electronically, and did face some trouble, though not as fatal.
Full story at: http://www.ynetnews.com/articles/0,7340,L-3635022,00.html

Unfortunately, there aren't many technical details about the systems
involved.

------------------------------

Date: Sat, 6 Dec 2008 16:49:22 +0900
From: Curt Sampson <cjs_at_private>
Subject: Re: Risks of assuming constant hours in a day (Toby, RISKS-25.45)

> I made the (altogether reasonable, I thought) assumption that if you take a
> timestamp and add 24 hours, it becomes the same time on the following day.
> Well, not always.  Such as when clocks change for Daylight Savings Time.

And that's only the start. As we're all well aware, you can't even add sixty
seconds to a time and assume it's then in the next minute.

We normally don't think much about this, but lately I've been doing a lot of
programming in Haskell, and the folks who built the libraries being much too
smart for their own (or, anyway, my) good, make this clear, not to mention
push it a bit in your face:

  http://haskell.org/ghc/docs/latest/html/libraries/time/Data-Time-Clock.html

Actually, though, as well as being more than a little pedantic, this is I
think a fairly brilliant example of good risk management: by forcing
programmers to stop and make a choice between a DiffTime (which includes
leap seconds) and a NominalDiffTime (which more or less pretends they don't
exist), it also forces them to think for a moment about what exactly they're
doing.

So kudos to Ashley Yakeley, the rather smart author of this library.

Curt Sampson <cjs_at_starling-software.com> +81 90 7737 2974  Functional
programming in all senses of the word: http://www.starling-software.com

------------------------------

Date: Thu, 4 Dec 2008 13:36:48 -0800
From: Matt Bishop <bishop_at_private>
Subject: Workshop on GENI and Security: Call for Participation

                       Workshop on GENI and Security
                             January 22-23, 2009
                            Davis, California, USA

The Global Environment for Network Innovations (GENI) is a suite of network
research infrastructures now in its design and prototyping phase. It is
sponsored by the National Science Foundation to support experimental
research in network science and engineering. The goal of this workshop is to
engage the security community in GENI's design and prototyping, to ensure
that security issues are properly considered during its development.

First, what classes of security experiments should GENI support? What
capabilities will GENI require to allow the conduct of these experiments?
Second, how can GENI itself be adequately secured and protected from attack?
What forms of authentication, authorization, and accountability would be
most appropriate?

As the GENI Project Office expects to issue its 2nd solicitation for GENI
analysis and prototyping subcontracts in the middle of December, with
proposals due in mid-February, it is anticipated that topics discussed at
the workshop will lead to proposals from the security community.

Participation. We invite short (1 paragraph preferably; at most 1 page)
statements of ideas addressing these two issues. Submit your statement to
geni-workshop_at_private by December 18. Please use either PDF or text.

For more information: http://seclab.cs.ucdavis.edu/meetings/genisec

Matt Bishop, UC Davis

------------------------------

Date: Wed, 3 Dec 2008 16:21:03 -0800
From: Fred Cohen <fc_at_private>
Subject: MiniMetricon call for participation

For those interested in security metrics, here is the link to the Call for
Participation for MiniMetricon 3.5.  [20 April 2009, Moscone Center SF]

http://www.securitymetrics.org/content/Wiki.jsp?page=Metricon3.5

Fred Cohen & Associates 572 Leona Drive Livermore, CA 94550 1-925-454-0171
http://all.net/

  [Frequent RISKS contributors Fred and Jeremy Epstein are on the PC.  PGN]

------------------------------

Date: Thu, 4 Dec 2008 11:03:07 -0800
From: Rob Slade <rMslade_at_private>
Subject: REVIEW: "The History of Information Security", de Leeuw/Bergstra

BKHISCCH.RVW   20081020

"The History of Information Security", Karl de Leeuw/Jan Bergstra,
2007, 978-0-444-51608-4
%E   Karl de Leeuw karl.de.leeuw_at_private
%E   Jan Bergstra
%C   256 Banbury Road, Oxford, OX2 7DH
%D   2007
%G   978-0-444-51608-4
%I   Elsevier Advanced Technology
%O   +44 865 512242 Fax: +44 865 310981 books.elsevier.com
%O  http://www.amazon.com/exec/obidos/ASIN/0444516085/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0444516085/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0444516085/robsladesin03-20
%O   Audience i Tech 1 Writing 2 (see revfaq.htm for explanation)
%P   887 p.
%T   "The History of Information Security: A Comprehensive Handbook"

Chapter one, which stands in for an introduction to the papers in this
volume, already notes that the title is inaccurate.  The editor admits
that this work is not a history, as such, but an overview from the
perspective of different disciplines related to information security,
taking a historical approach in examining the socio-political shaping
of infosec.  The authors ask whether technology influenced public
policy and politics, and look for information security strategies (or
the lack thereof) in politics.  I found the selection of references
disquieting, noting that the editor responsible for the choice of
papers complained that there was no historical material addressing
industrial espionage, administrative practices, disruption of
communications with criminal intent, or other areas.  No mention is
made, in the references, to the works of Stamp (cf. BKINSCPP.RVW),
Winkler (cf. BKCRPESP.RVW, BKSPAMUS.RVW), or Denning (cf.
BKDENING.RVW) to name just a few.

I can agree with the emphasis on social aspects of security: security
is, and always has been, a people problem.  Information security,
however, necessarily involves technology, and the authors of most of
the papers included in this collection have concentrated so much on
history (mostly in the form of dates and political rivalries) that the
questions of influence of technology on politics, or politics on
technology, can't really be analyzed.  Additionally, enormous topical
areas relevant to information security (such as risk management,
intrusion detection, cryptographic infrastructure (PKI), physical
security, computer architecture, application development, and malware)
are notable by their absence.

Part one addresses intellectual property.  Essay subjects include
various forms of censorship and self-censorship (with no mention of
the "full disclosure" debate), the German patent system, copyright,
and the application of copyright and patent to software.

Part two looks at items related to identity management, with a highly
abstract and impractical philosophy of identity, notes on document
security, a review of identity cards, and a recent history of
biometrics.

Although entitled "Communications Security," part three is about
cryptography.  The papers on Renaissance (1400-1650) and Dutch (up to
1800) cryptography, British postal interception up until the 1700s,
the KGB crypto office, and the NSA (US National Security Agency) are
of primarily political interest.  The articles on rotor cryptography,
Colossus, and the Hagelin machines have points of curiosity, but are
still very thin on technical details.  A final essay attempts a very
terse overview of modern cryptographic concepts.

Computer security is in part four.  Early US military evaluation
standards, some of the basic formal information security models, an
academic look at application security and auditing, a rough division
of recent information technology into decade "periods," an equally
unpolished history of Internet security, and a scattered review of
computer crime make up this section.

For some reason questions of privacy and regulations governing the
export of cryptography are seen to fit together in part five.  Three
papers present US cryptographic export restrictions, a random and not
completely successful attempt to define privacy, and various US
undertakings at regulating the use of encryption.

Part five can't have been lumped together simply due to a lack of
articles, since part six is a single piece providing a limited and
incomplete overview of information warfare.

As a book this volume is disappointing.  It is not "a history," merely
a collection of papers, with little structure or linkage.  The topics
relate to security, but a work on infosec should have more technical
content and understanding.  It is certainly not comprehensive.  And,
at several kilograms in weight, it bears little resemblance to a
handbook.

That said, a number of the essays do provide interesting historical
points, anecdotes, and references.  Therefore, those with the stamina
to work through the material may be rewarded with historical nuggets,
and pointers to further sources of information.

copyright Robert M. Slade, 2008   BKHISCCH.RVW   20081020
rslade_at_private     slade_at_private     rslade_at_private
victoria.tc.ca/techrev/rms.htm blogs.securiteam.com/index.php/archives/author/p1/

------------------------------

Date: Thu, 29 May 2008 07:53:46 -0900
From: RISKS-request_at_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_at_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_at_private or risks-unsubscribe_at_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_at_private>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks_at_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 for current volume
     or ftp://ftp.sri.com/VL/risks for previous VoLume
 <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
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:
    <http://www.acm.org/joinacm1>

------------------------------

End of RISKS-FORUM Digest 25.47
************************
Received on Mon Dec 08 2008 - 16:03:15 PST

This archive was generated by hypermail 2.2.0 : Mon Dec 08 2008 - 16:24:27 PST