RISKS-LIST: Risks-Forum Digest Monday 17 January 2005 Volume 23 : Issue 67
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.67.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Loss of data from Huygens Probe (John Murrell)
130 most common bugs -- and counting (Peter Ludemann)
Cellery worm plays games with victims (NewsScan)
Hollywood Sign Security (Bruce Schneier)
Problems with Chicago-area toll road transponders (jhhaynes)
GPS used to arrest snowplow driver (David Tarabar)
Re: A Comedy of Errors (Rex Black)
Yet another route map software problem (Nick Brown)
MapPoint explains Vikings? (Adam Shostack)
Re: Risks of lenient parsing (Doug McIlroy, Walter Roberson,
Roger Burton West, Jonathan Kamens, Russell Smiley, Sander Tekelenburg)
Copyright and reverse engineering (Rob Slade)
Re: High Tech Crimes Revealed" (Steven Branigan)
Re: A Kafka day at the Los Angeles traffic ticket office (Paul Robinson)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sat, 15 Jan 2005 20:38:57 -0000
From: "John Murrell" <johnmurrell@private>
Subject: Loss of data from Huygens Probe
It appears that data was only received from one of the two semi-redundant
communications channels from Huygens by the Cassini spacecraft. At this
morning's press conference it appears that one of the two receivers on
Cassini was not turned on due to a software error.
This has not caused a major loss as most data was duplicated between
channels - the only two losses are that 50% of the images are lost but most
of these will overlap with images sent on the other channel.
Also the 'Doppler Wind' experiment relied on the carrier signal from the
channel that was not switched on however it is believed that this
information can be reconstructed from the radio telescope observations that
were tracking Huygens.
ESA has set up a board of enquiry into why the receiver was not turned on.
It is interesting to know why 'end to end' system tests did not find this.
------------------------------
Date: Sat, 15 Jan 2005 12:13:33 -0800
From: Peter Ludemann <p_ludemann@private>
Subject: 130 most common bugs -- and counting
Bruce Tognazzini has started collected well-known bugs at
http://asktog.com/Bughouse/index.html ... many of these have shown up
before in Risks, such as "Harassing Confirmations & Missing
Confirmations" and "'Smart' functions that aren't smart".
Readers might also enjoy (if that's the right word) Tognazzini's article
on Security D'ohlts: http://asktog.com/columns/058SecurityD'ohlts.html
and an older article on how inconvenience and security are confused:
http://asktog.com/columns/051AirSecurity.html
------------------------------
Date: Fri, 14 Jan 2005 06:19:58 -0700
From: "NewsScan" <newsscan@private>
Subject: Cellery worm plays games with victims
Users are being warned about the Cellery worm -- a Windows virus that
piggybacks on the hugely popular Tetris game. Rather than spreading itself
via e-mail, Cellery installs a playable version of Tetris on the user's
machine. When the game starts up, the worm seeks out other computers it can
infect on the same network. The virus does no damage, but could result in
clogged traffic on heavily infected networks. "If your company has a culture
of allowing games to be played in the office, your staff may believe this is
simply a new game that has been installed -- rather than something that
should cause concern," says a spokesman for computer security firm
Sophos. [BBC News, 13 Jan 2005; NewsScan Daily, 14 Jan 2005]
http://news.bbc.co.uk/1/hi/technology/4170903.stm
------------------------------
Date: Sat, 15 Jan 2005 02:50:05 -0600
From: Bruce Schneier <schneier@private>
Subject: Hollywood Sign Security
>From Bruce's CRYPTO-GRAM, January 15, 2005
http://www.schneier.com/blog/archives/2004/12/physical_access.html
In Los Angeles, the "HOLLYWOOD" sign is protected by a fence and a locked
gate. Because several different agencies need access to the sign for various
purposes, the chain locking the gate is formed by several locks linked
together. Each of the agencies has the key to its own lock, and not the key
to any of the others. Of course, anyone who can open one of the locks can
open the gate.
This is a nice example of a multiple-user access-control system. It's
simple, and it works. You can also make it as complicated as you want, with
different locks in parallel and in series.
[Ah, a wonderful new use for the switching theory of relay circuits that
takes me back to Howard Aiken's switching course in 1953! Boolean
switching functions and even bridge networks, where current can flow in
either direction in some links, provide for nifty multilock combinations.
PGN]
------------------------------
Date: Wed, 5 Jan 2005 12:03:06 -0600 (CST)
From: jhhaynes@private
Subject: Problems with Chicago-area toll road transponders
[Source: Activating I-PASS hits a roadblock; Online demand blamed for delay
Virginia Groark, *Chicago Tribune*, 4 Jan 2005; PGN-ed]
http://www.chicagotribune.com/technology/chi-0501040029jan04,1,5273675.story
?coll=chi-techtopheds-hed
http://www.chicagotribune.com/technology/chi-0501040029jan04,1,5273675.story?coll=chi-techtopheds-hed
The Illinois State Toll Highway Authority raised the tolls at 12:01 on New
Year's Day 2005 for drivers paying cash, which caused floods on both the
phone lines (with typically a 15-minute wait) and the Web site, with 65,000
requests for I-PASS accounts over the weekend. Officials warned that it
might take up to eight hours for activated transponders to work.
------------------------------
Date: Tue, 11 Jan 2005 18:39:03 -0500
From: David Tarabar <dtarabar@private>
Subject: GPS used to arrest snowplow driver
For the past several years, the Massachusetts Highway Department has
required that private snow-removal contractors carry a GPS equipped mobile
phone. The purpose is to allow the department to better schedule plowing and
to verify that the roads are actually being plowed.
"The state found another use for the global positioning satellite network
...", according to the *The Boston Globe*, 11 Jan 2005. At 3:45 AM on 10
Jan, a snow-removal truck stopped at a local coffee shop, where the driver
ordered coffee and allegedly exposed himself to a female employee. The
Highway department tracked a truck from a local depot and by later that
day, the driver had been arrested and charged with multiple offenses.
------------------------------
Date: Sat, 15 Jan 2005 19:39:16 +0200
From: Rex Black <rexblack@private>
Subject: Re: A Comedy of Errors (Lamport, RISKS-23.66)
I don't know about whether all professional programmers would necessarily
catch this error, but any programmer doing competent unit testing and/or any
tester doing competent input-handling testing would have caught it.
Equivalence class partitioning would identify at least three classes of
strings:
1. Null string (sometimes valid)
2. Non-null strings that contain no special characters (valid)
3. Non-null strings that contain at least one special characters (valid)
4. Malformed string (always invalid)
In each those classes--excepting perhaps the null string--a competent
programmer or tester should be able to identify multiple subclasses and
other interesting tests (e.g., using boundary value analysis), such as the
non-null string of minimal length, the non-null string of maximum length,
the non-null string exactly one character longer than the maximum length, a
non-null string long enough to overflow a buffer, etc.
Since these types of tests tend to be effective at finding bugs during
system testing by independent test teams, I conclude that many programmers
do not cover these tests during unit testing. With the advent of some of
the so-called agile methodologies, that may well change, provided that
programmers take the time to study and apply well-established testing
techniques.
Rex Black Consulting Services, Inc., 31520 Beck Road, Bulverde, TX 78163 USA
1 830 438-4830 www.rexblackconsulting.com rex_black@private
------------------------------
Date: Sat, 15 Jan 2005 00:31:13 +0100
From: Nick Brown <Nick.BROWN@private>
Subject: Yet another route map software problem
This kind of thing has been discussed in RISKS before (20.62, 23.20), but
apparently the problems are still there:
1. Go to http://mappoint.msn.com/DirectionsFind.aspx
2. In the Start section, select "Norway" from the listbox
and enter "Haugesund" into the "City" field
3. In the End section, select "Norway" from the listbox
and enter "Trondheim" into the "City" field
4. Click on "Get Directions"
Interestingly, inverting the cities in the request produces "less
spectacular" results.
What was fundamentally the same service (Microsoft Expedia Maps, now called
MSN MapPoint) figured in article in RISKs 20.62, more than five years ago.
------------------------------
Date: Sat, 15 Jan 2005 12:06:55 -0500
From: Adam Shostack <adam@private>
Subject: MapPoint explains Vikings?
(Or, that wrong turn at Djupaskarvegen again!)
When going from Haugesund, Rogaland, Norway, to Trondheim,
S=F8r-Tr=F8ndelag, Norway, be aware that following Microsoft MapPoint's
directions, will take you through England, France, Belgium, the
Netherlands, Germany, Denmark, Sweden, and finally back into Norway.
While this may be culturally sensitive and respectful of historic
Viking routing, rooting, or looting, it is somewhat less efficient than
other routes, as a quick glance at a map will show.
Start: Haugesund, Rogaland, Norway
End: Trondheim, S=F8r-Tr=F8ndelag, Norway
Total Distance: 1685.9 Miles, Estimated Total Time: 47 hours, 31 minutes
(This is listed as the "quickest" route.)
[.gif file deleted]
------------------------------
Date: Sun, 16 Jan 2005 16:05:39 -0500
From: Doug McIlroy <doug@private>
Subject: Re: Risks of lenient parsing (Horning, RISKS-23.66)
Following up on Jim Horning's remarks that rightfully blame the prevalence
of bad HTML, which works here but not there, on browsers' silently "fixing"
errors, I note that this behavior was officially encouraged:
HTML user agents should be liberal except when verifying code.
- Berners-Lee, Connolly et al, "HyperText Markup Language
Specification - 2.0", Internet Draft, November 28, 1994
Browsers -- the only ubiquitous tools for seeing that a web page works --
are rarely built for verification, and this sentence lets them off the hook.
It has always ranked high on my list of misguidances in language design.
[Doug's message is right on. Jim's posting created quite a flurry, both
in-band and out-of-band. I have selected a few, despite some overlap,
which by no means covers the waterfront, but may exhaust the reader. PGN]
------------------------------
Date: Sat, 15 Jan 2005 02:07:48 -0600 (CST)
From: Walter Roberson <roberson@private>
Subject: Re: Risks of lenient parsing (Horning, RISKS-23.66)
In RISKS-23.66, Jim Horning contended that "*all* of the browsers were wrong
not to indicate clearly the presence of a syntax error."
In my experience, pages *without* HTML syntax errors are quite uncommon.
I usually use an older browser that does less automatic fixups of incorrect
HTML. If I hand-edit nonconformant HTML to make it compliant, the browser
almost always works.
I find that an increasing number of sites are insisting on IE6, or Firefox,
or Netscape 7, supposedly because "We use advanced HTML features not
supported in older browsers". In *every* such case that I have
investigated, if I grab the content elsewise and fix its broken HTML, the
pages have worked fine on the old browser.
Sites almost never fix their HTML in response to my reports.
It has become clear to me that requiring IE6 has become a euphemism
for "Our HTML is nonconformant and we have no intention of fixing it."
------------------------------
Date: Sat, 15 Jan 2005 12:52:42 +0000
From: Roger Burton West <roger@private>
Subject: Re: Risks of lenient parsing (Horning, RISKS-23.66)
Mr Horning may find it useful to be aware of the Dillo browser
(http://www.dillo.org/), which not only gives detailed information on errors
in HTML but uses a clearly-specified set of heuristics in trying to correct
them.
------------------------------
Date: Mon, 17 Jan 2005 10:21:29 -0500
From: Jonathan Kamens <jik@private>
Subject: Re: Risks of lenient parsing (Horning, RISKS-23.66)
I had a "those who fail to learn from history" moment when I read Jim
Horning's account of his difficulty tracking down an HTML syntax error
because all of the browsers used to display the page with the error silently
corrected it.
Years ago, early on in the browser wars when Netscape was still king, I
heard a similar rant from one of my friends who is an SGML / XML / HTML
expert. The very controversial question the browser developers and early
adopters were asking then was, should HTML be treated as a structured
language which must parse correctly to be displayed, or should it be treated
as a markup language which browsers should obey as much as possible even
when it's broken?
Clearly, the browsers have chosen the latter. As uncomfortable as that
decision may make the technology purists among us, it is a reasonable
application of Postel's rule to "Be generous in what you accept and
conservative in what you generate."
Developers who regularly encounter difficulties with HTML syntax errors
which the browsers make difficult to locate may wish to avail themselves of
one of the numerous free and commercial HTML validation tools that are
available.
------------------------------
Date: Mon, 17 Jan 2005 11:01:18 -0500
From: "Russell Smiley" <smiley@private>
Subject: Re: Risks of lenient parsing (Horning, RISKS-23.66)
> A friendly browser would even have made some
> attempt to indicate the approximate location on the page of the error.
Personally I'd be rather annoyed if my favourite browser started generating
prompts for "general syntax error at line x" on every poorly formed web page
out there and I suspect most general users would as well.
It seems to me that browsers try to cleanly and silently work around
problems in HTML to ease the experience for users who simply don't
understand the issues with writing good HTML, or don't want to. In a general
sense this seems particularly reasonable when most of the time the error can
be worked around without any noticeable problem for the user.
However Mr Horning's experience suggests there is a specific class of users
who actually need the error reporting to validate the HTML they are
generating. Rather than "enhancing" browsers to report all errors as Mr
Horning suggests I would suggest that browsers should have a debug mode
which is by default disabled to facilitate the present user-friendly
experience. When enabled the debug mode could report all HTML errors for the
benefit of those users who need to know about such errors.
------------------------------
Date: Sat, 15 Jan 2005 13:45:05 +0100
From: Sander Tekelenburg <tekelenb@private>
Subject: Re: Risks of lenient parsing (Horning, RISKS-23.66)
> So what is the lesson?
The 3 lessons are:
1. There is no excuse for publishing invalid HTML as there are plenty of
HTML validators available. (Once you use them you will notice that there are
(almost?) no CMS tools, blogs, 'WYSIWYG HTML editors', etc. that output
valid HTML. At best they output minor errors (like not encoding ampersands)
but usually they'll just output crap, relying on browsers' ESP engines to
guess what was meant.)
Note that some of those tools, like HTMLTidy, are useful but are not
*validators*.
2. When a Web page shows a problem, the first thing to do is make sure its
HTML is valid. It's no use wasting time on any other aspect as long as it is
not. For some reason most Web designers seem to be unaware of this.
3. You were using the wrong tools. (iCab, see below, would have been a right
tool.)
> Given the frequency of errors in HTML, it would be unreasonable for
> renderers to refuse to display pages with errors.
IMO this is open for debate still. Browsers refusing to display invalid HTML
would be the ideal solution, as it would force authors to ensure valid HTML.
However, I recognise that, given that easily 95% of the Web contains broken
HTML, a user agent that would refuse to display such pages would never become
popular. It is simply too late now. Users expect Web pages to 'just work'.
They expect browsers to guess what the author meant, and to guess right.
Still, indicating to the user that a page contains invalid HTML, and that
therefore what is rendered is no more than a best guess at what the author
intended *would* be realistic. It would be a very useful tool for those who
care, and it would not get in the way of those who don't. Give it time, and
more users will hopefully begin to realise that indeed it does matter. The
Web browser iCab has offered this for many years.
A way to make this even more useful, perhaps even to popularise this, might
be to have browsers score pages. The less HTML errors, the better the score,
thus indicating that the user can be more confident that what is being
displayed is what the author intended.
If that becomes popular enough, then maybe, just maybe we can finally arrive
at a point where users will appreciate browsers that refuse to display
invalid Web pages. Probably the right way (both to make it a smooth step from
the previous step, and to popularise it) would be to allow users to define
the threshold at which their browser should simply refuse to display a page.
Of course you would need to come up with a sensible algorithm to be able to
score HTML in a useful way. This won't be easy given that 1 error will
influence the effect of another error...
> We stumbled around blindly because *none* of the browsers we were using
> gave any hint that there was a syntax error on the page.
There is at least one browser that does contain a HTML syntax checker, and
has so for many, many years: iCab. See <http://www.icab.de/>. When it
considers a document's HTML to be good, it shows a green smiley in the
toolbar. When it considers a document to contain 1 or more errors, the green
smiley turns into a red sad face, which you can click to get a list of all
the errors it found (including a hint as to what is wrong about it and
sometimes even what it probably should have been) and in turn
double-clicking individual errors makes it show the document's source code,
with the relevant portion highlighted.
This tool has been available since about 1998 (provided you have a Mac to run
it on). AFAIK to this date no other browser vendor has been smart enough to
copy this function.
iCab 3.0, which is currently in 'limited public beta testing' phase not only
validates HTML 4.0.1 but also XHTML 1.0, CSS 2.1 and javascript.
> Each just silently "corrected" the error. Unfortunately, but predictably,
> they didn't all "correct" it in the same way, meaning that Peter and his
> testers were consistently getting one result, and I was consistently
> getting another.
Although I agree, IMO you're forgetting an even more (and far more common)
danger: that silently fixed HTML errors can easily lead to output that is
wrong, but *not obviously wrong*.
Also note that this goes beyond just HTML. For instance, many Web sites do
not provide any or the correct character repertoire that applies (and
sometimes even claim 2 different charsets!), and browsers will often silently
guess which character repertoire to use. This can lead to outright nonsense
which is easily recognised, but can just as well lead to just the odd
character being wrong. You bet that in some cases that 'wrong' character
could make perfect sense and can thus go by undiscovered, even though it
could change the meaning of the content completely. AFAIK no browser will
warn the user in this case.
So use iCab, and/or put pressure on the makers of your favourite browser to
make their product useful.
Sander Tekelenburg <http://www.euronet.nl/~tekelenb/>
------------------------------
Date: Tue, 11 Jan 2005 11:31:25 -0800
From: Rob Slade <rslade@private>
Subject: Copyright and reverse engineering
> http://www.zdnet.com.au/news/security/0,2000061744,39176657,00.htm
>
> A French security researcher who published exploit codes that could
> take advantage of bugs in an anti-virus application, could be
> imprisoned for violation of copyright laws.
I warned ya.
OK, well not quite the same situation, but on page 21 of "Software
Forensics" I noted that this type of situation might one day result in a
malware author challenging evidence obtained by forensic examination on the
basis of the laws supposedly supporting copyright by inveighing against
reverse engineering.
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: Sun, 16 Jan 2005 18:21:10 -0500
From: Steven Branigan <steveb@private>
Subject: Re: High Tech Crimes Revealed" (Slade review, RISKS-23.65)
I am honored by the fact that Robert Slade took the time to do a review of
my book, "High Tech Crimes Revealed", back on December 29th, 2004. It covers
a few high tech crime cases from "inside the investigation", based upon
actual cases with which I was involved.
I believe that these stories are very relevant in today's society. We need
just look at the recent story about hackers breaking into T-Mobile to read
e-mails of an ongoing investigation to see that hackers are still getting
past computer security.
http://www.cnn.com/2005/LAW/01/12/cellular.hacker.ap/
I just wanted to address a couple of small points that I spoke with Robert
about prior to his publishing this review.
(1) steganography
The quote from my book is... "Rumors persist that Al-Qaeda style terrorist
groups have used steganography to hide their communications out in the
open. Using steganography, a person can hide a secret message inside a
picture that is sent via e-mail or even posted on a website. All that is
needed from the person receiving the picture is to extract the hidden
message from it."
Rumors do persist that terrorist have looked at using steganography for
clandestine communication.
http://www.fitug.de/news/newsticker/old/2001/newsticker200901125229.html
http://www.heise.de/tp/r4/artikel/11/11004/1.html
Let me state that I have not seen any conclusive evidence that steganography
has been used for terrorist communications. I do wish to point out, though,
that some in the government are concerned about it and are not looking into
it.
(2) Salami scam
I had a discussion with Robert and I believe that his view is that the
salami scam is all hype because there are very few documented cases of it.
I respect that point of view, but I believe that the following documented
cases are sufficient to be concerned about it as a potential crime.
http://www.collyerbristow.com/site/default.asp?s=55&cID=301&ctID=13&bhcp=1
http://www.nwfusion.com/newsletters/sec/2002/01467137.html
------------------------------
Date: Mon, 17 Jan 2005 11:14:44 -0500
From: Paul Robinson <ohshitidontknow@private>
Subject: Re: A Kafka day at the Los Angeles traffic ticket office (R.23-66)
[Open letter to Mark Frauenfelder:]
I saw the discussion of your problem with your wife's traffic ticket which
was also reported in RISKS-23.66. I am not a lawyer but I have some idea on
what your wife needs to do if you can't resolve the ticket because the
system won't record it:
Call (or preferably write) the headquarters office for the district attorney
for Los Angeles County. If you write, you explain the situation; if you
call you ask to speak to the district attorney or get an appointment,.saying
you need to discuss the disposition of a court case. You do not inform the
secretary of what the case is unless she says she has authority to negotiate
a plea bargain herself (which she won't of course). You'll get some lawyer
in the office but that's fine, because that's what you want..
If you can get a lawyer on the phone or you get an appointment, you explain
the circumstances of the situation and ask them to agree to dismiss the
charge and not prosecute this particular ticket because the case office is
not posting the ticket and you can't be put in a position where you are
"twisting, turning in the wind," waiting for an unknown and unknowable
filing to be made which places you in jeopardy of even more serious criminal
penalties when you can't get the current one resolved.
If they won't or you can't get someone, you file suit in Superior Court
against the District Attorney's office (you will probably have to sue the
D.A. personally by name) for a writ of mandamus prohibiting them from
prosecuting the original ticket. You may even be able to sue for damages
but I think all you're interested in is to get rid of the matter, either by
converting it off of a moving violation or getting it dismissed. I don't
think it would be that difficult to file for an order even without a lawyer
since you're only trying to solve the problem and the government, by its
incompetence or misconduct is placing you in a position in which you are
being denied the right to a constitutionally guaranteed speedy trial and
quite possibly to equal.protection and possibly other issues. Even if you
don't get the order you've got grounds to have any potential penalty for not
paying the ticket and not appearing canceled.
------------------------------
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.67
************************
This archive was generated by hypermail 2.1.3 : Fri Jan 28 2005 - 10:24:50 PST