Subject: RISKS DIGEST 16.88

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

RISKS-LIST: RISKS-FORUM Digest Weds 8 March 1995 Volume 16 : Issue 88

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 [Sorry for ungrouped list. It keeps automatic indexers happy.]
Caller ID Ghosts (Jim Huggins)
Interesting cellular news from Pakistan (Abhijit Dutta via Ben Burch)
Re: Microsoft and Lotus spreadsheet errors (Barry Margolin)
Re: Confused remotes (Philip H. Smith III)
Re: The source of semantic content (Steven Tepper)
Re: The source of semantic content (A. Padgett Peterson)
Re: The source of semantic content (Barry Margolin)
Re: The source of semantic content (Jeremy Epstein)
Re: The source of semantic content (Jon Krueger)
Re: The source of semantic content (Tim Kolar)
Re: The source of semantic content (David Harpe)
Re: Sparc10 keyboards and resetting the CPU (A. Harry Williams)
Re: Sparc10 keyboards and resetting the CPU (Simson L. Garfinkel)
Re: Sparc10 keyboards and resetting the CPU (Ed Bruce)
Re: Sparc10 keyboards and resetting the CPU (Mark Stalzer)
Re: Sparc10 keyboards and resetting the CPU (David Honig)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: Wed, 8 Mar 1995 10:20:31 -0500 (EST)
From: Jim Huggins <[email protected]>
Subject: Caller ID Ghosts

News item from the Detroit Free Press, 8 March 1995.

A Detroit area woman last week looked at her Caller ID box (manufactured by
CIDCO, Morgan Hills, CA) and was puzzled to notice that it indicated 19
received calls that evening, even though only one person had called. Then
she checked the names listed. John F. Kennedy. Thomas Paine. Harry S
Truman. John Hancock. Ulysses S. Grant. Samuel Clemens. Ronald Reagan.
And many others.

Most of the phone numbers were non-working, but a few were. Ryan Biermann,
an English student at the University of Wisconsin-Madison has been plagued
with phone calls for Abraham Lincoln recently.

No definitive explanation has been given. Ameritech (the Baby Bell
for Detroit and Madison) believes the Caller ID box was probably
a pre-programmed demonstration model. Dave Glowacz, a telecommunications
consultant in Chicago, suspects the work of a phone hacker.

Depending on the cause, lots of old Risks here (either a faulty
demonstration circuit with non-fake data or an insecure data system), but
perhaps with a new face to them.

Addendum: accompanying the article is a photo of the Caller ID box listing
Abraham Lincoln's name and phone number. I hope Mr. Biermann won't be
getting too many more phone calls because of it ...

Jim Huggins ([email protected])

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

Date: Mon, 6 Mar 1995 17:21:30 GMT
From: [email protected] (Burch Ben)
Subject: Interesting cellular news from Pakistan

From misc.news.southasia Sun Mar 5 17:56:49 1995
From: [email protected] (Abhijit Dutta)
Date: Sun, 5 Mar 1995 00:34:16 GMT
Newsgroups: misc.news.southasia
Subject: Pakistan Forces Motorola To Halt Cellular Services In Karachi

Voice of America, March 04, 1995
By Jennifer Griffin

Islamabad: The Pakistan government has forced the US telecommunications
giant, Motorola, to halt mobile telephone service to the country's
strife-torn city, Karachi. Pakistani officials are demanding Motorola
hand over sophisticated eavesdropping equipment that would allow
intelligence agencies to tap into phone calls made on the company's
cellular network. Analysts are saying the government's action is not
encouraging to foreign investors. The Pakistan government claims it is
trying to crack down on Karachi terrorists using mobile telephones to
coordinate attacks and organize violence in the ravaged city.

In a memo to James Beneda, the president of Mobilink -- Motorola's
Pakistani joint venture -- the communications ministry demanded
equipment needed to tap into all calls made by its subscribers be given
to the government.

Without these sophisticated scanners, intelligence agents would not be
able to tap into the cellular network. It is the first time the
government has admitted such tapping and eavesdropping is commonplace
in Pakistan. Mobilink's service to Karachi was cut by the government
January fourth.

According to Mobilink's regional manager, Zahid Hussain, two other
cellular phone companies presently operating in Karachi have not had
their service interrupted because their calls are easily tapped. "The
facility the other two cellular companies have, all you do is buy a
200-dollar scanner from Hong Kong or wherever, and you can walk the
streets and just keep tuning into different frequencies and listening
to people's conversations."

