RISKS-LIST: Risks-Forum Digest Thursday 11 October 2007 Volume 24 : Issue 85
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.85.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
DHS List Server causes flood (David Lesher)
LI Railroad double-bills for tickets (Al Stangenberger)
California off the Net (Bryan Webb)
Clues to 3 Plane Wrecks Could Be Lost in Files Purge (Ken Knowlton)
Name hacking comic strip (Anders Sandberg)
Another case of Deploy First, Test Later (Huge)
Stalling Cars Via OnStar: A Hacker's Dream Come True? (Lauren Weinstein)
Microsoft HealthVault and Porn (Lauren Weinstein)
The Coax Straightjacket: Stopping Cable Copy-Protection Abuse
(Lauren Weinstein)
Proposal for Breaking the Internet Network Neutrality Deadlock
(Lauren Weinstein)
Practical Issues of the Proposed "Global Internet Measurement Analysis Array"
(Lauren Weinstein)
More Regarding the Online Medical Records Trap (Lauren Weinstein)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 4 Oct 2007 19:35:07 -0400 (EDT)
From: "David Lesher" <wb8foz@private>
Subject: DHS List Server causes flood
It started off early Wednesday as an innocuous request from a North Carolina
businessman to the Homeland Security Department. He was responding to a
daily antiterrorism bulletin by asking that it be sent to another e-mail
address. But by afternoon, a programming flaw involving the REPLY function
transformed that e-mail message into a flood of more than 2.2 million
messages nationwide that clogged the e-mail accounts of government and
private experts on domestic security, including the operators of an Illinois
nuclear power station. .... [Source: Eric Lipton, Security Bulletin Problem
Creates Message Flood, *The New York Times*, 4 Oct 2007]
http://www.nytimes.com/2007/10/04/us/04secure.html
[Who needs a greater-than-3-oz liquid bottle when an e-mail reply will do?
Do we need to get DHS a new broom and bucket to clean up this mess?
Clearly they (or more likely the contractors they hired...) need a senior
sorcerer to watch over the apprentice admins.]
[See also Lauren Weinstein's blog on this topic, Homeland Security Floods
Users With Private E-Mail. PGN]
http://lauren.vortex.com/archive/000305.html
------------------------------
Date: Tue, 09 Oct 2007 12:13:15 -0700
From: Al Stangenberger <forags@private>
Subject: LI Railroad double-bills for tickets
At least 2,000 Long Island Railroad passengers were double-billed for
tickets purchased with credit cards at automatic ticket kiosks in early
October. The problem occurred on the first business day in October. A
record number (over 30,000) of tickets were purchased by credit card via
their network of automated kiosks. This triggered a software error
(apparently undetected since 2001) which caused the system to bill for the
tickets on October 1, and then again on October 2. The vendor is working on
the problem. [It's not clear from the article whether the problem is in
each of the 269 kiosks, or possibly some central server.]
[Source: Michael Amon, *Newsday*, 5 Oct 2007]
http://www.newsday.com/news/local/ny-lilirr1006,0,7787106.story
------------------------------
Date: Fri, 5 Oct 2007 17:51:54 -0700
From: "Bryan Webb" <bwebb@private>
Subject: California off the Net
You are responsible for a sub-domain of a large, distributed, and well-known
organization. Your DNS server, maintained by your ISP, gets hacked so that
its entries are pointing to pornographic websites. When your ISP doesn't
resolve the issue after 2 weeks, you switch to another DNS provider and fix
the problem.
In the meantime, someone has discovered the problem, but suspects it is not
just your domain that's been hacked, but your entire organization's, and
complains to your new DNS provider. They, of course, don't recognize your
well-known DNS name, nor try to effectively resolve the issue. As a result,
you and all your sister domains are erased from the net.
And that's how the General Services Administration came to remove
California's ca.gov domain -- because your domain tam.ca.gov was hacked.
(That's the Transportation Authority of Marin county.)
http://www.networkworld.com/news/2007/100407-feds-pull-ca-gov-domain.html
Talk about Denial of Service!
[*NYT* item noted by David Lesher.
http://mobile.nytimes.com/2007/10/05/us/05brfs-APOLOGYAFTER_BRF.xml
PGN]
------------------------------
Date: Thu, 4 Oct 2007 09:25:29 EDT
From: KCKnowlton@private
Subject: Clues to 3 Plane Wrecks Could Be Lost in Files Purge
The Air Force destroyed all records from unsuccessful searches for aircraft
missing before 1989, which is likely to make it much harder for Nevada
investigators to determine the victims of three wrecks found in the recent
search for the aviator Steve Fossett ... One resource that had been
expected to help in the inquiry was suspended mission files, kept at Tyndall
Air Force Base in Panama City, Fla. Those files are the paper trails of all
failed searches for missing aircraft by the Civil Air Patrol, a volunteer
Air Force auxiliary group, or any other Air Force resources. But in 1994,
the Air Force instituted a regulation requiring the destruction of records
of noncombat missions after seven years. [Source: Steve Friess, *The New
York Times*, 4 Oct 2007; PGN-ed]
http://www.nytimes.com/2007/10/04/us/04fossett.html?th&emc=th
------------------------------
Date: Wed, 10 Oct 2007 11:05:50 +0200 (MEST)
From: "Anders Sandberg" <asa@private>
Subject: Name hacking comic strip
A cartoon with a cute exploit:
http://xkcd.com/327/
This example may not work in real life due to naming laws, but I would be
surprised if there were some systems out there vulnerable to names with
exotic letters being interpreted as escape characters.
Anders Sandberg, Oxford Uehiro Centre for Practical Ethics,
Philosophy Faculty of Oxford University
[xkcd is "A webcomic of romance, sarcasm, math, and language".
This item was also noted by John Tate. PGN]
------------------------------
Date: Wed, 10 Oct 2007 15:00:03 +0100
From: Huge <huge@private>
Subject: Another case of Deploy First, Test Later (Re: Ross, RISKS-24.84)
Many years ago, I was involved in 'porting' the payroll system of a large
British TV company from an ICL 1902S to an ICL 2903 (told you it was a long
time ago). We actually rewrote the whole thing in RPG2, from its original
Autocoder. We moved the data between the two machines on punched cards.
So, come the day of the first parallel run, after months of testing, and the
results were different. Not much, a few pennies, but different nonetheless.
Huge panic, much headless chicken behaviour until we discovered that ... the
old system was the one that was wrong. And had been for years.
So, what have we learned in the intervening 30 years? Not a whole lot, it
appears.
------------------------------
Date: Tue, 09 Oct 2007 12:05:41 -0700
From: Lauren Weinstein <lauren@private>
Subject: Stalling Cars Via OnStar: A Hacker's Dream Come True?
http://lauren.vortex.com/archive/000313.html
Ready to turn over the keys of your vehicle to the cops, or that clever
hacker in the next lane? How about that creepy guy following you on a
lonely country road?
GM apparently plans to perhaps make this all possible. It's been announced
that they'll be equipping nearly two million of their 2009 model vehicles
(that have OnStar installed), with the capability to be remotely shut down
to idle via OnStar commands at the request of law enforcement (
http://abcnews.go.com/Business/Autos/story?id=3706113 ).
The claim is that owners will have to give permission first for this
capability to be enabled. Bull. I don't care what OnStar's privacy policy
says, if the technical capability for this function is present, OnStar will
have no practical choice but to comply when faced with a law enforcement
demand or court order, whether or not owner "permission" was ever granted.
This new capability will also create an irresistible challenge to the hacker
community -- and perhaps criminal organizations -- to try find ways into the
OnStar system for triggering this fun -- one way or another. It's
impossible to hack OnStar? Would you bet your life on that?
Unfortunately, this is yet another laudable idea that's being "driven" into
the marketplace before all of the negative ramifications have been thought
through or fully understood. And how long will it be before such systems
are mandated, one might wonder?
OnStar has long been the subject of various privacy concerns. This new
capability appears to be the most serious privacy-related issue for OnStar
to date.
Lauren Weinstein lauren@private or lauren@private +1 (818) 225-2800
Lauren's Blog: http://lauren.vortex.com PRIVACY Forum: http://www.vortex.com
------------------------------
Date: Tue, 09 Oct 2007 09:39:48 -0700
From: Lauren Weinstein <lauren@private>
Subject: Microsoft HealthVault and Porn
http://lauren.vortex.com/archive/000312.html
It looks as if Microsoft may already have some significant quality problems
with their heavily hyped HealthVault.
I received an e-mail last night from a reader who was disgusted to find that
some completely valid queries to the HealthVault search engine -- mentioning
bodily parts or bodily functions -- returned extremely high percentages
(sometimes almost 100%) of porn keyword "sucker" pages (porn pages that have
been "seeded" with all manner of likely keywords). I won't offer example
search strings here in the interests of good taste, but I've confirmed this
situation myself.
In fact, this person noted getting masses of porn results starting with
their very first HealthVault search. They were stunned that Microsoft's
quality control and presumed filtering of results for health relevance were
so defective on a highly touted health-specific search engine deployed for
the general public. I agree.
For comparison purposes, a test of the same searches on Google also yielded
a lot of porn hits, but overall more relevant hits were returned, and Google
isn't promoting their main search engine as having a health focus.
There is a potential bright side to this situation. I'm all in favor of
using encryption whenever possible on the Net, and HealthVault uses SSL
crypto for searches in both directions. So finally there's a way to search
for porn on the Net with better privacy!
All Microsoft needs to do now is simply rebrand their service as "PornVault"
-- now that's a winner.
Lauren Weinstein lauren@private or lauren@private +1 (818) 225-2800
Lauren's Blog: http://lauren.vortex.com PRIVACY Forum: http://www.vortex.com
------------------------------
Date: Mon, 08 Oct 2007 16:08:46 -0700
From: Lauren Weinstein <lauren@private>
Subject: The Coax Straightjacket: Stopping Cable Copy-Protection Abuse
http://lauren.vortex.com/archive/000310.html
VHS is dead. Its ghost lingers in our homes and in cobweb-filled corners of
electronics retailers, but make no mistake, VHS recording is rapidly going
the way of the dodo. And this passing is being used as an excuse for one of
the biggest consumer ripoffs in technology history -- with our friendly
neighborhood cable television services (in their various incarnations)
chuckling mightily at the situation.
When we first started hearing about Digital Rights Management (DRM) systems
planned for digital television, there was a great deal of concern, even
though the planned focus appeared to be on "premium" programming (HBO,
Showtime, Pay Per View - PPV, and so on). Much of this seemed rather
academic anyway, since consumer devices that would be affected by such
systems were still largely vaporware.
But that situation has changed rapidly, and now cable firms (and their
fiber, satellite, IPTV, and other variations -- I'm calling them all cable)
have got their subscribers by the you know what, and unless the FCC (fat
chance) or Congress (perhaps a better chance) get moving, consumers will see
their hard won rights to record and save television programming fade into
history. It's happening right now.
The Supreme Court "Betamax" decision decades ago established the fair use
rights of consumers to make copies of television programs, and save them on
videocassettes. But with the demise of VHS, the newly ascendant technology
is Digital Video Recorders (DVRs), such as the TiVo and its various cruder
generic cousins (the latter typically cable company supplied).
DVRs allow saving of programs on their internal hard drives, but there's a
problem. Video takes a lot of bits, and hard drive space is limited. So
the trend now is to find ways for consumers to save programs to external
media and devices (such as DVDs or PCs), much as they could with VHS tapes.
Direct DVD recorders are appearing, as are newer generation TiVos that will
shortly have the capability enabled to move programs to PCs and then write
them to DVDs.
But many cable firms are trying to thwart these capabilities via DRM, trying
to turn back the clock to pre-Betamax days. Their magic wand for this
purpose is the Copy Control Information (CCI) byte, transmitted as part of
digital cable channels, which impacts any modern device that interfaces
directly to a cable system (e.g., through cableCARDS like with the newest
TiVo HD -- and many more devices so affected are now appearing).
Set CCI=0x00, and the consumer can dump programs off of their DVRs. Set it
to 0x02, and the programs are locked down. The device manufacturers must
abide by this rule or suffer the wrath of CableLabs -- the cable industry's
own version of Dr. Evil's R&D operation.
Given the power that CCI holds over consumers, one would think that there
would be concise standards for how it would be applied to programming.
Buzzz! Wrong! In fact, the significant regulations that apply to CCI
simply require that digital broadcast channels (that is, over-the-air
signals retransmitted as digital cable channels), must set CCI=0x00. Beyond
that, the regs are essentially silent.
Now, logically one wouldn't be surprised to find cable companies setting
CCI=0x02 -- blocking program saving to DVDs, etc. -- for special event
programming, PPV, and perhaps even the HBO/Showtime class of premium
channels.
What you might not expect to frequently find is cable company ad hoc CCI
blocking of essentially *all* basic digital channels (other than
over-the-air) totally on their own volition -- creating unfair recording
capability variations around the country.
For example, Time Warner Cable is generally setting CCI=0x02, and blocking
dumping of programs from DVRs, in this expansive manner. There's no
evidence that all of these programs suppliers have demanded such an action.
Many of these channels run Cable in the Classroom programming that is
specifically licensed to be recorded, saved, and distributed in schools
under various terms. CCI=0x02 can directly block such licensed use.
Similarly, it seems unlikely that the various C-SPAN channels would demand
blocking of program dump functions, yet Time Warner is routinely setting
CCI=0x02 for some or all of these channels as well (which may often appear
only on digital tiers) on many TW systems.
Since nothing requires TW to be taking this broad control freak approach to
DRM on their digital channels, the most likely explanation would seem to be
a CYA mentality run amok, subscribers' rights be damned.
Comcast, on the other hand, has reportedly been trending in the opposite
direction, with their systems moving toward CCI=0x00 settings for most
digital channels, allowing consumer program dumping and external saving.
Question: What possible valid reason can there be for cable subscribers of
one company's systems to have vastly fewer recording rights for the same
channels, compared with subscribers of another company's cable systems?
Answer: There's *no* valid explanation for this disparity. It's wacky,
wrong, and just plain unacceptable. And as more consumer devices affected
by this craziness rapidly deploy in the marketplace, subscribers are going
to go ballistic when they discover that the pricey boxes they've bought have
key functionality cut off at the knees by cable company edict in many
locations.
If the cable industry was smart, they'd collectively start reversing
draconian CCI settings right now, and start universally treating their
subscribers as individuals to be appreciated, not chattel to be abused. But
absent such an enlightened approach from the industry as a whole, it's
likely that we're going to have to make it clear to Congress that when it
comes to this sort of DRM abuse (to paraphrase Howard Beale in the 1976 film
"Network"): "We're as mad as hell and we're not going to take this anymore!"
-- assuming that our cable companies don't try to block this too, of course.
Lauren Weinstein lauren@private or lauren@private +1 (818) 225-2800
Lauren's Blog: http://lauren.vortex.com PRIVACY Forum: http://www.vortex.com
------------------------------
Date: Thu, 27 Sep 2007 14:55:42 -0700
From: Lauren Weinstein <lauren@private>
Subject: Proposal for Breaking the Internet Network Neutrality Deadlock
I've just posted a proposal for a project aimed at moving past the current
Network Neutrality impasse, with the deployment of a distributed global
Internet traffic measurement system as a major component.
http://lauren.vortex.com/archive/000299.html
Comments, questions, etc. are welcome. Thanks!
Breaking the Internet Network Neutrality Deadlock (HTML)
http://www.pfir.org/nn-proposal
Breaking the Internet Network Neutrality Deadlock (PDF)
http://www.pfir.org/nn-proposal.pdf
Lauren Weinstein, +1 (818) 225-2800 http://www.pfir.org/lauren
Lauren's Blog: http://lauren.vortex.com
------------------------------
Date: Mon, 1 Oct 2007 15:08:32 -0700 (PDT)
From: Lauren Weinstein <lauren@private>
Subject: Practical Issues of the Proposed "Global Internet Measurement Analysis Array"
Practical Issues of the Proposed
"Global Internet Measurement Analysis Array"
http://lauren.vortex.com/archive/000303.html
In "Proposal for Breaking the Internet Network Neutrality Deadlock" (
http://lauren.vortex.com/archive/000299.html ), I recently suggested a
project for the gathering and analysis of worldwide Internet traffic data
and characteristics, for Network Neutrality-related and other purposes,
based on a distributed architecture of processes running mainly on end-user
computers.
I've now dubbed this project the "Global Internet Measurement Analysis
Array" (GIMAA).
I'd like to now touch very briefly on a few of the many practical
considerations that such a project would entail, including deployment,
security, and privacy issues.
To be useful, the measurement collection environment requires a very large
number of participating end-user sites. While standalone versions of the
GIMAA programs will of course be needed for a variety of hardware platforms,
deployment could be significantly hastened by including the associated code
into other already widely used end-user packages, e.g. popular browser/OS
toolbars and/or free utility application bundles. It may even prove
possible to primarily use the existing application/toolbar data traffic as
the foundational operational corpus for the measurement system itself,
supplanted as necessary by purpose-generated measurement-related data.
To the extent that the vendors of such toolbar and application packages are
interested in the potential ongoing output of a GIMAA environment, such
"packaging" would seem an attractive possible route for dissemination of the
system, with the goal of reaching a practical deployment level as quickly as
possible.
A range of security and privacy issues accompany a project like GIMAA, some
of which will likely be leveraged by some entities into objections against
the entire project.
Clearly the GIMAA code modules, measurement payload data, and any associated
aggregated data will need to be secure and as protected against manipulation
and tampering as current technology will allow. User data on participating
systems must be protected as a first priority concern.
A more unique issue with the GIMAA methodology is that the techniques
envisioned, if they prove out and are very widely deployed, could be
extremely powerful. As such, concerns are sure to be raised that GIMAA may
publicly reveal network traffic, topological, vulnerability, and other data
that some network participants, and others, might prefer to keep hidden for
business, security, or other reasons.
It can be anticipated, for example, that some firms (including ISPs) would
become concerned that GIMAA node activity could reveal what they consider to
be proprietary aspects of their network topologies, and that attempts to
block GIMAA measurement traffic, and/or the writing of prohibitions against
such measurement techniques into Terms of Service agreements, would be
forthcoming.
Of course, one of the key purposes proposed for GIMAA is to detect
vulnerabilities and abuses so that they can be corrected (through technical
or policy means, as appropriate), and it would be expected that some of
those entities responsible for such conditions would not be enthusiastic
about their being so exposed.
I also consider it likely that GIMAA will be criticized from some quarters
on national security grounds, with the argument being that the Internet
infrastructural data that could be exposed would make attacks on the
Internet and its attached systems more effective.
All of these concerns are real, and considerable effort will be needed to
balance the benefits and risks associated with a project like GIMAA.
But aside from the more obvious cost/benefit analysis that can be applied to
this project, there's another basic reality that renders some of these
concerns relatively moot in important respects.
The categories of measurement methodologies proposed for GIMAA could be
deployed on a clandestine basis by technologically skilled adversaries,
perhaps as part of widely disseminated computer viruses and the like. If
GIMAA does not move forward, that doesn't guarantee that "bad guys" won't
get access to such data via their own GIMAA-like technologies that could
infect systems around the world. Blocking GIMAA would only assure that
honest players wouldn't have access to the same sorts of important
information.
In my book, it's nonsensical and dangerous to block open and honest use of
even potentially sensitive data, while the unscrupulous can likely gain
access to similar data via their own means and for their own purposes.
Sometimes sunlight really is the best disinfectant, and in the case of the
Internet the old paradigm of "security through obscurity" has been widely
discredited.
GIMAA, while not without real risks, will hopefully shed some needed
light on aspects of the operational Internet that have been in the
shadows for far too long, having caused a resulting lack of trust
that only more open availability of data in these respects can likely
ameliorate.
Thanks as always for your consideration.
Lauren Weinstein lauren@private or lauren@private +1 (818) 225-2800
Lauren's Blog: http://lauren.vortex.com PRIVACY Forum: http://www.vortex.com
------------------------------
Date: Fri, 05 Oct 2007 08:59:50 -0700
From: Lauren Weinstein <lauren@private>
Subject: More Regarding the Online Medical Records Trap
http://lauren.vortex.com/archive/000307.html
In response to my discussion of "The Online Medical Records Trap" (
http://lauren.vortex.com/archive/000306.html ), I've been asked what would
happen if a central medical records system were encrypted in the manner I
suggested, where the service provider couldn't access the records even in
the face of an outside demand (like a court order) without the user's
permission, in the case of the person being incapacitated or unconscious.
There are several rather simple answers to this. The most basic is that to
depend on a centralized system as the only location where medical records
are stored would be incredibly foolhardy. If doctors or hospitals needed
access to that data, and their local computers or Internet connections were
down, or if the central servers had been hacked or were having other
problems (including possible connectivity issues) then patients would be
S.O.L. (that is, up the creek without a paddle).
It should be required that doctors and hospitals maintain local copies of
patient records, ideally not only on their local computers (the same level
of encryption and access control that I propose for central medical records
systems would not be necessary nor desirable on these local systems), but
also the records should be kept in hardcopy form as well.
Yes, I said hardcopy. A hassle that devalues the computerized systems?
Yep, but I want my medical records kept locally in a form that doesn't
depend on computers or even electricity. I like those manila folders on the
shelves, especially living in an area where earthquakes and other natural
disasters (with their resulting power outages) are always a possibility.
Most other areas also have their own risks of disasters or problems that
could make computer-based access to patient records impossible just when
they're needed most, especially if those records are centralized and
communications are down.
As far as access to a central system is concerned, nothing says that a user
couldn't provide friends, next-of-kin, etc. with their access key, or even
have it noted on whatever emergency contact information that they hopefully
carry routinely. I have a slip of paper in my wallet with a few contact
names and numbers for emergency use, mainly in case some idiot wipes me out
making a left turn in front of me when I'm riding, but the point is that
while carrying around your passwords isn't a great idea in the general case,
this is one specific situation where it could make sense.
I should add that it's also wise to include on your contact sheet full
information about any allergies or other serious medical conditions that
exist so that responders will know about them in emergencies. To depend on
access to a centralized medical system for such info in these situations
could be disastrous, even if none of the central data were encrypted or
otherwise access controlled -- there's no guarantee that the central system
would be reachable when you might need it most.
So what does this all boil down to? A centralized medical records system
should never be depended upon for anything other than secondary access to
medical data, if that. Doctors and hospitals must be required to maintain
local copies of patient data since there is no guarantee that central
systems will be accessible at any given time, particularly in disaster or
other emergency situations.
To help prevent misuse of central medical records systems, all personal
medical data on those central systems should only be accessible with the
permission of the user or their designated contacts, and should be encrypted
in a manner that makes other access impossible. Period. Anything short of
this opens up enormous abuse potential.
Lauren Weinstein lauren@private or lauren@private +1 (818) 225-2800
Lauren's Blog: http://lauren.vortex.com PRIVACY Forum: http://www.vortex.com
[In subsequent discussion, Curt Sampson noticed the "beta" tag below the
HealthVault logo doesn't make him very confident about putting all of his
and his family's critical health information into the system. He also
noted a nasty problem with their feedback facility. Lauren noted a cert
inconsistency there. Curt replied "I think I can get some sense of how
well your site is run by clicking on 'feedback', which first gives me:
'Unable to verify the identity of feedback.live.com as a trusted site.'"
PGN]
------------------------------
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 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
------------------------------
End of RISKS-FORUM Digest 24.85
************************
This archive was generated by hypermail 2.1.3 : Wed Oct 10 2007 - 17:39:02 PDT