Subject: RISKS DIGEST 16.89

Subject: RISKS DIGEST 16.89
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Friday 10 March 1995 Volume 16 : Issue 89

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, etc. *****

Contents:
Celsius-to-Fahrenheit conversion risk (Michael Tobis)
Two on net porn charges (Jonathan Bowen)
Re: 6-cent T-shirts (Evelyn C. Leeper)
Re: Remote-Control Risks (Mike Cavanagh)
Consumer electronic problems (Les Hatton)
Can Pakistan Eavesdrop in America? (Peter Wayner)
Sow's Ear from a Purse (Joseph H Presley)
Resetting BSD/OS is easy as resetting MS-DOS (Re: Sparc10) (Kenji Rikitake)
Re: Microsoft and Lotus spreadsheet errors (Tony Lauck)
Loss of one of the X-31 research airplanes (Peter Ladkin)
PGP Moose: moderator authentication and antispamming tools (Greg Rose)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

----------------------------------------------------------------------

Date: Wed, 8 Mar 95 18:15:15 CST
From: [email protected] (Michael Tobis)
Subject: Celsius-to-Fahrenheit conversion risk

I thought the RISKS readership shouldn't miss this gem, posted in
sci.geo.meteorology by [email protected] (Steven Babin at Johns
Hopkins University Applied Physics Laboratory):

> There seems to be some confusion over the giant iceberg. [...]
> The Reuters news agency reported that the iceberg was 656 feet 2
> inches thick, implying a tremendous accuracy of measurement. It
> is actually 200 m thick and the reporter converted this to English
> units. Reuters also reported that this event was the result of a
> 36.5 F increase in temperature since the 1940's. It was actually
> a 2.5 C increase. The reporter apparently converted this to F
> as a temperature rather than a temperature difference.
> I don't know whether this speaks more for the educational level of
> reporters or more for the fact we should all be using SI units.

The risks of the transmission of technical information by people who don't
know what they are talking about will be familiar to RISKS readers. Perhaps
more striking is the risk that something as simple as a Celsius to
Fahrenheit conversion algorithm can be misused by making invalid assumptions
about context.

Michael Tobis [email protected]

[And the mention of SI reminds me of Steve Lipner's OLD joke about
being an SI, namely a Civil Engineer. (For those of you who don't
get it, sivil injinears are not supposed to be able to spell.) PGN]

------------------------------

Date: Fri, 10 Mar 95 13:13:31 GMT
From: [email protected]
Subject: Two on net porn charges

Newspaper: The Times Higher Education Supplement
URL: http://www.timeshigher.newsint.co.uk/
Reference: page ii, Multimedia news section, 10 March 1995
Headline: Two on net porn charges

An 11-month investigation by West Midlands police has led to two men being
charged with distributing child pornography on the Internet. The charges
arise from a raid by police on the metallurgy department at Birmingham
University following information on child pornography passed to them by
federal authorities in the United States. ... The prosecution is seen as
[a] test case on what can be legally transmitted globally across the network
from computer hosts.

Jonathan Bowen, Oxford University Computing Laboratory, Programming Research
Group, Wolfson Building, Parks Road, Oxford OX1 3QD, England.

------------------------------

Date: Thu, 9 Mar 1995 19:50:44 GMT
From: [email protected] (Evelyn C. Leeper)
Subject: Re: 6-cent T-shirts

> we end up with .06 cent t-shirts and free shallots.
XXXXXXXX

This is a pet peeve of my husband's (and by extension, of mine, I suppose).
He keeps trying to explain to the clerks why they should sell him that
two-liter bottle of Coke for a cent, when the sign says, ".99c" ("c"
actually being a cents-sign).

The Risks in this? I suppose it's the risk that if people have turned over
all their computing to machines and don't even *think* about where the
decimal point should go, then we're all in trouble.

Evelyn C. Leeper | +1 908 957 2070 | [email protected]

------------------------------

Date: Thu, 9 Mar 1995 02:18:41 +0100 (GMT)
From: mike <[email protected]>
Subject: Re: Remote-Control Risks

