RISKS-LIST: Risks-Forum Digest Thursday 19 October 2006 Volume 24 : Issue 45
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.45.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
A380 delivery delays attributed partly to design SW problems (Peter B. Ladkin)
More on A380 delivery delays (Peter B. Ladkin)
A380 design software incompatibility costs 4.8 billion euros (Mike Martin)
Brazil collision: Too much precision a bad thing? (David Magda)
The NTSB on John Denver's crash and bad interfaces (Trammell Hudson)
More on the Transrapid accident (Debora Weber-Wulff)
Transrapid: fault of the people? (Debora Weber-Wulff)
Re: Cost of online banking typo put on consumer (Peter B. Ladkin)
Identity Theft With Google Code Search (Gervase Markham)
AmEx security (Gregory Marton)
2007 Collegiate Voting Systems Competition (Tim Finin)
REVIEW: "World War 3: Information Warfare Basics", Fred Cohen (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 11 Oct 2006 09:32:26 +0200
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: A380 delivery delays attributed partly to design SW problems
*Flight International* 10-16 Oct 2006 attributes the wiring-matching
problems in the Airbus A380 assembly to problems with design software,
reported in an article by Max Kingsley-Jones on p5.
The A380 aircraft has approximately 500 km (300 miles) of internal
electrical wiring, which is aluminium rather than the traditional copper.
It has been widely reported that the wiring harnesses on body parts
fabricated in Hamburg, Germany did not match those of their neighbors built
in France when they were mated in Toulouse. This has led to extensive delays
in delivery dates, culminating in the resignation both of the former Airbus
chief, Gustave Humbert, a few months ago and now his successor, Christian
Streiff, this week, as well as the resignation of EADS co-chief Noel
Forgeard, who as Airbus chief was largely responsible for the initial
development of the A380.
Airbus is forecasting that full production will not be achieved until 2010,
and that only 39 A380 aircraft will be delivered by the end of 2009,
"compared with 107 originally planned and 80 anticipated under the
rescheduling announced in June 2006." The 68-aircraft shortfall is reported
by Kingsley-Jones to be worth USD 19 billion in lost revenue, based on a
list price of USD 282 million each (note: it is believed that few aircraft
sales take place at list price).
Airbus claims to have underestimated the work required to install
(press-speak: "complete the installation of") the harnesses. Kingsley-Jones
cites Airbus: "The root cause of the problem is the fact that the 3D digital
mock-up [software], which facilitates the design of the electrical harnesses
installation, was implemented late and that the people working on it were in
their learning curve."
It looks as if Airbus is claiming that the wiring design software was a
single point of failure. Given what we all know about the risks of
developing new SW tools, it seems appropriate to ask why no risk-mitigation
measures were put in place as the SW was developed.
Indeed, the former chief executive Christian Streiff sees the problems more
generally, reported as saying that Airbus is not yet an "integrated company"
and "doesn't yet have a simple and clear organisation".
Peter B. Ladkin, Causalis Limited and University of Bielefeld
www.causalis.com www.rvs.uni-bielefeld.de
------------------------------
Date: Thu, 12 Oct 2006 09:07:57 +0200
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: More on A380 delivery delays
With respect to the penultimate paragraph in the preceding item,
John Rushby pointed out to me that it had been reported that Airbus Hamburg
and Airbus Toulouse were using different versions of CATIA software which
had incompatible file formats. CATIA is the CAD-CAM software which Airbus,
Boeing and Sikorsky, amongst others, have been using for a while. The
reports say that engineers in Germany and Spain used Version 4, while those
in the UK and France use Version 5, and it is "no secret" (Newton, see
below) that those versions are "incompatible at the file format level".
The problems and challenges with using different versions of SW, indeed with
data in different formats, are well-known to software managers (if not to
almost everyone who has used a PC and tried to upgrade some favorite SW),
and Airbus must have had some measures in place to address those
issues. Those measures obviously did not suffice. But choosing and
evaluating the measures is much more a management issue than a SW issue.
The Bloomberg News story by Andrea Rothman from September 29 is at
http://www.bloomberg.com/apps/news?pid=20601085&sid=aSGkIYVa9IZk
and a technical discussion, including some sensible comments about the
situation with company-critical-software updates by Randall S. Newton at
http://aecnews.com/articles/2035.aspx
Peter B. Ladkin, Causalis Limited and University of Bielefeld
www.causalis.com www.rvs.uni-bielefeld.de
[More on the Bloomberg item follows, from Mike Martin. PGN]
------------------------------
Date: Wed, 4 Oct 2006 09:46:48 +1000
From: "mike martin" <mke.martn@private>
Subject: A380 design software incompatibility costs 4.8 billion euros
Bloomberg has reported that the wiring problems that have delayed A380
deliveries yet again are related to incompatibility between versions of CAD
software being used:
http://bloomberg.com/apps/news?pid=20601109&sid=aSGkIYVa9IZk&refer=exclusive
... engineers in Germany and Spain stuck with an earlier version of
Paris-based Dassault Systemes SA's Catia design software, even though the
French and British offices had upgraded to Catia 5. That meant the German
teams couldn't add their design changes for the electrical wiring back
into the common three- dimensional digital mock-up being produced in
Toulouse, [Charles] Champion [former head of the A380 program]
says. Efforts to fiddle with the software to make it compatible failed,
meaning that changes to the designs in the two offices couldn't be managed
and integrated in real time, he says. ``The situation worsened when
construction and tests of the first A380s generated demands for structural
changes that would affect the wiring. The changes in configuration had to
be made manually because the software tools couldn't talk to each other.''
Catia file formats changed between version 4 and version 5. An initiative
has now begun to standardise software tools across the program.
According to the latest report on 3 Oct 2006, cost of the consequent
two-year delay to Airbus is estimated to be 4.8 billion euros. Emirate
Airlines accounts for 45 of the 159 A380s currently on order and according
to Bloomberg yesterday is said to be "reviewing 'all options'". If it
cancels, the whole program could be in trouble,
http://www.bloomberg.com/apps/news?pid=20601087&sid=aNULET1PwpvE&refer=home.
While there has been no statement about the reason, the fatal decision to
not upgrade software in Germany and Spain may have been taken so as to avoid
delay to the schedule.
------------------------------
Date: Fri, 6 Oct 2006 22:20:12 -0400
From: David Magda <dmagda@private>
Subject: Brazil collision: Too much precision a bad thing?
In light of the recent mid-air collision in Brazil, Philip Greenspun posted
an article to his weblog where he suggests that too much precision in
navigation can be a bad thing.
It's fairly short so I've 'reprinted' it below (which his CC license allows
:):
The recent mid-air collision in Brazil of a new regional airliner (fitted
out for use as a business jet) and a Boeing 737 has people baffled. How
could two brand-new airplanes with advanced avionics, flown by two
professional pilots in each plane, collide at 37,000 feet? The precision of
modern avionics may well have contributed to this collision.
Airplanes under instrument flight rules fly from one navigation beacon to
another along published standard routes. In the old days, with radio
navigation receivers and pilots flying by hand, a plane wouldn't fly its
clearance exactly. The airways include a tolerance for error of +/- 4
miles. If you're 4 miles to the right of course, in other words, you're
still legal and safe from hitting mountains or other obstacles. Altitude
was similarly sloppy. If you reached for a drink of coffee or to look at a
chart, you might drift up or down 200 feet. Air traffic control wouldn't
get upset.
How does it work now that the computer age has finally reached aviation?
The GPS receiver computes an exact great circle route from navaid to navaid.
All GPS receivers run from the same database of latitude/longitude
coordinates, so they all have the same idea of where the Manchester, New
Hampshire VOR is, for example. The autopilot in the plane will hold the
airplane to within about 30 feet of the centerline of the airway and to
perhaps 20 feet in altitude. If two planes in opposite directions are
cleared to fly on the same airway at the same altitude, a collision now
becomes inevitable.
Almost any other system would be safer. If you sent airplanes up to fly in
random point-to-point paths, e.g., from Boston to Denver, they'd be less
likely to encounter one another. If you kept the airway system, but
introduced some slop into the avionics so that planes always flew 1 mile to
the right of an airway and + or - 200 feet in altitude, they'd be less
likely to encounter one another. If you replaced the precise autopilots
with imprecise humans, planes would be less likely to encounter one another.
If you replaced the high- precision GPS receivers with low-precision VOR
receivers, planes would be less likely to encounter one another.
http://blogs.law.harvard.edu/philg/2006/10/06/mid-air-collision-in-brazil-when-precision-kills/
------------------------------
Date: Wed, 27 Sep 2006 10:02:28 -0400
From: Trammell Hudson <hudson@private>
Subject: The NTSB on John Denver's crash and bad interfaces
> An awful lot of modern user interface design seems to me to amount to
> printing little silkscreened arrows next to buttons that were hopelessly
> misplaced to begin with.
I was a guest once at a hotel with a TV remote that had the entire
silkscreen worn off from too much use. Luckily none of them were "Buy now"
or anything that cost more than a few minutes of frustration. Taking this
idea to an extreme, the Das Keyboard makes a fetish out of it by removing
all labels from the keycaps to create a totally black keyboard.
Apropos the John Denver crash:
> [This of course might reminds us of John Denver's final flight, in which
> he thought he had run out of gas on one tank and tried to switch tanks.
> The lever positions were UP for both tanks off, RIGHT for the left tank,
> and DOWN for the right tank. PGN]
The NTSB report Probable Cause listed the switch orientation as a
contributing factor, but the primary one was the switch location behind the
pilot seat. The NTSB found that "when investigators attempted to switch
fuel tanks in a similar Long EZ, each time while an investigator turned his
body the 90 degrees required to reach the valve, his natural tendency was to
extend his right foot against the right rudder pedal to support his body as
he turned in the seat."
As reported in RISKS-20.43, the original builder of the rear engined
experimental aircraft deviated from the designers plans, and selected the
non-standard location to avoid having any fuel plumbing in the cockpit. A
good idea, perhaps, but one with plenty of other repercussions.
------------------------------
Date: Tue, 26 Sep 2006 19:37:44 +0200
From: Debora Weber-Wulff <D.Weber-Wulff@fhtw-berlin.de>
Subject: More on the Transrapid accident
Spiegel-Online reports on the "Stone-Age" technology used for security on
the Transrapid test track:
http://www.spiegel.de/panorama/0,1518,439302,00.html
Characteristic for a number of other unnamed technology is the record of the
communication between the central control and the cars.
[Other reports have said that normally the oral command to proceed is given
only after the controllers have seen that the maintenance car is in its dock
(it is with sight of the tower) *and* they have spoken with the operators.]
The communication record (sort of the black box of airplanes) is recorded on
8-track tapes. The tapes in use have been used over and over again and are
almost not audible. The system also tries to "optimize" the tape use by
storing every transmission on the "next free track" which is not necessarily
the n+1th mod 8 track. There is no time stamp, so the investigators will
have to piece together a puzzle of almost inaudible bits of communication,
trying to figure out exactly what happened.
It appears that the investigators have no 8-track playing equipment in all
of Germany and are asking for international help. [Mine died *years* ago! -
dww] The first order of business will be trying to make a copy of the tape,
because they are fearful of destroying it by replaying it too much.
In another report criticism has been leveled on the security concept for the
transrapid track to be built in Munich.
http://www.br-online.de/bayern-heute/artikel/0609/26-transrapid/index.xml
It seems that the concept goes like
this [grossly shortened and distorted by dww]:
1. The Transrapid is absolutely secure, no accidents can happen.
2. Not even in a tunnel.
3. So we don't need a fancy security system.
No more detailed reports are expected until the communications can be
deciphered.
Prof. Dr. Debora Weber-Wulff, FHTW Berlin, Internationale Medieninformatik
10313 Berlin http://www.f4.fhtw-berlin.de/people/weberwu/ +49-30-5019-2320
------------------------------
Date: Sat, 14 Oct 2006 01:10:49 +0200
From: Debora Weber-Wulff <D.Weber-Wulff@fhtw-berlin.de>
Subject: Transrapid: fault of the people?
The official investigation into the Transrapid crash (a magnetic levitation
train crashed into a non-maglev service car at approximately 170 km/h,
killing 23 people on 22 Sep 2006) has determined that there is no
"technical" failure behind the crash, but that the fault lies with the
trainman in the maglev vehicle (who died in the crash) and the two
dispatchers who let the train start although the service train was still on
the track.
There were, however, two previous accidents involving the service cars,
according to the Tagesschau-online:
http://www.tagesschau.de/aktuell/meldungen/0,,OID5999452,00.html
On 10 Dec 2004 two service cars running in opposite directions collided in
the fog because of icy conditions. The impact was only at 20 km/h, so no
people were hurt, but the collision caused 100,000 euros worth of damage to
the cars. At this time the employees of the Transrapid requested additional
security precautions, which were denied on the grounds of being an
unnecessary expenditure.
In Jan 2005 there was another accident (that has been acknowledged by the
state government) in which a service car hat an attachment folded down under
the track and smashed into one of the stilts the tracks are built on. There
were no people hurt in this incident, either.
A speaker for the government insists that everything is fine, these
accidents were recorded but not reported, since they were such "small
accidents".
An ethical question: even if the company running the train is found to be
legally guiltless, shouldn't they have set up some sort of fool-proof
signaling system after that first accident?
Further reports say that a German and an American lawyer are suing Siemens,
who are responsible both for the security system of the Transrapid and for
the cable car in Kaprun, which caught fire on 11 Nov 2000, killing 155
persons, in the USA because the company has a subsidiary there.
(http://www.tagesschau.de/aktuell/meldungen/0,1185,OID5980314_REF_NAV_BAB,00.html)
------------------------------
Date: Fri, 22 Sep 2006 05:15:57 +0200
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: Re: Cost of online banking typo put on consumer (Homme, RISKS-24.43)
Kjetil Torgrim Homme's account of a mistakenly typed bank account number in
an electronic transaction causing a transfer to a third party astounds me.
German banks require not only the account number but also the recipient name
to match the account number before they will initiate a transfer. The danger
of a typo is largely that the discrepancy will cause an attempted payment to
fail, and you will only be informed in time if you print out your account
statement shortly afterwards, since German banks issue on-demand statements
only. This may well lead to tensions with creditors if one forgets to
check.
This same danger has been present in another form for some time. If one
fills out a payment slip by hand, characters or numerals may be misread by
the automatic reader, leading similarly to non-payment. German banks do not
issue checks (cheques); account-to-account transfers are the usual non-cash
means of payment (apart from credit cards, whose use is still not
widespread, compared with the US or UK).
Peter B. Ladkin, Causalis Limited and University of Bielefeld,
www.causalis.com www.rvs.uni-bielefeld.de
------------------------------
Date: Wed, 18 Oct 2006 12:56:30 +0100
From: Gervase Markham <gerv@private>
Subject: Identity Theft With Google Code Search
Several blogs [0] have pointed out that Google Code Search can be used to
discover vulnerabilities in the indexed code. One can find SQL injection
possibilities [1], potential buffer overflows [2] and backdoor passwords
[3]. But it's not just security holes in software that you can find.
One particular search I did revealed a file containing a particular person's
entire collection of usernames and passwords. It included several banking
account numbers and passwords, SSNs for him and his wife, keys for popular
software and mortgage payment details. Assuming the passwords hadn't changed
since, I had more than I needed to steal all his money and his identity.
Irony of ironies, the file was included, as plain text, in the source code
package for a "secure password storage" product this person had written and
posted to the web!
I sent him an e-mail a couple of weeks ago, and he replied saying that some
of the data was out of date, and he would change the rest. But it's not easy
to change bank account numbers and SSNs.
The RISKs: testing security software with confidential data; when working on
software, not keeping the development version and the version you use
separated.
[0] http://www.kottke.org/06/10/google-code-search
[1] http://www.google.com/search?q=inurl:%22SQL+select%22+inurl:asp
[2] http://www.google.com/codesearch?q=buffer+%22should+be+big+enough%22
[3] http://google.com/codesearch?hl=en&lr=&q=%22backdoor+password%22+%28warning%7Cshell%29
------------------------------
Date: Fri, 13 Oct 2006 17:45:07 -0400 (EDT)
From: Gregory Marton <gremio@private>
Subject: AmEx security
Somehow I forgot the password I reset recently on my American Express Blue
Cash card. I thought I knew it, and figured I mistyped it, because it's a
somewhat strong password, so I entered it three times and got "locked out".
This turns out to mean that they asked me for my four- to eight-digit
"secure code". These are inherently less secure than the normal password,
so I'm in the habit of generating a random number and forgetting this, but
out of curiosity I also tried this three times, just to see if it would
really lock me out. Why do so many services use these?
I was soon told to call customer service, who asked me about the card number
and the cvv on the card, my name, and one prior address. Now my current
address is easily available, and my prior addresses are a matter of public
record, as they warned me, and easy to discern if you know some basic facts
about me, so it's apparently appallingly easy to pretext me.
At this point I was given a temporary password with which to log in and
change my real password, so far so good. They also asked me to set my
"secure" number. I asked if I could change that on the web site. No. I
asked if they could put me through to something I could type it into. No.
I had to reveal it to the representative, and the representative encouraged
me to label it, e.g. as mother's birth date, etc. Random numbers away!
So there's no security in a procedure you can circumvent with insecure
information, but at least their normal password procedure appears relatively
strong, so I thought perhaps it won't take *too* much convincing or
education. I reset my normal password, only to be told:
"You Have Successfully Changed Your Password
Please record your new Password."
Thanks, AmEx. Good advice!
Gregory A. Marton http://csail.mit.edu/~gremio/
------------------------------
Date: Tue, 26 Sep 2006 21:05:52 -0400
From: Tim Finin <finin@private>
Subject: 2007 Collegiate Voting Systems Competition
US election systems are in a crisis -- maybe students can find the way
forward. In the 2007 Collegiate Voting Systems Competition, student teams
will design, implement, analyze, attack and evaluate complete voting system
that must have been used in some election, such as one for a student
government or organization. Papers describing and analyzing the system will
be submitted for the conference and used to select candidates for the final
competition. The conference, to be held in Portland in July 2007, will
include demonstrations, mock elections, submitted presentations and invited
talks. A panel of judges will make awards for the best overall system, best
presentation, best attack, and best paper on voting system metrics. VoComp
2007 will be run by UMBC's Alan Sherman with support from the NSF Cyber
Trust program and is seen as a way to engage students in nationally
important, state-of-the-art security and privacy research projects and
course work. More information on the conference, competition, its rules,
and an example system is available at http://vocomp.org/.
------------------------------
Date: Wed, 11 Oct 2006 10:38:21 -0800
From: Rob Slade <rmslade@private>
Subject: REVIEW: "World War 3: Information Warfare Basics", Fred Cohen
BKWW3IWB.RVW 20060823
"World War 3: Information Warfare Basics", Fred Cohen, 2006,
1-878109-40-5
%A Fred Cohen fred.cohen at all dot net
%C 572 Leona Dr, Livermore, CA 94550
%D 2006
%G 1-878109-40-5
%I Fred Cohen and Associates
%O 925-454-0171 all.net
%O http://www.amazon.com/exec/obidos/ASIN/1878109405/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1878109405/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1878109405/robsladesin03-20
%O Audience n+ Tech 2 Writing 2 (see revfaq.htm for explanation)
%P 314 p.
%T "World War 3: Information Warfare Basics"
Chapter one asserts that world war 3 is not what most people think it is or
will be, and that it is going on right now. (There is also a fairly
extensive biography of Dr. Cohen.) A definition of information warfare (or
iwar) is the province of chapter two. Cohen starts with the notion that
warfare itself is a high-intensity conflict, and then notes that iwar is the
manipulation (and protection) of symbolic representations used by the
participants in such a conflict. Numerous instances and examples of iwar
are explored, and the definition certainly fits all the forms noted. At the
same time, it must be said that the definition, while comprehensive, does
not appear to assist in formulating responses to the problem. (The mention
of marketing as a form of low-intensity iwar is intriguing. I recall a
conversation, with an ex-employee of the CIA, as it happens. This person
had just encountered the proposal that advertising agencies deliberately
used, and reinforced, certain symbols that were associated with specific
meanings and emotions. Being part of the direct target audience he had
never noticed the practice while I, as an outsider, was just far enough away
from the central culture to have observed it for years.) Cohen finally
points out that we are all at war, on an information level, with everyone
else.
Chapter three examines the intensity levels of iwar. The information
warfare capabilities of numerous nations, and relative comparisons between
various groups, are analyzed in chapter four. Cohen also makes a case for
China overtaking the United States as a world leader in this regard. (This
seems to have the strongest relationship to the subtitular admonition that
"we are losing" the world war 3 that we didn't even know was being fought.
However, if so, it seems in some contradiction to statements, in chapters
two and three, that "we" are all fighting each other, or that "we" are all
in this together.) Criminal activity is reviewed in chapter five, but the
material is relatively weak in regard to iwar. The relationship between
preaching (especially the dogmatic and extreme forms) and propaganda is
clear, so chapter seven's association between religion and iwar is not
surprising, but the text does not support the contention in any detailed
way. Corporate public relations and business intelligence is discussed in
chapter seven. (Of particular interest are the sections on companies
against nations and religions.)
Chapter eight analyzes propaganda, not only in terms of the component parts,
but also in regard to effective countermeasures. Politics, and the various
forms of iwar inherent in it, are in chapter nine. Gaming and game theory
have been used in warfare and politics for years, and are examined in
chapter ten. Chapter eleven looks at electronic warfare, in many of its
forms. Information attack tactics, in chapter twelve, repeats procedures
that are well known to those dealing with intrusions and penetration
testing. Legal issues associated with iwar are outlined in chapter
thirteen. Chapter fourteen deals with broad categories of defences that can
be mounted against iwar activities. Education is one, and chapter fifteen
examines various forms of education that are necessary for effective
protection. Finally, in chapter sixteen, Cohen returns to the concept that
all of us need to know about information warfare, and to be on guard against
it.
Ultimately, this book is not about World War Three, but about the
information warfare, at all levels, taking place around us every day. While
more personal and not as academic as Denning's "Information Warfare and
Security" (cf. BKINWRSC.RVW), Cohen's work is, in its own way, just as
important, since it addresses the types of propaganda to which almost
everyone is subject, likely without being aware of it.
copyright Robert M. Slade, 2006 BKWW3IWB.RVW 20060823
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
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.45
************************
This archive was generated by hypermail 2.1.3 : Thu Oct 19 2006 - 15:47:54 PDT