precedence: bulk
Subject: RISKS DIGEST 19.18
RISKS-LIST: Risks-Forum Digest Thursday 22 May 1997 Volume 19 : Issue 18
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, caveats, etc. *****
Contents:
Software problems with new-generation air-traffic control center
(Peter B. Ladkin)
On-line change of postal address (Peter Scott)
Petrol bowser fun and games (Stuart Lamble)
Anti-spam bill introduced in U.S. House (Jim Griffith)
Anti-spam bill introduced in U.S. Senate (Lance J. Hoffman)
E-mail disaster: inadvertent use of a mailing list (Don Byrd)
DEC's OpenVMS has Y2K problem on 19 May 97: UNIX compatibility
(Smith and O'Halloran plus Tim Shoppa)
Risks of key recovery - and likely ineffectiveness (Clive Page)
Security risks from active usenet articles (Steve Atkins)
Java security architectures/testing methodology/flaws (Emin Gun Sirer)
Abortion.com suspends poll (Mich Kabay)
Re: Power system loss, despite multiple redundancy (Al)
Re: Fire ants and computers (James H. Haynes)
Re: Clock synchronization and relativity (Wayne Hayes)
Double Positives (Barry Jaspan)
Re: Time-Bomb Ticks in No-Name Pentium ... (William Hacker)
Risks of out of context information (Richard Brodie)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 21 May 1997 20:22:32 +0200
From: "Peter B. Ladkin" <
[email protected]>
Subject: Software problems with new-generation air-traffic control center
*Flight International*, 21-27 May 1997, pp. 26-27, has an article by Andrew
Doyle entitled "Moving Target", subtitled "Software problems are delaying
the completion of the world's most advanced air-traffic-control centre". The
$570M center is said by National Air Traffic Services (NATS) to be "the
largest and most advanced development of its kind in the world". The
problems have delayed the opening by 15 months and "stem from the unusually
high number of `bugs' which prime-contractor Lockheed Martin is having to
remove from the 1.82 million lines of software code at the heart of the
system."
The system is designed to fulfill 3,300 "functional requirements" and work
on 203 workstations. Around 1M lines were written initially by IBM staff
without previous ATC project experience. IBM's Federal Systems Division was
acquired by Loral, which was in turn taken over by Lockheed Martin. The
London area NATS program director, Dr. John Barrett, is reporting around 15
defects per 1,000 lines, as opposed to the expected figure of between 8 and
12. He claims they are clearing them at a rate of 500 per month, there are a
lot still to remove, and "we know where all the bugs are."
This last statement stands a very, very good chance of being false, for
reasons that should be well-known to RISKS readers. I tend to forget how
some segments of the software industry still likes to talk about its
product. I can imagine a nonexpert reader thinking, well, if you know where
those buggy lines are, why not just throw them away?
Being `buggy' or `correct' is not a property of single lines of code, and I
don't know how a professional can still talk in those terms. Significant is
that the system appeared to work on 30 workstations, but they had trouble
scaling up to 150. I wish NATS, and us air travellers, the very best of
luck. I also wish we could talk in more sensible terms in public about
software quality control.
Peter Ladkin, Universitaet Bielefeld, Technische Fakultaet, D-33501
Bielefeld, Germany
[email protected] +49 (0)521 106-5326/5325/2952
------------------------------
Date: Wed, 21 May 1997 16:41:52 -0700
From: Peter Scott <
[email protected]>
Subject: On-line change of postal address
The new USPS web site allows you to fill out a change-of-address form in a
web page, and send it to the post office
(
http://www.usps.gov/moversnet/coa.html).
By way of reassurance to the ill at ease, it goes on to state:
NOTE: The person who prepares and signs this form certifies that he or
she is the person, executor, guardian, authorized officer, or agent of
the person for whom mail would be forwarded under this order. Anyone
submitting false or inaccurate information on this form is subject to
punishment by fine or imprisonment or both under Sections 2, 1001,
1702 and 1708 of Title 18, United States Code.
thus advertising the fact that you can really cause trouble just by
pretending to be someone else...
Not that this hasn't been possible before with paper forms, just that now,
you could get screwed by many more people in many more countries than before.
I wonder if it's possible to instruct one's post office not to accept any
change of address except in person?
------------------------------
Date: Thu, 22 May 97 09:45:51 +1000
From: Stuart Lamble <
[email protected]>
Subject: Petrol bowser fun and games
Recently, My sister's fiance, Michael, needed some petrol, so, as people in
such situations tend to do, he pulled into a nearby service station
advertising unleaded petrol at seventy cents per litre. Off came the cap to
the tank, in went the nozzle of the fuel pump, and up went the amount of
petrol therein.
Having filled up, Michael went into the store to pay, to be confronted with
something of a shock: whilst he was busily filling up, the computer
controlling the pricing at the pumps had decided to go troppo. Petrol was
now costing around ten or so _dollars_ per litre - over ten times the
advertised price. The net bill to him? A mere $600.
Being in a company car, he paid the bill (on the company's petrol card, as
it happened; I doubt he would have done so if it had been his own money.)
Meanwhile, another guy had done something similar, and was faced with a bill
of $800 or so. Out came the calculator, and the cashier was offered around
the sum that would have covered the petrol at the advertised price. Said
the cashier, "You must pay the full bill, as otherwise our books won't
balace. The company will credit you for the difference." The man refused,
handed over the sum he had offered, and went out, driving off; the cashier
took his license plate number for the police.
The risks should be obvious - or maybe this is just a harbinger of things
to come with the next fuel crisis?
[Fuel and his money are soon charted. PGN]
------------------------------
Date: Wed, 21 May 1997 19:54:53 -0700
From:
[email protected] (Jim Griffith)
Subject: Anti-spam bill introduced in U.S. House
Reuters reports today (via the CNN web page at www.cnn.com) that New Jersey
Republican Representative Chris Smith has introduced the "Netizens
Protection Act of 1997". Intended to be an effective extension of the 1991
Telephone Consumer Protection Act, which bans unsolicited junk faxes, his
NPA would "ban unsolicited commercial e-mail including get-rich-quick
schemes, unproven medical remedies and similar solicitations that can cost
recipients money by incurring online charges".
As much as I support his actions, I find myself using my favorite anti-CDA
argument against it - in that even if this law is passed (one can only
hope), those who are determined to spam will merely do so from overseas.
But it sounds like a good start.
Jim
------------------------------
Date: Thu, 22 May 1997 12:14:39 -0400 (EDT)
From: "Lance J. Hoffman" <
[email protected]>
Subject: Anti-spam bill introduced in U.S. Senate
Senator Murkowski of Alaska has introduced S. 771, the Unsolicited
Commercial Electronic Mail Choice Act of 1997. It would, among other
things, require unsolicited commercial e-mail to include the word
"advertisement" as the first word of the subject, provide a real name and
Earth-based locator information, and require ISPs to terminate service to
violators (as determined by the Federal Trade Commission). Within a year
from passage, larger ISPs would be required at customer request to filter
e-mail with the "advertisement" tag (and all ISPs would be required to
notify new and existing customers of this service).
Details are at
http://www.senate.gov/~murkowski/commercialemail
Professor Lance J. Hoffman Dept of Elec Eng and Comp Sci, The Geo Washington U
801 22nd St NW Wash DC 20052 (202) 994-5513
[email protected]
------------------------------
Date: Thu, 22 May 1997 14:16:24 -0500
From:
[email protected] (Don Byrd)
Subject: E-mail disaster: inadvertent use of a mailing list
A friend of mine got fired by the large utility company he worked for last
week for what might be called "accidental spamming". He tried to forward a
humorous, feminist-oriented message to his friend Ken Something-or-other.
Like many people, my friend has aliases set up for people to whom he
frequently sends e-mail, each named by the person's first name; so, he
forwarded the message to "Ken". So far, so good.
Unfortunately, he forgot that, months before, he'd been given a mailing
list named "Ken" of some 500 people--namely, everyone in information
systems at all the company's locations. And his mail program, Reflections,
didn't give him clear feedback about who "Ken" was until _after_ he'd sent
the message. Also unfortunately, his company is under intense government
scrutiny. My friend immediately e-mailed an apology to "Ken". He also told
his boss and his boss' boss what had happened and they told him not to
worry about it. However, a senior official decided the company couldn't
keep him around in case some employee complained, e.g., about sexual
harassment. (The government scrutiny is because of problems with their
nuclear power plants and such, not sexual harassment charges.)
An e-mail client could protect its users against disasters like this in a
number of ways. For example, in this case, it could have displayed "Ken
(500 subscribers)" as soon as "Ken" was added to the list of addresses.
And/or it could require confirmation before sending to any list of more
than, say, 25 names; or it could let the user tell it to require
confirmation before sending to a given list. I've seen just one program
that does anything along these lines: RMAIL, a mail client that runs inside
emacs.
Of course, in my friend's case, someone in his company really set it up by
giving this mailing list _such_ a misleading name.
Caveat usor.
Don Byrd, Computer Science Department, Center for Intelligent Info. Retrieval
Univ. Massachusetts, Amherst MA 01003 413-545-3147
[email protected]
------------------------------
Date: 22 May 1997 16:17:38 -0700
From:
[email protected] (Smith and O'Halloran)
Subject: DEC's OpenVMS has Y2K problem on 19 May 97: UNIX compatibility
The 20 May 1997 editions of newspapers in Alameda County (east of the San
Francisco Bay) reported a problems where the police computers ran out of
dates. The article said that Bay Area police departments in Emeryville,
Oakland, Piedmont, Walnut Creek, and portions of the Contra Costa County
Sheriff's Dept all use DEC's Open VMS System. It appears that Open VMS hit
the equivalent of the TOPS-10 DATE75 problem on Monday, 19-May-97.
I posted to alt.sys.pdp10 this message:
>Why would a 64-bit OS have a 27-year date limit? Something in the PDP-11
>compatible RMS stuff? I can't believe that DEC didn't learn from the
>DATE75 problem.
Here is the response:
: From:
[email protected] (Tim Shoppa)
: Newsgroups: alt.sys.pdp10
: Subject: Re: Open VMS has a DATE75 problem?
: Date: 20 May 1997 22:51:51 GMT
: Organization: TRIUMF, Canada's National Meson Facility
: Message-ID: <
[email protected]>
: References: <
[email protected]>
:
: DEC did learn from the DATE75 problem. The internal VMS representation
: of time works until 31-JUL-31086 02:48:05.47. The problem with
: 19-May-1997 is that some C programmers like to know the number of
: days from 1-Jan-1970 (the Unix base time). To do this, these
: programmers used some "Delta-time" routines that are part of the
: VMS system libraries. These delta-time routines have a maximum of 9999
: days difference built in to them, and this maximum was well documented
: in the library manuals. Nevertheless, application programmers
: tended to ignore this restriction and use the delta-time routines
: anyway. Recently, some optional components of OpenVMS (such as the
: Security Server) were written in C and would suffer from the same
: problems, so this delta-time trap was more insidious than just affecting
: third-party applications.
:
: DEC, in order to step around this problem, has released patched
: delta-time routines which no longer have the original documented 9999
: day limit. As a result, application programs written in C which
: calculate delta-times from 1-Jan-1970 will continue to work properly
: after the patch is applied, despite the fact that the application
: programmers blissfully ignored the documented restrictions.
:
: The 9999-day limit on delta times had always existed. It's just
: that the proliferation of programs which like to know the number of
: days since the Unix base time is now the largest abuser of this limit.
: Before 19-May-1997, you'd encounter exactly the same problems if
: you tried to calculate the delta-time between any two dates more than
: 9999 days apart.
:
: Tim. (
[email protected])
INWAP.COM is Joe and Sally Smith, John and Chris O'Halloran and our cats
See
http://www.inwap.com/ for "ReBoot", PDP-10, and Clan MacLeod.
------------------------------
Date: Thu, 22 May 1997 11:38:16 +0100 (BST)
From: Clive Page <
[email protected]>
Subject: Risks of key recovery - and likely ineffectiveness (RISKS-19.17)
One thing the executive summary might have pointed out (but perhaps the
authors thought was beyond their remit) was the likelihood that key-recovery
methods will be largely ineffective against organised criminals, terrorist
groups, and the like, should they choose to equip themselves with suitable
software.
Surely such outlaws are likely to use steganography (i.e., encrypting their
messages using some non-escrowed system such as PGP, hide the result in the
least-significant bits of some ordinary-looking image or sound file, and
then perhaps encrypt the result using an approved and recoverable key
system). Even if the authorities get legal powers to recover their keys and
decrypt all their messages, they will still not be able to get the
information they want. I don't know whether software packages are already
available to do all this, but if not surely they soon will be? And I
suspect that it is not, at present, illegal to sell them in most places.
The main drawback of steganographic techniques is the large increase in
bandwidth; this will make it unattractive to many high-volume users such as
banks, but won't be seen as much of a problem by criminals passing
occasional messages via e-mail etc. So the net result will be that
government agencies will be able to snoop on the private messages of
law-abiding citizens, but not on those of serious law-breakers.
Clive Page, Dept of Physics & Astronomy, University of Leicester
[email protected]
------------------------------
Date: Thu, 22 May 97 14:36:46 EDT
From:
[email protected]
Subject: Security risks from active usenet articles
If I don't run a web browser then I'm immune to all the
(java/javascript/activeX) security holes, right?
Well, no.
I was just reading usenet using the Netscape Navigator newsreader, when
suddenly a browser window appeared and started connecting to a site.
Looking closer, the news article had a ten-line uuencoded html document
attached to it, with a .html extension.
Navigator recognised the .html extension, fired up the browser component and
executed the Javascript contained in the attachment.
Fortunately the Javascript was benign - all it did was open a new browser
window pointing at the posters site.
If it hadn't opened that new window, though, there would have been no sign
that the Javascript was executing.
Neat trick, but the security holes are obvious.
I guess the same thing would work with e-mail received by Netscape or
Internet Explorer - 'GOOD TIMES' anyone?
(It's <news:
[email protected]> advertising
http://www.pandact.co.uk/ if anyone wants to take a look)
Steve Atkins --
[email protected]
------------------------------
Date: Tue, 20 May 1997 04:18:50 GMT
From: Emin Gun Sirer <
[email protected]>
Subject: Java security architectures/testing methodology/flaws
Our group at the University of Washington has developed an alternative
security architecture for Java systems based on factored components. In the
course of implementing this architecture, we built a clean-room Java
verifier and tested it using a variant of N-version programming and mutation
testing. In short, we took a set of valid class files, introduced errors
into them, and checked if our verifier agreed with commercial verifiers on
the safety of the mutated code. If we accepted some code that was rejected
by a commercial verifier, we fixed our verifier and resumed testing. If the
commercial verifier accepted some code that we rejected, we first
double-checked our verifier and the Java specification, then flagged the
flaw in the commercial verifier. We repeated this process 2.5 million
times, and in the process uncovered a number flaws in the Java
implementations found in Microsoft Internet Explorer 4.0 and Sun JDKs 1.1.1
and 1.0.2. Microsoft and Sun have both announced security patches for the
flaws that they decided to fix immediately.
A few of the flaws involve breakdowns in the typesafety guarantees of Java,
which expose web users who execute foreign Java code to security attacks. A
flaw in typesafety may allow an application to gain access to restricted
data or to restricted services. Some of the other flaws are deviations from
the JVM specification, and a few are particular unenforced interpretations
of an ambiguous specification.
Our web site,
http://kimera.cs.washington.edu, contains the details of our
architecture, verifier, testing methodology, and the flaws that we found.
Emin Gun Sirer, Sean McDirmid, Prof. Brian N. Bershad
------------------------------
Date: Wed, 21 May 1997 22:12:54 -0400
From: "Mich Kabay [NCSA]" <
[email protected]>
Subject: Abortion.com suspends poll (Re: RISKS-19.16)
Wired Magazine's Web site reports that <
http://www.abortion.com> has
suspended its electronic poll. The anonymous article states that the site
displays the following message: "We have received notice that the voting
numbers seem inaccurate. We have removed the voting program so we can
review it for any possible errors. We apologize for any inconvenience."
M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA)
http://www.ncsa.com
------------------------------
Date: Wed, 21 May 97 09:29:05 EDT
From:
[email protected] (Temporary Admin)
Subject: Re: Power system loss, despite multiple redundancy (Stevens, R-19.15)
In the early 1970's I was working as a transmitter engineer at a 750,000
watt UHF TV station in mid-Missouri. The transmitter was located 20 miles
or so outside of town in a corn field, with an 1100 foot antenna and the
transmitter housed in a metal structure on a concrete slab. The transmitter
itself was a massive structure, water-cooled, maybe 8 feet high, 12 feet
wide, and 20 feet deep, and there was a door where you could walk inside the
transmitter enclosure for maintenance. The toilet facilities were simply in
the back corner of the building, not enclosed, but mostly hidden behind this
massive transmitter enclosure.
One day several members of the family that owned the TV station showed up to
do maintenance. The wife of one of the owners asked where the toilet was,
and was directed inside.
Shortly thereafter, all of us outside hear this LOUD BANG!!!, followed
immediately by screaming. The woman had seen the door to the transmitter
enclosure, figured that was the toilet, and had opened the interlock while
the 750,000 watt transmitter was running.
I didn't ask if she _still_ needed to use the facilities.. :-)
Al
------------------------------
Date: Wed, 21 May 1997 10:59:49 -0700
From: "James H. Haynes" <
[email protected]>
Subject: Re: Fire ants and computers (RISKS-19.17)
A speaker from Metricom, the wireless modem people, reported that they had a
lot of trouble early on with fire ants infesting their pole-top repeaters,
especially in Florida. The repeater enclosures are vented to the
atmosphere, originally through a piece of Gore-Tex(tm) fabric. They found
the ants would chew through the fabric to get inside the repeaters; so they
had to back the Gore-Tex with a very fine stainless steel mesh to keep the
critters out.
It was his opinion that the ants were heat-seeking rather than attracted to
electricity.
However I see by the paper that the city council in Hope, Arkansas took up
the weighty matter of fire ants in one of their meetings and concluded that
the ants are attracted to "electrical boxes and anything containing relays".
------------------------------
Date: Thu, 22 May 1997 12:39:30 -0400
From: Wayne Hayes <
[email protected]>
Subject: Re: Clock synchronization and relativity (Klossner, RISKS-19.17)
> It's not meaningful to compare a clock in Denver with a clock in
> California to within a microsecond, ...
Not true. The two locations are essentially fixed with respect to each
other, except that they are both in a very slowly accelerating frame (the
Earth rotates once a day, revolves around the Sun once a year, around the
Earth-Moon centre-of-gravity once a month, etc). The Earth's surface can,
at this level of synchronization, be considered an inertial frame, at least
from the standpoint of special relativity. Special relativity has no
problem with synchronization of clocks that share an inertial frame,
regardless of the distance that separates them.
The test of whether a frame is inertial ("flat") can be found in
Chapter 1 of _Gravitation_, by Misner, Thorne, and Wheeler.
[Let me add that the thread on leap-seconds was pretty much a red herring.
Also, the Y2K thread is petering out -- until the next big fiasco. PGN]
------------------------------
Date: Thu, 22 May 1997 15:27:32 -0400
From: "Barry Jaspan" <
[email protected]>
Subject: Double Positives (Re: ~2K, Frankston, RISKS-19.16)
>> * "no no" means No! It rarely means yes.
This reminds me of a story. A linguist was giving a talk at a conference
and made the point that English is one of the few languages *without* a
double-positive ("yes, yes") that actually means a negative ("no"). While
pausing to let his statement sink in, someone from the audience
sarcastically exclaimed, "Yeah, right." (DejaNews found a few references to
this story in alt.usage.english but they included no attributions, so
probably its apocryphal.)
The RISK? Hmmm, let's see, there must be one somewhere. How about: People
rarely mean what they say, and computers generally can't tell the
difference?
Barry
------------------------------
Date: Fri, 16 May 1997 13:28:23 -0700
From: William Hacker <
[email protected]>
Subject: Re: Time-Bomb Ticks in No-Name Pentium ... (Baker, RISKS-19.15)
I have to agree with Henry Baker about the motherboard makers possibly
spreading FUD. Let's look at some of the claims of the article from a
former hardware engineer's point of view. (I'm now a manager so I've
probably forgotten everything ;-) ).
1. I took an unscientific survey of my "no-name" clone motherboards (four
brands) and found the same components that the "name" makers use. I'm
not sure of the chip bypass caps because they are too small to stamp a
company logo on. Given this limitation, how did they determine the
"no-names" have cheap ones?
2. One of the major purposes of the bypass caps is to reduce the transient
energy localized around high speed circuits. This energy has an annoying
habit of producing radiated RF. Many of the no-name motherboards are
used in computer systems that meet the class B emission levels required
by the FCC (USA). If the "no-names" have bypassing that is inadequate
enough to damage the processor, it possibly follows that they would NOT
also pass the EMI requirements.
3. The seriously excerpted article (I have not read the original) seems to
imply that "more is better" when it comes to bypass caps. In my
experience as an EMI engineer, (one of my many hats) I found that
generally, (a broad brush, I admit) that's not necessarily true.
Sometimes, large numbers of bypass caps are used to compensate for poor
PWBA layout practices. As clock frequencies increase and processors (and
all high speed ASICS for that matter) become more demanding of careful
layout and bypass practices, I submit that it is not sheer numbers of
caps that determine "quality".
4. A brief note on some of the reply comments to the original message.
Ripple frequencies on power supplies approaching clock cycles????
Yow, let me know the name of the power supply manufacturer that has
ripple on their output that has significant harmonics that exceed
even 30 Mhz, and I'll report them to the FCC. Considering that many
modern processors have internal clock frequencies exceeding 200
Mhz or more, this hardware engineer has never heard of such a phenomenon.
Transients in high speed circuits caused by electrons vibrating when
they hit semiconductor material???? Hmmmm... I always thought it
was the charging and discharging those pesky capacitances that some-
how seem to crop up in ICs. (High-speed CMOS is particularly annoying
in this respect). Admittedly, I took semiconductor physics some
years ago, but that's the first time I have heard of the new
electron quantum states of ON and OFF !!!?
PS: Yes Hacker is my REAL last name. I have been a Hacker for 40+ years.
William Hacker Director of Technology Services, U.S. Data Source
------------------------------
Date: Thu, 22 May 1997 14:31:52 +0
From: "Richard Brodie, RAL x6245" <
[email protected]>
Subject: Risks of out of context information
There is an interesting side issue to the newmediagroup.com spam attack
story (Youll, RISKS-19.16 and Gulbrandsen, RISKS-19.17).
Both Jim and Arnt refer to enterprise.net as "a UK ISP". Presumably they got
this information from the postal address given by the InterNIC.
However, the Isle of Man is not part of the UK, nor subject to UK law. I
can't say whether or not it is relevant to the present case but there is an
obvious risk of net abuse originating from territories that may not have
suitable legislation.
Richard Brodie
------------------------------
Date: 1 Apr 1997 (LAST-MODIFIED)
From:
[email protected]
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. Or use Bitnet LISTSERV. Alternatively,
(via majordomo) DIRECT REQUESTS to <
[email protected]> with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
INFO [for unabridged version of RISKS information]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to
[email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available:
ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
[volume-summary issues are in risks-*.00]
[back volumes have their own subdirectories, e.g., "cd 18" for volume 18]
or
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
get illustrative.PS
------------------------------
End of RISKS-FORUM Digest 19.18
************************