I was interested to see the examples of optical remote-control systems being
upset by other light sources. In my student days I worked as a TV engineer
in holidays. A customer complained that his set would randomly switch
channels. Several weeks of to-ing and fro-ing to the workshop failed to
find a problem. Eventually the cause was found. The customer kept budgies
in an aviary outside the window next to the TV. The set had an ultrasonic
remote control. The budgies were setting off the remote. If you made the
budgies tweet, the set changed its channel.

These risks are still there 20 years later.

Mike Cavanagh

[A new Hallowe'en motto: Click or tweet?
With the new noise-cancellation techniques,
the challenge is how to balance the budgies. PGN]

------------------------------

Date: 10 Mar 1995 11:44:38 +0000
From: Les Hatton <[email protected]>
Subject: Consumer electronic problems

Has anybody heard of consumer electronic stuff being recalled because of
software problems yet? The reason I ask is that most such products will
have massive amounts of software in them by the end of the decade, (many
tens of thousands of lines in such things as televisions, cars, washing
machines, electric razors and so on).

As an example:

In August'94 I rented a Vauxhall Omega car for 1 month. This car was brand
new and consequently has a number of micro-processor controlled systems.

In the first week, the sun-roof started to oscillate (in the rain!). The
sun-roof is a simple rotating switch which you turn to the position you want
the roof and then leave it to move there. Mildly concerned and alternately
dampened by this, my eldest son figured out that by pushing the button, the
roof reset. On looking through the manual, in tiny writing at the back,
this featurette was described, "in case of some circumstances when the
sun-roof ...".

One week later, I discovered one morning that the car was completely without
power - not even the control panel lights came on. A volt-meter revealed
that the battery was perfectly OK. A call to the RAC (Royal Automobile
Club, a UK organisation that operates a rescue service like the US. AAA),
brought an engineer out who said it was one of two things, one of which he
could fix. He moved the drive lever from Park to Drive and back and all the
lights came on and the engine would then start. (The drive train is also
controlled by a microprocessor in this car). I asked him what was the one
he couldn't fix. He said that on this model, the auto immobiliser (the cute
little button on the key ring) could in some circumstances at the edge of
its range so immobilise the car that only the factory could get it going,
(the ultimate theft deterrent!). I suspect that this is also controlled by
a microprocessor. In fact on this car, the radio is controlled by two
microprocessors !

In terms of reliability growth modelling, one person experiencing two
defects and hearing of another in just one month in one car adds up to a
shaky reliability record.

Hence my question at the beginning. Maybe its just me, because I'm in the
profession.

Les Hatton, Ph.D. C.Eng, Director of Research & Engineering, Programming
Research Ltd, England [email protected] +44 (0) 1 932 888 080

------------------------------

Date: Thu, 9 Mar 1995 14:44:35 -0500
From: [email protected] (Peter Wayner)
Subject: Can Pakistan Eavesdrop in America?

RISKS-16.88 includes a transcript of a Voice of America broadcast describing
Pakistan's hardball play to get access to Motorola's best cellular
eavesdropping technology. The transcript says that Pakistan shut down
Motorola's cellular service until it got the device that would let them
eavesdrop on all conversations.

I'm not sure if Motorola complied, but I hope that someone asked these
questions:

1) Can this eavesdropping hardware work in the United States? Many speculate
that Pakistan wants to be (or is) a member of the nuclear club of nations.
When a Princeton undergraduate designed a nuclear bomb for credit, he was
visited by someone who seemed to be a Pakistani intelligence operative. The
goal? Nuclear information.

2) Can this eavesdropping hardware work against Motorola? Industrial
espionage is a popular way for countries to do "research." Does Pakistan
want to build up a local electronics company?

3) Can this eavesdropping hardware be used against US companies angling for
business in Pakistan?

4) Will the technology make its way into the hands of the terrorists?
Several days ago, US citizens were killed in an ambush. The dead included at
least one intelligence operative. Today's Washington Post says that some
witnesses claimed a police car with a submachine gun mounted on the top
stood by idling and let the killers get away. The excuse is that they were
afraid. The ambush was supposedly retaliation for the US capture of
terrorists.

