[RISKS] Risks Digest 25.52

From: RISKS List Owner <risko_at_private>
Date: Thu, 22 Jan 2009 11:03:17 PST
RISKS-LIST: Risks-Forum Digest  Thursday 22 January 2009  Volume 25 : Issue 52

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

  Contents:
German Train System Computers Down for Hours (Debora Weber-Wulff)
Yet Another Reason Not to use Windows for Medical Devices (Jeremy Epstein)
Tricky Windows Worm Wallops Millions (Brian Krebs via Monty Solomon)
Electronic Medical Records, Google, and Microsoft (Lauren Weinstein)
Cursive, foiled again: What will become of handwriting? (David Mehegan via
  Monty Solomon)
The perils of trusting the UK government to get software right (Bernard Peek)
New Web Analytics Service Spies on Web Browsing Activity Without Permission
  (Lauren Weinstein)
Re: "Spy pens" and the future of private speech (Henry Baker, Jerry Leichter)
Re: Tony Hoare: "Null References: The Billion Dollar Mistake" (Henry Baker)
Risks of Avis insufficient customer data checking (Chris Warwick)
Abridged info on RISKS (comp.risks)

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

Date: Sat, 17 Jan 2009 13:05:55 +0100
From: Debora Weber-Wulff <D.Weber-Wulff_at_fhtw-berlin.de>
Subject: German Train System Computers Down for Hours

Another Peter Neumann (!!) reports in the *Berliner Zeitung* 17 Jan 2009:

On January 14, 2009 at 14.03 the plug got pulled on the German national
train system's computers - all of them.  No ticket machines would work,
either the self-service or the counter machines; the Internet pages returned
404s; the boards in the train stations telling you which track to take died;
and apparently even some of the operations computers just shut off.

There was a single point of failure - the "uninterruptible" power system
(UPS).

The computer center of the Deutsche Bahn in Mahlsdorf (Berlin) was was
upgrading the UPS. Suddenly there was no electricity flowing through the
mains. None. And the entire system fell like a house of cards.

Oh, they had a backup system set up [for lots of money, we suppose, I've
seen the computer centers, they look like prisons, windowless monstrosities
with high fences topped by razorwire -dww] just down the road in
Biesdorf. The speaker won't say exactly what happened, but the cut-over to
the backup system did not work.

It took hours to get the system back up and running - apparently every
system assumes that every other system is already up and running, and
turning them all on at the same time is quite a drain on electricity. The
speaker will not go into any more detail on this topic, except to say that
the specific nature of the error meant that each system had to be restarted
by itself.

Of course, the usual speculation made the rounds - hackers, terrorists,
viruses.  But again - never make up complicated theories for what can be
explained by simple incompetence.

The speaker: We have found the weak point and can guarantee that something
like this will never happen again.

comp.risks has a long memory....

Prof.Dr. Debora Weber-Wulff, FHTW Berlin, FB 4, Treskowallee 8, 10313 Berlin
http://www.f4.fhtw-berlin.de/people/weberwu/   +49-30-5019-2320

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

Date: Wed, 21 Jan 2009 09:07:31 -0500
From: Jeremy Epstein <jeremy.j.epstein_at_private>
Subject: Yet Another Reason Not to use Windows for Medical Devices

*The Register* reports that "staff at hospitals across Sheffield are
battling a major computer worm outbreak after managers turned off Windows
security updates for all 8,000 PCs on the vital network" with "more than 800
computers ...  infected with self-replicating Conficker code".  And how did
this happen?  The worm takes advantage of a known problem that is resolved
through a Windows patch that wasn't installed because "the decision to
disable automatic security updates was taken during Christmas week after PCs
in an operating theatre [were] rebooted mid-surgery.  Conficker was detected"
on 29 Dec 2008.
  http://www.theregister.co.uk/2009/01/20/sheffield_conficker/

Or in short:
- Life-critical systems rely on software that has a long history of
  vulnerabilities.
