RISKS-LIST: Risks-Forum Digest Friday 15 December 2006 Volume 24 : Issue 51
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.51.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Bloomington bank night depositors victims of old fashioned fishing
(David Zawislak)
Trig error checking (Martin Ewing)
Re: A380 delivery delays (Peter B. Ladkin)
Re: Flat train wheels (Peter B. Ladkin)
Re: Yet another canceled public sector IT project (Gary Hinson,
Richard Karpinski, Jack Ganssle, Rex Black, Richard Karpinski)
Re: Slade on "Kim" (Michael Bacon)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sun, 10 Dec 2006 18:04:27 -0600
From: David Zawislak <davidzawislak@private>
Subject: Bloomington bank night depositors victims of old fashioned fishing
The Bloomington, Indiana Fifth Third Bank, learned that the Internet is not
the only way to be a fishing victim. Up to 11 depositors who used the night
deposit slot had their deposits fished out of the slot, after one of the
slot's metal security pieces had been sheared off and the bags fished out.
<http://www.theindychannel.com/news/10473879/detail.html>
[The article notes that a dowel rod was found next to the broken metal
piece, with fishing line and a fish hook attached. No bait was required.
No switch either. No need to spare the rod. No reel-time problems. No
social engineering. Just a straightforward low-tech approach. It reminds
us of the futility of believing in high-tech solutions that can be so
easily bypassed. PGN]
------------------------------
Date: Sun, 10 Dec 2006 15:27:13 -0500
From: Martin Ewing <m.ewing@private>
Subject: Trig error checking (Re: McIlroy, RISKS-24.49)
Doug McIlroy's report of the effect of missing punched cards on trig
accuracy (RISKS-29.49) brought to mind another troubling trig episode. In
the early 1990's, we were heavy into scientific calculations on the Digital
VAX-11/780 -- ephemerides which required every last drop of precision.
Sometimes the answers weren't checking out. Eventually we found that our
VAX floating point unit (a very large circuit board) was malfunctioning. It
gave slightly wrong results, but quietly - there were no system error
reports. The diagnostic was that sin**2 + cos**2 was intermittently not
quite equal to 1 for various arguments. [NOTE: This is a positive example
of circular reasoning! PGN]
Field service got us new boards, but how could we have confidence this bug
was not recurring? In the end we ran a background routine that checked
sin**2 + cos**2 forever. (Today, we would make it a screensaver program.)
There is a RISKS issue -- how do you know your CPU is giving good results?
There aren't any check bits for trig functions.
(Alluded to in RISKS-16.68.)
------------------------------
Date: Wed, 13 Dec 2006 18:56:06 +0100
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: Re: A380 delivery delays (Ladkin, RISKS-24.45)
In RISKS-24.45, I reported that Bloomberg News and AEC News were saying that
Hamburg was working with CATIA Version 4 CAD-CAM SW, and Toulouse with CATIA
Version 5.
Now comes a different story.
Nicola Clark wrote an extensive article on the A380 delivery problems in the
*International Herald Tribune* this week, in which she states that the
Hamburg design SW was in fact made by a U.S. company, Computervision, and
dated from the 1980s. If this is so, it isn't simply a file-format problem,
as one could suppose with different versions of the same SW.
The article is available at
www.iht.com/articles/2006/12/11/business/airbus.php
Peter B. Ladkin, Causalis Limited and University of Bielefeld
www.causalis.com www.rvs.uni-bielefeld.de
------------------------------
Date: Wed, 13 Dec 2006 18:42:45 +0100
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: Re: Flat train wheels (PGN, RISKS-24.47)
In RISKS-24.47, PGN reported on trainset availability problems in NY/NJ,
resulting from maintenance backups in replacing/retruing wheels which had
flattened. In Fall, in areas with deciduous trees, a slippery film deriving
from mulched fallen leaves can build up on rails. When trains accelerate or
brake on rails with such a film, adhesion is much reduced and wheels can
slip. The wheel tires (most trains have steel tires on wheels) can develop
flat spots through rubbing at places where a slipping wheel comes to a patch
with good adhesion and the speed of the wheel does not match the train speed
over the rail. It is also not so good for the rails, but they are less
affected.
This problem is as old as railways. What is new is the computer dimension.
In Fall 2003, the German Railways (Deutsche Bahn, DB) had problems with its
new electrical multiple units (EMUs, as they are called in England; I use
the word "trainsets" henceforth), which have designators ET 423 - 426
depending on their use. The ET 425 series trainsets for regional trains in
the Ruhr valley and eastwards through Bielefeld to Minden and
Ostwestfalen-Lippe were having serious problems of two sorts. First, ET 425
units, which under dry conditions have extremely good braking
characteristics, were overshooting their allowable braking distances in
slippery conditions. Since signalling, allowable line speeds, and operations
in general depend upon trains being able to stop within a specified braking
distance (defined by a braking performance curve), this presented a safety
issue. Various incidents had trains passing their stopping point by some
hundreds of meters; clearly unacceptable. Second, train wheelsets were
developing flat spots at a much higher rate than anticipated and there were
not enough replacement sets on hand to be able to keep the required number
of trainsets in service.
The result was chaos in commuter and regional train service. The trainsets
were restricted to maximum speeds of 80 kilometers per hour (kph), half that
to which they are certified. They could not maintain the timetable at these
slower speeds, and certain trains traveling longer distances had to be
turned into two trains at a suitable breakpoint: the second train departed
the breakpoint at the timetabled time, with the first train arriving later
at the breakpoint, leaving travelers who previously traveled on one train
through that point on their journey then to take two: the first one to the
breakpoint, arriving late, and a second, later, one from the midpoint
onwards, causing a large increase in journey time for these unfortunate and
unhappy people. And the Ruhr is the largest urban conglomeration in Germany,
so there were lots of them.
Some of the trains serviced with ET 425 trainsets were replaced with
locomotive-hauled sets, which with their heavier carriages were less
susceptible to the problem, and could travel at their posted speeds even in
the lower-adhesion conditions.
In 2004, the DB planned the trainset replacement on the most heavily
affected lines in Fall from the outset, and delays were much reduced,
although travelers were not as happy as they would have been with the
originally-offered service.
I discussed the issues extensively in early 2004 with the railway engineer
Oliver Lemke at the Institute for Railway Engineering and Traffic Safety at
the Technical University of Braunschweig, and again in early 2005, and Fall
2005. The information below specifically on the ET 425 problem comes mainly
from Oliver and from the technical article "Neue Erkenntnisse zum
Gleitschutzverhalten elektrischer Triebzüge" (translated: "New Findings
on the Antislip Behavior of Electric Trainsets") by K.-R. Hase, S. Müther
and P. Spiess, in the Eisenbahntechnische Rundschau volume 54, pp 599-610,
October 2005, available online at
www.eurailpress.com/archiv/artikel.php?id=8339 (I would translate the
journal name as: "Railway Technical Review", but that is the name of a
different journal, in English, from the same publisher.)
First, a word about brakes. There are roughly four different kinds of
braking systems in common use on railways. Two of them, friction brakes and
regenerative braking, brake the wheels: the first through friction (as in
cars and bicycles), the second turns the motor into a generator and thereby
the kinetic energy of the train into electricity (and also some heat) which
is fed back into the overhead line. On trains which are certified to travel
at over 160 kph, brakes acting directly on the rails are required. There are
generally two kinds. Eddy-current brakes consist of electromagnets which
hover some millimeters above the rail. The moving electromagnet produces an
eddy current in the rail, which produces a force on the electromagnet, and
thereby on the trainset to which it is attached, in the opposite direction
to that of travel. Eddy-current brakes are used on very-high-speed trains to
brake from high speeds, and they are relatively ineffective at lower speeds.
The kinetic energy is dissipated largely as heat, and some applications have
been said to have set the rails glowing. (I understand that eddy-current
braking is also being investigated for road trucks.) Second, there are
magnetic rail brakes, which are also electromagnets, but use the magnetic
attraction to set themselves firmly on the rail and achieve their braking
effect through friction (which also generates heat, of course).
The ET 425 units are light, and depend for various reasons more on
regenerative braking than other units. For technical reasons, it is harder
under regenerative braking to start a halted and sliding wheel rolling
again. The ET 425 series was not certified to travel at higher than 160
kph, so did not require rail brakes. Magnetic rail brakes would have solved
the braking underperformance problem directly, but the bogies (the chassis
which holds the wheel sets, including the wheel sets. In the U.S. they are
called "trucks") were not designed to be able to take them. Outfitting the
ET 425s with magnetic rail brakes would have entailed replacing bogies, at
great cost. (Back in 2005, when I was discussing this, there was a picture
of a magnetic rail brake on an ET 425 on the WWW, but it is no longer
there.)
There was also discovered to be an issue with the sanding devices. These
spray sand just in front of the rail-wheel adhesion point to increase
adhesion in conditions of low adhesion. The aerodynamics weren't quite right
and at high speeds the sand was ending up elsewhere than at the point of
adhesion.
The braking on the ET 425 trainsets is computer-controlled:
brake-by-wire. The driver issues a braking command which consists in a
target braking value (in German, "Soll"-Wert), and the computer controller
figures out how to attain that value. It turns out that the braking problems
were largely solved by optimising the braking algorithms implemented in the
control SW. The SW was doing what it should have been doing but the
algorithms for braking under non-optimal conditions of friction were not as
good as they could have been.
I leave it to readers to decide whether this a computer-related problem or
rather a computer-related solution to a problem. I suspect the
characterisation is a matter of taste.
Mark Brader reported a problem in RISKS-23.63 with braking systems on Virgin
Trains's then-new Pendolino tilt-trains for the British West Coast Line, a
year after the DB problems first surfaced. The BBC carried reports dated 11
November 2004 at news.bbc.co.uk/1/hi/uk/4002257.stm Brader's RISKS report
referred only to the very-low-speed braking issues, because these were
caused by out-of-spec SW issues, but such issues had little to do with the
speed limit of 110 mph to which the BBC article also referred. It turns out
that the Pendolinos also had problems with braking during leaf-mulch
conditions and, unlike DB high-speed units, were neither required to be
fitted with magnetic rail brakes, nor were they so fitted. (I no longer
have a suitable reference for this.)
Peter B. Ladkin, Causalis Limited and University of Bielefeld
www.causalis.com www.rvs.uni-bielefeld.de
------------------------------
Date: Mon, 11 Dec 2006 11:55:09 +1300
From: "Gary Hinson" <Gary@private>
Subject: Re: Yet another canceled public sector IT project (R-24.49)
Richard has picked out just one of many important issues that commonly
affect software development projects, perhaps implying that if only this one
issue were addressed, everything would be fine. If so, that's silver bullet
thinking. The Real World(TM) is far more complex, for examples:
* Small projects are less risky than large ones since they are more
predictable and controllable. It is sound advice to split huge monolithic
projects into phases and/or to treat them as programmes containing multiple
sub-projects that are, as far as possible, mutually independent.
Unfortunately, some systems (such as national health systems) are inherently
huge and complex, and are extremely difficult to subdivide. There are also
additional costs to subdividing projects. Programme management is a more
abstract, specialist and hence expensive form of project management
(qualified and successful programme managers are in high demand). There are
always residual dependencies between sub-projects meaning additional
planning and execution risks;
* Large projects invariably involve politics, whether national or
corporate/internal. There are numerous vested interests, differing aims and
competing priorities. This is a given. Dealing effectively with the
politics is more art than science;
* Richard identified changing requirements specifications, fair enough.
Many other aspects of projects often change too, such is the nature of
project risk and planning. It makes sense for management to anticipate the
likelihood of changes and put in place, in advance: (a) contingency
arrangements; and (b) the project governance structures to work proactively
with whatever crops up rather than reactively picking up the pieces; and yet
there is a curious faith in pre-cast plans, budgets and teams. I am fond of
the concept of constantly revising the business case for major projects as
they proceed from concept to delivery since the initial case prepared for
budgeting purposes is highly unlikely to reflect fully the 'as built'
system, both in terms of the costs and the benefits. A useful side-effect
is that from the highly refined business case emerges a comprehensive
blueprint for metrics to measure and maximize the value obtained from the
delivered system (read John Thorp's "The Information Paradox" for more);
* Projects are themselves change activities, introducing the thorny topic of
change management. We persist in referring to "software development
projects" etc. rather than "organizational change initiatives" etc. The
organization is of course going to be different post-implementation,
significantly different in the case of large systems. Managing the
transition from pre- through para- to post-implementation is no easy task
but seldom (in my experience) is it truly recognized by management as an
important and difficult activity, at least until things are already going
seriously wrong. The more organizational and political layers there are
between developers and users, the harder it is to ensure that the project
sponsor's change vision is both appropriate/feasible and reflected on the
ground;
* There will always be conflicting priorities for senior management's
attention. If there were not, there would be a greater risk of management
'going native' on the project, perhaps losing sight of the true business
objectives and changes in the environment. On top of that, we all have
different skills and motivations. The more people are involved in a
project, the more diversity of views and opinions there will be.
It seems to me that management by and large needs to be more creative,
professional and flexible with respect to the governance of large projects.
Why not, for instance, initiate multiple parallel project teams in friendly
competition to develop the best business case and project plans? Management
can monitor their progress, seed good ideas between the teams and when
appropriate kill off the weakest to focus resources on the most promising
(my hero Charles Darwin coined the term 'survival of the fittest'). Sure
there would be higher costs up front but the risk mitigation and competitive
motivation may more than compensate. 'Extreme programming' techniques,
object orientation, formal methods, outsourcing etc. all potentially have
their place in a creative organization that is prepared to experiment and
learn. Traditional stick-in-the-mud management teams are destined to repeat
the same failures over and over, and perhaps worse to stall vital projects
because of the fear of failure (the risk of not doing what's necessary).
Leaning brings me to my final point. Every project, good and bad, is a
worthwhile learning opportunity. Those directly involved clearly learn from
the experience (subject to the limitations of their own perspectives) but it
is probably worthwhile spreading the knowledge further afield. Internal
Audit has a valuable role both to review and advise on the political,
risk and project management during the project and to tease out and share
the lessons to be learnt afterwards. Doing this repeatedly improves
Internal Audit's competence and expertise.
Dr Gary Hinson PhD MBA CISSP CISM CISA, CEO IsecT Ltd. +64 634 22922
www.NoticeBored.com www.IsecT.com www.ISO27001security.com
------------------------------
Date: Sun, 10 Dec 2006 17:15:33 -0800
From: Richard Karpinski <dick@private>
Subject: Re: Yet another canceled public sector IT project (R-24.49)
Gary, If it were one issue, it wouldn't have taken Gilb 474 pages to address
the rather broad topic of project management. Would you like to see the PDF
to understand how thoroughly he approaches the problems? I just tried to say
the essential parts in a short enough form that people could read it
through. It was brief.
How can you do it with extreme incrementalism and not know you are failing
before you have spent ten percent of the budget? I boldly claim that you
cannot. I further claim that that fact justifies my claim that the horrors
of the current methods can be reliably averted by adopting extreme
incrementalism.
Ask Gilb or Malotaux about their experience with it.
P.S. In fact, here is what Niels Malotaux said in response to my item:
Nice to hear from you. And all true. Every time a project gets in
trouble, I ask myself: "Why didn't they just ask for a bit of help?" It's
SO easy to get a project on track and let it conclude successfully, that
it must be either ignorance (which it mostly is) or lack of interest
(which it mostly seems to be) when people let projects fail again and
again.
You say: "... evolutionary method is still considered radical and
risky". I regularly get the comment that what I say is "highly
controversial and philosophical". Still, we know from practice that it is
highly practical and successful. Recently I saw again two project
managers very reluctant to start letting me help getting their failing
projects on track. Only because their boss gave them the choice to either
from now on pass every milestone on time themselves (which they have never
done before), or to let me help them, they reluctantly conceded to let me
help them. Within on week, just only applying the TaskCycle, they were
convinced that this was great and helping them immensely to be more
successful. So I was thinking: "Why can't I explain people convincingly
about the Evo benefits before starting?". I think that before starting
eating the pudding, people have no clue what we are talking about. A lack
of frame of reference. People just don't hear what we are saying. Besides,
what we are saying is so simple that it cannot be true.
Still a big marketing problem. So many projects that can be saved and
hardly anybody understanding that we can do something about it.
Niels
------------------------------
Date: Mon, 11 Dec 2006 08:05:19 -0500
From: Jack Ganssle <jack@private>
Subject: Re: Yet another canceled public sector IT project (R-24.49)
Richard Karpinski complained that projects fail when we expect to be able to
nail down all of the requirements up front, rather than embrace an
incremental approach as advocated by Tom Gilb and many others. Yet this
reflects the essential tension in software development. He's right;
realistically it's hard and sometimes impossible to understand the
requirements early in the project. Yet he's wrong: management needs a price,
up front, to decide if the project is at all affordable, and if the promised
value exceeds development costs. Management needs a date, up front, to know
if the product will hit the market window. We can waffle and promise to
deliver a range of dates and costs, or we can protest mightily that such
expectations are unreasonable. Yet if the project is late, so there's no
revenue being generated, and as a result our paycheck is a dollar short or a
day late, we go ballistic.
Alas, I fear this conundrum will never be resolved.
Jack Ganssle, jack@private 410-504-6660 Skype jack.ganssle
------------------------------
Date: Tue, 12 Dec 2006 08:05:42 +1300
From: Rex Black <rexblack@private>
Subject: Re: Yet another canceled public sector IT project (R-24.49)
I have a great deal of respect for Tom Gilb, who I consider a personal
friend as well as an esteemed colleague. Also, I realize that these
iterative lifecycle models are very popular right now.
That said, this heavy emphasis on these types of lifecycle models represent
the latest manifestation of what Fred Brooks described as software
engineering's "silver bullet" quest. A number of years ago, during the
deflation of the 4GL bubble, which, ironically, overlapped the early days of
object-oriented languages, Boris Beizer wrote mockingly in Latin about the
"lingua salvator est" tendency, a desire to see the adoption of the right
language as the magic solution, the savior, the discovery that would make
all our problems go away. And, while we're on that note, CMM and TQM,
anyone?
I am not saying that good languages, good processes, and a focus on quality
are useless. I am saying that holding any *one* thing out as a solution is
counter-productive at best.
Software engineering is hard for a number of reasons. Some of those reasons
result from doing things we (collectively) know to be stupid. Others result
from dogmatically following approaches laid out by others without regard for
how to tailor those approaches to our situation. Let's not pretend that
something as simple as a lifecycle model is going to solve all our problems,
particularly when the real magic of a lifecycle model--if there is any magic
in it--lies in tailoring it to what we really need.
Amer. Software Testing Qualifications Board, Int'l Software Testing Qual.
Board,... Bulverde, TX 78163 USA +1-830-438-4830 www.rexblackconsulting.com
------------------------------
Date: Tue, 12 Dec 2006 16:20:24 -0800
From: Richard Karpinski <dick@private>
Subject: Re: Yet another canceled public sector IT project (Black, R-24.49)
> That said, this heavy emphasis on these types of lifecycle models
> represent the latest manifestation of what Fred Brooks described as
> software engineering's "silver bullet" quest.
Tom Gilb, in his 474 page "Competitive Engineering" is not offering a silver
or magic bullet but rather a fleet of magic bulldozers, viewing lenses,
decision processes, evaluation techniques, and an overarching focus on
delivering measured value to identified stakeholders, including the users of
the proposed system. The radically small steps allowed between instances of
facing reality again, with usable deliveries to stakeholders, guarantees
that if failure occurs, then it happens clearly in the first tenth of the
project, not hidden until years of effort have been invested.
> A number of years ago, during the deflation of the 4GL bubble, which,
> ironically, overlapped the early days of object-oriented languages,
The early days of object-oriented languages was the mid 1960's for me with
SIMULA-67.
> Boris Beizer wrote mockingly in Latin about the "lingua salvator est"
> tendency, ...
We have never before had a system like Planguage, where the magic was so
thoroughly inspected, evaluated, guided, and verified in routine use of a
"single" "language".
> And, while we're on that note, CMM and TQM, anyone?
You won't get me to disdain TQM since it seems to me that that is pretty
close to SQC as advocated to such success in Japan by W. Edwards Deming
whom I respect greatly.
> ... I am saying that holding any *one* thing out as a solution is
> counter-productive at best.
If you think Competitive Engineering is one thing, or that Tom's Planguage
is just a good language for designing a project, then you need to read more
of those 474 pages.
> Software engineering is hard for a number of reasons. ...
Which is exactly why the non-simple approach taken in Competitive
Engineering is both demanding and successful. The very essence of the method
is the focus on tailoring to the actual circumstances and measuring the
success of applying engineering effort toward the identified measurable
business goals of the project. In order to take advantage of all that
tailoring and measuring, it is absolutely vital to avoid even medium sized
development cycles.
Obviously, the best approaches will naturally avoid doing the things we know
to be stupid. Since fixing the steps of the project at the very beginning is
one of those really stupid ideas, I felt the need to rail against it. But I
had to do it in a page or so to be published and read.
My view is that we actually will need many more pages than Tom used to
explain his approach so that it can be understood without intense
consideration of each paragraph. But he had to do it in a form that could
still be lifted without violating OSHA rules even when made manifest on
printed paper.
Perhaps I'm unfairly picking on what you said. Clearly, I have some skill in
treading on people's toes, despite a lack of conscious intent. Would you
care to check in with Tom or Kai or Niels Malotaux to see what they say
about your assertions?
Richard Karpinski, World Class Nitpicker
148 Sequoia Circle, Santa Rosa, CA 95401
dick@private Home +1 707-546-6760 Cell +1 707-228-9716
------------------------------
Date: Mon, 11 Dec 2006 12:21:34 +0000
From: attilathehun1900@private
Subject: Re: Slade on "Kim" (RISKS-24.49)
Rob Slade hits it right on the nose with his review of Rudyard Kipling's
"Kim". Kipling was definitely one of us. In his "Just So Stories", he
provided his "Six Honest Serving Men", the key question starters that every
information security analyst and auditor worth their salt always uses:
"I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who"
Michael "Streaky" Bacon
[Brent J. Nordquist notes that Project Gutenberg has the free E-text. PGN ]
<http://www.gutenberg.org/etext/2226>
------------------------------
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.51
************************
This archive was generated by hypermail 2.1.3 : Fri Dec 15 2006 - 17:17:26 PST