Years ago, we only needed to worry about whether we could trust our
immediate neighbors and the other folks in town. Now trust is a global game.

------------------------------

Date: Fri, 10 Mar 95 10:39:21 EST
From: [email protected] (Joseph H Presley)
Subject: Sow's Ear from a Purse (Tepper, RISKS-16.88)

A zealous and unscrupulous prosecutor could "prove" that the KJV (King James
Bible) is obscene by using a mask of A=[KJV xor obscene]. [A xor KJV] gets
you the obscene file. Can you imagine trying to prove that you didn't just
erase your encryption mask to a technologically naive jury?

I should also mention that you could transmit A as your file and your
recipient use KJV as the encryption mask.

Joe Presley

------------------------------

Date: Fri, 10 Mar 1995 13:17:25 +0900
From: Kenji Rikitake <[email protected]>
Subject: Resetting BSD/OS is easy as resetting MS-DOS (Re: Sparc10 keyboards)

The Sparc10 story reminds me of my 486 PC running BSD/OS; it was configured to
ask for rebooting if you press CTRL+Alt+Delete as default. I immediately
disabled this feature. I even consider this a bug, although you can fix it
by recompiling the kernel.

Think about this. Most MS-DOS users know CTRL+Alt+Delete, and many
of them just do it if they think they have done something wrong with their
PCs. And few of them know the difference between MS-DOS and BSD/OS; what if
they start to use BSD/OS? Rebooting everytime they think they've got crashed?

BSD/OS has another design flaw on its X server. You can terminate it anytime
by pressing CTRL+Alt+Backspace. This is enabled as default, though you can
turn this off by its configuration file. I respect flexibility of UNIX, but
it's obviously dangerous to enable emergency-stop features to everybody.

// Kenji Rikitake <[email protected]>

------------------------------

Date: Thu, 09 Mar 1995 09:46:17 -0500
From: [email protected] (Tony Lauck)
Subject: Re: Microsoft and Lotus spreadsheet errors

Errors in financial calculations are not new. When I worked at Autex, Inc.
in the early 70's I wrote a program to calculate bond tables. I was told
that my calculations, right or wrong, had to agree with a certain book that
all the traders used. Bond prices were given in dollars and cents and I was
told that a difference of one cent was unacceptable. A one cent error in a
large trade could easily cost more than a Wall Street lunch for two, hence
was significant.

The bond table book gave the formula used and indicated the method of
rounding. It was very easy to duplicate these calculations, but would they
agree using a different processor? By printing out my own version of the
book and comparing each entry by hand I found only a single error, in the
amount of one cent. In the early 70's fancy desk calculators still ruled.
The one I happened to have had a switch that controlled rounding mode (down,
up, halfway) so it could do interval arithmetic. Cranking the calculation
on this calculator to 15 digits I was able to bound the correct value. It
was almost exactly halfway between two pennies, and my rounding was correct.
(This didn't surprise me as I had used 64 bit floating point, a large
number of guard digits indeed for a four decimal place answer.)

Knowing that I was right and the book wrong was a nice position. I discussed
this with my boss and we decided to stick with our value. I secretly hoped
there would be a dispute someday between two traders over this entry,
figuring that I could somehow turn this into a nice lunch. No such chance.

Do people still use these old tables? How many have errors?

------------------------------

Date: Mon, 6 Mar 1995 00:22:37 +0100
From: [email protected]
Subject: Loss of one of the X-31 research airplanes

Flight International, 1-7 February 1995, reports the loss of a
Rockwell-Daimler-Benz Aerospace X-31A enhanced fighter-manoeuverability
research aircraft on 19 January 1995. `Investigations [..] are
focusing on the air-data system, say sources close to the project.
"There is a possibility that hardware operation of some of the systems
may be involved [and] it cannot be excluded that the instruments were
giving false readings," says one source, adding that there is no indication
that the aircraft's advanced flight control system was involved [..].'

Flight International, 8-14 February 1995, reports that investigations are
centred on the pitot-static system (which measures altitude and airspeed by
means of pressure differentials, and that pitot icing is suspected by some.
`The aircraft was [...] in straight-and-level flight, when [the pilot]
detected false airspeed readings, followed by pitch oscillations. These
increased and were followed by a violent roll before [the pilot] ejected.'

