RISKS-LIST: Risks-Forum Digest Wednesday 5 October 2005 Volume 24 : Issue 06
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.06.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Google, Privacy, and Masochism (Lauren Weinstein)
Legal docs expose various risks in routine Diebold maintenance in NC
(Joseph Lorenzo Hall)
Car and van collide (Kathy Uek via Monty Solomon)
Y2K glitches linger (George C. Kaplan)
Windows delete command can fail silently (Diomidis Spinellis)
Buffer overrun in television sets (Matt Roberds)
Why telephone "Caller ID" is actually now even worse than we expected
(Lauren Weinstein)
Re: Mea culpa: How we got it wrong on CNID (Kelly Bert Manning)
Windows and USB devices (Mike Swaim)
Router worms and International Infrastructure (Gadi Evron)
D.C. Red-Light Cameras Fail to Reduce Accidents (Monty Solomon)
Re: Katrina victims required to use Microsoft IE (Michael Bacon)
Re: Kitten on the keys... (Andrew Koenig)
CCSA Fall Symposium Call for Participation 3 Nov 2005 (Michel Kabay)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 04 Oct 2005 16:24:46 -0700
From: Lauren Weinstein <lauren@private>
Subject: Google, Privacy, and Masochism
Today Google and Sun Microsystems announced a joint venture, and while their
grand plan seems somewhat murky at this point, there is speculation that
their goal is to move toward "hosted" versions of applications (such as
Sun's "StarOffice") that would run largely on remote central servers instead
of local users' PCs, theoretically allowing access from any Internet
location. This would presumably present formidable competition to
Microsoft's own software products.
Whether or not this is actually the Google/Sun target, it's worth taking a
moment to review where we stand right now regarding Google in some important
respects.
Google keeps records of your searches, and can tie them to other activities
via cookies. Google scans the e-mail you send and receive through
Gmail. Google collects a variety of information on your other browsing
activities through various optional toolbars and services.
Google wants to make copies of copyrighted books without paying for them.
Arguments about how they might make "snippets" of such materials available
in "Google Print" aside, the internal R&D value alone of that collection to
Google would presumably be immense, and all without sending a dime to the
copyright holders.
When CNET ran a story using Google to research data on Google's chief exec,
Google reacted like an enraged and petulant child.
Now, with the new Sun Micro deal, if hosted versions of word processing and
related applications are developed and deployed by the joint Google and Sun
team, Google could quite possibly be tied into your document editing and
other Office-like activities if you use such services.
Google refuses to hire a privacy officer (after all, they're the "Trust us
-- First do no evil" company, and they're smarter than everyone else
about... well... everything, right?)
Google refuses to detail their data retention policies or the extent to
which they make that growing corpus of data available to outside entities.
Of course, it's Sun's Scott McNealy who has famously said: "You have no
privacy, get over it" and who suggested that consumer privacy is a "red
herring" issue.
Let's face it, the writing isn't only on the wall, it's dripping off and
collecting in putrid pools on the floor.
"Trust us" is not enough.
Why does Google so strenuously resist at least consulting with the privacy
community? What have they got to lose if everything they're doing is on the
up and up? (I'm certainly willing to assume that this is currently the
case.) Why do they take such a masochistic approach when it might be
possible with a relatively few changes to let in the fresh air?
Here's my free advice to Google. Pick up the phone and start talking to
folks who quite possibly might have more experience dealing with these
issues than you do, and might even be able to help you. I for one would be
much happier if I could support Google's efforts rather than having to be
concerned every time they announce a new project.
Hell, my number is listed below. I'd be glad to chat. But I won't be
holding my breath waiting for their call.
Lauren Weinstein lauren@private lauren@private Tel: +1 (818) 225-2800
http://www.pfir.org/lauren http://www.pfir.org http://www.eepi.org
Lauren's Blog: http://lauren.vortex.com DayThink: http://daythink.vortex.com
------------------------------
Date: Mon, 3 Oct 2005 23:04:20 -0700
From: Joseph Lorenzo Hall <joehall@private>
Subject: Legal docs expose various risks in routine Diebold maintenance in NC
Reference [1] (from Joyce McCloy [of NCVV][2]) is fascinating. It is an
exchange between an attorney at Diebold Election Systems, Inc. (DESI) and
the general counsel for the North Carolina State Board of Elections. It
mostly centers around a few incidents that occurred in Gaston Co., NC. It
is a great illustration of a number of worrying characteristics of the
vendor/jurisdiction relationship typical of modern election systems.
[1]: http://www.josephhall.org/nqb2/media/GastonDiebold2004.pdf
[2]: http://www.ncvoter.net/
Three incidents are of particular note:
1. In one city, Dallas, NC, a bug appears to have prevented the downloading
of 11,945 votes which wasn't caught for seven days. At which point, it
appears the county compared paper print-outs from the precinct with the
totals reported by the tabulation server. A DESI technician reproduced
the bug twice and then decided to forgo usual DESI protocol and loaded
the flash-based memory packs directly into the central (GEMS) server to
retrieve the votes from the memory pack.
2. In another case, another memory pack "failed to download" and the DESI
technician got approval to send a back-up file electronically to DESI
technicians who then e-mailed the results back. After writing this data
to a memory pack, the on-site technician loaded them into the central
server via a tabulator unit.
3. Finally, the document describes hand-entering of "three to five"
ballots. DESI claims as a "check and balance" this process doesn't allow
the technician to enter more votes than the total vote count (that is,
the number of valid plus spoiled ballots). This would implicate that one
would be prevented from entering more than a certain number of votes,
but, of course, does nothing to constrain what votes are entered. A
human looking over the technician's shoulder is the only other
constraint.
I've posted more below the fold:
<http://josephhall.org/nqb2/index.php/2005/10/03/desi_nc>
Joseph Lorenzo Hall, UC Berkeley, SIMS PhD Student
<http://josephhall.org/> blog: <http://josephhall.org/nqb2/>
------------------------------
Date: Mon, 3 Oct 2005 00:40:50 -0400
From: Monty Solomon <monty@private>
Subject: Car and van collide
Kathy Uek, MetroWest Daily News, 2 Oct 2005
A two-car accident on Rte. 20 in Marlborough in front of Burger King sent
several people to area hospitals, including one who was flown by medical
helicopter to a Worcester hospital. Police said a handicapped-equipped
two-seat Dodge van was traveling on Rte. 20 when it hit a Lexus traveling in
the opposite direction yesterday at about 11:30 a.m. "The disabled driver's
arm began twitching," said Officer Rob Insani. "Since the controls are on
the steering wheel, he couldn't control the car and it seems like he swerved
into the oncoming lane." ...
http://www.metrowestdailynews.com/localRegional/view.bg?articleid=110555
------------------------------
Date: Sat, 1 Oct 2005 16:45:04 -0700
From: "George C. Kaplan" <gckaplan@private>
Subject: Y2K glitches linger
I decided to make a contribution to the Red Cross, so I went to their
website and followed the "Donate by Mail" link. This brings up a simple
form where you can enter your name, address, donation amount, etc, and then
display the info on a page to be printed out and mailed with your check.
On the page I printed, right above my name, is the line:
Today's Date: Saturday, October 1, 105
It appears to be a well-known problem with the Javascript 'getYear()'
method, which is implemented to return either the current year, or (year -
1900), depending on which browser is being used. There are equally
well-known ways to avoid the browser incompatibilities; why the Red Cross
doesn't use them is an open question.
George C. Kaplan, Communication & Network Services, University of California
at Berkeley 1-510-643-0496 gckaplan@private
------------------------------
Date: Mon, 03 Oct 2005 16:48:33 +0400
From: Diomidis Spinellis <dds@private>
Subject: Windows delete command can fail silently
In the Windows XP command interpreter CMD.EXE (the default command line
shell) one can specify multiple arguments to the DEL(ete) command, in order
to delete multiple files. If at least one of the files can be deleted, the
command will not complain about any nonexistent files specified as
arguments. For example:
C:\> echo.>foo
C:\> del nonexistent foo
C:\> del nonexistent
Could Not Find C:\nonexistent
This behavior is non-orthogonal and risky. If one mistypes the name of one
of several files that are to be deleted, that file will silently continue to
exist. The same will happen if one of the files has the hidden attribute
set: DEL will silently ignore it, rather than issue an error message.
Although one should not depend on a delete command to reliably obliterate
data, the current behavior can lead to difficult-to-locate bugs, especially
in scripts.
Further examination of the command reveals other instances of non-orthogonal
behavior. When specifying multiple non-existent files as arguments, DEL
will complain only about the first one, but when specifying multiple files
with the read-only attribute set, DEL will complain about each one. Also
DEL, never sets the ERRORLEVEL environment variable to indicate an error,
although other commands, like DIR, set it correctly.
The logic behind a correctly-operating implementation of DEL is trivial.
errorlevel = 0
foreach filename
if not delete(filename) then
display_error_message(filename)
errorlevel = 1
end if
end foreach
exit(errorlevel)
If a central and critical piece of the Windows operating system, such as the
command shell, can't get the above logic right, what are the chances of
having in the system a secure TCP/IP stack, web browser, or firewall?
Diomidis Spinellis - http://www.spinellis.gr
------------------------------
Date: Sat, 01 Oct 2005 00:26:34 +0000
From: Matt Roberds <mroberds@private>
Subject: Buffer overrun in television sets
A recent discussion in news:sci.electronics.repair concerned late-model RCA
television sets that would suddenly lose their sound. Two repair
technicians stated that they could find nothing physically wrong with the
sets, and that unplugging the set for a while seemed to cure the problem.
One technician later posted this link:
http://www.iwaynet.net/~nesda/SilentCTC.html
According to that article, a device from one particular manufacturer that is
used to insert closed captioning and other data into the video stream is
generating data that has two bits more than the specification. These two
extra bits were causing the microprocessor in the television to become
confused. The article claims that Sony, Hitachi, and Philips sets are also
affected.
That article is dated June 2001, but the discussion in the newsgroup appears
to indicate that this problem has occurred more recently than that.
------------------------------
Date: Sun, 2 Oct 2005 17:33:04 PDT
From: Lauren Weinstein <lauren@private>
Subject: Why telephone "Caller ID" is actually now even worse than we expected
Recently, a former critic of telephone company "Caller ID Services" (more
properly "Calling Number ID" - CNID) has publicly stated that he has changed
his mind and now feels that our concerns (I'm a CNID critic of long standing
myself) have turned out to be unjustified.
With all due respect, I must strongly disagree.
First, there's a logical flaw in the argument that simply because one
doesn't perceive or experience the sorts of problems cited, that they don't
exist -- or that they wouldn't exist even with less or no blocking of
CNID. These are both incorrect. In fact, CNID has now become even more
dangerous than we ever imagined.
Taking the latter point first, we have no way to know how many problems have
been and continue to be avoided by the use of CNID blocking. Most people
sensitive to these concerns have been using blocking all along, so by
definition to the extent that they're not making non-blockable 800/900-type
ANI calls they are relatively protected. Business collection of CNID info
may have been somewhat suppressed by the heavy usage of blocking, but if
there were less blocking there would almost certainly be more collection
since it would become a more valuable resource.
And yet, most of the horror stories still *do* take place. You may not hear
about them, but in my role as PRIVACY Forum moderator I frequently get
reports that are utterly nightmarish. Spousal abuse facilitated by CNID,
massive abuse by businesses that *do* collect the CNID data, and then use it
as an excuse to claim exemptions from the "do not call" lists, and all
manner of other problems, some of them life threatening, and particularly
bad in regions that don't offer per-line blocking, where one can easily
forget to dial the block code on an individual call.
But our crystal ball *was* foggy, in that we never predicted the new CNID
scourge that has actually been putting even more lives at risk - -- CNID
Spoofing. This is becoming very widespread and is being used by crooks, scam
artists, stalkers, collection agencies, pranksters, and so on -- and is a
total mess. The telcos in general so far can't/won't do anything about this
-- it may not be fixable in a practical sense -- and this spoofing is
rapidly being commercialized, using PRI telephone trunks and VoIP
interfaces. Both CNID number and name info can be easily spoofed in most
cases via these systems. It's an enormous problem and getting rapidly worse,
and is poised to blow up in a big way in the public sphere, and really give
CNID yet another new and very serious black eye.
In a comment to a PRIVACY Forum message in 1993, I suggested that, "As a
practical matter, 'spoofing' of caller ID (CNID) systems should not be a
significant problem in modern, properly implemented systems."
The last three words in that quote are key. We did not anticipate that
untrusted parties would gain routine access to such sensitive aspects of the
telephone network in a manner that would allow such abuse.
Lauren Weinstein +1 (818) 225-2800 http://www.pfir.org http://www.eepi.org
http://daythink.vortex.com Moderator PRIVACY Forum - http://www.vortex.com
------------------------------
Date: Sun, 02 Oct 2005 22:36:22 -0400 (EDT)
From: bo774@private (Kelly Bert Manning)
Subject: Re: Mea culpa: How we got it wrong on CNID (Kuenning, RISKS-24.05)
Time out to start. Has Geoff Kuenning done any research about the impact of
Caller ID, or is this one of those situations where someone projects their
personal experience and assumes that it applies to everyone.
I've been seeing descriptions of the negative consequences of Caller ID
for years, including murders, in publications such as Privacy Journal:
http://www.privacyjournal.net/
In discussions with people I often notice a gender split. Men tend to think
that Privacy is mainly concerned with junk mail, telemarketing and spam,
while women tend to assume that it is more to do with not being confronted
by someone they wish to have No Contact with.
> Then a few privacy advocates noticed that there was a dark side: if
> you called a local business, it could capture your number with CNID
> and add you to a telemarketing list. Suddenly CNID changed from a
> beneficial service to a nefarious plot.
There is far more to the issue and to the concerns. Caller ID for a hardline
phone places you at a particular location. That isn't necesarily the case
for cellular phones, unless someone with access to tower or GPS data for
that mobile phone can be corrupted. Prepaid cellular solves much of the
billing data privacy issue. I do agree with Geoff Kuenning's comments about
cell phones "solving" some Caller ID problems.
> What happened? The answer is simply that I was wrong about the evils of
> CNID, and wrong about the (perceived lack of) benefits. That error arose
> primarily from an inability to correctly predict the future. In particular,
> the following forces have reduced the evils and increased the benefits:
Privacy Journal sometimes offers prediction about future abuse, but often PJ
publishes "War Stories" of real life experiences.
> 1. The predicted data collection by small businesses never happened.
Says who? Is there any researched evidence behind this claim?
Kevin Evans, "President" of the BC Business Council, that is to say, Paid PR
front man, stated that customers expect businesses to answer the phone with
"Hello Mr. -politician's surname- are you happy with your Hugo Boss purchase
from last week?", while making the Business Council's pitch to a legislative
committee responding to a national mandate to enact private sector privacy
laws. He made the comment in connection with the issue of Caller ID, not
ANI.
It is perfectly possible that Mr. Evans was exaggerating the ability and use
of Computer Integrated Telephony by business. On the other hand he was
making a claim in public and the cost of Computer Integrated Telephony gets
cheaper every year. Retrieving a customer name via CNID and associating it
with account data and recent purchase history is well within current
technology for large, medium or even small businesses. Haven't we seen Risks
submissions about companies billing the wrong customer because they use ANI
data with the assumption that it uniquely identifies customers?
In my own submission to the legislative committee I responded to Mr. Evan's
claim, rhetorically asking how he reconciled it with at least 1/3 of telco
customers paying for non published numbers, and with the fact that at least
1/4 of Canadians are Privacy Fundamentalists.
I also changed Evan's scenario to one in which "Mr. Smith's" wife calls a
store and is asked "Hello Mr. Smith, are you happy with that gold necklace
you bought earlier this week?". I pointed out that Mr. Smith is unlikely to
be happy with that, regardless of whether the necklace is a surprise
anniversary/birthday gift for his wife, or one for his girlfriend.
> 3. The unforeseen Federal Do-Not-Call List has become an effective defense
> against telemarketing, so revealing your telephone number isn't much of a
> problem anyway.
Again this reflects an idiosyncratic definition and perception of the risks.
The risks of Caller ID are not limited to telemarketing.
A hard line phone number reveals your location at the time you call. Think
of the meaning of the phrase "I know where you live". While it has become
something of a dramatic cliche it is based on a harsh reality which most
people should be able to understand.
There are 100s of millions of people in the world with hard line phones. The
fact that Geoff Kuenning hasn't personally experienced a downside of Caller
ID doesn't mean that everyone else has been so fortunate.
Most murder victims are killed by someone they know. Personal experiences
vary widely and allowance should be made for that. The fact that Geoff
Kuenning hasn't been murdered doesn't mean that nobody should worry about
homicide.
The display of hard line calling numbers creates a potential for a wide
variety of privacy invasion and abuse. Stating that it has never happened
seems naive, to say the least.
Personally I found many people using caller ID got confused when the
information on my employer paid home phone line was displayed. It can create
confusion as well as eliminate it. Eg. I got paged at home and whoever
answered my call decided I must be at my office, based on caller ID showing
the name of my employer. (My employer provided cell phone was unreliable at
home).
------------------------------
Date: Sun, 2 Oct 2005 21:54:44 -0500
From: "Mike Swaim" <mswaim@private>
Subject: Windows and USB devices (Re: Koenig, RISKS-24.05)
In RISKS-24.05, Andrew Koenig complains that every time he moves a USB MIDI
device to another port, Windows thinks that it's another device. Raymond
Chen discusses this behavior in his blog in message
http://blogs.msdn.com/oldnewthing/archive/2004/11/10/255047.aspx
What is probably happening is that the MIDI device doesn't have a serial
number, so Windows can't tell if it's the same device it's seen before or
not. So Windows errors on the side of caution and considers it a new device.
Mike Swaim, MD Anderson Dept. of Biostatistics & Applied Mathematics
mpswaim@private or mswaim@private at work
------------------------------
Date: Sat, 01 Oct 2005 15:49:06 +0200
From: Gadi Evron <ge@private>
Subject: Router worms and International Infrastructure
The subjects of routers security, possible worms and the "taking down of the
Internet" are ones that occupy much of my time. Trying to distinguish
different threats, plausibility and FUD - as well as finding solutions.
The following is an e-mail message in which I discuss a certain simple
scenario to such a risk, and I would really appreciate some feedback on it.
You can find the text in this blog entry:
http://blogs.securiteam.com/?p=73
My blog: http://blogs.securiteam.com/?author=6
------------------------------
Date: Tue, 4 Oct 2005 12:43:53 -0400
From: Monty Solomon <monty@private>
Subject: D.C. Red-Light Cameras Fail to Reduce Accidents
Del Quentin Wilber and Derek Willis, *The Washington Post*, 4 Oct 2005, A01
The District's red-light cameras have generated more than 500,000 violations
and $32 million in fines over the past six years. City officials credit them
with making busy roads safer. But a *Post* analysis of crash statistics
shows that the number of accidents has gone up at intersections with the
cameras. The increase is the same or worse than at traffic signals without
the devices. Three outside traffic specialists independently reviewed the
data and said they were surprised by the results. Their conclusion: The
cameras do not appear to be making any difference in preventing injuries or
collisions. ...
http://www.washingtonpost.com/wp-dyn/content/article/2005/10/03/AR2005100301844.html
------------------------------
Date: Sun, 2 Oct 2005 04:21:06 +0100
From: "Michael \(Streaky\) Bacon" <himself@streaky-bacon.co.uk>
Subject: Re: Katrina victims required to use Microsoft IE (RISKS-24.05)
Douglas W. Jones wrote about FEMA's website working under one browser (IE)
only ... and then not well.
Not too many moons ago, one of the largest oil companies in the world relied
upon telex as its stand-by communications system. Rugged, reliable, needing
only a telegraph wire to work, reaching multiple audiences, accessible by
sophisticated (e.g. PC) devices as well as dedicated telex terminals,
working in any language using the Roman alphabet, store-and-forward but with
instant access and delivery capability; telex is (was) the epitome of
simplicity and availability, practically a guaranteed method of
communication in the aftermath of a disaster.
Complex websites, packed with graphics and requiring particular software,
fonts, etc. to work properly are not suited to such situations.
The RISKS are manifold, and engineered in by the inability of "imagineers"
to truly imagine.
------------------------------
Date: Fri, 30 Sep 2005 22:00:29 -0400
From: "Andrew Koenig" <ark@private>
Subject: Re: Kitten on the keys...
> From: Harvey Fishman
> I read the article in Risks about your contretemps with regedit and I
> think that the fault here lies with you rather than Microsoft. I am a
> cat person also, and when I get a new kitten it learns quickly that
> desktops and computer keyboards are verboten. Water guns are really
> excellent tools for teaching young cats what is acceptable and what is
> not. A cat that gets to the age of five months without learning this
> discipline is the mark of a lazy owner.
The interesting thing is that this particular incident is the *only* time I
can recall this kitten actually walking on the keyboard. After receiving
your e-mail, I watched her normal behavior, which is to jump from the table
next to my computer stand onto the stand and from there to my lap, without
touching the keyboard. I have no problem with her behaving that way.
Anyway, if a kitten can come that close to permanently deleting a registry
key, so can a dropped object. Such things happen. For that matter, I
suspect that if I failed to suppress my Unix habits and hit "delete" instead
of "backspace" at the wrong time, it would have a similar effect.
So what I'm trying to say is that regardless of how my cats behave, I don't
think it's wise to design a software system that allows a single keypress to
make an irrevocable change to the system's state.
PS: I don't think using a water pistol near computer equipment is a real
good idea, either.
------------------------------
Date: Tue, 4 Oct 2005 05:26:13 -0400
From: "Michel Kabay" <mkabay@private>
Subject: CCSA Fall Symposium Call for Participation 3 Nov 2005
The Cyber Conflict Studies Association Fall 2005 Symposium will be held
November 3, 2005 in Arlington, VA. The CSC is a non-profit entity organized
to promote and lead research and intellectual development efforts to advance
the field of cyber conflict.
This Symposium will form the basis for the initial issue of the Cyber
Conflict studies Association's *Journal of Cyber Conflict Studies* and will
help create agendas for Workshops in the Spring of 2006.
Full details of the conference can be downloaded as a PDF file from
http://www2.norwich.edu/mkabay/unlinked/ccsas_cfp.pdf
The registration form is available from
http://www2.norwich.edu/mkabay/unlinked/ccsas_reg.doc
For further details, contact Jane Swann at < mailto:kswann@private >.
M. E. Kabay, PhD, CISSP http://www2.norwich.edu/mkabay/
* Assoc. Prof. Info. Assurance * Prog. Dir., MSc & BSc in Info. Assurance
* CTO, Online Graduate Programs
http://www.msia.norwich.edu/overview.htm http://www2.norwich.edu/mkabay/bsia
Norwich University, Northfield VT V: +1.802.479.7937 mkabay@private
* Network World Fusion Security Newsl http://www.nwfusion.com/newsletters/sec
------------------------------
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 24.06
************************
This archive was generated by hypermail 2.1.3 : Wed Oct 05 2005 - 11:04:53 PDT