- To avoid critical interruptions, automatic fix installation is disabled,
  with no backup process for installing them at non-critical times.
- These systems are interconnected (including to the Internet) for
  whatever reason.
- There are (apparently) no other protection mechanisms beyond installing
  fixes.
- Malware leaks in to the network and spreads.
- The interaction of the above leads to really bad results.

And where is the surprise?  Even Microsoft's license agreement notes that
you shouldn't use their software for life-critical systems (among other
things).  Perhaps that's just a CYA thing, but one would hope that there's
consideration of the risks before ignoring those terms.

  [Also noted by Toby Douglass.
  Incidentally, Phil Porras (whose Cyber-Threat Analytics project
    <http://www.cyber-ta.org> has been tracking conficker) noted to me
  that the relevant RPC exploit was patched and distributed by MS's security
  update service on 23 Oct 2008.  PGN]

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

Date: Tue, 20 Jan 2009 22:59:08 -0500
From: Monty Solomon <monty_at_private>
Subject: Tricky Windows Worm Wallops Millions (Brian Krebs)

Brian Krebs, *The Washington Post*, 16 Jan 2009

A sneaky computer worm that uses a virtual Swiss army knife of attack
techniques has infected millions of Microsoft Windows PCs, and appears to be
spreading at a fairly rapid pace, security experts warn.

Also, while infected PCs could be used for a variety of criminal purposes --
from relaying spam to hosting scam Web sites -- there are signs that this
whole mess may be an attempt to further spread so-called "scareware," which
uses fake security alerts to frighten consumers into purchasing bogus
computer security software.

The worm, called "Downandup" and "Conficker" by different anti-virus
companies, attacks a security hole in a networking component found in most
Windows systems. According to estimates from Finnish anti-virus maker
F-Secure Corp., the worm has infected between 2.4 million and 8.9 million
computers during the last four days alone.

If accurate, those are fairly staggering numbers for a worm that first
surfaced in late November. Microsoft issued an emergency patch to fix the
flaw back in October, but many systems likely remain dangerously exposed.

One reason for this is because businesses will generally test patches before
deploying them on internal networks to ensure the updates don't break custom
software applications. In the meantime, an infected laptop plugged into a
vulnerable corporate network can quickly spread the contagion to all
unpatched systems inside that network.

But the worm also has methods for infecting systems that are already patched
against the Windows vulnerability. According to an analysis last week by
Symantec, the latest versions of Downadup copy themselves to all removable
or mapped drives on the host computer or network. This means that if an
infected system has a USB stick inserted into it, that USB stick will carry
the infection over to the next Windows machine that reads it. That's an old
trick, but apparently one that is apparently still very effective. ...

http://voices.washingtonpost.com/securityfix/2009/01/tricky_windows_worm_wallops_mi.html

  [Conficker is apparently even more widespread than reported above.  PGN]

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

Date: Mon, 19 Jan 2009 12:25:51 -0800 (PST)
From: Lauren Weinstein <lauren_at_private>
Subject: Electronic Medical Records, Google, and Microsoft

Lauren Weinstein's Blog Update, 19 Jan 2009
  http://lauren.vortex.com/archive/000497.html

Greetings.  It's well known that a significant portion of the Obama
administration's stimulus plans will likely be a major thrust toward
electronic medical records.  These are touted as reducing errors, creating
jobs, and saving money -- though it's arguable if medical consumers are the
ones who actually pocket the savings in most cases.

But there are serious concerns about these systems as well -- reminding us
that exactly the same sorts of problems that tend to plague our other
computer-based ecosystems could now start hitting people's medical records
in pretty much the same ways.

*The New York Times* (19 Jan 2008) had an excellent story about privacy and
security issues associated with electronic medical records -- and the
medical industry heavyweights who are trying to water down related
provisions in associated and upcoming legislation.
http://www.nytimes.com/2009/01/18/us/politics/18health.html

A few days ago, AP reported on a range of potentially serious medical errors
*created* by the Veterans Administration's new electronic medical records
system.
http://www.tampabay.com/news/military/veterans/article967778.ece

Both Google and Microsoft have unveiled electronic medical records systems
for users, and are actively seeking partnerships with major medical
treatment organizations.  While they both promise comprehensive privacy and
control by users -- in some ways that exceed those mandated by HIPAA privacy
requirements, these systems are explicitly not actually covered by HIPAA --
though my hunch is that this status is likely to change in the near future.

The key concern with such non-HIPAA medical records systems isn't their
privacy and security at the moment -- which as I noted appear to be good at
present.  Rather, an important aspect of HIPAA is that it represents a set
of rules that cannot be arbitrarily changed by the organizations involved.
Consumers need to know that the "rules of the game" when it comes to their
medical records will not be subject to unilateral alterations on the basis
of business conditions or management changes, outside the realm of
legislated national rules.

My belief is that electronic medical records in general, and the services
like those from Google and MS in particular, have the potential for
significant benefits.  I also believe that a massive rush into any of these
environments could end up creating a whole new range of problems that could
waste money, risk privacy, and in the worst case even cost lives.

I trust that Congress will move with deliberate speed, but not be pressured,
in the area of electronic medical health records implementation, and that
they will put patients' rights to privacy, accuracy, security, control, and
choice at the top of agenda.  A stampede to electronic medical records
without due consideration and care would be a very dangerous prescription
indeed.

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

Date: Tue, 20 Jan 2009 22:33:03 -0500
From: Monty Solomon <monty_at_private>
Subject: Cursive, foiled again: What will become of handwriting? (David Mehegan)

[Source: David Mehegan, *The Boston Globe*, 19 Jan 2009]

Cursive, foiled again:
We e-mail, we text, we Twitter - what will become of handwriting?

"The moving finger writes," says the famous Rubaiyat of Omar Khayyam, "and,
having writ, moves on." Nowadays, the finger more likely is hammering away
on a computer keyboard, texting on a cellphone, or Twittering on a
BlackBerry.

If you predate the computer age, you might remember a school subject called
"penmanship," which trained your cursive handwriting, usually by the Palmer
Method. The penmanship teacher would come by once a week to rate your work,
and if your handwriting was bad, you'd hear about it. It's still taught, to
be sure, but it's no longer emphasized. "There's been a decline in attention
to all kinds of basic skills," said Louise Spear-Swerling, coordinator of
the graduate program in learning disabilities at Southern Connecticut State
University. "With handwriting, people think it's just not that important."

Some people are concerned, though, and one is Kitty Burns Florey, whose book
"Script and Scribble: The Rise and Fall of Handwriting" comes out Friday -
John Hancock's birthday and National Handwriting Day. Florey, author of nine
novels and a book about sentence diagramming, became interested in the
subject after reading that computer keyboarding has displaced handwriting in
schools. ...

http://www.boston.com/ae/books/articles/2009/01/19/cursive_foiled_again/

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

Date: Tue, 6 Jan 2009 21:35:16 +0000
From: Bernard Peek <bap_at_private>
Subject: The perils of trusting the UK government to get software right

In the UK there is a Government Gateway web site used to access a number of
government services. One of the better hidden services is that it is
possible to register a claim for unemployment benefit. Like many of the UK's
IT staff I now have need of the service.

Everything starts off reasonably well. Access to the site requires an ID
that is delivered to users by post, together with a password users can
choose for themselves. So far so good.

Registering a claim for "Jobseekers' Allowance" takes the user through a
questionnaire that parallels the one that most people deal with via a
telephone interview. At the end of the process the user is given a final
chance to review the data and finally confirm that they wish to submit a
claim.

At this point the user is presented with a pop-up confirmation that the
claim has been submitted. The interesting thing is that the claim has not
been submitted at that point and still has a status of "not yet submitted."
The next stage should presumably be that the claim is actioned, but this
part of the code silently fails. The claim will stay in limbo. Unless the
user has some reason to return to the system and log in again they have no
reason to suspect that their data has been dropped on the floor. If they do
log in again they will see the "not yet submitted" status and can complete
the submission again, getting a new pop-up saying that the claim has been
submitted. Which submission will again be silently dropped on the floor and
the "not yet submitted" flag will remain unchanged.

I'm sure that there must be a lesson to be learned from this, probably
several. I hope that one of the lessons which will be learned is that when
you FUBAR a user's data, don't do it to a RISKS subscriber.

Bernard Peek, London, UK. DBA, Manager, Trainer & Author.

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

Date: Thu, 22 Jan 2009 09:14:48 -0800
From: Lauren Weinstein <lauren_at_private>
Subject: New Web Analytics Service Spies on Web Browsing Activity Without Permission

  New Web Analytics Service Spies on Web Browsing Activity Without Permission
                http://lauren.vortex.com/archive/000498.html

Greetings.  In the business of "Web Analytics" -- collecting, analyzing, and
reporting of Web usage data -- various firms are continuously pushing the
envelope.

Such data is in many ways the bread and butter of the free Web services that
we've come to expect, since it is in key respects a crucial element of the
ad-supported Web services ecosystem.  However, the temptation to push
analytics technology too far always exists.

A firm that appears to have succumbed to that temptation came to my
attention today.  "Tealium Social Media," a service of Tealium
(http://www.tealium.com) in San Diego, California, is a commercial analytics
service that uses JavaScript tricks to inspect -- without the knowledge or
permission of Web users -- specific URLs in their current browser histories.

The service attempts to provide a finer grain of usage information than is
typically available through analytical techniques, by querying users'
browsers for the presence of particular URLs.  While this does not permit
the reading out of complete browser URL histories, it does permit the
service to ask the potentially highly privacy-invasive question: "Has this
user been to a particular URL recently?"

Obviously, by sending a variety of such queries (all of which are
essentially invisible to the user), a fascinating portrait of users'
activities could be generated.  Visited this CNN story?  This
government Web page?  This porn image?  This medical information page?
Well, you get the idea.

While the JavaScript functionalities that enable this intrusion have
been known for quite some time in hacking and other technical circles,
this appears to possibly be among the first commercial applications of
this technique.

I had a cordial chat early this afternoon with Olivier Silvestre, one
of Tealium's partners, and a later e-mail exchange with Ali Behnam,
another partner.

They both emphasized a number of points that will sound all too
familiar, and I'm afraid far from convincing.  They noted that they do
not collect PII ("personally-identifiable information"), don't
accumulate user-linked data, and only query browser histories for
specific ("social media") related links.  It was also mentioned that
they have obfuscated their JavaScript to try prevent their clients
from altering the code, have a customer use policy that prohibits
their clients from attempting such alterations, have put in place a
privacy policy ... and so on.

Opt-out is apparently possible via a cookie -- but of course you have
to know what's going on before you'd ever think to set an opt-out
cookie!  They hope to move to non-cookie opt-out techniques, and
claimed in answer to my query that they'd really prefer to be opt-in,
but realize that getting people to opt-in to such a service could be,
shall we say, impractical.

If so much of this sounds like deja vu, it's because we've heard
virtually all of it before.  In many ways it's quite similar to
arguments made by Phorm and NebuAd, which were roundly criticized as
self-serving and inadequate.

The fundamental question is an obvious one -- "Unless we're asked for
our permissions in advance, what the hell business is it -- of anyone
by ourselves -- what is or is not in our browser histories?"

Arguments about not collecting PII, only looking for particular URLs,
and all the rest, necessarily fall flat.  Inspecting browser URL
histories in such a manner -- without affirmative opt-in permission --
clearly crosses the line from acceptable analytics to an unacceptable
intrusion into private activities.

If a burglar argued that the only reason they conducted break-ins was
to check to see if you had purchased particular products, would such
reasoning be likely to prevail in court?  I'm not a lawyer, so I won't
attempt here to present a legal analysis of the Tealium technique --
though I'd certainly be interested to hear opinions about this.

But again, the guys at Tealium were friendly and open in our contacts,
and made no attempt to evade my questions.  Clearly we're dealing in
this case with a very different view of what privacy is, and what is
acceptable behavior on the Web.

My hope is that Tealium will reconsider their use of this methodology,
and I urge that all browsers vulnerable to such manipulations be
altered to prevent their use.

In the meantime, there are some ways to protect yourself from this
technology, though none are particularly pretty.  You can make a practice of
clearing your browser history frequently, or not keeping a history at all,
but these are both inconvenient.  You can turn off JavaScript, but this will
completely break a vast number of sites and is generally not very practical
these days.

[ Update (1/22/09): Several people have suggested the Firefox "NoScript"
plugin as a method for finer-grained control over JavaScript.  This is
certainly available, though it is not necessarily clear which sites to
script block, or what the side-effects of selectively blocking JavaScript
will be in any given case.  But as a practical matter, most people can't run
NoScript since they don't use Firefox, and most people who run Firefox tend
not to use plugins.  The only ad hoc "solution" available to pretty much
everyone with a Web browser is to turn off JavaScript completely, with the
serious downside already noted.  More to the point, blocking such activities
at the PC is essentially a diversion from the larger issues surrounding the
Tealium service, such as should their technique be permitted at all and is
it legal in all jurisdictions?  It is unrealistic to expect everyone to
fiddle around with their browser configurations to try protect against these
sorts of intrusive activities. ]

Or you might contact Tealium and let them know if you do (or don't)
approve of their practices in these regards.

As far as I'm concerned, my browser history is mine, nobody else's.
Period.  Full stop.  End of discussion.

+1(818)225-2800 http://www.pfir.org/lauren http://lauren.vortex.com
http://www.pfir.org  Network Neutrality Squad - http://www.nnsquad.org

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

Date: Sat, 17 Jan 2009 09:20:07 -0800
From: Henry Baker <hbaker1_at_private>
Subject: Re: "Spy pens" and the future of private speech (Leichter, RISKS-25.51)

At the Consumer Electronics Show (CES) this year, a number of booth
personnel were wearing cameras on their chests that recorded video & audio
of every person they talked to the entire day.  The cameras had enough
quality to pick up the names on the badges of the people they talked with.
According to one gentleman, the camera allowed him to focus on talking with
the person and not wasting time getting his/her badge information.

These cameras are not expensive -- one of the booths I stopped at was
actually selling them.  I expect them to start showing up at all kinds of
business meetings.

The future you project is already here.

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

Date: Sun, 18 Jan 2009 06:33:47 -0500
From: Jerry Leichter <leichter_at_private>
Subject: Re: "Spy pens" and the future of private speech (Baker, RISKS-25.52)

> The future you project is already here.

That being the case ... I'll add my social predictions.  :-)

Prosecutors today complain of the "CSI effect": On the CSI series of TV
shows, every week, crimes are solved by introducing all kinds of detailed,
highly specific, scientific evidence.  Juries assume that that's the way
things work in the real world, and convincing them without it has gotten
harder - an attitude the defense bar encourages, of course.  But the reality
of scientific evidence doesn't approach the fantasy.

In a world of ubiquitous recording, anything that *wasn't* recorded will
seem, at the least, less reliable - and eventually even suspicious.  "If you
had nothing to hide, why didn't you make a recording of what you were
doing?"  The common law has traditionally accepted oral contracts - special
cases, going back the the oddly- named Statue of Frauds, excepted - in
recognition of the inconvenience of memorializing on paper the huge number
of dealings in which we are involved on a daily basis, especially in
business.  The "he said/she said" evidentiary arguments that inevitably
follow are just something that we have to accept to keep commerce flowing.
In a world where every conversation is trivially recorded - will we continue
to do that?  -- Jerry

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

Date: Sat, 17 Jan 2009 09:43:31 -0800
From: Henry Baker <hbaker1_at_private>
Subject: Re: Tony Hoare: "Null References: The Billion Dollar Mistake"

Billion Dollar Mistake?  (Dagenais, RISKS-25.51)

I'd be willing to bet that the actual number is far, far higher, especially
when adjusted for inflation.

But I applaud Tony for his apology.  I haven't yet heard an apology from
Fortran/C/C++/etc. creators over their inability to police array bounds.  A
good fraction of the ACM Fellows (perhaps the ACM itself?) need to provide
mea culpas over this issue.

To a first approximation, the lack of array bounds checking created the
virus/worm industry, and we are still paying handsomely for this.

Madoff was a rank amateur by comparison.  Computer "scientists" have been
producing insecure code like this since before NASDAQ was started.

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

Date: Mon, 19 Jan 2009 21:46:11 -0700
From: Chris Warwick <chris.warwick_at_private>
Subject: Risks of Avis insufficient customer data checking

[Re: Risks of data retention 25.48 (Armburst RISKS-25.48)]

I'm not sure I agree the assertion that one-time accounts should never be
re-used. I can see a significant benefit of storing and keeping current such
information as a way to reduce errors from having to enter the information
each time.

I think the problem comes from the resulting system, and ensuring that the
re-used information is correct and correctly used. Also, if a failure
occurs, then the system (human and automated) needs to be able to determine
where the error occurred, so it can be corrected.

I have a related story:

Avis, and other car rental companies, have a service where information
(driver's license number, billing info, etc.) is pre-entered into their
reservation/billing system, under a Wizard Number. The benefit, to me, is
that the time needed to rent a car is significantly reduced.

I checked my account last summer and found that someone had made a
reservation in my name.

I called Avis and was told that they thought that operator error had
resulted in my Wizard Number being used as part of someone else's
reservation.

Issues:

- The system should have done some checking to ensure the correct Wizard
Number was being used. Canadian banks love asking silly questions to confirm
identity, why not this system?

- The system didn't seem to have any way to determine who had made the
reservation, and inform them that correction was needed. Was the reservation
made through an agent? Was it associated with an airline reservation?

I canceled the reservation, and suggested Avis send a note to the place the
car was to be picked up, so they would know what happened when this person
arrived (and hopefully keep a car available for him).

Somewhat later copy of receipt from this person's rental turned up on my
Avis account.

So, logically, he must have arrived at the rental office, with a printed
copy of the reservation. Rather than checking why the reservation was
canceled, the rental office must have simply reconstituted the reservation
under my Wizard Number.

Issues:

- Something should have detected a fault. A detailed check of this person's
information against what was in stored under my Wizard Number should have
detected something.

- The system has stored the record of the rental, complete with parts of his
credit card number, under my Wizard Number.

I called Avis, and their response was that since the rental hadn't been
charged to me (the renter had provided a credit card) nothing was wrong.

So, I called the rental office. The person I talked to told me they
remembered the rental, and that the Wizard Number had come up when they
swiped his credit card <!>. Further discussion revealed that the name on the
credit card was the same as mine, and that the driver's license was issued
from the same province as where I live.

Issues:

- The linking of his information to my Wizard Number seems like a serious
system fault, so I am curious about Avis's response.

- In cases where the information between two customers has some overlap the
system (human and automated) needs to do extra special checking. In this
case there is a strong possibility that I could have been billed, without
any way to determine who had actually rented the car.

I guess the risk is all Avis (since the stamps on my passport prove it
wasn't me who rented the car), but in these days of identity theft, I would
hope our automated systems are being developed to reduce the IT reservation
under my Wizard Number.

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

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.52
************************
Received on Thu Jan 22 2009 - 11:03:17 PST

This archive was generated by hypermail 2.2.0 : Thu Jan 22 2009 - 11:27:08 PST