RISKS-LIST: Risks-Forum Digest Tuesday 29 March 2005 Volume 23 : Issue 82
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/23.82.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Times change ... problems don't (Michael Bacon)
Unintended consequences: CA data theft reporting (Steve Summit)
Even some major corporations don't understand domain names (Jonathan Leffler)
Re: Cruise-control failures? (Stanislav Meduna, Steve Loughran, Nick Brown,
Robert Scheidt, Ray Todd Stevens, Mark Brader)
Re: Don Norman: High is good? (Ken Knowlton)
Re: Computerized medical mistakes (Dave Brunberg, Bob Morrell, Richard Cook)
Re: More uses of satnav/GPS (Chris Smith)
Re: Remote physical device fingerprinting (David E. Ross)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Mon, 28 Mar 2005 10:49:11 +0100
From: "Michael \(Streaky\) Bacon" <himself@streaky-bacon.co.uk>
Subject: Times change ... problems don't
On 27 Mar 2005, the UK put its clocks forward one hour. This apparently
caused problems for Barclays Bank - one of the UK's leading banks - with
ATMs and other online services unavailable to customers in the South of the
country. The text of the Daily Telegraph's report on the failure is
reproduced below.
http://www.telegraph.co.uk/news/main.jhtml;sessionid=3D4HHCXBASXCNU5QFIQMGCM5WAVCBQUJVC?xml=3D/news/2005/03/28/nbarc28.xml&sSheet=3D/portal/2005/03/28/ixportal.html
I would be surprised if the bank relied upon the actions of a human to
change the time on its servers. For example, if the servers are not time
synchronised through an atomic clock receiver or from an NTP Time Server, it
begs serious questions regarding the time-standing of transactions.
Bi-annual time changes have been a part of computing at least since the
first commercial systems began processing. Surely 54 years is not too short
a time to have worked out the risks and put in place procedures to deal with
them.
If it was indeed a human error, perhaps the heading on the relevant page
should read: "Spring forward, fall back".
Another puzzling factor is that it apparently took 11 hours (4 am to 5 pm)
to determine and correct the problem. In my experience, the first thing to
be blamed is the last thing that was changed.
Michael 'Streaky' Bacon
Summer Time slip-up forces Barclays' cashpoints to close
*The Daily Telegraph*, 28 March 2005
Millions of Barclays customers were unable to withdraw money yesterday
after the bank's cashpoint network crashed amid claims that a duty manager
had accidentally put the clocks back instead of forward. More than 1,400
auto-tellers in the south of England and some on-line services were out of
order. Barclays customers were unable to withdraw money from any bank,
while cardholders with other banks were unable to use Barclays cash
machines.
The error came to light at 4am on 27 Mar 2005 when technicians noticed
that customers' personal details were not being forwarded to the computers
that control much of the bank's infrastructure. The problem was eventually
resolved at 5pm. Executives trying to determine the cause of the problem
admitted that a mistake during the switch to British Summer Time could
have been to blame. Customer services staff were less ambiguous. One
admitted: "A manager put the clocks back instead of forward and that has
caused enormous problems."
The bank's British network uses two servers based in Gloucestershire: one
for operations north of the Wash and the other to control operations in
the South. The Gloucester South server is understood to have been set one
hour back instead of forward. The bank conceded that an error over the
time change was to blame but denied that an individual manager made the
mistake. Alistair Smith, a spokesman for the bank, said: "It seems that
this problem may somehow be related to the time change, although I am told
it was not to do with someone making a mistake while manually changing the
time."
------------------------------
Date: Tue, 29 Mar 2005 12:27:39 -0500
From: Steve Summit <scs@private>
Subject: Unintended consequences: CA data theft reporting
A laptop computer containing names, SSNs, and some addresses and
birthdates for 98,369 alumni, grad students and applicants was stolen
from an office at UC Berkeley. In compliance with California's new
data-theft reporting law, the breach was reported and has now been
widely publicized -- although ironically, as a writeup on slashdot
points out, this publicity may have alerted the thief, who was probably
only interested in the hardware, to the true value of his find.
Links:
http://www.sfgate.com/cgi-bin/article.cgi?f=/n/a/2005/03/28/financial/f151143S80.DTL
http://yro.slashdot.org/article.pl?sid=05/03/29/036237
------------------------------
Date: Wed, 23 Mar 2005 23:17:49 -0800
From: Jonathan Leffler <jleffler@private>
Subject: Even some major corporations don't understand domain names
Case in point, the agreement (Enrollment E-Consent) you are asked to accept
when you sign up for Hertz #1 Gold membership - at
https://www.hertz.com/servlet/JoinProfileServlet?club=G
Right at the bottom, where your consent is sought, there's a footnote that
says:
* "Any Hertz rental website" or "the Hertz rental website" means any Hertz
website relating to vehicle rentals including, without limitation, all
websites with addresses which begin "www.hertz".
The relevant text, much further up the document, is:
Disclosures to You by Hertz
1. Summary of Your Consent. At the bottom of this page, after you have
reviewed these disclosures, you will be asked to give your consent
(your "Consent") to Hertz's use of an electronic record rather than
paper format to provide or make available to you the following
information (the "Information") via any Hertz rental website* or by
e-mail (collectively "Electronic Record(s)"), subject to the conditions
and other requirements discussed below:
I first noticed this several years ago - and reported it to the web master.
I don't recall getting any response, and the web site today shows that I
didn't get the message through to anyone.
Clearly, if I own a domain bogus.tld, I can create a www.hertz.bogus.tld
site and there's nothing to stop Hertz using any information submitted
there - I'm not sure how they'd get hold of information submitted to my
hypothetical web site. It'd be cute mistake for a Mom'n'Pop outfit to
make; it is more serious when it's a major international corporation that
is suffering from technical myopia.
Jonathan Leffler Guardian of DBD::Informix v2005.01 -- http://dbi.perl.org/
jleffler@private, jleffler@private
------------------------------
Date: Mon, 28 Mar 2005 22:40:55 +0200
From: Stanislav Meduna <stano@private>
Subject: Re: Cruise-control failures? (Scheidt, RISKS-23.81)
> I wonder if somebody on this board has some insight on how the electronic
> controls of modern cars are designed
AFAIK technically it is a distributed control system with quite many
relatively independent units communicating through a bus (typically CANbus).
> and especially if a single component's failure (such as a common
> microprocessor) could affect multiple functions (e.g., acceleration and
> brakes).
The various ESPs (electronic stability programs) are able to reduce engine
power and apply selective braking on some wheels in order to stabilize the
vehicle. So there already is something that can give commands to both the
brakes and the engine. I have no idea how (im-)probable is that kind of
failure mode, though.
------------------------------
Date: Tue, 29 Mar 2005 20:34:49 +0100
From: Steve Loughran <steve.loughran@private>
Subject: Re: Cruise-control failures? (Scheidt, RISKS-23.81)
In RISKS-23.81, Robert Scheidt expresses doubt that a hung cruise
control system would stop braking, in "Cruise-control failures"
I can't assess that, but I do know that the handbrake/parking brake on a
2004 Renault Scenic is CPU controlled, by the system that manages the
ignition.
When you pull out the 'ignition card", the parking brake engages
automatically. There is also a handle you can pull below/left of the
steering wheel, which sends a request to turn parking on. There was a bit of
a lag engaging, as I recall from my weeks rental, say 0.5s or so.
How does it disengage? Well, there is the fun part. The parking brake
disengages when you drive off. This seems like a convenient feature, but was
certainly a disadvantage when I rented the car in the Alps for a week -even
without any of these 'cruise control failure' disasters.
The problem was simple: how do you turn round on a sloping mountain road
near grenoble, when the snow has got too deep for you to continue.
In a conventional car, the solution is the three-point turn, executed with
maximum care. You back up and turn, then go forwards, completing the turn.
This is actually a manouevre which is part of the UK driving test, albeit on
a flat road. To do it safely on a mountain road you need to
1. Make sure you are in a gear that is going in the correct direction, so
as not to drive off the edge of the (steep, unprotected) drop.
2. With a manual transmission, bring up the clutch slowly until the
transmission is engaged. This stops you slipping (the hill start), and
provides an extra cue that you have (#1) right.
3. Move off very gently as you release the handbrake. This is your final
sanity check.
The key point here is the failure mode "driving off the edge of the road" is
not something you want to encounter, nor is "sliding down the hill as you
set off".
Unfortunately, the Renault Scenic, with its automatic handbrake, doesn't let
you do any of these. You cant bring up the clutch under gentle acceleration
(check 2), as the handbrake comes off too early. The only way to do a hill
start is put your foot down enough to be sure that when the handbrake comes
off, you aren't go slide backwards. This eliminates any chance of making
sure that you are in the right gear through tentative car motions.
Let's just say I wasn't happy with the whole process. We did turn round
safely; I am writing this email. But I had to check and doublecheck the gear
lever settings before each step in the process, and it was no fun at all.
An interesting footnote is what would have happened if I'd got it wrong? I'd
have driven off a cliff and not been found until later in the spring. At
that time, I am sure the cause of the crash would have been attributed to
"driver error", and not system failure. This is so reminiscent of assigning
"pilot error" to any crash of an airplane with no obvious mechanical
cause. This is something that should be so familiar to RISKS readers, be it
related to A320 flight control systems. Chinook fog navigation, etc,
etc. Are we going to replicate these incidents with drive-by-wire car
control systems?
------------------------------
Date: Tue, 29 Mar 2005 15:13:56 +0200
From: "BROWN Nick" <Nick.BROWN@private>
Subject: Re: Cruise-control failures? (Scheidt, RISKS-23.81)
In any car that I have ever seen, cruise control has been an option
installed late in the assembly process. In some cases, the marketing
department has decreed that you can't buy the car without cruise control,
but it's not something that is generally built in "deep down" in the system.
Cruise control is typically a fairly dumb system - "all" you have to do is
to detect the current road speed and apply more or less pull on the throttle
cable to compensate. In all the cars which I have driven with cruise
control, you can feel the accelerator pedal drop slightly when you hit an
uphill climb. And cruise control after-market modules are widely available.
The basic brake system of "most" (all?) modern cars - certainly including
the Renault "Vel Satis" and "Laguna" models allegedly involved in the
widely-publicised cruise control issues - is essentially a very simple
hydraulic circuit. ABS, EBD, etc modules may be able to cut in and remove
pressure from the circuit momentarily, but you'll generally know about that
(at least in the case of ABS) from the noise. Aside from that, there's a
direct mechanical/hydraulic, cause-and-effect relationship between the brake
pedal and the wheels. Additionally, braking systems are designed so that
the force which can be applied exceeds the force which the engine can
provide by a substantial factor.
So in the Renault cases, while it's entirely possible that a number of
independently-designed and unconnected mechanical systems (brakes, throttle,
gear lever, ignition key or card) failed simultaneously, it's also possible
that the driver made a mistake (honest or otherwise). It has been reported
that the driver in the first incident (October 2004) had just had his
driver's license restored after a four-year ban for various speeding and
alcohol-related offences; perhaps he thought he'd been "flashed" by a speed
trap and needed an excuse ? And after that, anyone who wants to get on TV
can just call and say their Renault's cruise control blocked; it's "another
claimed incident", and why should anyone check if it really happened, if it
makes a good story ?
When the first incident occurred, it became an excuse for every columnist
who has ever had an expensive electronic module replaced in their car, to
get on their high horse about "how there's too much electronics and software
in cars these days". This ignores the generally superior reliability of
electronics - although it's maybe not much comfort if you have a $600 part
to replace, that 10 other people have been saved $80 each - and also the
fact that without electronics, car manufacturers would be unable to meet
emissions standards, thereby incurring the wrath of much the same group of
journalists.
A few years ago in the UK, there was a related incident when a trucker
claimed that a stuck throttle cause him to be unable to stop his truck on a
busy highway. It was later revealed (but not on the front page) that he was
undergoing psychiatric treatment for an attention-seeking disorder...
------------------------------
Date: Tue, 29 Mar 2005 16:07:03 +0200
From: "Robert Scheidt" <robertscheidt@private>
Subject: Re: Cruise-control failures? (Scheidt, RISKS-23.81)
Nick, Thanks for your reply. Please note that I am not taking sides on this,
just being curious, and I am not an owner of one of those renault cars. I
also had no accident recently where I need this as an excuse and don't plan
any.
Regarding your first remark I would like to mention that cruise control is
in my opinion now part of the system in newer cars. The gas pedal does not
move as part of speeding up or going up a hill. In fact the gas pedal just
gives an electric signal to the electronic injection system and there is no
mechanical connection. This is true for my current car (Honda accord 2004)
and was true in my previous car (bmw 530d 2000) and to the best of my
knowledge it is implemented in such a way also in the Renault cars involved.
Regarding the brakes I hope of course that there is no relation with the
cruise control. However many cars (including some of the renault models)
have now more dynamic controls, like for anti-skidding where brakes on one
of the rear wheels is activated when some detection that the car skids in
one or the other directions is detected. And this happens without having to
press the brake pedal. Mercedes started this a few years ago and it is now
widely used (including in my Honda)
The other possibility I could think about, it that if the cruise control
goes indeed get stuck or blocked (for whatever reason) and does not
deactivate when pressing the brake pedal, the driver may have the impression
that the brakes are ineffective since the cruise control will counteract
with the brakes by speeding up the car whilst the brake pedal is being
pressed.
See that you are living in Strasbourg. I was born in a village not far away
(Mundolsheim) and lived there until I started traveling as a computer
specialist in the 1970's. Now living in Brussels.
------------------------------
Date: Tue, 29 Mar 2005 08:12:03 -5
From: "Ray Todd Stevens" <raytodd@private>
Subject: Re: Cruise-control failures?
This would not take a common microprocessor. It would not even take a
microprocessor although there might be one for the anti-lock brakes which
are common on today's cars. Brakes when they operate turn forward motion
and turn it into heat. In doing so the brakes themselves heat up --- a lot.
Now in normal use they can quickly cool down because you reach a speed of
zero, and either wait for a bit, or stop braking and start going again.
Either way they can cool down. However, if they are used enough they don't
get a chance to cool. This is a problem in race cars and they use special
brake bads because of this. It is not normally a problem in street
cars. However, if you are trying to override the accelerator with the brakes
the brakes will in fact overheat. This can cause the brakes to work less
well. Eventually if you get them hot enough the fluid can boil, and cause
the feedback issue that has been mentioned.
The real question is why do they make cars where the computer also controls
turning the engine off and on?
------------------------------
Date: Tue, 29 Mar 2005 13:05:15 -0500 (EST)
From: msb@private (Mark Brader)
Subject: Re: Cruise-control failures? (Scheidt, RISKS-23.81)
Perhaps the loss of braking is really a loss of power braking due to
the ignition switch being off? Then the brake pedal still works, but
requires more pressure, so it seems to be resisting.
Mark Brader, Toronto, msb@private
------------------------------
Date: Mon, 28 Mar 2005 18:20:33 EST
From: KCKnowlton@private
Subject: Re: Don Norman: High is good?
In his otherwise well reasoned mini-essay, I take issue with Don Norman's
statement (RISKS-23.81) regarding what is interpreted as "good".
My own recent blood work report gives the measured concentrations, counts,
etc., along with "reference ranges" of acceptable values:
34 instances of the form m < acceptable < n i.e., higher or lower are bad
6 instances of the form acceptable < n i.e., low is good
1 instance of the form m < acceptable i.e. high is good
This suggests that doctors, in particular, are in general not likely to
assume that "high numbers are good."
------------------------------
Date: Mon, 28 Mar 2005 16:31:07 -0500
From: "Dave Brunberg" <DBrunber@private>
Subject: Re: Human error and computerized medical systems (Norman, RISKS-23.81)
(I am tempted to say: case closed. Quick: is high MIC good or bad? Rule of
thumb: Any definition that has to contain the phrase "in other words" is a
definition in trouble. In this case, after reading the "in other words"
phrase, I still don't know. I think this means that a High MIC number is
good for the organism, but bad for the physician trying to kill it. I still
have no idea of how this translates into the MIC rating for an antibiotic.)
The definition is quite clear, in fact I (not a medical doctor) understood
why a low MIC indicates acceptable antibiotic performance of a drug upon
reading the original article (Morrell, RISKS-23.79).
The definition makes clear that the MIC refers to the minimum dose that
provides suitable antibiotic performance. The text, "The MIC of a drug is
defined in broth as the lowest concentration that prevents visible turbidity
of the broth following the overnight incubation of 105-6 colony forming
units (CFU)/ml (obtained during the log phase of growth)," cannot get more
clear on this. All that is required for a complete understanding is
knowledge of the word "turbidity" and why measured turbidity in a previously
clear solution indicates pathogenic growth.
In this respect I must disagree with Mr. Norman, and submit that a surgeon
who can't be bothered to remember (or figure out as quickly as I did) the
more desirable relative magnitude of a MIC, should be giving his work
considerably more thought.
David W. Brunberg, Engineering Supervisor, The F.B. Leopold Company, Inc.
------------------------------
Date: Mon, 28 Mar 2005 18:16:18 -0500
From: "Bob Morrell/Cancer Center" <bmorrell@private>
Subject: Re: Computerized medical mistakes (Cook & Norman, RISKS-23.81)
The responses to my note concerning the original *JAMA* article on computer
assisted mistakes miss my point entirely. Richard Cook discusses at length
the problems of complex mistakes and cites Three Mile Island and other
complex systems. Don Norman googles himself into trouble by trying to figure
out what an MIC is. Like many a googler, he got the definition right, but
lost on context. Meanwhile, off thread I discussed the nature of mistakes in
the medical environment. Several people sought information on detected
medical mistakes. I cautioned against looking for the complex, obscure
mistake and instead suggested they target "simple" problems in an
overworked, high volume system. "Aim low" I suggested, having observed that
most mistakes that I found were simple mistakes dealing with basic medical
ideas that preceded computers, computerized systems and were taught to first
year medical school students, but forgotten, ignored or overlooked by
overworked staff. The fact that computerized systems did nothing to help
alleviate these errors is lamentable, but has nothing to do with the
mistake, and in fact the error, conceptually preceded computers. Amputating
the wrong limb is not a computerized mistake, an adult dose to a pediatric
patient is not convergence of multiple errors. Picking the wrong antibiotic
based on a confused memory of which is best (high or low) is more
understandable to layman, but to the physician proud of how many undergrad
and others he had to be better than to become a doctor, it is
insulting. When an in-house reviewer reviewed an appendix of mistakes on our
first publication, he scribbled in the margins: "this is going to make some
of our doctors look like blockheads". This doctor did not consider these
mistakes the product of a complex interaction of events, but something that
could have been avoided with simple thought and professionalism.
I have no real disagreement with either responder on the problems with the
complexity of current medical systems, and the need for expensive and
comprehensive reform. What I disagree with, as someone who watched real
mistakes being made is the idea that that the bulk of mistakes being made in
a hospital environment resemble the complex chain of events that occur in
airline crashes or nuclear reactor accidents. I am sorry, I have worked my
entire professional life in a hospital, and it is far less regulated and far
more human, and has far fewer layers of protection between the patient and a
serious mistake. Are complex systems introducing new mistakes? No doubt. But
the mistakes my system found routinely were simple, and embarrassing to
those that made them.
My point was that before we chase the complex mistakes, we need to first
deal with the simple ones.
------------------------------
Date: Mon, 28 Mar 2005 17:49:20 -0600
From: Richard Cook <topquarkguy@private>
Subject: Re: Computerized medical mistakes (Morrell, RISKS-23.82)
Bob, Thanks for your note. It was charitable of you to send it. I am afraid
that we are in rather serious disagreement here. There is is no
misunderstanding on my part or on Don Norman's. We understood you
perfectly. What you wrote was simply wrong. The 'aim low' argument is
nonsense as is the contention that these are 'simple' mistakes. Don and I
have written enough to make all this clear.
[This has been a very interesting discussion. However, I think the basic
points have now been adequately made. As I noted in RISKS-23.81, the
bottom line is that blame can often be distributed variously and
generously! Thanks to the contributors (who have serious credentials) and
to the RISKS readers for staying with us! PGN]
------------------------------
Date: Thu, 24 Mar 2005 01:39:31 -0500 (Eastern Standard Time)
From: Chris Smith <smith@private>
Subject: Re: More uses of satnav/GPS (RISKS-23.80)
In RISKS-23.80, Roland Giersig makes two assertions that I
do not believe to be correct.
While discussing railroad safety and communication, he states that, for
example, if "track-side communication to the on-board units fails, then the
system falls back to a state where the train pilot has to navigate by sight
instead of relying on the electronic systems. And this is perfectly safe,
unlike in air-traffic-control."
Every system will have its limitations. Even navigation by sight is not
perfectly safe. I refer you to the Canadian Transportation Safety Board
Investigation Report on the derailment and collision at Thamesville,
Ontario, 1999 April 23, at
http://www.tsb.gc.ca/en/reports/rail/1999/r99h0007/r99h0007.asp
The train involved was navigating by sight, in midday, under reasonable
conditions. After noting a switch target indicating an incorrectly
positioned crossover, the crew did not have sufficient time to prevent the
subsequent derailment and collision with parked and loaded cars on a siding.
Many times, your most reliable safety measure is an alert and informed human
somewhere in the system. In the 10 seconds between observing the switch
target and the derailment, the crew fully applied emergency braking, shut
down the main diesel engine, and transmitted and then repeated an emergency
stop message to a train approaching within two minutes in the opposite
direction, successfully preventing a far greater tragedy than did occur.
Both of the train crew in the engine were killed - the only deaths in the
accident. For their actions, both were posthumously awarded the Meritorious
Service Medal by the Governor General of Canada.
Second, he highlights the statement that "The danger lies in the unknown
accuracy of the GPS signal!!" I do not believe the accuracy of the GPS
signal is unknown. Many GPS units report EPE - Estimated Position Error,
which is an estimate of the accuracy of the GPS signal. It is the estimated
error for a 1-sigma level of confidence. A 3-sigma, 95% confidence level,
error measure can be calculated by multiplying the given EPE by 3. (Some
low-end handheld units are reported to stray from this definition.)
With many GPS units delivering 3 metre accuracy, a 95% confidence level with
an accuracy of 9 metres would be possible under many conditions. With a GP40
engine measuring 18 metres overall, accuracy comparable to the size of the
engine should be possible, and verifiable, in many cases. Of course, it is
still necessary to actually design the control system to take advantage of
this information.
Ultimately, it appears that developers of such systems can fail twice - once
by not leveraging all the information provided by the positioning system,
and again by not providing useful human interfaces (both informational and
control) in the event of either positioning failures or degraded accuracy.
------------------------------
Date: Wed, 23 Mar 2005 17:09:33 -0800
From: "David E. Ross" <david@private>
Subject: Re: Remote physical device fingerprinting (Roth, RISKS-23.80)
Clock Skew
I have an NTP (Network Time Protocol) client installed on my PC. Every hour
(and additionally when I manually request), it resynchronizes my clock to
NTP servers around the world. Querying five servers (from a list of 164
servers), it uses results from the "best" based on a scoring algorithm.
Since different scores might result at different querying events, I keep
resynchronizing to different NTP servers with differing skews. If any of
the five servers gets a really poor score, it drops out of the chosen five;
and another server from the list of 164 joins the five.
To defeat fingerprinting based on clock skew, all I have to do is change the
option for the resynchronization period to a shorter interval.
David E. Ross <URL:http://www.rossde.com/>
I use Mozilla as my Web browser because I want a browser that complies with
Web standards. See <URL:http://www.mozilla.org/>.
------------------------------
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 23.82
************************
This archive was generated by hypermail 2.1.3 : Tue Mar 29 2005 - 16:41:54 PST