Subject: RISKS DIGEST 17.59

Subject: RISKS DIGEST 17.59

RISKS-LIST: Risks-Forum Digest Tuesday 2 January 1996 Volume 17 : Issue 59

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

[*** BEST WISHES FOR A RISK-REDUCED 1996! ***]
***** See last item for further information, disclaimers, etc. *****

Contents:
A glitch in time shaves NIST (Ivars Peterson)
Inside Microsoft is a floating crap game? (Peter J. Denning)
Nearest-match alphabetic metrics (Henry G. Baker)
Maine Yankee alleged to have deliberately run bad simulations (Daniel Smith)
Bavarian Police Censors CompuServe (Klaus Brunnstein)
1st Net Wiretap (& CompuServe too) (David Kennedy)
System modifications in grocery store (Michael Zehr)
Dynamic IP mistakes (Bill Bereza)
LoadDog - a risk reducer? (Julian Assange)
Re: Timing cryptanalysis of RSA, DH, DSS (Saso Tomazic)
TI e-mail snafu explained... (Bruce R Koball)
Re: Colonels, bugs and spellcheckers (Jake Livni)
Re: Robotic justice hoax! (Pete Mellor)
ABRIDGED info on RISKS (comp.risks)

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

Date: Tue, 02 Jan 96 13:22:11
From: [email protected] (Ivars Peterson)
Subject: A glitch in time shaves NIST

Did you hear about the problem that occurred when a leap second was added at
midnight on New Year's Eve. Apparently, because of a mistake somewhere along
the line, the leap second was added but the date was also inadvertently
advanced to Jan. 2. I heard from a source at AP radio that the
synchronization of their broadcast networks depends on the official time
signal, and this glitch affected their operations for several hours until
the problem was corrected.

You can't even count on the national timekeepers to get it right all the
time! And the year 2000 is coming up fast.

Ivars Peterson, Math/Physics Editor, Science News, 1719 N Street, NW
Washington, DC 20036-2888 [email protected] 202-785-2255 Fax: 202-659-0365

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

Date: Sat, 30 Dec 95 08:29:16 EST
From: [email protected] (Peter J. Denning)
Subject: Inside Microsoft is a floating crap game?

The Cobb Group publishes INSIDE MICROSOFT OFFICE, a monthly newsletter for
users of Microsoft office products. In their January 1996 issue, they
address a problem already discussed at some length in the Risks Forum ---
floating point expressions in spreadsheets like Excel 5.0 that do not
evaluate properly. They say the problem isn't an Excel bug, it's a
consequence of the IEEE floating point standard 754. Many numbers with
exact decimal representations do not have exact binary representations;
arithmetic operations on the binary approximations may not give the same
results as the same operations on the decimal numbers. They suggest a
"workaround" -- wrap your floating point expressions in the ROUND() function
-- e.g., ROUND(0.3-0.2-0.1,5) will yield 0 rather than -2.8E-17.

This analysis, while helpful to spreadsheet users worried about the accuracy
of calculations, is somewhat misleading. The IEEE 754 standard is an
innocent bystander because the real problem, finite binary representations
of decimal numbers, will happen with ANY binary floating point standard.
The ROUND() function does not eliminate the problem, it only masks it behind
a larger approximation error at the decimal level.

Modern spreadsheets are so powerful that any user can set up numerically
intensive computations and invoke all the problems that specialists have
spent years to learn to avoid. For example, if you are doing a capacity
study of a client-server system, you are likely to want to solve balance
equations of the form x=Ax, where x is a vector of unknown numbers and A is
a matrix. It is easy to set this up on a spreadsheet and utterly amazing
how difficult it is to get the spreadsheet's iterative calculation algorithm
to converge to a meaningful answer. This one can't be helped by the ROUND
function. A far better answer would be for the makers of spreadsheets to
offer numerical libraries that contain numerically stable algorithms for
various problems, and urge users to select those packages rather than
attempt their own, homegrown solutions.

Peter Denning

[What comes ROUND goes ROUND? PGN]

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

Date: Tue, 2 Jan 1996 09:02:22 -0800 (PST)
From: [email protected] (Henry G. Baker)
Subject: Nearest-match alphabetic metrics