Mr. Hussain says his company will comply with some of the government's
demands and will deliver the mobile scanning equipment sometime this
month. But, there remain other obstacles to resuming operations. The
government has also demanded Mobilink not expand its number of
subscribers from the present 3000 -- a request mobilink officials say
they cannot possibly honor.

US state department officials and Secretary of Commerce Ron Brown are
said to have brought the matter to the attention of Pakistan's
Washington Ambassador, Maleeha Lodhi.

The US-based company has invested more than 32-million dollars in
establishing its Pakistani operation since last August, and intended to
invest nearly 20-million dollars more this year.

The scandal has caused many foreign businessmen to rethink their
investment in Pakistan, where they say licensing agreements are easily
rewritten and often disregarded. Mr. Hussain says the government's
handling of the incident sends a negative signal to foreign investors,
particularly on the eve of prime minister Benazir Bhutto's trip next
month to the United States.

Ben Burch Motorola Wireless Data Group [email protected]

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

Date: Wed, 8 Mar 95 06:17:33 EST
From: [email protected]
Subject: Re: Microsoft and Lotus spreadsheet errors (Hunt, RISKS-16.87)

>Barry Ward, ... `I've been in the computer business for 19 years and
>have never come across this problem before. ...

I find it difficult to imagine someone who's been in the computer business
for two decades and has never heard of floating point round-off errors.
This should be part of any computer science curriculum.

Of course, part of the problem is that 20 years ago, virtually all business
software was written in COBOL or PL/I, and that's probably Mr. Ward's
background. These languages provide fixed-point decimal as a built-in data
type, and require that decimal arithmetic be done accurately. There may
still be round-off errors (e.g. dividing 100 by 3, or multiplying .01 by
01 and putting the result in a variable with two digits after the decimal
point), but the programmer has direct control over the level of precision.

These days, end users use spreadsheets to write "business software", and
the spreadsheet designers seemed to have forgotten how business software
has traditionally worked. The spreadsheet implementors are simply using
the built-in mathematics that C provides, which is not appropriate for this
problem domain. Floating point was designed for scientific computing --
it's often not much of a problem that errors are introduced, since there's
an inherent imprecision in the input data (since it's translated from the
analog real world to the digital cyber world).

Barry Margolin, BBN Internet Services Corp. [email protected]

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

Date: Wed, 08 Mar 95 07:59:24 EST
From: [email protected] (Philip H. Smith III, (703) 506-0500)
Subject: Re: Confused remotes

Re: the various appends about lights, etc., fooling remote controllers: I
used to have a Jerrold cable box that had a clock in it. When I used my
stereo receiver remote, it would sometimes cause the Jerrold clock to jump
an hour. What was interesting about this was that this was NOT a function
offered by the Jerrold remote! ...phsiii

[This is a clock that goes JERROLD McBoing-Boing when it triggers
the alarm? If it change the right <left?> digit, it would become a
YEAR-OLD clock. PGN]

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

Date: Tue, 7 Mar 95 21:51:17 PST
From: [email protected] (Steven Tepper)
Subject: Re: The source of semantic content (RISKS-16.87)

> [The situation is even more complicated by the availability of
> programs that mask encrypted messages as graphical image files
> (.gif), so that irrespective of their REAL content, a message
> appears to be an innocuous picture. PGN]

What about going in the other direction? If you take an image file or some
other data file (say a core dump file) that appears random, apply some
simple operations (say XOR with various values) to it and run the output
through a program that filters out everything except strings of
alphanumerics (such as the Unix "strings" program), eventually you're bound
to come up with with something that contains some obscene words, possibly
"misspelled". A zealous prosecutor could use this to "prove" that the
original was an encrypted form of obscene text.

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

Date: Wed, 8 Mar 95 10:17:21 -0500
From: [email protected] (A. Padgett Peterson)
Subject: Re: The source of semantic content (RISKS-16.87)

[The situation is even more complicated by the availability of
programs that mask encrypted messages as graphical image files
(.gif), so that irrespective of their REAL content, a message
appears to be an innocuous picture. PGN]

Let's consider something even easier: Take a digital picture "A" of a
politico presenting an award. Using a graphics editor, a miscreant
removes certain items and adds a mustache (or something). The two
digital files are then XORed so that only the changes remain in file "B".

Again we have a two part solution but now the first part is mixed so
that the second becomes a night sky or lost in the 24th bit of the first.

Viewed as sent, it is an innocuous picture, but rearranged...

Can you see the prosecutor trying to explain "yes but if you switch this
and change that color and twitch you nose it becomes...

Kinda like the person (not catching me with that one) complaining of
the indecent behaviour next door: "Yes officer, it's horrible. Just
climb out here on the roof of the garage, lean against that light pole
and with these infrared binoculars you can see it just as plain..."

"Life will find a way". Padgett

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

Date: Wed, 8 Mar 95 06:17:33 EST
From: [email protected]
Subject: Re: The source of semantic content (Gat, RISKS-16.87)

>If A and B exchange P in this way, then they can individually publish F1 and
>F2, from which anyone can recover P, but both A and B can plausibly deny
>having done anything but publishing a random bit stream.

Unless they actually didn't know what the purpose of those random bit
streams were, they would be perjuring themselves. They would have to
convince a judge (and maybe jury) that they really thought they were just
random bit streams, and they were passing them to each other for no reason.
Were I on the jury, I would be skeptical.

Barry Margolin, BBN Internet Services Corp. [email protected]

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

Date: Wed, 8 Mar 95 10:11:09 EST
From: [email protected] (Jeremy Epstein -C2 PROJECT)
Subject: Re: The source of semantic content (Gat, RISKS-16.87)

In RISKS-16.87, [email protected] (Erann Gat) had some very clever
comments about ways of exchanging bit streams that together make up a
picture. I'd propose another scenario: if U1 embeds a pornographic image in
the background of a picture, and sends U2 a binary image of the picture, U2
may well be unable to detect it. If U2 forwards the picture to U3, who (if
anyone) has violated the proposed Exon law? As was shown in a paper
published at the 1993 Computer Security Applications Conference, an amazing
amount of data can be embedded in a digital picture without it being visible
to a human looking at the picture on a screen or on paper.

Truly amazing how little insight our legislators have into the
technology they're trying to legislate.

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

Date: Wed, 08 Mar 1995 01:58:08 PST
From: "Jon Krueger" <[email protected]>
Subject: Re: the source of semantic content

> [encrypt image file F1 with one-time pad F2, email F1 to person A
> and F2 to person B; A and B then exchange F1 and F2]
> A and B each can now recover the original image. Has the law been
> broken? Who broke it? All anyone did in the above scenario was to
> send a random bit stream to someone else. At no time did anyone send
> a bit stream with any identifiable semantic content.

An undeveloped photo becomes evidence of crime when it's developed and
is deemed porn. A special film requiring its own developing process
doesn't change this. Whether a crime was committed wouldn't rest on
mechanisms of imaging, therefore, but on the image transmitted. If
it's deemed porn, chances are all three of you broke the law (plus
conspiracy to commit same, given the way you went about it.) Lectures
to judge or jury on the mathematical properties of the tools used will
probably seem to them like lectures on thin film chemistry.

> One might argue that I broke the law by sending out two files that I
> knew could be combined to produce a pornographic image.

That would be the prosecution's argument, yes.

> So imagine now that A sends a random bit string F1 to B, who then uses
> this as a one-time pad to encode P, which B then sends back to A. Has
> the law been broken? Who broke it?

A has conspired with B to effect the transmission of images deemed
pornographic from B to A. I wouldn't bet the rent on any judge or
jury concluding anything else.

> B could never be convicted of violating the law, since he could always
> claim that he had sent F2 before receiving F1, and that therefore A
> had transferred P to him rather than vice versa. Even if the
> government had timestamps to show that F2 was sent after F1, B could
> claim that this was simply a retransmission.

Oh? We couldn't recover P from A or B's storage?
Or talk to someone who knew where P came from?
If we do, we don't need to know anything about F1 or F2.
We know where P came from and where it went to.

Even without that, if timestamp records conflict with B's claims,
we simply have to choose which one we believe. B's claims might
be found credible, and might not. The judge or jury decide.

On either grounds, B's toast under a variety of circumstances.

> If A and B exchange P in this way, then they can individually publish
> F1 and F2, from which anyone can recover P, but both A and B can
> plausibly deny having done anything but publishing a random bit stream.

The key word here is "plausibly"; plausible to whom? Judge or jury
might find it less than plausible that A and B engaged in the generation
and distribution of random bit streams, which later just happened to
form images in combination.

> The DA might try to prosecute both A and B on a conspiracy charge,
> but it is not necessary for A and B to have conspired. The mere
> knowledge that random bit streams can be used in this manner might
> prompt some people to start sending random bit streams around.
> Without reliable time stamps there is no way to trace the introduction
> of semantic content. So as soon as anyone starts to transmit
> one-time-pads, everyone can publish anything and no one can be
> prosecuted for it.

The above discussion should demonstrate why this is a rather
naive view. However anyone who wants to give it a whirl is
welcome to; it's your nickel. The danger lies instead in
an equally naive view:

> Any attempt to legislate the content of digital communications is
> therefore doomed to fail

And therefore we need do nothing. Wrong. The fact is that clever
games such as these will not impress the judicial system nor derail
the legislative process. If the law gets on the books it will work
its damage. Such schemes as suggested above will be looked on as
what they are, attempts to evade it or confuse its enforcement;
little will be gained; it might even be counterproductive. No,
if we want to stop Senator Exon's nonsense, we have to do it the
old fashioned way: organizing, lobbying, informing, and persuading.

Jon Krueger [email protected] (510) 523-2514

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

Date: Wed, 8 Mar 95 10:09:29 PST
From: Tim Kolar <[email protected]>
Subject: Re: The source of semantic content (Gat, RISKS-16.87)

Erann Gat's article on semantics (RISKS-16.87) provides a nice example of
the difficulties of identifying any bit stream with certainty.
Unfortunately it also provides an example of an all too common Risk:
Engineers confusing scientific "proof" with that of a legal nature.

Censorship is already enforced on the internet. In particular, allowing
transfer of encryption technology out of the U.S. is illegal. This leads
to awkward situations for companies who's products include security, but
by Gat's arguments they can get around the problem by simply encoding the
software and sending it as two "random" bit streams. Anyone who decides to
try this, please be sure to let us all know...

Sarcasm aside, I don't think anyone believes that Department of Commerce
(or Defense, or whoever enforces that restriction) would even slow down
on their way to the courthouse because the information was encrypted. Intent
is far more important than encoding, and I don't believe they'd have any
trouble with a conviction.

But back to the basic Risk: Engineers forgetting the end users and
getting wrapped up in notions of mathematical certainty and "solid" proof.
Remember: your firewall _supports_ an overall security policy. Your
automated flight system _supports_ a pilot. Your software filters _support_
the legal system.

In all these cases the software is not the end all be all, but an aid to
accomplishing some other task. At some point we may feel comfortable
replacing humans with software completely for these uses, but RISKS forum
itself is a testimony to how far off that actually is.

-Tim Kolar

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

Date: Tue, 07 Mar 1995 22:46:57 -0500 (EST)
From: [email protected]
Subject: Re: The source of semantic content (Gat, RISKS-16.87)

>Now suppose that I email F1 to person A and F2 to person B. Then A and B
>exchange F1 and F2. A and B each can now recover the original image. Has
>the law been broken? Who broke it? All anyone did in the above scenario
>was to send a random bit stream to someone else. At no time did anyone send
>a bit stream with any identifiable semantic content.

Unfortunately, our legal system is not advanced enough to recognize the
subtle differences described above. The authorities will wait until the two
parts are combined. They will then seize every piece of hardware which
appears to be associated with the image. Anyone who happens to be in the
mail header will be arrested. During the trial, the reconstructed image is
all the jury will see, understand or remember. They will fall asleep during
the expert witness testimony regarding public key cryptography. This is the
RISK of living in a society which is heavily dependent on technology, but
whose users are not very well educated.

David Harpe [email protected]

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

Date: Fri, 03 Mar 95 18:54:41 EST
From: "A. Harry Williams" <[email protected]>
Subject: Re: Sparc10 keyboards and resetting the CPU (Neustaedter, 16.85)

>Actually, this is a feature.

I'm sorry, but throwing a user into an unknown state and requiring them to
know they have to type "go" and calling it a feature simply because the
operating system can't handle losing power without risk of losing the file
system is wrong. It's a kludge covering a bug. It never ceases to amaze me
the ends to which people will put up with this from vendors. They won't fix
the original bug, but they will add on all sorts of backdoor patches and
think they've solved the problem. It would be like taking your car in for
service for a rattle, and and the garage giving you ear plugs so you can't
hear it anymore.

To steal a line from the same Risks issue, the ultimate solution to these
recurring file system problems is for consumers to demand working file
systems from software manufacturers.

/ahw

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

Date: Fri, 24 Feb 1995 21:22:53 -0500
From: [email protected] (Simson L. Garfinkel)
Subject: Re: Sparc10 keyboards and resetting the CPU (Neustaedter, RISKS-16.85)

I would like to take issue with Tarl Neustaedter for saying, in effect,
that Sun's decision to have its SPARC computers go into the ROM Monitor
when you unplug the keyboard is a FEATURE and not a BUG.

Mr. Neustaedter eloquently says, basically, the following:

1. Sometimes you need to be able to interrupt the computer.
2. User software can completely remap the keyboard.
3. Therefore, we need some signal that can't be remapped to get the
user into the ROM Monitor.
4. The only thing left is unplugging the keyboard and plugging it
back in.

Here are some things to consider:

1. First at fault is the ROM monitor itself, which has one of the
most un-user-friendly prompts I have ever seen. The menus are difficult to
read; the commands are not neatly formatted; it's just not clear for
non-technical people what to do.

2. I am sure that more files have been left by some poor secretary
or other non-technical person accidentally unplugging the keyboard and then
plugging it back in (and consequently getting trapped at the ROM prompt),
then have been saved by UNIX weenies who have known that they could trap
into the ROM monitor by playing this game with the keyboard plug.

3. Mr. Neustaedter's note that this functionality can be disabled
by hand-editing the function call to abort_sequence_error() in the function
zsa_xsint() in the file zs_async.c is the typical UNIX weenie response: if
you don't like it, then search through the source-code (or object code) and
fix it yourself.

Yes, it is wonderful that UNIX gives its users such flexibility.
But it's also clear that UNIX was designed for small research labs where
the users want this sort of flexibility, and not for general use. Putting
UNIX into general distribution is dangerous: it's dangerous for the users,
and dangerous for those who have to give support to the users.

"It helps to be handy with kadb."

Indeed.

Simson L. Garfinkel
Co-Editor, "The UNIX-HATERS Handbook", IDG Programmer's Press, 1994.

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

Date: Thu, 23 Feb 1995 09:06:53 -0600
From: [email protected] (Ed Bruce)
Subject: Re:Sparc 10 keyboards and resetting the CPU RISKS (DIGEST 16.83)

This has been a feature of Sun Workstations at least since the Sun-2s. I
worked on a project in 1985 with six rack mounted Suns each supporting 6
diskless Suns. There was a table beside each rack and on the table was a
keyboard. No CRTs of any kind to be seen. I don't know why, but periodically
someone would decide that they needed one of these keyboards. With the
result that at least six Suns (generally more as NFS mounts to the now hung
server would fail) would freeze up until we could get the keyboard back and
reboot the server.

Just last year I was stung by this feature. I was to give a demo on a Sparc
10. Some one had connected the mouse off the left side of the keyboard and I
decided I needed it on the right. So I immediately unplugged the mouse then
proceeded to disconnect the cable on the right side, and the Sparc 10
proceed to crash. After reconnecting the cables I attempted to reboot. Well
it failed to reboot and later it was discovered that one key file had been
corrupted (I forget which one).

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

Date: Mon, 27 Feb 95 08:38:05 EST
From: [email protected] (Mark Stalzer)
Subject: Re: Sparc10 keyboards and resetting the CPU

This is a good topic for a trivia question in the Computer Bowl. I bet SMI
borrowed the break behavior from PDP-11s. I'm not sure when it was
introduced into the PDP-11 family (certainly by the mid 70's), but holding
the break key for a bit on the console caused a "framing error halt". On a
PDP-11/03, this dropped you into the microcode monitor. On machines without
a monitor, you had to restart it from the front panel with all the funky
lights.

Anyways, it served a useful purpose. On the RSX-11 operating system, you
could schedule a job with a priority higher than the command line
interpreter. If this job went into an infinite loop, it could not be
terminated. The solution was to stop the machine with the break key, and
poke around in kernel memory to remove the job (there were various ways to
do this.) Hopefully, when the machine was restarted, it would be back to
normal.

-- Mark Stalzer ([email protected])

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

Date: Mon, 27 Feb 1995 17:09:34 -0800
From: David Honig <[email protected]>
Subject: Re: Sparc10 keyboards and resetting the CPU (Puchol)

Disconnecting the keyboard is the same as the L1-A interrupt which throws
Suns (since Model 3s) into their monitor program. Typing "c" for continue
will let the cpu resume unixing.

This is indeed obscure behavior if you don't know about it :-0 Most
computers have arcane stuff like this mentioned (once) in their voluminous
manuals.

Computers aren't the only such systems: there are cars you can shut down by
kicking in the right place, where you activate a sensor that shuts off the
fuel pump, for instance.

The problem with big systems is no one reads (or understands) whatever
descriptions of it there might be.

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

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.88
************************