Risks Digest 21.95

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Tuesday 12 March 2002  Volume 21 : Issue 95

   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. *****
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.95.html>
and by anonymous ftp at ftp.sri.com, cd risks .

  Contents:
ATTBI / Eudora / SSL (Jock Gill via Dave Farber)
'Phantom Menace' typing is just a Microsoft speech feature (Dale Hawkins)
Re: Yet another case of a program changing your input (Gene Wirchenko)
Re: Air Force seeks better security from Microsoft (Tom Poe, Jei)
Disclaimers (Michael Bacon)
Re: Loosing It's Grammer Skill's (Michael Bacon, Klaus Brunnstein, 
  Mike Albaugh, Merlyn Kline, Dave Williams)
Re: The RISK of ignoring permission letters (Rob Slade, Greg Searle,
  George C. Kaplan, Michael Bacon)
Re: Welland Canal Bridge runs into ship (Dave Gillett)
Re: LED lights can reveal computer data (Nick Simicich, Peter B.)
REVIEW: "Incident Response", Kevin Mandia/Chris Procise (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Tue, 12 Mar 2002 10:03:52 -0500
From: Jock Gill <jock () jockgill com>
Subject: ATTBI / Eudora / SSL

  [From Dave Farber's IP list.]

Eudora users who are ATTBI customers might want to know this.

As Eudora users will know, ATTBI Broadband [formerly Road Runner or
MediaOne] does NOT support Eudora -- only MS products.  What they may not
know is that ATTBI's instructions for re-configuring Eudora to work with
ATTBI contain a very peculiar instruction in lines 10 and 17 = suggesting
that you MUST select SECURE SOCKETS WHEN RECEIVING.

This is in fact NOT TRUE, as David Reed helped me to discover last night.
If you do follow their instructions and select the SSL feature, you will
discover that your RETURN address MUST be the same as your LOGIN name.
This, obviously prevents a return address other than the ATTBI domain.  So,
if you have your own domain and wish to use it in the RETURN field in
Eudora, do NOT select the SSL functions in steps 10 & 17 of ATTBI's online
instructions -- see their web site.

Trying to be a good dooby, I explicitly followed ATTBI's online
instructions, only to discover the above problem.  When ever I tried tied to
use <,jock () jockgill com> as my return address, I got error 553 from the
ATTBI servers.

Calls with very long wait times to ATTBI, and chats with them online, were
fruitless to the point of their suggesting the 553 error message was an
Eudora problem.  The ATTBI techs had no idea what so ever about the
relationship between the so called SSL requirement and is effect to force
you to use your ATTBI login in name for your return address.

Makes you wonder why we ever trust large organizations.  As David might say,
the power of the edges to collectively organize around problems solved this
problem in very short order -- once I gave up on the old notion of turning
to the central authority.

Jock Gill < jock () jockgill com > <www.jockgill.com <http://www.jockgill.com/> >
Interactive Digital Studies

  [For Dave's IP archives see:
    http://www.interesting-people.org/archives/interesting-people/
  ]

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

Date: Tue, 12 Mar 2002 13:30:48 -0800 (PST)
From: Hawkins Dale <rhdale () yahoo com>
Subject: 'Phantom Menace' typing is just a Microsoft speech feature

Slashdot (slashdot.org) and others are reporting that "some Windows XP users
are finding random words inserted into their text as they write. The problem
is caused by XP's speech recognition system, which is turned on by default
by some manufacturers. It's listening to the random noise you get even when
the mic is turned off."

Microsoft is blaming the problem on some computer manufacturers who enable
this feature by default in their installation of the operating system.

Draw your own conclusions regarding the risks of adding powerful features
that users are unaware of.

Hawkins Dale

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

Date: Tue, 12 Mar 2002 08:16:44 GMT
From: genew () mail ocis net (Gene Wirchenko)
Subject: Re: Yet another case of a program changing your input (RISKS-21.94)

Funny.  On Sunday, I was doing an Excel tutorial as part of an accounting
course.  The tutorial was setting up a grades spreadsheet system.  I ran
into the same problem of short grades being overridden by longer ones!

Then there was Word miscorrecting a word in an e-mail address for me
recently.  Unfortunately, the lab computers at my college have the Word
settings set so that spelling corrections are automatically accepted.  While
this can be turned off, it must be done every login.  What a bother.

My college is University College of the Cariboo.  The domain is
cariboo.bc.ca.  Word miscorrected "cariboo" to "caribou".  I'm glad that I
noted it as it happened as this was on my resume for co-op.

Just to add to the fun, Word does some substitutions.  Try typing a line
with a number of asterisks.  Word will replace it with blocks.  Sometimes,
you can delete this line.  Sometimes, you can't.  I have also had horizontal
lines inserted that I couldn't get rid of.  I had a draft for a report that
I had to retype, because I couldn't get rid of the lines.

Gene Wirchenko

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

Date: Tue, 12 Mar 2002 10:14:54 -0800
From: tom poe <tompoe () renonevada net>
Subject: Re: Air Force seeks better security from Microsoft (Jei, RISKS-21.94)

> "The military and the government don't really have too much choice at
> this point except to start to put pressure on Microsoft and others to
> improve software security," Erbschloe says.

Hi: Well, Erbschloe, you're wrong.  You have an easy, easy choice to make.
If $13 Billion in taxpayer losses isn't enough to switch OS and tighten
security for the Air Force, there's something terribly wrong in the Computer
Economics workshop?!!  Thanks, Tom

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

Date: Tue, 12 Mar 2002 19:25:58 +0200 (EET)
From: Jei <jei () cc hut fi>
Subject: Re: Air Force seeks better security from Microsoft (Jei, RISKS-21.94)

Sounds to me like we need a law that empowers the consumers to demand their
money back if the products prove to be faulty.

But didn't the US lawmakers just make a law that empowers the software
makers to enforce whatever licences they like?

Software quality will not only get worse, but it will be impossible to
publicly state that it sucks.  Publishing security holes will also likely be
equal to legal suicide.

The only thing we'll get is a public mirage of better security and
functionality, while in reality things will actually be a lot worse.

Oh well.

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

Date: Tue, 12 Mar 2002 07:47:47 -0000
From: "Michael (Streaky) Bacon" <streaky () baconsonline com>
Subject: Disclaimers

A friend sent me the following disclaimer at the end of an e-mail he
received from a contact in the BBC (British Broadcasting Corporation).  It
reads (in part):

  "Please note that the BBC monitors e-mails sent or received. Further
  communication will signify your consent to this."

Now this presents a dilemma because, merely by responding, you consent to
the monitoring - making it challenging to refuse whilst keeping a convenient
and effective communication channel open.

Anyway, if the external correspondent uses (say) telefax and the internal
correspondent uses e-mail -- is that "communication".

If one does not consent (and can successfully communicate this without
compromising one's position), can one's internal correspondent continue to
send me e-mails - without them being monitored?

Further, since the first part of the 'disclaimer' says that, "the BBC
monitors e-mails sent", there is the unanswered question, "Was the original
e-mail monitored - WITHOUT the recipient's consent?"

Additionally, what constitutes a 'response'?  If the original message had
requested a 'read' or even 'received' response - often automatically sent --
would this be a 'consent' to the monitoring?

Differences between 'opt-in' and 'opt-out' are exploited by marketeers (see
several other threads, most recently Knox, RISKS 21.94), but RISKS arise
when those who write disclaimers are ignorant of the technology involved.

Also, why pick on only one form of communication?  How long before the
'thought police' in the BBC extend their monitoring to the telephone,
telefaxes and letters?

Michael (Streaky) Bacon

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

Date: Tue, 12 Mar 2002 07:18:22 -0000
From: "Michael (Streaky) Bacon" <streaky () baconsonline com>
Subject: Re: Loosing It's Grammer Skill's (Searle, RISKS 21.94)

I recently reviewed some pages on the Web site of a major computer
manufacturer and, among other issues, found several solecisms, grammatical
errors, strange and tortuous phraseology, mixed persons, typographical
errors and differences in how separate hypertext links to the same 'off
site' page were treated.  A particular classic was: "...  challenges of
reliability, scalability, and manageability that are needed ..." -- I hadn't
realised that anyone *needed* challenges!

On enquiry I was told that no-one reviewed for content, as the pages were
written by subject matter experts.  Any reviews were to check conformance
with corporate presentation style.  But even that alleged check missed the
incorrect presentation of the company name in one instance.

SMEs may know their subject, but clearly that isn't grammar, law or risk
management.

The risks are manifold, and include: inappropriate material being
accidentally or deliberately posted; the company being committed to do
something they never intended to do; corporate liability being attracted in
a manner that is not properly (risk) managed; any corporate commitment to
quality being thereby degraded.

Michael (Streaky) Bacon

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

Date: Tue, 12 Mar 2002 09:54:21 +0100
From: Klaus Brunnstein <brunnstein () informatik uni-hamburg de>
Subject: Re: Loosing It's Grammer Skill's (Searle, RISKS 21.94)

Concerning Greg's complaint about some impact of contemporary publication
support software qw cause in reducing the quality of English (or AmGlish?)
writing, another -- possibly more serious -- cause may be related to what I
call the "imperialism of English": when multi-million non-native English
speakers and writers are forced to use English as communication vehicle, how
can someone assume that "quality English" may result? Moreover, differences
between "island English" and "American English" may also contribute to bad
grammar (as well as manuals even from English companies).

On the other side, we observe that German students use publication software
to produce better looking papers though at significantly lesser grammatical
quality. This tendency which is also observable in schools may not only be
attributed to usage if IT!

My 2 cents (yes, we have also cents in Germany now), with my apologies for
possibly bad grammar and expression :-)

Klaus Brunnstein (March 12, 2002)

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

Date: Tue, 12 Mar 2002 08:25:13 -0800 (PST)
From: albaugh () spies com
Subject: Re: Loosing It's Grammer Skill's (Searle, RISKS-21.94)

> ... "Driver's Wanted" 

I believe Greg has misunderstood. They are trying to warn you that they are
a "family business", and that there are outstanding warrants for the driver
of this cab.  Perhaps you will choose this cab for a sense of adventure.
Perhaps you will decide that arriving at the airport with a half-dozen
police cars in hot pursuit is not your cup of tea.  Either way, you have to
applaud their honesty.

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

Date: Tue, 12 Mar 2002 10:25:35 -0000
From: "Merlyn Kline" <merlyn () zyweb com>
Subject: Re: Loosing It's Grammer Skill's (Searle, RISKS-21.94)

  [I omitted a comment on "Driver's Wanted" similar to Mike Albaugh's 
  preceding message.  PGN]

[...] as you point out:

> Sure, I know what they really mean,
and
> English is defined by its common usage over an extended period of time.

So what's the problem? Sure[1], it's annoying when the language drifts away
from the dialect you had hammered in to you at school, but that's life. It's
not wrong; just different. If you want annoying, you should try being a
British English speaker reading Risks![2] In fact, as has been mentioned on
Risks before, there are actual risks here: e.g. American English has lost
the distinction between "ensure" and "insure". Here in Britain, I'm happy to
deal with someone who ensures risks won't be realised, but not so happy to
deal with someone who just insures. In America, I can't tell which is
which. One of my favourite examples of this type of error is a notice in a
local music store that says "CDs cannot be returned for a refund. This does
not effect your statutory rights." (No, I bet it doesn't!). I'm not sure
this is even an error in America, let alone funny[3].

The evolution of language is driven by a fantastically complex and
ultimately self-correcting system. If (e.g.) the taxi firm starts to suffer
because everyone thinks their drivers are wanted criminals, eventually there
will be another drift in the language to enhance the distinctions between
possession, plurals and elision.

Anyway, isn't your complaint really about the failings of an education
system that is apparently incapable of helping its clients understand the
simple rules related to the use of apostrophes in English?

>  Are we doomed to accept bad grammar as the official standard?

We are :(
Chaucer, even Shakespeare, would be horrified by what we call English.

Merlyn Kline

[1] Arrgh! I'm drifting into American English idiom! The power of context!

[2] Perhaps you are. See [1].

[3] OTOH perhaps I am mislead by the ever increasing abuse of these two
words, and the distinction remains in American English as well as
British. I'm not sure.

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

Date: Tue, 12 Mar 2002 14:31:28 +0000
From: Dave Williams <dave_williams () compuserve com>
Subject: Re: Loosing It's Grammer Skill's (RISKS-21.94)

You are talking about the rise of the Apostrophe Virus (also known in the
UK as the Greengrocers' Virus, because the misplaced apostrophe only used
to appear on hand lettered signs in fruit and vegetable shops)

The rise of DIY publishing, in print and on the Web, has propagated this
virus to the point that it now appears in national newspapers,
advertisements, and on major Web sites; all published by people who ought to
know better. The problem is compounded by the long-term shift to a less
literate culture, where words are less cared for, and spellcheckers are
assumed to handle all grammar issues.

As people see the misplaced apostrophe more and more in established
media, the virus becomes legitimised, and so they are more likely to use
an apostrophe, on the principle that it's best to put it in just in case

The probable future is that in time, the use of the apostrophe-s will become
the default for all occurrences of the letter s at the end of a word. So we
are soon likely to assume it's normal to see apostrophe's at the end of
word's, even though reader's of mature year's might think it suck's.

Dave Williams (or should that be William's?)

  [DIY = Do-it-yourself, a.k.a. samizdat, which might inspire a
  self-publishing outfit called Sammy's.Dot.com?  PGN]

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

Date: Tue, 12 Mar 2002 11:18:53 -0800
From: Rob Slade <rslade () sprint ca>
Subject: Re: The RISK of ignoring permission letters (Knox, RISKS-21.94)

Our recommendation in regard to spam, for those who did not want to expend
the time and effort required to track down the spammer and his upstream
provider, has always been to ignore it.  This new style of spam is rather
more problematic.  The United States now has a slew of legislation in regard
to spam: various states have their own, and I believe that there is federal
legislation as well.  The legal questions boggle the mind.  Is this just
another address harvesting scheme, like the old "reply to this message if
you want off the list" types?  Does a failure to respond to this type of
message constitute a legitimate "acceptance" on my part?  (Particularly for
those of us from outside the US?)

> This is NOT requesting permission. This is warning you that by NOT
> responding, you are implicitly consenting to them sending you spam. With
> UCITA, this might even become legally acceptable (like click-wrap licenses).

Yet another twist to the legal questions.  Would this kind of thing be legal
in Virginia?

> Finally, note how they try to play it cool in the last paragraph, talking
> about how I 'requested' to be notified of special offers. 

Apparently I've done all kinds of things on the net that I've never actually
done.  I've even been signed up in some weird kind of pyramid/mlm scam that
I've never heard of ...

rslade () vcn bc ca  rslade () sprint ca  slade () victoria tc ca p1 () canada com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

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

Date: Tue, 12 Mar 2002 08:34:58 -0500
From: "Greg Searle" <greg_searle () hotmail com>
Subject: Re: The RISK of ignoring permission letters (Knox, RISKS-21.94)

The best thing that you can do when you receive this type of message is to
REPORT IT.  This message itself is unsolicited e-mail.  If you report it to
the ISP that it was sent through, then the ISP may enforce its Acceptable
Use Policy, and make the offending company think twice about this practice.
Spammers are good liars.  Call the lie and report the abuse, pointing out
that you DID NOT request the message.

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

Date: Mon, 11 Mar 2002 16:38:34 -0800
From: "George C. Kaplan" <gckaplan () ack berkeley edu>
Subject: Re: The RISK of ignoring permission letters (Knox, RISKS-21.94)

> With UCITA, this might even become legally acceptable ... 

I don't know about whether UCITA makes this legal, but it's commonly
accepted that such "opt-out" links don't actually remove you from the
spammer's mailing list.  Instead, they confirm that there's a real person
reading e-mail sent to your address, thus ensuring that you'll end up on
*more* mailing lists.

> Finally, note how they try to play it cool in the last paragraph, talking
> about how I 'requested' to be notified of special offers. This is an
> outright lie. 

If they lie to you about this, don't you think they'll lie to you about 
what their opt-out link does?

George C. Kaplan, Communication & Network Services, University of California
at Berkeley  1-510-643-0496  gckaplan () ack berkeley edu

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

Date: Tue, 12 Mar 2002 07:27:05 -0000
From: "Michael (Streaky) Bacon" <streaky () baconsonline com>
Subject: Re: The RISK of ignoring permission letters (Knox, RISKS 21.94)

This presents a compound RISK.  On the one hand, not replying appears to
give consent to continuing to receive e-mail; on the other hand, replying
confirms your e-mail address - which can then be resold as a legitimate,
active, human-attended address.

Michael (Streaky) Bacon

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

Date: Tue, 12 Mar 2002 14:08:06 -0800
From: Dave Gillett <dgillett () deepforest org>
Subject: Re: Welland Canal Bridge runs into ship (RISKS-21.61)

The freighter Windoc, which was hit by a lift bridge last summer, losing its
wheelhouse and funnel and catching fire, has made the news again.

Windoc was apparently one of twelve freighters wintering over in Hamilton
harbor, and one of three of those to break loose from their moorings in 130
kph winds last week.  The ship drifted for about 5 km before grounding close
to a major highway.

No obvious computer connection, just follow-up on an old item....

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

Date: Mon, 11 Mar 2002 22:07:41 -0500
From: Nick Simicich <njs () scifi squawk com>
Subject: Re: LED lights can reveal computer data (NewsScan, RISKS-21.94)

It is not quite true that no one has looked at reading computer data from
LEDs before.  In the 1990 timeframe, there was a brand of scuba computer
called the Orca Delphi that would dump recordings of your depth profiles to
a LED which normally functioned as a decompression warning LED.  You put it
in dump mode by disconnecting the power (9v lithium or alkaline battery) and
reconnecting it within a few seconds.

As you can imagine, most diving computers are designed on the "KISS"
principle.  Errors in these computers could cause a life threatening
condition - by incorrectly calculating your decompression obligation, they
could put you at risk.  An inexperienced diver might not detect that the
answers that the computer was calculating was wrong. But they are purposely
simply devices. They may not even have an "on" button, for example---they
may turn on in response to water pressure, conductivity, or, in the case of
this computer, the fact that you turned on your air (this computer also
tried to estimate how much air you had left in minutes based on how rapidly
you were using it, so it had a high pressure air connection).  This frees
you from the task loading of having to remember to turn the computer on.
Many do not have an off switch - once they determine that you have
"completely decompressed" according to their mathematical model, they turn
off automatically.  The point here was that the engineers did not want to
add the complexity of an extra electrical interface to this computer for
dumping - they wanted two inputs, the water pressure and tank pressure
transducers, one power input, and the lcd panel for output.  And the LED to
call your attention to warning issues.  The point was to try and get a
second use out of this LED as a data output device.

In any case, the company had promised a dump device for the computer and
never delivered.  The method of memory dumping was not initially announced,
although they eventually mentioned, at a lecture, that it was going to be a
"light pen". Someone noted that under some circumstances, disconnecting and
reconnecting the power to the computer (it was a nine volt battery) caused
the LED to light up for a few seconds at half brightness.  I made a call to
the engineer and he admitted that yes, that was their planned dump method --
they flashed the LED at 2400-8-N-1, and simply dumped the memory.  The dump
was in this format:

> 000 C7 FF C0 48 C0 01 8D A5 8D A0 C7 FF C0 47 C0 07
> 010 89 97 8D 9A 84 40 84 33 80 2E 80 2B 80 2C 80 2D

...and so on.  That is, it dumped in ascii characters, complete with offsets
at the beginning of each line, and a crlf at the end.

There was a checksum for some of the memory, but not much of it.

I'm not an electronics person, and, whereas there were circuits published
(on rec.scuba), we were never able to get anything that worked reliably.  We
tried the approach of reading the LED directly, and it was difficult to hold
the detector in the exact alignment required for the duration of the dump.
It was actually so difficult to get a good dump by reading the light from
the LED that we built a circuit that measured battery voltage instead.  The
company engineers had the same problem, I heard.  I also heard that they had
problems getting consistent readings because of LED brightness differences
and positioning under the faceplate.  The engineer suggested the battery
method to me - and whereas I was able to breadboard a circuit and get a dump
with it, I was not enough of an electronics person to be able to build one
that would adapt to various battery voltages - mine would only work with a
fresh lithium battery and an oscilloscope for tuning.

Obviously, Loughry has a great deal more skill than we did in reading these
LEDs.

Search google in rec.scuba for the words "orca delphi dive dump device".
There are some posts from 1990.

Nick Simicich - njs () scifi squawk com

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

Date: Mon, 11 Mar 2002 15:53:49 -0800
From: peter () whirled-routers com
Subject: Re: LED lights can reveal computer data (NewsScan, RISKS-21.94)

I'll believe it when I see it.
The articles actually state, that no one got it to work yet.
Until then : FUD !

Peter B.

Whirled Routers, 200 Pier Ave. Suite 39, Hermosa Beach, CA 90254 USA
310 376 8755 / fax 8785

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

Date: Tue, 12 Mar 2002 07:49:30 -0800
From: Rob Slade <rslade () sprint ca>
Subject: REVIEW: "Incident Response", Kevin Mandia/Chris Procise

BKINCDRS.RVW   20020108

"Incident Response", Kevin Mandia/Chris Procise, 2001, 0-07-213182-9,
U39.99
%A   Kevin Mandia mandiak () erols com
%A   Chris Procise authors () incidentresponsebook com
%C   300 Water Street, Whitby, Ontario   L1N 9B6
%D   2001
%G   0-07-213182-9
%I   McGraw-Hill Ryerson/Osborne
%O   U$39.99 905-430-5000 fax: 905-430-5020
%P   509 p.
%T   "Incident Response: Investigating Computer Crime"

Part one is supposed to provide us with the basics of incident
response.  Despite the assertion, in the introduction, that such
response deals with much more than computer crime and that incidents
can vary widely, chapter one details a deliberate and malicious
intrusion into a computer system, by an incredibly inept attacker,
using inside information.  Chapter two provides a definition of
incident response, but it does lean heavily towards crimes, law
enforcement involvement, and directed attacks.  The material also
assumes that an incident response team can be called upon or formed at
short notice.  The suggestions for advance preparation, in chapter
three, do cover a broad range, but the writing is not always
organized, and the material has gaps and covers many topics
superficially.

Part two purports to deal with technical issues.  Chapter four deals
with guidelines for investigations, but, again, concentrates only on
directed attacks from outside the organization.  The computer forensic
process, in chapter five, is limited to retention and copying of
evidence.  There is a rather terse review of Internet Protocol header
information in chapter six.  Chapter seven lists some information
related to network monitoring and logging.  "Advanced Network
Surveillance" (chapter eight) examines a few of the more convoluted
exploits.

Part three describes operating system functions associated with system
investigation.  Chapters nine to twelve list a number of utility
programs that can be used to obtain system information.

Part four is a grab bag of material dealing with special topics,
chapter thirteen dealing with routers, fourteen the Web, and fifteen
various servers.  A number of security and security breaking tools are
enumerated in chapter sixteen.

The emphasis in this book is adversarial: seeing incident response as
primarily a matter of active defence against an active attacker.  Most
companies will probably see incident response as a matter related to
technical support: an endless stream of incidents, most of which are
trivial, and a select few of which indicate serious problems.  As
such, the book does, occasionally, point out some matters to consider,
and possibly new practices to adopt in order to deal with those
isolated events that are important enough to turn over to law
enforcement agencies.  However, overall, the text does not provide
much guidance in preparing for and responding to serious incidents.

copyright Robert M. Slade, 2002   BKINCDRS.RVW   20020108
rslade () vcn bc ca  rslade () sprint ca  slade () victoria tc ca p1 () canada com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

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

Date: 12 Feb 2001 (LAST-MODIFIED)
From: RISKS-request () csl sri com
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.  Alternatively, via majordomo,
 send e-mail requests to <risks-request () csl sri com> with one-line body
   subscribe [OR unsubscribe]
 which requires your ANSWERing confirmation to majordomo () CSL sri com .
 [If E-mail address differs from FROM:  subscribe "other-address <x@y>" ;
 this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
 Lower-case only in address may get around a confirmation match glitch.
   INFO     [for unabridged version of RISKS information]
 There seems to be an occasional glitch in the confirmation process, in which
 case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
   .MIL users should contact <risks-request () pica army mil> (Dennis Rears).
   .UK users should contact <Lindsay.Marshall () newcastle ac uk>.
=> The INFO file (submissions, default disclaimers, archive sites,
 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 risks () CSL sri com 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 20" for volume 20]
 http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
   Lindsay Marshall has also added to the Newcastle catless site a
   palmtop version of the most recent RISKS issue and a WAP version that
   works for many but not all telephones: http://catless.ncl.ac.uk/w/r
 http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
 http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
    http://www.csl.sri.com/illustrative.html for browsing,
    http://www.csl.sri.com/illustrative.pdf or .ps for printing

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

End of RISKS-FORUM Digest 21.95
************************