I tried to finger someone at Carnegie Mellon University, and got the following
reply:

[cs.cmu.edu]
finger: No names match "jwebb" , 1 nearest match is:
Hooman Yaghoobi (hooman)

This was not done on April 1st, and I don't think that I connected to the
Monty Python server by mistake.

I was quite impressed that the finger program considered this a 'match' at
all, and am at a total loss as to what metric it could possibly be using.
CMU CS department has a large number of people in it, so the chances of
getting this match instead of some other would normally seem to be quite
remote.

(BTW, Jon Bentley did his thesis on best matches using a Euclidean metric at
CMU if I recall correctly, although I doubt that CMU 'finger' is using his
algorithm. :-)

Henry Baker www/ftp directory: ftp.netcom.com:/pub/hb/hbaker/home.html

Copyright (c) 1996 by Henry G. Baker. All rights reserved.

[Well, at least "JWebb" and "Hooman Yaghoobi" have the
letter "b" in common! Close enough for some purposes? PGN]

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

Date: Sat, 23 Dec 1995 18:28:45 +0001 (EST)
From: "Daniel P. B. Smith" <[email protected]>
Subject: Maine Yankee alleged to have deliberately run bad simulations

Peter Neumann's book "Computer-Related Risks" discusses some examples of
problems with reproducibility and validation of computer simulations used to
assess the safety of nuclear power plans. A story ("Maine reactor probe
widens") in *The Boston Globe*, 23 Dec 1995, p. 17, adds some new twists.
The story uses the phrase "it became clear that Maine Yankee had made
widespread use of an allegedly inaccurate computer code to simulate
accidents." The story gives me the impression that the charges are credible
enough to have spurred action by the NRC. They are attributed to an
anonymous whistleblower writing to Robert Pollard of the Union of Concerned
Scientists, an organization to which I donate which can be vaguely
characterized as "antinuclear."

The whistleblower alleges that "in 1983, Maine Yankee officials developed a
computer code that help predict the plant's emergency core cooling systems
would be `grossly inadequate' in the vent of a pipe break. Maine Yankee
`refused to even discuss the possibility' of upgrading the emergency safety
system, and did not report the results. Instead... plant officials
repeatedly modified the computer code over the next four years, but each
`reasonable' computer-simulated accident had the same result: the fuel got
too hot to meet NRC standards... finally in May 1989, Maine Yankee told the
NRC that their new computer code, known as RELAP5YA, showed the plant could
withstand a pipe break without a serious accident... Pollard said the NRC's
[resulting] approval looks particularly bad because the agency had evidence
in 1989 that RELAP5YA was not a reliable computer code."

The RISK here is the popular presumption that anything that comes out of
a computer is authoritative and objective, which made it easier for Maine
Yankee, with the complicity of a lenient NRC official, to evade the
purpose of the regulations requiring computer simulation. In addition, it
appears from the story that Maine Yankee was in effect able to stall the
NRC for at least five years by "claiming they were still working on the
more sophisticated computer projection." When regulations are tied
to the completion of a computer-related project it may be hard for
officials to enforce deadlines because they recognize that big software
projects are never completed on time.

Daniel P. B. Smith [email protected]

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

Date: Tue, 2 Jan 1996 15:26:25 +0100
From: Klaus Brunnstein <[email protected]>
Subject: Bavarian Police Censors CompuServe

Last Friday (December 30,1995), a Bavarian State Attorney sent police to
Germany's CompuServe offices to close down any German access to the Internet
via CompuServe for services offering child pornography. The legal
prosecution was based on paragraphs forbidding distribution of child
pornography. As CompuServe felt (technically?) unable to close such access
exclusively for its (about 200,000) German customers, they decided to close
such services IN GENERAL, also affecting its 3,800,000 customers world-wide.
No other German provider of Internet access (e.g. T-Online, a service of
German Telekom) were NOT prosecuted (their headquarter is NOT in Munich).

Following discussions in diverse newsmedia suffered from evidently missing
knowledge about Internet in general and issues of responsibility of service
providers. Though such aspects were internationally broadly discussed
recently (e.g. the difference between responsibilities of a moderated group
versus unmoderated ones), Bavarian police seemed rather unaware about such
intricacies.

Apart from the risk of living in a country with censorship-friendly
bureaucrats, a UNIVERSAL RISK derives from the fact that NATIONAL LAW is
applied in a way to influence the UNIVERSE. As countries with different
cultural values and legal principles handle "freedom of information" (FOI)
aspects differently, laws of countries with strongest restrictions in FOI
may dominate more liberal ones :-). This may also apply to Germany itself,
being a federal state with hardliners (such as Bavaria, which even did not
sign the Federal Constitution 50 years ago :-) and more liberal countries
(esp. those where some national service providers reside :-) Moreover, some
lawyers doubt that the ancient paragraphs concerned with distribution of
child pornography may apply to electronic distribution.

Klaus Brunnstein (Jan.2,1996)

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

Date: 31 Dec 95 04:46:21 EST
From: David Kennedy <[email protected]>
Subject: 1st Net Wiretap (& CompuServe too)

Compiled from various wire services extracted from CompuServe's Executive
News Service:

Cyberspace wiretap leads to arrests
UPI Northeastern US 29/12/95 14:46

By TRACEY L. MILLER
> NEW YORK, Dec. 29 (UPI) -- The G-men have started bugging cyberspace.
> The U.S. Secret Service announced Friday that a court-sanctioned
> wiretap on the Internet has led to the arrests of three people who
> allegedly advertised the sale of illegal electronic surveillance devices
> through the on-line service, CompuServe.
> "These arrests offer a glimpse into what crime and law enforcement
> will look like in the 21st century," Brooklyn U.S. Attorney Zachary
> Carter said at a Manhattan news conference. "Criminals are adjusting to
> new means of communications in the same way we are."

o Bernard Bowitz a German national, his estranged wife, Rachel, and Gregory
Brooks of Seattle were arrested.

o Seizures included a cellular phone cloning equipment: a "Lifetime Phone"
capable of storing 99 stolen Mobile Identification Numbers (MIN) and
Electronic Serial Number (ESN) combinations; a "Celltracker" that also
allows the caller to eavesdrop on any nearby cellular conversation, and an
"ESN Reader", which allows the user to steal the MIN/ESN combinations. Also
seized laptop computers, scanners, covert transmitters and receivers
hundreds of cellular phones and a satellite cellphone. Some covert
transmitters were disguised as a three-pronged wall socket and a fountain
pen.

o AT&T Wireless Services Security noticed Bowitz's ads on CompuServe. They
verified what he was offering and tipped the US Secret Service (USSS) and
the Drug Enforcement Agency (DEA). Bowitz also advertised openly on a World
Wide Web site.

> The Department of Justice and the U.S. district court gave
> investigators authorization to monitor the trio's outgoing and incoming
> CompuServe E-mail messages, the first time permission for such a wiretap
> over the Internet has ever been granted.
> "This authorization was critical, since Bernhard and Rachel Bowitz,
> and Gregory Brooks, perhaps believing that Internet communications were
> immune from interception, spoke relatively openly in their E-mail
> communications," said Brian Gimlett, who heads the Secret Service's New
> York Field Office.

o Operation has been ongoing for several months and ran from New York City
to Seattle, Las Vegas and Hong Kong.

o Bowitz communicated with an undercover DEA agent by e-mail and met him
several times for buys. Bowitz also was laundering US$225K believed to have
come from drug trafficking.

> "The significance of this case should not be minimized," said
> Gimlett. "This case has substantially impeded the spread of technology
> that would undercut law enforcement's ability to conduct effective
> electronic surveillance, endanger the telecommunications and
> international business community and intrude upon the public's right to
> privacy."

o All three charged with wire fraud, the manufacture and sale of illegal
intercepting devices, and conspiracy. Bernhard Bowitz, alone, was charged
with money laundering. Bowitz is in the grey-bar hotel pending US$500K
bail. His wife is out and about on bond in Las Vegas. Brooks was arrested
in New York and is free pending his arraignment next month.

o Joint investigation included AT&T and the New York Electronic Crime Task
Force. The task force includes USSS, DEA and the New York Police
Department.

> "The Internet has become the new battleground for law
> enforcement to fight crime," said Gimlett.

Dave Kennedy [US Army MP] [CISSP]
Volunteer SysOp National Computer Security Association Forum on CompuServe

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

Date: Wed, 27 Dec 95 10:16:28 -0500
From: [email protected]
Subject: System modifications in grocery store

While not life-threatening, this situation is definitely sanity-threatening
when one is in a hurry.

I recently had to go to a local Star Market grocery store to purchase
chicken stock. It turned out that the store was having a sale on chicken
stock that day. Normally you might expect this would be a good thing from
my point of view, but it added more than 5 minutes to my wait in the express
checkout lane. Here's why:

As with most large supermarkets, Star has UPC scanners connected to price
databases to speed checkout. They also print weekly circulars with coupons.
They recently started a program called Star Advantage which uses a scannable
card instead of coupons. You present the card to the cashier, and when the
bill is totalled the system automatically applies any of the weekly coupons
for items you bought.

[You're encouraged to present your card for all purchases, because you don't
always know if something has a coupon or not. The subject of the store
building up a database of what you buy, when, and how you pay for it is a
privacy RISK for a separate article.]

The checkout procedure has provisions for buying a large quantity of items
at once. People often buy a case of something on sale, the cashier scans
one item followed by "quantity 36" for example. People purchasing one or
two cases of something often go through the express lane because the
checkout is as fast as buying one or two single items.

Coupons must always be entered and printed one at a time, however. Herein
lies the problem. The two people ahead of me in the line both purchased two
cases of the chicken stock, and both used Star Advantage cards. It took
only a few seconds to scan one can of stock and hit quantity 72. When the
purchase is totalled, the computer applies 72 coupons to the sale. But the
software knows it has to print all the coupons individually, so it starts
cranking out 72 or 144 lines (coupons might require two lines) on the
receipt. The register printers are fast enough to keep up with items being
scanned individually. But at a second or so per line of text, it's a long
wait for the cashier, the customer, and everyone in line when it's printing
the coupon information.

This is an example of adding a feature without thinking through how it will
be used. In the past, no one would pick up 36 circulars and tear out 36
coupons. Or if they did, they wouldn't consider going through the express
line like that.

Using systems for something other than what they were originally designed
for is one of the stock RISKs we see here. What seemed like an idea that
would help customers could end up leaving a fowl taste in their mouths if
they wait too long in the express lane. I'm almost chicken to submit this
for fear of seeing what commentary PGN will add to this "Case of the Delayed
Customer."

-michael j. zehr

[Zehr gut, Michael, although if it were an Oriental chicken in Germany,
my *stock* answer would be that you might have a Hahn Dynasty or
Huhn-Nohs-Wat?, depending on its gender. We are Soupernuts? PGN]

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

Date: Sun, 24 Dec 95 13:05:03 -0500
From: Bill Bereza <[email protected]>
Subject: Dynamic IP mistakes

At home I have a Unix workstation which I connect to the Internet using PPP
from a service provider that gives me a dynamically assigned IP address.
Yesterday when I connected I noticed that I was getting large amounts of
incoming data over my low-bandwidth phone connection. I couldn't do anything
through the connection.

After checking some log files, I found out that my machine was receiving
dozens of mail messages. All of the messages were addressed for a machine
called XXXXX.org [I put X's in place of the real name]. I did a DNS lookup
on this XXXXX.org and found that its IP address was the same as my assigned
address.

So my home machine was being sent mail messages from mail servers that thought
my machine was XXXXX.org. To make it worse, since my machine knew it wasn't
XXXXX.org, it would pass the mail onto a mail-relay host, but that mail-relay
host would pass the mail right back since it still thought my machine was the
right one.

Each piece of mail that my machine received for XXXXX.org would be passed back
and forth 18 times, and on a slow phone-line this essentially stopped me from
doing anything else.

The only thing I could do was drop the connection, reconnect with a new IP,
and send some mail to a few sys admins.

This problem could have gone unnoticed for a while, since most people
connecting with dynamic IPs are probably not running mail server software,
so their machines would just refuse the connection and the mail would
just stay spooled on the mail servers waiting for a machine that will
accept a mail connection.

Another problem is that this could be used as a denial of service attack.
You could send large amounts of mail to addresses you know are dynamic,
and the next person to connect could be deluged.

I think the biggest risk from this is that I was receiving dozens of possibly
private messages intended for someone else. Mistakes in configuring name
servers or assigning IP addresses could cause anyone's mail to be
misdirected.

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

Date: Fri, 29 Dec 1995 05:16:47 +1100 (EST)
From: Julian Assange <[email protected]>
Subject: LoadDog - a risk reducer?

I have spent some time trying to maximise the ability of a of a unix system
to self-diagnose impending or actual insanity. Not a risk (or is it? ;)) but
I thought risk readers might be interested in this software.

Julian Assange EMAIL: [email protected] FAX: +61-3-9819-9066

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

This is the first public release of LoadDog!

Please read the man page below for implementation and archive location
details.

LOADDOG 0.90b(8) LOADDOG 0.90b(8)

NAME
loaddog - system crash detection dead man's switch

SYNOPSIS
loaddog [-d] [-l loadavg] [-m bytes] [-r retries]

DESCRIPTION
loaddog monitors system vital functions and if they
repeatably fail shuts the system down (if possible with
one minute warning) and reboots. Nearly all possible fail-
ure points within loaddog itself due to serious system
malfunction are handled, from file system unmounting and
syncing requests hanging to loaddog suffering from segmen-
tation violations. Currently the following vitals are
tested every 60 seconds:

system can create new processes
system can execute new binary images (/bin/date is
used as the test program)
system can create new file descriptors
system can create new tcp sockets
system load average over the course of the last 15
minutes is within reason
system is scheduling correctly
system can allocate new virtual memory

If running under Linux-1.3.51+ Loaddog also supports Alan
Cox's in-kernel software deadman's switch /dev/watchdog
which will perform a hard (nasty) reboot should the system
become so unusable that even the Loaddog daemon can't run.

OPTIONS
-d Detach from the controlling tty.

-l loadavg
The highest acceptable 15 minute loadavg. Defaults
to 10.0.

-m bytes
The minimum acceptable quantity of free virtual
memory. Defaults to 2 Mb.

-r retries
Do not consider the system terminal until retries
consecutive vital failures have occurred. Defaults
to 3 - that is three consecutive failures over
three minutes.

EXAMPLE
loaddog -d -l 6 -m 2097152 -r 2

Julian Assange ([email protected])

ARCHIVE
The latest version of this program can be obtained from
the Suburbia archives at ftp.suburbia.net or
ftp://suburbia.net/pub/proff/original/loaddog.tgz.

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

Date: Tue, 26 Dec 1995 17:23:09 -0100
From: Saso Tomazic <[email protected]>
Subject: Re: Timing cryptanalysis of RSA, DH, DSS (Kocher, RISKS-17.53)

The timing attack presented by Paul C. Kocher in his extended abstract
of the paper "Cryptanalysis of Diffie-Helman, RSA, DSS, and Other
Systems Using Timing Attacks"
(ftp://ftp.cryptography.com/pub/kocher_timing_attack.ps)
is really worth consideration, however I would like to stress there is no
need for panic, mainly for two reasons:

1) Security of practical cryptosystems do not rest solely on security of
crypt algorithm. In fact, cryptoanalysis attacks are rare, due to strong
crypto algorithms that are presently known. More often cryptosystems are
broken using other weak points of cryptosystems as insecurity of keys, bad
key management, easy to guess passwords, computer screen radiation,
monitoring the keystrokes of computer in network, ... The timing attack can
be considered just as one of them, not the most dangerous one. For practical
cryptosystem, it would be extremely difficult to measure exact timing of
encryption process, at least much more difficult as to monitor keystrokes or
to capture entire message from the screen. The intruder, who would be able
to measure the exact timing of encryption in a multitasking environment,
would probably also have access to everything else (i.e., secret message,
secret key, passwords, ...) and thus no need to measure timing.

2.) It is not so difficult to rewrite algorithms to be resistant to timing
attacks, i.e., to have execution time independent of secret key. For
example, the algorithm to compute R = y^x mod n given in the Kocher paper
can be simply rewritten as:

Let R = 1.
Let A = 1.
Let z = y.
For i=0 upto (bits_in_x-1):
If (bit i of x) is 1 then
Let A = (R*z) mod n
Else
Let B = (R*z) mod n
Let y = y^2 mod n.
Let R = A.
End.

to be resistant to timing attacks.

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

Date: Mon, 25 Dec 1995 12:53:40 -0800
From: Bruce R Koball <[email protected]>
Subject: TI e-mail snafu explained... (Koball, RISKS-17.58)

..and here's the explanation:

> From [email protected] Fri Dec 22 23:18:47 1995
> Date: Sat, 23 Dec 1995 00:14:02 -0600
> To: (TI&ME users)
> From: TI&ME Internet Information Service <[email protected]>
> Subject: E-mail on TI&ME Internet Information Service
>
> Last night, Texas Instruments sent out a short one-time announcement of
> changes to the TI&ME Internet Information Service. The objective was to
> simply inform you about service improvements. TI sent only one copy of
> this e-mail to each user who had registered for this service.
>
> Unfortunately, a few users sent back an e-mail reply and also copied
> the mail list address. We did not anticipate that anyone would do this
> so we did not take the proper precautions to keep these replies from
> being forwarded to the entire mail list. We deeply regret that this
> caused you to receive extraneous e-mail as these responses were
> forwarded. We were able to pull the plug on sendmail this morning and
> stop the blizzard of e-mail.
>
> If you sent a reply requesting to be unsubscribed, we will honor that
> request. The TI&ME announcement we sent last night also contained
> instructions on how to do this yurself via http://www.ti.com. We wish
> to provide information via e-mail only to customers who request it.
>
> We sincerely apologize for our mistake that allowed you to receive
> multiple e-mail replies. We will take action to prevent this from
> happening again.
>
> Sincerely,
> Texas Instruments' Webmasters

Bruce R. Koball, 2210 Sixth St, Berkeley, CA 94710 1-510-845-1350
[email protected] (fax) 1-510 845-3946

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

Date: Wed, 27 Dec 1995 18:28:13 -0500
From: [email protected] (Jake Livni)
Subject: Re: Colonels, bugs and spellcheckers (Oram, RISKS-17.58)

>Convoluting matters further, in the Canadian and British militaries,
>lieutenant is pronounced 'lef-tenant' yet spelled the same. And the AF
>equivalent of a captain is a colonel, which is also not pronounced as it
>sounds because of a horrific entomological journey from Italian via French
>to English. ^^^^^^^^^^^^^

I think the intended word was "etymological", the study of of historical
linguistical change. "Entomological" relates to the study of insects.
Should we call this a "bug" or should we blame it on an overenthusiastic
spellchecker (and not a spell checker). :-)

Jake Livni [email protected]

[Yes, the error did seem quite suitable for RISKS.
Correct spelling is a tough roach to haugh. PGN]

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

Date: Thu, 28 Dec 95 18:54:23 GMT
From: Pete Mellor <[email protected]>
Subject: Re: Robotic justice hoax! (Matthews, RISKS-17.47)

Sean Matthews <[email protected]> writes:-

> While this particular project may be a hoax, the inspiring idea is certainly
> not. Prof. Robert Kowalski at Imperial college in London is/was closely
> associated with a project to encode UK immigration law (so far as I
> remember) as an expert system of logic program clauses.

As a junior executive officer in the UK Civil Service (Home Office,
Immigration Department) many years ago, my first wife had the job
of responding to enquiries from abroad regarding immigration.

Her work consisted of reading each letter, selecting from a set of
trays one of around 50 standard pre-typed replies, clipping the reply
to the letter, and placing it in the out-tray from where it was taken
to be checked by a more senior officer before being signed and posted.

It seems like *exactly* the sort of task that could be computerised,
and would not even require a particularly "expert" system. In fact, any
system with any real intelligence would probably do what my wife did
after three days: crawl up the wall screaming and hand in her notice!

Peter Mellor, Centre for Software Reliability, City University, Northampton
Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422, Fax: +44 (171) 477-8585
E-mail: [email protected]

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

Date: 6 September 1995 (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) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...]
DIRECT REQUESTS to <[email protected]> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for further information]

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. [...]
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.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks

RISKS ARCHIVES: "ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP. [...]
[Back issues are in the subdirectory corresponding to the volume number.]
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]
ftp://unix.sri.com/risks [if your browser accepts URLs.]

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

End of RISKS-FORUM Digest 17.59
************************