RISKS-LIST: Risks-Forum Digest Monday 14 May 2007 Volume 24 : Issue 66
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.66.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Browns Ferry 3 nuclear power site scrammed (PGN)
Reactors, remotely defended (Wendell Cochran)
Unit confusion caused fatal chemotherapy overdose (Mark Brader)
Error in climate data recording software (Charles Perrow via Martyn Thomas)
Another sat-nav accident: car destroyed, driver escapes (Mark Brader)
Touch typing (Jim Horning)
NZ fisheries "ruler" short (George Michaelson)
TSA Loses Hard Drive With Personal Info (PGN)
Internet2 Knocked Out By Homeless Man? (Chris Hodge via Dave Farber)
Ed Felten: You Can Own an Integer Too - Get Yours Here (Monty Solomon)
More on the bogus Canadian "spy coin" (Jim Horning)
Re: Impossible data requested (Gillian Brent)
Re: Automatic translation leads to ethnic slur (Tony Ford)
An interesting phishing risk... (Craig DeForest)
Microsoft sets the wrong time in the PC's real time clock chip (Len Spyker)
Re: US Daylight Saving Issues (Nick Bender, John Levine, Joseph Barrett)
First Usenix Workshop on Offensive Technologies: WOOT 07 (Tal Garfinkel)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 8 May 2007 10:58:28 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Browns Ferry 3 nuclear power site scrammed
This is another example of a system environment in which components that
were supposedly not safety related could compromise safety. The case is of
considerable interest to RISKS.
On 19 Aug 2006, operators manually scrammed Browns Ferry, Unit 3, following
a loss of both the 3A and 3B reactor recirculation pumps, as required after
the loss of recirculation flow -- which placed the plant in a high-power,
low-flow condition where core thermal hydraulic stability problems may exist
at boiling-water reactors (BWRs). Generally, intentional operation is not
permitted under this condition. Although some BWRs are authorized for
single loop operation, sudden loss of even one pump could present the plant
with the same stability problems and could result in the reactor protection
system initiating a shutdown of the plant. [Source: Effects of
Ethernet-based, Non-safety Related Controls on the Safe and Continued
Operation of Nuclear Power Stations, United States Nuclear Regulatory
Commission, Office of Nuclear Reactor Regulation, Washington, DC 20555-0001,
17 Apr 2007; PGN-ed, although the following text is abridged but unedited.]
http://www.nrc.gov/reading-rm/doc-collections/gen-comm/info-notices/2007/in20075.pdf
The initial investigation into the dual pump trip found that the
recirculation pump variable frequency drive (VFD) controllers were
nonresponsive. The operators cycled the control power off and on, reset the
controllers, and restarted the VFDs. The licensee also determined that the
Unit 3 condensate demineralizer controller had failed simultaneously with
the Unit 3 VFD controllers. The condensate demineralizer primary controller
is a dual redundant programmable logic control (PLC) system connected to the
ethernet-based plant integrated computer system (ICS) network. The VFD
controllers are also connected to this same plant ICS network. Both the VFD
and condensate demineralizer controllers are microprocessor-based utilizing
proprietary software.
The licensee determined that the root cause of the event was the malfunction
of the VFD controller because of excessive traffic on the plant ICS network.
Testing by site personnel performed on the VFD controllers confirmed that
the VFD control system is susceptible to failures induced by excessive
network traffic. The threshold levels for failure of the VFD controllers due
to excessive network traffic, as determined by the on-site testing, can be
achieved on the existing 10-megabit/second network. The NRC staff's review
of industry literature and test reports on network device sensitivity, and
the threshold levels for such failures, confirmed these testing results. The
licensee could not conclusively establish whether the failure of the PLC
caused the VFD controllers to become nonresponsive, or the excessive network
traffic, originating from a different source, caused the PLC and the VFD
controllers to fail. However, information received from the PLC vendor
indicated that the PLC failure was a likely symptom of the excessive network
traffic.
To ensure that excessive network traffic will not cause future Unit 3 VFD
controller malfunctions, the licensee disconnected these devices from the
plant ICS network before restart. The licensee also disconnected the Unit 2
VFD controllers from the plant ICS network.
Licensee corrective actions included (1) developing a network firewall
device that limits the connections and traffic to any potentially
susceptible devices on the plant ICS network and (2) installing a network
firewall device on each unit -- VFD controller and condensate demineralizer
controller. The Browns Ferry Unit 3 event is discussed in Licensee Event
Report 05000296/2006-002, dated October 17, 2006, Agencywide Documents
Access and Management System, Accession No. ML062900106.
The reason the licensee at Browns Ferry investigated whether the failure of
one device, the condensate demineralizer PLC, may have been a factor in
causing the malfunction of the VFD controllers is that there is
documentation of such failures in commercial process control. For instance,
a memory malfunction of one device has been shown to cause a data storm by
continually transmitting data that disrupts normal network operations
resulting in other network devices becoming locked up or nonresponsive. A
network found to be operating outside of normal performance parameters with
a device malfunctioning can effect devices on that network, the network as a
whole, or interfacing components and systems. The effects could range from a
slightly degraded performance to complete failure of the component or
system. Major contributors to these network failures can be the addition of
devices that are not compatible, network expansion without a procedure and a
overall network plan in place, or the failure to maintain the operating
environment for legacy devices already on the network.
While only non-safety related network devices became nonresponsive at Browns
Ferry Unit 3, it is important to protect both safety-related and non-safety
related devices on the plant network to ensure the safe operation of the
plant. The 19 Aug 2006, transient unnecessarily challenged the plant safety
systems and placed the plant in a potentially unstable high-power, low-flow
condition. The potential safety implications for future similar events would
depend on the type of devices that are connected to the plant ethernet.
Careful design and control of the network architecture can mitigate the
risks to plant networks from malfunctioning devices, and improper network
performance, and ultimately result in safer plant operations.
------------------------------
Date: Thu, 26 Apr 2007 20:01:22 +0100
From: Wendell Cochran <atrypa@private>
Subject: Reactors, remotely defended
In *The New York Times*, 25 Apr 2007, a headline (A22, National Edition)
reads 'U.S. Takes Step to Address Airliner Attacks on Reactors'.
The agency was the Nuclear Regulatory Commission; its 'step' was to urge
that reactor designers seek to mitigate the effects of suicide attacks 'to
the extent practicable' -- rather than to aim for 'the capability to
withstand the effects of an aircraft crash.'
'Mitigate' vs 'withstand' is being debated, with one mitigator among the
commissioners citing difficulty in making cost-benefit analyses based on
speculation about probabilities.
The story goes on to say 'By the time new plants are actually built, he
added, the aircraft industry may have solved the problem by installing
equipment to control planes remotely in case of hijacking.'
It may be that the commissioner does not read RISKS.
------------------------------
Date: Thu, 10 May 2007 18:38:01 -0400 (EDT)
From: msb@private (Mark Brader)
Subject: Unit confusion caused fatal chemotherapy overdose
The Alberta Cancer Board has released a report into the death of patient
Denise Melanson last August due to an accidental overdose of the
chemotherapy drug fluorouracil. The prescription gave the dosage as "5,250
mg (at 4,000 mg/m2) intravenous once continuous over 4 days" and then as
"baseline regimen 1,000 mg/m2/day = 4,000 mg/m2/4 days". The m2 here
apparently refers to the total area of the patient's skin and explained how
the dose in mg had been calculated rather than how it was to be
administered.
To administer the drug, a nurse loaded it into a portable infusion pump.
The drug label would have read "Final Concentration: 45.57 mg/mL; Dose: 5250
mg/4 days (1312.5 mg/24h); Rate: 28.8mL/24h (1.2mL/h)". The pump had
several options to program the rate of flow, but none of them involved a
rate per day. The nurse selected milliliters per hour, and recalculated the
rate herself, but forgot to convert days to hours, and typed in the number
for mL/day, which she saw on the label.
For some other drugs 28.8 mL/h would have been a plausible amount, but with
fluorouracil it was fatal. Another nurse checked the arithmetic, partly
mentally, and did not spot the error. The problem was only realized when
the drug supply ran out, and then it was too late. The fact that the pump's
user interface said "mL" when it meant "mL/h" cannot have helped.
The report summarizes the causes as: "miscalculation; opportunity for false
confirmation on label; information required to program pump not part of
medication administration record; double check process failed; complex
workload and multitasking; no feedback from pump; and low knowledge of
hazard."
This is not the first time this sort of thing has happened, and the report
details some of the other ones as well as making recommendations for
improved procedures.
News media reports:
http://www.cbc.ca/cp/health/070508/x050819A.html
http://www.theglobeandmail.com/servlet/story/LAC.20070509.OVERDOSE09/TPStory/National
Cancer Board report (PDF, and curiously marked "Privileged and Confidential"
on every page):
http://www.cancerboard.ab.ca/NR/rdonlyres/D92D86F9-9880-4D8A-819C-281231CA2A38/0/Incident_Report_UE.pdf
------------------------------
Date: Thu, 03 May 2007 07:54:41 +0100
From: Martyn Thomas <martyn@thomas-associates.co.uk>
Subject: Error in climate data recording software
Charles Perrow noticed this:
>From the latest Nature: 447, p 7140
In 2006, data from the array led a team of scientists to the surprising
conclusion that the world's oceans had cooled during 2003 exceptionally warm
years in terms of global surface temperature. The team published its
findings in Geophysical Research Letters1. Such apparent cooling was seized
on by people keen to highlight the uncertainties in forecasts of global
warming2.
That cooling has now been shown to be an artefact. In some of the buoys --
they are manufactured in separate batches -- a software glitch caused the
temperature and salinity data to be associated with the wrong depths. When
the problem data are excluded from the analysis, the cooling trend drops
below the level of statistical significance.
------------------------------
Date: Sat, 12 May 2007 01:05:30 -0400 (EDT)
From: msb@private (Mark Brader)
Subject: Another sat-nav accident: car destroyed, driver escapes
Accepting satellite-navigation directions without sufficient thought has
caused another accident. A young woman in Great Britain followed its
directions onto a country lane which was blocked by a gate. At first she
thought it was a dead end, she said, but "the sat nav insisted it was the
correct way so I opened it and drove through."
After the first gate there was a second one, so she got out to close the
first gate and open the second one, apparently not thinking about why there
might be two gates across a road, or why there was a sign saying to proceed
"if the light is green". (None of the news reports I found says any more
about that light than that the sign existed.)
And while she was out of her car, a train came along the tracks and
demolished it.
http://news.bbc.co.uk/2/hi/uk_news/wales/south_west/6646331.stm
http://icwales.icnetwork.co.uk/0100news/0200wales/tm_headline=sat-nav-guides-driver-into-path-of-train&method=full&objectid=19083438&siteid=50082-name_page.html
http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2007/05/11/nsatnav11.xml
http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=453991&in_page_id=1770
------------------------------
Date: Wed, 25 Apr 2007 11:50:10 -0700
From: Jim Horning <Jim.Horning@private>
Subject: Touch typing
I have long been a fluent touch typist. I consider Typing to have been the
high-school course that has been most useful during my professional career.
Early this year I started noticing increasing problems with my typing.
Sometimes characters would be dropped. As many as half of them. When
things got bad, even if I slowed down and typed a single character at a
time, I lost quite a few. I was sometimes reduced to a mode of typing a
character, seeing if it appeared on the screen, and then either typing it
again or proceeding to the next character. I found this quite distressing.
Initially, I thought it might be my keyboard, since I'd fairly recently
acquired a new ergonomic keyboard. However, swapping the old keyboard back
in didn't help.
I thought maybe I'd done something to mess up my software configuration, but
checking all the settings I could think of that might be relevant didn't
turn up anything out of the ordinary, and none of the changes I tried seemed
to help. (Deleting Temporary Internet Files did sometimes seem to help a
little bit, as did exiting Internet Explorer and restarting it.)
I found that I had the same problem on both my home and office computers,
which made it seem unlikely that it was a problem with my hardware.
The problem seemed most acute when using Blogger, but checking the Help and
searching the Web turned up no indication that anyone else was seeing this
problem with Blogger. And it didn't only happen when I was using Blogger.
By this time I had to consider the possibility that the common factor was
me. My neurologist ran some tests, and concluded that this was NOT
peripheral neuropathy affecting my fingers (although I did have a mild case
of Carpal Tunnel Syndrome that cleared up very quickly wearing wrist splints
at night).
The penny dropped yesterday during a frustrating session creating a new blog
post: I realized that the typing problem had started when I converted to
Internet Explorer version 7, with its feature of "tabbed browsing," which I
rather like. I typically have four to ten tabs open at any given time, more
when I'm looking for information and links to put into my blog posts. The
troublesome combination was typing into an IE form (e.g., the Blogger
editor) while having a large number of tabs open.
I quickly tested this by opening a second IE window with only a single tab
for Blogger, leaving the other window on the screen with all its tabs still
open. Glory be! I could touch-type at my old speed once again!
It appears that IE 7's input de-multiplexing routine is so inefficient that
it can't reliably keep up with a couple of characters per second when there
are more than about six tabs open, even on a dual-core Pentium D 3.40 GHz
processor with a 1 GB memory! This seems so preposterous to me that I'm
asking for other IE 7 users to do the experiment and let me know if they see
the same thing; alternatively, perhaps someone else can offer me a better
explanation.
[We have nothing to fear but Blogosphere. FDR-PGN]
------------------------------
Date: Mon, 7 May 2007 17:46:15 +0300
From: George Michaelson <ggm@private>
Subject: NZ fisheries "ruler" short
The New Zealand fisheries ministry handed out printed "rulers" to stick on
the edge of a boat, to have handy for measuring fish sizes. (If too small,
throw it back.) Unfortunately, the rulers were 20mm short.
http://www.abc.net.au/news/newsitems/200705/s1916683.htm
I'm wondering, with ABSOLUTELY NO EVIDENCE, given how print/production
cycles work nowadays, whether this maybe could have been a PDF file at some
point in its life, and that somebody forgot to un-check the option "shrink
to fit". Or, something close.
------------------------------
Date: Tue, 8 May 2007 16:48:46 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: TSA Loses Hard Drive With Personal Info
The U.S. Department of Homeland Security's Transportation Security
Administration reported that it had lost a portable computer hard drive
containing Social Security numbers, bank data, and payroll information for
about 100,000 employees from Jan 2002 to Aug 2005.
[Source: AP item in *The New York Times*, 5 May 2007]
http://topics.nytimes.com/top/reference/timestopics/organizations/t/transportation_security_administration/index.html?inline=nyt-org
------------------------------
Date: May 2, 2007 11:42:02 PM EDT
From: Chris Hodge <hodge@private>
Subject: Internet2 Knocked Out By Homeless Man? (via Dave Farber's IP)
http://techdirt.com/articles/20070502/171657.shtml
http://www.networkworld.com/news/2007/050207-internet2-fire.html
The news today is that a homeless man in Boston tossed a cigarette on a
mattress, setting off a two-alarm fire that happened to knock out the
Internet2 connection between New York and Boston.
------------------------------
Date: Tue, 8 May 2007 09:09:03 -0400
From: Monty Solomon <monty@private>
Subject: Ed Felten: You Can Own an Integer Too - Get Yours Here
Ed Felten, 7 May 2007, http://www.freedom-to-tinker.com/?p=1155
Remember last week's kerfuffle over whether the movie industry could own
random 128-bit numbers? (If not, here's some background: 1, 2, 3)
Now, thanks to our newly developed VirtualLandGrab technology, you can own a
128-bit integer of your very own.
Here's how we do it. First, we generate a fresh pseudorandom integer, just
for you. Then we use your integer to encrypt a copyrighted haiku, thereby
transforming your integer into a circumvention device capable of decrypting
the haiku without your permission. We then give you all of our rights to
decrypt the haiku using your integer. The DMCA does the rest. ...
------------------------------
Date: Mon, 7 May 2007 18:33:00 -0700
From: Jim Horning <Jim.Horning@private>
Subject: More on the bogus Canadian "spy coin" (Re: RISKS-24.55,56,57)
The bogus report of Canadian "poppy quarters" with embedded radio-frequency
transmitters apparently resulted because several different U.S. Army
contractors traveling in Canada filed confidential espionage memos. The
coins showed a red poppy overlaid on the Canadian maple leaf, where the red
poppy had a protective coating that looked like a microscopic wire mesh
"that looked like nano-technology." About 30 million coins were minted,
commemorating Canada's 117,000 war dead. The AP managed to obtain redacted
Secret NoForn government documents under the U.S. Freedom of Information
Act. [PGN-ed]
http://news.yahoo.com/s/ap/20070507/ap_on_go_ot/spy_coins
[Ted Bridis article also noted by Kelly Bert Manning. PGN]
http://www.cbc.ca/cp/Oddities/070507/K050723AU.html
------------------------------
Date: Fri, 20 Apr 2007 16:08:59 +1000
From: reynardo@private
Subject: Re: Impossible data requested (RISKS-24.64)
Residents of Australia have long known to add a fake 0 to the beginning of
their 4 digit post code to allow ordering from US-centric online ordering
companies.
But spend a moment in thought for the residents of Tristan da Cunha, in the
middle of the Atlantic ocean, who only 2 years ago were allocated the UK
post code (TDCU 1ZZ) to make it easier for the residents to order goods
online.
(Information from Wikipedia, confirmed by other sources).
Gillian Brent, Matraville, NSW 2036
------------------------------
Date: Mon, 30 Apr 2007 18:51:01 +0100
From: "Tony Ford" <tony.ford@private>
Subject: Re: Automatic translation leads to ethnic slur (Epstein, RISKS-24.65)
The posting from Jeremy Epstein on 20 April illustrates a particularly
egregious example. However, the fact remains that across the world false
economies are constantly being made through commercially or otherwise
important brochures, menus, product brochures, web pages etc being
translated 'on the cheap'.
It seems that some businesses and organisations will persist in shutting
their eyes to the impression that they make when they release cringe-making
or even sub-standard translations of their flagship written output.
The RISK is a reputational one, I guess: as they say, it takes a long time
to establish a good reputation but it can be lost extremely fast.
(Here, although a computer translation program may have facilitated the
event, at least it was not a case of GIGO. )
Tony Ford, Guildford, Surrey, UK
------------------------------
Date: Thu, 19 Apr 2007 17:06:39 -0600
From: Craig DeForest <deforest@private>
Subject: An interesting phishing risk...
Today, I received a call -- on my cell phone -- from a voice synthesizer.
It claimed to be from my bank, and asked me to verify my identify by typing
the last four digits of my social security number. Of course, I hung up.
Since those four digits are so useful for authenticating all manner of
bank-by-phone transactions, I can imagine a nice phishing scheme: penetrate
an online store's customer database (thereby getting names, phone numbers,
and credit card numbers -- which themselves contain bank information) and
then autocall every single one and ask for account passwords and/or social
security numbers. Step 3: profit!
I wrote to my bank (Elevations Credit Union) expressing my sincere hope that
it wasn't them, but I have a sinking feeling it was.
------------------------------
Date: Mon, 14 May 2007 12:54:34 +0800
From: Len Spyker <lspyker@private>
Subject: Microsoft sets the wrong time in the PC's real time clock chip
The MS design error and the risk:
Microsoft has always set your PC RTC (realtime clock chip) to the "Local
Time" and not to UTC as unix and others do.
It then applies rules to correct that actual chips RTC time (again and
again) during your daylight saving transitions.
This fundamentally broken idea results in a correction function with two
possible time answers at the time shift boundary overlap.
Hence the ban on rebooting your PC multiple times in such and an overlap
period, as would force multiple time shifts!
However, if the RTC chip stored UTC and applied a UTC local time offset
correction factor, then there is never ambiguity.
Even with VISTA WOW our wizards at Microsoft will apparently not fix this
stupidity as no doubt it would break a few thousand apps.
------------------------------
Date: Thu, 26 Apr 2007 10:23:52 -0400
From: "Nick Bender" <nbender@private>
Subject: Re: US Daylight Saving Issues ...
> I have no idea if the various patches I've applied to the systems I've been
> using have been applied only to the operating system, the C Run time
> libraries, or only half, and making sure that they are only applied once and
> not multiple times.
This is not likely a result of anything you have done.
DST under Windows (all versions) is fundamentally broken. The way they chose
to implement the time change is to adjust *all* dates by one hour when DST is
in effect.
Try this simple test:
1. Set your system time to the day before a time change.
2. Create a file and observe the timestamp.
3. Set your system time to the day after a time change.
4. Observe the timestamp on your file.
The time stamp will be one hour different after the time change.
This applies to *all* timestamps on *all* your files.
This also applies to *all* the entries in your event logs.
This is by design and is not likely to change. Ever.
This is a know problem (see http://catless.ncl.ac.uk/Risks/22.35.html#subj10
for example).
> I think that this US DST switch is going to continually bite us in small
> ways for several years. The only solution I see is to operate computers on
> UCT without any time zone translation enabled, which isn't really a viable
> solution.
The first statement may be correct but not in the way you mean. The second
statement is correct in general with respect to Windows systems.
I cannot say for certain not having looked at the code but I can only assume
that products such as Outlook/Exchange which do calendaring which must be
correct across time changes have entire libraries of code to deal with this
issue outside of the standard Windows system libraries. Maybe someone who
knows can enlighten the rest of us....
------------------------------
Date: 26 Apr 2007 14:35:11 -0000
From: John Levine <johnl@private>
Subject: Re: US Daylight Saving Issues (Bonner, RISKS-24.64)
> ... the process should be data driven, through a configuration file.
All of the time conversion software I'm aware of these days is indeed driven
by configuration files. But every time they change the DST rules, the
config files have to change, leading to exactly the software distribution
problems everyone has been noting.
John Levine, johnl@private, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
------------------------------
Date: Tue, 24 Apr 2007 22:59:46 -0700
From: Joseph <joseph_barrett@private>
Subject: Re: US Daylight Saving Issues (Jones, RISKS-24.65)
Jones alleges that Microsoft keeps system clocks in UTC instead of local
time (incorrect for versions 3.0, 3.1, 3.11 (WFW), 95, 95 OSR 2, 98, 98 SE,
NT 4.0, 2000, and XP); all of which set hardware clock to local time, as
shown in BIOS.
The suggested use of UTC and a translation configuration file is actually
typical of Unix/Linux/similar; not MS.
What risks do you see here?
------------------------------
Date: Tue, 1 May 2007 21:38:40 -0700
From: "Tal Garfinkel" <talg@private>
Subject: First Usenix Workshop on Offensive Technologies: WOOT 07
Got a good attack paper in the works?
In concert with the 2008 Usenix Security Symposium, we are putting on a
Workshop On Offensive Technologies (WOOT). It is intended to pull in folks
from a wide range of academic and industry communities to explore the state
of the art in attack technologies in a high quality, peer reviewed setting.
Topics include:
* Vulnerability research (software auditing, reverse engineering)
* Penetration testing
* Exploit techniques and automation
* Network-based attacks (routing, DNS, IDS/IPS/firewall evasion)
* Reconnaissance (scanning, software, and hardware fingerprinting)
* Malware design and implementation (rootkits, viruses, bots, worms)
* Denial-of-service attacks
* Web and database security
* Weaknesses in deployed systems (VoIP, telephony, wireless, games)
* Practical cryptanalysis (hardware, DRM, etc.)
Submissions are due June 7th, check out the call for papers at:
http://www.usenix.org/events/woot07/cfp/
------------------------------
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.66
************************
This archive was generated by hypermail 2.1.3 : Mon May 14 2007 - 12:33:18 PDT