So, investigators suspect that false sensor readings caused by icing-up of
the sensors led to inappropriate actions of the flight control system which
led to loss of control. Generally, airplanes which may fly in instrument
conditions, i.e. clouds, including my Piper Archer, are equipped with pitot
heat to avoid similar problems, but if my pitot ices up, all I lose is my
airspeed indicator, and not my control. A colleague who is a Chief Engineer
at NASA Dryden, where the accident took place, points out that airplanes
such as F4s, which are not fly-by-wire airplanes, have also been lost when
false sensor readings led to inappropriate actions of the flight control
system - but in the case of an F4 it is a mechanico-hydraulic system rather
than a computer. She suggests that a distinction be made between the flight
control system itself, which implements the control laws, and the system
that sends signals to the actuators to wiggle the control surfaces.

While we may not be able to ascribe the `fault' to a `computer' in this
case, it does raise the continuing issue as to how one ascribes faults. It
is always possible in theory to replace a computer control system by wires,
pulleys, hydraulics, bells and whistles - but not to fit all this hardware
in the same airplane all at the same time. For example, Airbus argues that
its computer-controlled airplanes are `evolutionary', that is, the same
control characteristics could be achieved with more traditional control
systems - and the only consequence of computer control is weight savings,
and therefore extended range or the ability to carry more passengers. This
is debatable. The more interconnection between systems contributing to
control (possible when most things are software unless extreme care is
taken), the more opportunity for an inappropriate sensor reading to send
everything haywire. The X-31 would not be able to fly without computer
control. It is true that any individual system fault may be replicated by
means of wires, pulleys and hydraulics. But I doubt that this knowledge
would help anyone to analyse the fault and prevent its reoccurrence. I
suspect that techniques developed by computer scientists for dealing with
safety-critical computers are more useful. Whereas in the case of my
Archer, only plumbers would be involved ........

Peter Ladkin

------------------------------

Date: 10 Mar 1995 20:28:33 +1000
From: [email protected] (Greg ROSE)
Subject: PGP Moose: moderator authentication and antispamming tools

-----BEGIN PGP SIGNED MESSAGE-----

PGP Moose
=========
by Greg Rose <[email protected]>

The aim of this software is to monitor the
contents of consenting moderated newsgroups, and
to automatically cancel messages that appear in
the newsgroup without having been authorised by
the moderator(s) of the group. This has
(obviously) been prompted by the recent spammings.

PGP, the crux of the cryptographic software, was
written by Phil Zimmermann <[email protected]>, who
otherwise has nothing to do with this. The
cryptographic framework was written by Greg Rose
<[email protected]>. The INN news
system hooks are being provided by Chris Lewis
<[email protected]>.

How Does It Work?
- -----------------

When a moderator wants to protect their group from
forged/unapproved postings, they should register
their interest with one or more of the sites
running PGP Moose, and pick up the submission
script. As part of this process, the moderator
would specify a PGP public key that is allowed to
approve postings.

When a post comes in, and the moderator wishes to
approve it, they do whatever they would normally
do before actually using inews (or whatever) to
post the message. As their last action, they run
the PGP Moose Approval program "pmapp". This
inserts a special form of Approved: header which
looks like this:

Approved: PGP Moose V0.9 950310 sci.crypt.research
iQBVAgUBL1/Kg2zWcw3p062JAQEYIgH/Xyrz6LaGG+fHaSxoexMECovzkIoADrQx
l73IXlUQEIoFl5jnDBBdHVvqTMEPS0118ytYVQZoQrdStuXB9Oc9gQ==
=azqs

In this example you can see that the approval
carries a date stamp and the name of the newsgroup
in question. These, as well as the From: and
Subject: lines, and the non-blank lines of the
message itself, are used as input to the PGP
program to generate a signature. The PGP signature
is the inserted into the Approved: header, mostly
so that it won't interfere with, or be confused
with, any signature in the body of the message.

Anybody can check whether the message has been
modified in any significant way, simply by running
the PGP Moose Approval Checking program "pmcheck".
More importantly, though, the sites running the
PGP Moose Checking Daemon will be doing this
automatically for every posting to the registered
newsgroups. And, if a posting fails the checks, it
will be automatically cancelled and a notification
sent to the moderator.

This software is made freely available for just
about any purpose, but I've retained copyright so
as to keep some semblance of involvement. See the
last section of this file.

The Bits:
- ---------

PGP Moose consists of a number of Bourne Shell
scripts calling standard Unix utilities and PGP.
I could have used perl more elegantly, but this
stuff is marginally more widely available. If
there are Unix version dependencies, they should
be considered to be bugs and I'll happily attempt
to remove them.

pmapp usage: pmapp newsgroup [file]

This script takes the not-yet-posted
article, specified either by filename or
from standard input, and creates a
signature for it, which is then inserted
in the Approved: header. The article,
ready for posting, appears on the standard
output.

In the configuration section at the top of
the script, the moderator may build in the
PGP User Id to be used for the signature,
and the corresponding password. This is
simply for convenience, since spammers are
not so likely to go cracking the computer
to get the password, and it is a
relatively simple matter to generate a new
user if it is, indeed, compromised. For
the paranoid, like myself, if the password
is not configured into the script it is
read from the terminal instead.

pmcheck usage: pmcheck [article]

This script takes the article, specified
either by filename or from standard
input, and checks that the Approved: line
is something it considers to be correct
and that the article has not been
tampered with. Pmcheck returns
successfully if everything checks out.
Otherwise it will return failure and
issue one of a number of error messages,
for example:

Usage: $0 [article]
Posting not approved with PGP Moose.
Wrong newsgroup: $6 != $GROUP.
Bad signature (altered or damaged file) on $FILE.
Signature '$SIG' on $FILE invalid for newsgroup $GROUP.

Anybody can run pmcheck. It behaves
slightly differently depending on the
existence of a file called (by default)
PGP_Moose_accept. This file, if it exists,
should contain lines with a newsgroup
name, some whitespace, and the PGP User Id
approved by the moderator (usually made up
specifically for this purpose). For
example:

sci.crypt.pgpmoose pgpmoose test <[email protected]>

If such a file exists, pmcheck is silent
if all is well, and issues the last of the
error messages above if everything else
was all right but the signature was from
the wrong person.

Without such a file, if the signature is
otherwise valid you will get a message
like:

Valid signature from '$SIG'.

A script is being developed by Chris Lewis (who
has more control over news stuff than I do) which
will perform the automatic cancellations. Stay
tuned. There is plenty of prior art, so this
shouldn't take too long.

Soon, when I get back from my trip in two weeks,
I will create mail server scripts that allow
moderators who are not using Unix to use these
facilities. The first allows a moderator to mail
a PGP signed copy of the article to be posted.
The server will then verify that the moderator
sent it, and post it with a (different but
corresponding) approval. The second will accept an
article and return something that you can check
the signature on. Either way, any moderator will
still need PGP.

How Do You Register For The Service?
- ------------------------------------

Ahhh, this is the hard part. After all, it would
be pretty undesirable if someone, meaning well,
took any old body's word for it that some
important moderated group should start working
this way, before the moderator was able to start
approving postings. A great way to hijack a
newsgroup.

Another possibility is that someone, having seen
what the valid signature looks like, simply
creates a whole new PGP key that happens to have
the same PGP User ID. Then they can sign and post
stuff too.

The solution to both of these problems is the
classical one for public key systems. You need
either a certifying authority or the PGP Web of
Trust. We're using the Web of Trust. If you don't
understand about PGP and the Web of Trust, go away
now and come back after you really do understand
it.

For each newsgroup that wants to utilise this
program, the moderator will have to create a
special PGP key pair (preferably 512 bits to keep
the Approved: lines short), and sign it. They
must then establish a path of trust to someone
who is running the PGP Moose server. It will be
up to the administrator of that server to make
sure that only trusted moderators' keys ever get
into the server's keyring.

THERE CAN BE NO SHORTCUTS TO THIS PROCEDURE.
Otherwise we are all back where we started.

What If You Have Multiple Moderators?
- -------------------------------------

Simple. Create one PGP key pair which can approve
posting, and share it among the moderators. You
have to exchange it securely, but by definition
you have PGP, so that shouldn't be too hard. You
can still tell which moderator approved a posting
from the Sender: line.

Possible Problems We've Forseen:
- --------------------------------

If an article is mangled e.g. by truncation, it
will fail the authentication and be cancelled.
Until it is demonstrated otherwise, this is
assumed to be a rare and minor problem. When a
cancel is issued, mail is sent to the moderator of
the group telling them, and they can tell us if it
becomes a problem.

Currently the signature produced is assumed to be
a PGP version 2.6 compatible one.

The moderated newsgroup in question must be the
first newsgroup on the Newsgroups: line; as a
corollary it is not possible at the moment for an
approved posting to multiple moderated newsgroups.

Only one PGP User Id can approve postings to a
particular group. This means that that PGP User's
private key must be shared between all of the
moderators, with all of the attendant risks.

Status:
- ------

These scripts are implemented already, or as noted
above. They are undergoing testing by Chris Lewis
<[email protected]>, and as soon as they
have settled (within a week for sure) they will be
made available via anonymous FTP and posting to
comp.sources.misc and sci.crypt.research.

It Really Wasn't That Hard.
- ---------------------------

I wish people (other than me and Chris Lewis) had
put as much effort into doing this as they did
into clogging the Moderators' mailing list. It
wasn't hard.

But you know what was hard? What Phil Zimmermann
did creating PGP in the first place. Phil is in
serious legal hassles over PGP, and if you think
this effort saves you or your company some time or
money, I'd like you to consider donating some of
it to Phil's legal defence fund. Write to me or
Phil's lawyer Phil Dubois <[email protected]>
regarding how to donate. You can do it over the
net using PGP!

Share and Enjoy!

License Terms
- -------------

This software is copyrighted by Sterling
Software, and other parties. The following terms
apply to all files associated with the software
unless explicitly disclaimed in individual
files.

The authors hereby grant permission to use, copy,
modify, distribute, and license this software and
its documentation for any purpose, provided that
existing copyright notices are retained in all
copies and that this notice is included verbatim
in any distributions. No written agreement,
license, or royalty fee is required for any of
the authorized uses. Modifications to this
software may be copyrighted by their authors and
need not follow the licensing terms described
here, provided that the new terms are clearly
indicated on the first page of each file where
they apply.

IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE
LIABLE TO ANY PARTY FOR DIRECT, INDIRECT,
SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OF THIS SOFTWARE, ITS
DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN
IF THE AUTHORS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

THE AUTHORS AND DISTRIBUTORS SPECIFICALLY
DISCLAIM ANY WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS
PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND
DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE
MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
MODIFICATIONS.

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBL2Ao0aRQkCwJ0+ZNAQEC5QQAzYC388xAkKCG+737mOLH0Bg3vbPnlSPO
4epkvW7GD6HyaCUq34mhqYx2h1gCn4ywRG0bTZbjOyEMjU9d78Xyar/abu+jkMGc
umwwbcNHssYfsHMsfbrUR8vVz2C8+5ULUyavN9aNRIlFTpekWGklYfa+NGtIB84I
Xr9QW8Y2TqY=
=tjMn
-----END PGP SIGNATURE-----
Greg Rose, Sterling Software, 28 Rodborough Rd., French's Forest. NSW 2086
Australia. +61-2-975 4777 (FAX: +61-2-975 2921) [email protected]

------------------------------

Date: 6 February 1995 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>). UK subscribers please contact
<[email protected]>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
<[email protected]> (which is not yet automated). SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html
(Please report any format errors to [email protected])

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>YourName<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 16 is in that directory: "get risks-16.J<CR>". For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 15, J always TWO
digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>" I and J are dummy variables here. REMEMBER,
Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password. Also ftp [email protected]. WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen. Use wisely.

------------------------------

End of RISKS-FORUM Digest 16.89
************************