RISKS-LIST: Risks-Forum Digest Friday 26 May 2006 Volume 24 : Issue 29
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.29.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Amtrak halted by power failures (Patrick McGeehan via PGN)
Vast Data Cache About Veterans Has Been Stolen (Monty Solomon)
NASA's DART spacecraft smashes into satellite (Alicia Chang via PGN)
Predator UAV crash: switchology mistake (Mark M. Newton)
Expensive Australian navy avionics development failure (Rodney Polkinghorne)
Premiere of new opera delayed by computer malfunction (Mark Bartelt)
Planes, Trains, wait, did that sign say what I think it just said?
(Trevor Paquette)
National Weather Center - Surface Winds from Bad Data (Ben Kamen)
Over-reliance on satellite navigation causes near-tragedy, again
(Omri Schwarz)
Mandated Data Retention: Noble Goals With Evil Outcomes (Lauren Weinstein)
Comcast outage leaves customers without TV, Internet & Phone service
(Tim Duncan)
Misunderstanding the risks of SSNs (Jeremy Epstein)
Re: Another near-disaster due to vehicle automation (Mary Shafer)
Re: Triple DES Upgrades May Introduce New ATM Vulnerability (Stephen Kent)
Re: RFID zappers: zappers are not a new problem (Jerome Svigals)
Re: Spelling (Dale Gombert)
Re: Man Gets $218 Trillion Phone Bill (Barry Gold)
Workshop on Trustworthy Elections: WOTE 2006 (Peter Ryan)
Electronic Voting Technology Workshop at USENIX Security (PGN)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Fri, 26 May 2006 09:11:12 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Amtrak halted by power failures notsp
In the morning rushhour of 25 May 2006, circuit breakers cut out at 7:55am
in Maryland, then in Queens, then in Philadelphia. By 8:03, Amtrak, New
Jersey Transit, and (Baltimore-Washington) MARC trains were coasting to a
standstill (without air conditioning, overhead lights, etc.). Four trains
were stranded in the tubes under the Hudson River, another in a tunnel in
Baltimore. By evening, Amtrak officials were still unable to locate the
triggering event, although it was noted that some of the electrical
transmission equipment dates to the 1930s. Service was expected to return
to normal on 26 May. The impact on commuters was of course severe.
[Source: Patrick McGeehan, *The New York Times*, national edition, 26 May
2006, C12; PGN-ed; Just one more reminder of the risks relating to an
inadequately commitment to public transit, and the continued ability of
single point failures to propagate? PGN]
------------------------------
Date: Tue, 23 May 2006 00:51:29 -0400
From: Monty Solomon <monty@private>
Subject: Vast Data Cache About Veterans Has Been Stolen
Personal electronic information on up to 26.5 million military veterans,
including their names, Social Security numbers, and birth dates, was stolen
from the residence of a Department of Veterans Affairs employee who had
taken the data home without authorization. [Comments about no evidence of
data misuse (yet) and no health/financial records, but deeply embarrassing
to VA. No mention of a statement that this incident was not reported for
several weeks. The previous CardSystems Solutions breach in June 2005 was
noted, affecting 40 million credit-card accounts. [Source: David Stout and
Tom Zeller Jr., *The New York Times*, 23 May 2006 PGN-ed; yet another ...]
http://www.nytimes.com/2006/05/23/washington/23identity.html?ex=1306036800&en=eb1c02a63fedca31&ei=5090
------------------------------
Date: Tue, 16 May 2006 15:13:15 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: NASA's DART spacecraft smashes into satellite
NASA's 800-pound Demonstration for Autonomous Rendezvous Technology (DART)
spacecraft was supposed to circle a defunct orbiting Pentagon satellite. A
report released on 15 May 2006 indicates that DART moved to within 300 feet
of the satellite 472 miles above Earth, and then lost control -- crashing
into the satellite. The report says the collision was based on faulty
navigational data from the main sensor that caused DART to "believe that it
was backing away from its target" rather than approaching. Investigators
concluded that DART had determined that it had spent too much fuel on the
approach, because of the inaccurate data, and was in the process of shutting
down when it collided. The investigation also concluded that the evaluation
of fuel consumed was also in error (overestimated), and also faulted the
mission's management style, lack of training and experience, avoidance of
expert advice, and lack of internal checks and balances. [Source: Alicia
Chang, AP item, Newsday, 15 May 2006; PGN-ed. Thanks to Lauren Weinstein
for spotting this one. PGN]
http://www.newsday.com/news/nationworld/wire/sns-ap-spacecraft-mishap,0,4358085.story?coll=sns-ap-nationworld-headlines
------------------------------
Date: Fri, 26 May 2006 04:56:10 GMT
From: "Mark M. Newton" <newton06262@private>
Subject: Predator UAV crash: switchology mistake
The National Transportation Safety Board has released a preliminary report
on the 25 Apr 2006 crash of a Predator UAV while on U.S. border patrol.
"The pilot reported that during the flight the console at PPO-1 'locked up',
prompting him to switch control of the UAV to PPO-2. Checklist procedures
state that prior to switching operational control between the two consoles,
the pilot must match the control positions on the new console to those on
the console, which had been controlling the UAV. The pilot stated in an
interview that he failed to do this. The result was that the stop/feather
control in PPO-2 was in the fuel cutoff position when the switch over from
PPO-1 to PPO-2 occurred. As a result, the fuel was cut off to the UAV when
control was transferred to PPO-2."
http://www.ntsb.gov/NTSB/brief.asp?ev_id=20060509X00531&key=1
------------------------------
Date: Mon, 15 May 2006 09:59:16 +1000
From: Rodney Polkinghorne <rodneyp@private>
Subject: Expensive Australian navy avionics development failure
Dr. Brendan Nelson, Australia's minister for defence, has considered
"getting out of" a billion dollar purchase of Super Seasprite helicopters,
because "You could not have 100 per cent confidence in the software
program that supports the pilot flying the helicopter to 100 per cent
safety". He has upheld the ANZAC tradition of blaming the imperial
overlords, US firm Kaman Aerospace and their subcontractors.
Full story in "The Australian" of 15th May 2006, online at
<http://www.theaustralian.com.au/story/0,20867,19136512-601,00.html>.
Full disclosure: the author is a postgraduate student at an Australian
university, and Dr Nelson was minister for education before he became
minister for defence.
[Dr. Nelson is obviously also not a RISKS reader, or he would have ample
evidence that "100% confidence" in a software program -- or even worse, in
the system in which it resides -- is impossible. PGN]
------------------------------
Date: Thu, 25 May 2006 16:24:49 -0700 (PDT)
From: Mark Bartelt <mark@private>
Subject: Premiere of new opera delayed by computer malfunction
The Los Angeles Opera was supposed to have been presenting the world
premiere of *Grendel*, a new opera by Elliot Goldenthal this Saturday.
Unfortunately, computer problems have forced a delay. A press release
issued today says ...
"The technical rehearsals ceased on 23 May when computer malfunctions caused
a large pivoting platform, central to scenery designer George Tsypin's
large-scale set, to stop working, causing the platform's internal mechanisms
to break. The platform, which uses 28 individually operating motors to move
horizontally and vertically and pivot a full 360 degrees at a variety of
speeds, must bear the weight of up to 15 performers at a time. Solving the
malfunction of the computer system and correcting the failure has severely
compromised the rehearsal time necessary for the success of the production,
which demands extensive technical work."
http://www.metoperafamily.org/operanews/news/pressrelease.aspx?id=1189
http://www.losangelesopera.com/pdf/press_release/Grendel%20opening%20postponed.pdf
------------------------------
Date: Fri, 5 May 2006 10:16:34 -0600
From: "Trevor Paquette" <Trevor.Paquette@private>
Subject: Planes, Trains, wait, did that sign say what I think it just said?
>From the CBC link at: http://www.cbc.ca/toronto/story/to-gotransit20060502.html
Risks of an unprotected public electronic sign should be obvious...
GO Transit signs insult PM, CBC News, 2 May 2006
Technicians with GO Transit are working to make its electronic message
boards hacker-proof after the scrolling signs were programmed to read
"Stephen Harper Eats Babies" over and over again. Officials say someone
used an inexpensive remote-control device to tamper with the narrow
advertising signs installed in the system's trains along the
Hamilton-Toronto route. The message was seen on Thursday and Friday, and
appeared again on three separate signs on Monday.
Gerry Nicholls, one of the commuters who reported seeing the message, told
the *Toronto Star* he thought he was "hallucinating" when he read it. None
of the other commuters on the packed train seemed to react to it at, he
said. As it happens, Nicholls is vice-president of the National Citizens
Coalition, the conservative think-tank formerly headed by the prime
minister. "I worked with Stephen Harper for five years and never once did
he, in that time, eat a baby," he told the newspaper.
Text messages destined for the scrolling signs are transferred from a
computer to hand-held, remote control device that retails for less than
$25. GO Transit employees then move from car to car with the device,
transmitting the messages to the signs. GO Transit officials said they
bought the signs six years ago and they were not password protected. It is
the first time someone has hacked into the system, they said.
------------------------------
Date: Wed, 03 May 2006 12:53:32 -0500
From: Ben Kamen <bkamen@private>
Subject: National Weather Center - Surface Winds from Bad Data
Being a pilot and armchair meteorologist, I woke up Tuesday morning and did
what I do every morning. I check the weather. I have various sinks
bookmarked and one of my favorites is the ADDS system at
http://adds.aviationweather.gov/
They have a Winds/Temps page at: http://adds.aviationweather.gov/winds/ for
which yesterday morning (Tuesday) the surface winds map showed this:
http://www.benjammin.net/www/images/ruc00hr_sfc_wind.gif
(saved on my website because I saved the .gif and mailed it to the site
webadmins to let them know something was wrong even to my non-certified
meteorologist eyes)
They e-mailed back (rather promptly I might add) to let me know that in fact
the National Weather Service got bad data that morning and that the graphic
was in fact wrong. NWS was working on fixing it.
Of course there was no mention on the website that something was awry with
what I was seeing, but my own brain told me - "I don't think so!"
Thus, an interesting failure of mechanisms that gather data and transform it
into useful images for the rest of us. Mechanisms that apparently have no
built-in method of error detection through a history of one input data set
to the next.
I just thought I would share with the rest of you.
Ben Kamen - O.D.T, S.P. ben@private http://www.benjammin.net
------------------------------
Date: Tue, 16 May 2006 16:14:20 -0400
From: "Omri Schwarz" <ocschwar@private>
Subject: Over-reliance on satellite navigation causes near-tragedy, again
How many times have we seen this? How many more times will we see this?
The North East Ambulance Service is equipped with satellite navigation,
which comes with the usual AI for giving driving directions. Said AI isn't
fully informed on roads too narrow for the ambulance model. Said AI selects
for short distances without factoring for traffic patterns and driving
speed. Result: long delayed arrival at an accident scene and a delayed
arrival at hospital afterward.
In this case the patient's mother offered to point out a better route, but
was not allowed. A rapid response team that arrived before the ambulance did
could have stayed with the ambulance and led a better route, but didn't.
[Source: British SATNAV service misdirects ambulance, *The Mirror*.
http://www.mirror.co.uk/news/tm_objectid=17083544&method=full&siteid=94762&headline=sham-bulance--name_page.html
Also noted by Joel Baskin, who included this pithy quote:
The service's patient forum said: ``SATNAV can be effective when used
with local knowledge. But it shouldn't be relied on by itself.''
PGN]
------------------------------
Date: Thu, 04 May 2006 09:27:36 -0700
From: Lauren Weinstein <lauren@private>
Subject: Mandated Data Retention: Noble Goals With Evil Outcomes
The irony of the situation relating to proposals for required data
retention, as I noted in:
http://lauren.vortex.com/archive/000175.html
is that many incredibly bad and dangerous concepts -- like
government-mandated data retention of this sort -- will virtually always be
linked to laudable ideas (like fighting child abuse) that we all agree are
important goals. A cynical view would be to assume that this is done
purposely to push "evil" laws using "noble" hooks. This clearly does happen
sometimes.
But I believe that in the majority of these cases we're dealing with
legislators and others who genuinely believe in their causes, and either
don't have the will or background to recognize or understand the horrible
collateral damage that their proposals would do.
Casting such persons as being purposefully evil is probably unproductive and
unfair. Instead, we need to help them see the "big picture," rather than
just the narrow focus of their good intentions.
For after all, the road to hell still does indeed remain paved with good
intentions.
Lauren Weinstein: +1 (818) 225-2800 http://www.pfir.org/lauren
http://lauren.vortex.com DayThink: http://daythink.vortex.com
------------------------------
Date: Sun, 21 May 2006 19:14:56 -0700
From: tim.duncan@private
Subject: Comcast outage leaves customers without TV, Internet & Phone service
Thursday, May 18th, I turned on my TV at 8:00 PM to catch the final episode
of "That '70s Show" only to find static. Checking another TV and finding
only static as well I reasoned my Comcast cable TV was out-of-service. I
tried calling comcast (800-COMCAST) to report the outage and only received a
message that there was an outage in my area (I think they use caller id for
this as I have received this message in the past when calling) and due to
unusually high call volume all representatives were busy.
Since Comcast already knew of the outage I expected it to be resolved in a
little while and decided to pay some bills and check e-mail while I waited.
Only then did I find out that my Comcast Internet was out as well. This is
the first time an outage has affected both services I receive from Comcast.
A few calls to friends and family confirmed that service was out all over
the Indianapolis area. Fortunately, as I was to find out later, my phone
service is not through Comcast as it appears that all of Comcast's phone
customers lost service as well.
It turns out a very localized power outage was to blame for the outage.
The Risk for customers? Putting too many eggs in one basket can cut you off
from the outside world in a hurry.
The Risk for Comcast? Never assume your backup generator will be there when
you need it. Test, test, test for power outages before they happen.
Some news reports of the outage:
http://www.indystar.com/apps/pbcs.dll/article?AID=/20060519/NEWS01/605190512
http://www.theindychannel.com/news/9242765/detail.html
------------------------------
Date: Tue, 16 May 2006 07:06:19 -0700
From: Jeremy Epstein <jeremy.epstein@private>
Subject: Misunderstanding the risks of SSNs
Interesting article on recent congressional testimony regarding use of SSNs:
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9000482&source=NLT_AM&nlid=1
I wasn't there, but based on the article there seems to be a serious
misunderstanding that the SSN is just fine as an *identifier*; the problem
is that it also gets used as an *authenticator*. Switching to a different
number (as the article discusses) that is used for both purposes will have
the same problem.
This quote sort of summed it up for me: "The Social Security number is the
only unique identifier in our country that enables a credit grantor, or a
credit bureau, or a bank, or an insurance company, or an investment firm to
be sure that the consumer they are doing business with" is legitimate,
according to Randy Lively Jr., CEO of the American Financial Services
Association. In other words, they're using it as both an identifier and an
authenticator.
Until Congress understands the problem, there's not much hope of solving it
through legislation.
------------------------------
Date: Thu, 04 May 2006 07:22:47 -0700
From: "Reunite Gondwanaland (Mary Shafer)" <reunite.gondwana@private>
Subject: Re: Another near-disaster due to vehicle automation (Norman, R-24.25)
> I still don't know enough about this class of potential accidents to offer
> definitive comment. But from what I can tell, automobile incidents will
> replace aircraft ones for the RISKS community. The more things change, ...
Once again, aviation was there first. I can't seem to find any details
after all these years, but there was an incident with, I think, a Fokker
airplane some years ago. I'm pretty sure I read about it in Flight
International and it happened in Europe (or, at least, not in the US).
The WOW (Weight On Wheels) switch didn't make when the plane touched down,
so the system wouldn't let the pilot throttle back. The pilot ended up
going off onto the taxiway and then going back around onto the runway before
bringing the plane to a halt, I think by pulling a circuit breaker. The
impression the article gave was of an airplane zooming around on the ground
while everyone else dove for cover.
I don't even think this was a fly-by-wire airplane, just one with safety
interconnects. Another bit of evidence illustrating why adding back-up
safety systems can make the entire system more dangerous. See Perrow on
"Normal Accidents", for example. The article about the ValuJet accident, in
Atlantic Monthly, was one of the best I've seen on this.
Mary Shafer Retired aerospace research engineer
reunite.gondwana@private or miliff@private
------------------------------
Date: Thu, 11 May 2006 17:17:05 -0400
From: Stephen Kent <kent@private>
Subject: Re: Triple DES Upgrades May Introduce New ATM Vulnerability
(Daley, RISKS-24.26)
Jim, I noticed your contribution to RISKS and just wanted to point out a
possible misunderstanding re how PINs are encrypted in ATM nets.
DES (or 3DES) keys are used in these nets to compute a message
authentication code (MAC) as an integrity and authentication check on a
transaction between and ATM and a bank. The PIN is then XORed with the MAC
to encrypt it. Thus one is not encrypting the PIN by passing it through the
DES/3DES algorithm, as your text suggested. Rather, the algorithm is
generating a pseudo-random bit string by virtue of being used to compute the
MAC on a transaction. Each transaction contains a serial number, ATM ID,
user account number, and other parameters that make the transaction likely
to be unique, relative to the key that is shared on a pairwise basis between
each ATM and a bank. Steve
------------------------------
Date: Mon, 1 May 2006 18:14:57 -0400
From: "smartcard@private" <smartcard@private>
Subject: Re: RFID zappers: zappers are not a new problem (RISKS-24.27)
The same challenge existed for magnetic striped cards in the form of magnets
and magnetic field devices. they didn't succeed for a few reasons:
1)zappers hesitated to attach when it inconvenienced them selves. 2) the
stripe or rf device is a pointer to a remote data base. after the zapping,
the remote data base is still easily accessible. 3) there are always
counterattacks to the zapping such as reduce range sensitivity and signal
shielding.
jerome svigals (father of the magnetic striped card).
------------------------------
Date: Thu, 11 May 2006 15:15:05 -0700
From: "Dale Gombert" <GOMBEDWG@private>
Subject: Re: Spelling
A note of some significance here in the Pacific Northwest is that a "Redd"
(pron. "redd") is a place salmon carve out of a stream bed to spawn. This
(perhaps more universal) definition does not show up on dictionary.com, but
a web search of "salmon redd" will supply many hits.
Dale Gombert <GombeDWG@private>, ITS4 WA Dept. Fish & Wildlife, Marine
Resources, 16018 Mill Creek Blvd., Mill Creek, WA 98012-1296 1-425-379-2317
[Also noted by Al Stangenberger, UCB Center for Forestry. PGN]
------------------------------
Date: Sun, 21 May 2006 06:34:09 -0700
From: Barry Gold <barrydgold@private>
Subject: Re: Man Gets $218 Trillion Phone Bill (Mathew, RISKS-24.27)
> Far more likely is that their billing system is written in COBOL, and uses
> BCD arithmetic.
I'm not impressed with the proposed representation. There is *no* advantage
to representing things in decimal. You are representing *numbers*, abstract
entities that exist independent of the base they are represented in. In
*any* fixed representation, there will be limits -- a largest (and smallest)
possible exponent, the maximum number of fractional bits/digits that can be
represented. This can lead to either of two errors:
* overflow: the number becomes too big for the representation
* precision loss: the fraction is too long for the system to represent, and
the least significant bits/digits are dropped, leading to rounding errors.
One example would be calculating interest. Say you advertise a rate of, say
2.75%, compounded daily. That means you need to divide .0275 by 365. The
result is an infinitely long repeating fraction, regardless whether you
express it in decimal or in binary. Decimal only provides an advantage if
you are dividing by 5 or 10, which produces a finite fraction in decimal
notation but an infinite one in binary.
If you want to represent numbers without loss of either significance
(overflow) or precision (rounding error), you can use any of several
package, you can write in Franz Lisp, which allows arbitrary-sized numbers
as a built-in type. Or you can use any of a number of arbitrary precision
packages available on the web. Just do a search for the words arbitrary
precision or rational arithmetic.
Using either of those techniques, you have _no_ loss of either precision or
significance(*) until the very end when you have to convert it to money
units for billing and round to the nearest cent. But that is inevitable
regardless of the representation you choose, an artifact of our monetary
system which has no unit smaller than one cent.
* Until you run out of memory, if your calculation goes on long enough
and the numerator and denominator get big enough.
------------------------------
Date: Fri, 12 May 2006 17:24:54 +0100
From: "Peter Ryan" <Peter.Ryan@private>
Subject: Workshop on Trustworthy Elections: WOTE 2006
Workshop On Trustworthy Elections (WOTE 2006) Robinson College,
Cambridge, United Kingdom June 29 - June 30, 2006
http://www.win.tue.nl/~berry/wote2006/
Held in conjunction with
6th Workshop on Privacy Enhancing Technologies Robinson College,
Cambridge, United Kingdom June 28 - June 30, 2006
http://petworkshop.org/2006/
Announcement and Call for Contributions
The workshop is organized by IAVoSS, the International Association for
Voting Systems Sciences, in association with the 6th Workshop on Privacy
Enhancing Technologies. It follows in the tradition of the series of
workshops devoted to cryptographic voting methods, such as WOTE '01, the
DIMACS Workshop 2004, FEE 2005, and the NeSC Workshop on e-voting and
e-democracy.
Scope and Objectives
Democracy and voting systems have received considerable attention of late,
with the validity of many elections around the world being called into
question. The US experience demonstrates that simply deploying technological
"solutions" does not solve the problem and can easily exacerbate it. The aim
of the workshop is to present and discuss promising technologies and schemes
to achieve high assurance of accuracy and privacy in the casting and
counting of votes.
The challenge is highly socio-technical in nature and requires an excellent
understanding of the potentialities and dangers of technological approaches
as well as an appreciation of the social, legal and political impact. The
workshop thus aims to bring together researchers and practitioners from
academia and industry as well policy makers, voting officials, whose work
relates to electronic voting systems, to evaluate the state of the art, to
share practical experiences, and to look for possible enhancements. The
overall aim then is to stimulate discourse between the various stakeholders
and enhance the understanding of voting technologies and practices.
[See full announcement for suggested topics. PGN]
The workshop will consist of invited keynote presentations and contributed
presentations. Panel discussions are also anticipated and submissions of
suitable topics, with or without a moderator or example participants are
welcome. The intention is is to encourage plenty of discussion and so work
in progress submissions are most welcome.
Accepted papers, abstracts and panel proposals will appear online. A
separate category of presentations, Informal Communications, encourages
preliminary ideas or status updates and requires only a short summary be
submitted that may even relate to submissions to other conferences.
Our intention is to publish a special edition of selected papers in a major
security journal. Acceptance of an extended abstract does not preclude
publication elsewhere. Submissions from PC members are welcomed.
There will also be an opportunity to demo systems and prototypes the evening
of Wednesday the 28th.
Contributions
To contribute a presentation, please submit an extended abstract summarizing
a technical contribution or a position paper summarizing your
research. Contributions will be selected by the expected interest in the
topic and the potential for stimulating exchange of ideas among the
participants. A submission must be a PDF file of at most 8 pages, in
letter-or A4-format, using at least 10pt fonts and no non-standard character
sets. Submissions should be sent as an attachment by e-mail to
peter.ryan@private
All submissions must be received by midnight (UK time) 2 Jun 2006.
Notification of acceptance will be sent by 9 June, 2006.
General Chair: Peter Ryan (University of Newcastle, UK)
Program Chairs: David Chaum (Votegrity, USA), Ron Rivest (MIT, USA)
P Y A Ryan
Professor of Computing Science
School of Computing Science
University of Newcastle
Newcastle upon Tyne NE1 7RU UK
Tel: +44 191 222 8972
Fax: +44 191 222 8788
peter.ryan@private
http://www.cs.ncl.ac.uk/people/peter.ryan
------------------------------
Date: Wed, 24 May 2006 16:37:11 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Electronic Voting Technology Workshop at USENIX Security
For those of you going to USENIX and interested in the voting issues, an
excellent workshop is being organized in conjunction with USENIX Security in
Vancouver, and will take place on 1 Aug 2006. The program and other
information are already online.
http://www.usenix.org/events/evt06/
------------------------------
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 [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.29
************************
This archive was generated by hypermail 2.1.3 : Fri May 26 2006 - 11:58:34 PDT