Risks Digest 22.13

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

RISKS-LIST: Risks-Forum Digest  Thursday 27 June 2002  Volume 22 : Issue 13

   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/22.13.html>
and by anonymous ftp at ftp.sri.com, cd risks .

  Contents:
Secret American spy photos broadcast unencrypted over satellite TV 
  (Duncan Campbell via Tim Finin via Dave Farber)
Software problem kills soldiers in training incident (Steve Bellovin)
Safety and human factors in ATC (via Hayley Davison and Nancy Leveson)
Car repair shops often can't crack diagnostic code (Monty Solomon)
Qui audit ipsos auditors? (Rob Slade)
Tools gauging blood pressure raise questions (Monty Solomon)
Microsoft's secret plan to secure the PC (Monty Solomon)
Risks to your privacy from using MSN Messenger 4.6? (Michael Weiner)
Microsoft sent Nimda worm to developers (Mike Hogsett)
Microsoft's Allchin: API disclosure may endanger U.S. (Brien Webb)
Identity theft site (Conrad Heiney)
Randomly generated 4-letter words in sendmail queue-ids (Earle Ake)
New virus can infect picture files (NewsScan)
Norwegian history database password lost and retrieved (Lillie Coney)
Calculators vs. handheld computers (NewsScan)
England halts distribution of bad money (Monty Solomon)
E-mail address parsing (William Colburn)
Risks subscription problem (Ethan Benatan)
Re: NERC + token ring (T Panton)
Re: US Navy suffers domain hijacking (Jay R. Ashworth)
Re: Please ignore the anti-shoplifting device! (Scott Peterson)
REVIEW: "Developing Trust", Matt Curtin (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Thu, 13 Jun 2002 22:39:31 +0900
From: Dave Farber <dave () farber net>
Subject: Secret American spy photos broadcast unencrypted over satellite TV

  [from Tim Finin, Prof Computer Science & Electrical Eng, Director Inst. for
  Global Electronic Commerce, U Maryland Baltimore County, 1000 Hilltop,
  Baltimore MD 21250  finin () umbc edu 410-455-3522 http://umbc.edu/~finin/
    Dave's IP archives at:
      http://www.interesting-people.org/archives/interesting-people/]

Now showing on satellite TV: secret American spy photos;
  Security lapse allows viewers to see sensitive operations
Duncan Campbell, Thursday June 13, 2002, *The Guardian*

European satellite TV viewers can watch live broadcasts of peacekeeping and
anti-terrorist operations being conducted by US spyplanes over the Balkans.
Normally secret video links from the American spies-in-the-sky have a
serious security problem - a problem that makes it easier for terrorists to
tune in to live video of US intelligence activity than to get Disney
cartoons or new-release movies.  For more than six months live pictures from
manned spy aircraft and drones have been broadcast through a satellite over
Brazil.  The satellite, Telstar 11, is a commercial TV relay. The US
spyplane broadcasts are not encrypted, meaning that anyone in the region
with a normal satellite TV receiver can watch surveillance operations as
they happen.  The satellite feeds have also been connected to the Internet,
potentially allowing the missions to be watched from around the globe.
  http://www.guardian.co.uk/international/story/0,3604,736462,00.html

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

Date: Thu, 13 Jun 2002 09:38:10 -0400
From: Steve Bellovin <smb () research att com>
Subject: Software problem kills soldiers in training incident

According to a U.S. Army report, a software problem contributed to the
deaths of two soldiers in a training accident at Fort Drum.  They were
firing artillery shells, and were relying on the output of the Advanced
Field Artillery Tactical Data System.  But if you forget to enter the
target's altitude, the system assumes a default of 0.  (A Web site I found
indicates that (part of) Ft. Drum is at 679 feet above sea level.)  The
report goes on to warn that soldiers should not depend exclusively on this
one system, and should use other computers or manual calculations.

Other factors in the incident include the state of training of some of 
the personnel doing the firing.  [Source: AP]

Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)

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

Date: Fri, 14 Jun 2002 11:03:25 -0400
From: Peter Neumann <neumann () csl sri com>
Subject: Safety and human factors in ATC (via Hayley Davison and Nancy Leveson)

Air control safety complaints soar
By Paul Marston Transport Correspondent
*Daily Telegraph* (Britain), 14 Jun 2002 [PGN-ed]

The number of formal complaints of over-work from air-traffic controllers
has more than doubled since the Swanwick national control centre opened in
January 2002.  National Air Traffic Services (NATS) said staff had filed 30
"overload" reports in the last five months, compared with 12 during the same
period in 2001.  [Computer-related problems related to Swanwick and UK ATC
are noted in RISKS-22.02,03,09,12.]  Planning staff at Swanwick have also
complained about the legibility of some flight levels and airport codes on
their terminal displays.

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

Date: Tue, 25 Jun 2002 01:32:16 -0400
From: Monty Solomon <monty () roscom com>
Subject: Car repair shops often can't crack diagnostic code

At least a couple of times a week, mechanic Ernie Pride tells customers at
his independent repair shop he can't fix their cars because he doesn't know
what's wrong with them. Go to the dealer, he advises.  He has the experience
and knowledge to service vehicles but lacks the closely guarded information
needed to diagnose problems with today's high-tech cars.  Automakers refuse
to make much of it available to independent shops that compete with
higher-priced dealerships. The practice is raising hackles in Congress and a
vigorous defense by the industry.  ...  [AP, June 24, 2002]
  http://www.cnn.com/2002/TECH/ptech/06/24/diagnosing.cars.ap/

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

Date: Wed, 19 Jun 2002 14:25:37 -0800
From: Rob Slade <rslade () sprint ca>
Subject: Qui audit ipsos auditors?

The Enron/Anderson debacle is fading as news, but it has some reverberations
for those of us in the info tech fields.

Anderson is not alone in engaging in questionable audit practices.  Others
of the "Big 5" are under scrutiny, in at least two cases involving,
ironically, high tech companies.  For the past decade or more, there have
been pressures to reduce regulatory oversight, and we are now seeing the
results.

So, what is the relation to IT?  Well, these are the same firms who hold the
major contracts for auditing information security and assurance.

(In relation to the subject line: yes, "ISACA," I know.)

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: Fri, 21 Jun 2002 23:00:04 -0400
From: Monty Solomon <monty () roscom com>
Subject: Tools gauging blood pressure raise questions

Gina Kolata, *The New York Times*, 16 Jun 2002

Across the nation, hospitals and doctors' offices are returning blood 
pressure cuffs to their manufacturers to comply with a federal 
environmental initiative to cut down on the use of mercury, a toxic 
metal that can pollute the air and water when disposed of improperly.
But leading medical experts, joined by the American Heart Association 
and the National Heart, Lung and Blood Institute, say the mercury 
gauges are being replaced by newer devices that may be unreliable, 
and they warn that inaccuracies may be leading to false diagnoses and 
inappropriate treatments.  [...]
  http://www.nytimes.com/2002/06/16/health/16BLOO.html

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

Date: Tue, 25 Jun 2002 01:40:54 -0400
From: Monty Solomon <monty () roscom com>
Subject: Microsoft's secret plan to secure the PC

You've heard of Trustworthy Computing, and the massive corporate remodeling
going on at Microsoft where every developer, product manager, and executive
assistant has been asked to rethink everything they do in the context of
security. Well, that's just the tip of the iceberg.  Secretly, the company
has been working on a plan to rearchitect the PC from the ground up, to
address the security, privacy, and intellectual property theft issues that
dog the industry today. Inexplicably, the company pulled an Apple and chose
to detail its plans solely to Newsweek, so we only have that one report to
work from. But if Newsweek's take on the plan is correct, and consumers and
businesses buy into the new devices that would result, the PC landscape will
soon change forever.  [...]
  http://www.ntsecurity.net/Articles/Print.cfm?ArticleID=25681

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

Date: Tue, 18 Jun 2002 17:44:11 +0200
From: "Michael Weiner" <michael_weiner () gmx net>
Subject: Risks to your privacy from using MSN Messenger 4.6?

Since I installed MS Messenger 4.6 (4.6.0082) on my machine, my firewall is
going wild: In addition to numerous Microsoft sites, Messenger is contacting
the following sites each time I log in: expedia.com, xp.mcafee.com,
carpoint.msn.com and port-64-1956779-zzt0prespect.devices.datareturn.net. No
way to know what information MS Messenger is transmitting to these sites, I
did not find any meaningful information on it on the Microsoft website...

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

Date: Fri, 14 Jun 2002 17:26:34 -0700
From: Mike Hogsett <hogsett () csl sri com>
Subject: Microsoft sent Nimda worm to developers 

Microsoft accidentally sent the virulent Nimda worm to South Korean
developers when it distributed Korean-language versions of Visual Studio
.Net that carried the virus, the company acknowledged Friday.

http://news.com.com/2100-1001-935994.html

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

Date: Fri, 14 Jun 2002 12:09:43 -0700
From: Active Quality Software <activequalitysw () la com>
Subject: Microsoft's Allchin: API disclosure may endanger U.S.

> From a 2002/05/13 article by Caron Carlson in eweek.com:

http://www.eweek.com/article/0,3658,s%253D701%2526a%253D26875,00.asp

  "A senior Microsoft Corp. executive [Jim Allchin] told a federal court
  last week that sharing information with competitors could damage national
  security and even threaten the U.S. war effort in Afghanistan. He later
  acknowledged that some Microsoft code was so flawed it could not be safely
  disclosed."

and later, directly quoting Allchin...

  "Computers, including many running Windows operating systems, are used
  throughout the United States Department of Defense and by the armed forces
  of the United States in Afghanistan and elsewhere."

Microsoft proposes to withhold details of the MSMQ protocol (TCP port 1801
and UDP port 3527), the Windows File Protection API, as well as APIs for
anti-piracy protection and digital rights management under the security
carve-out.

I recall that the Windows NT family of operating systems was designed to
meet DOD's C2 security criteria, including the Orange Book (standalone,
which they passed), as well as Red Book (networking) and Blue Book
(subsystems) criteria which they started working on at least 4 years ago; I
don't know if they've yet passed, but I suspect not if it's so flawed that
they don't want to disclose the protocol or API!  See
http://msdn.microsoft.com/library/default.asp?  url=/library/en-
us/dnproasp2/html/windowsntsecuritysystems.asp

So, one risk of flawed software might be that you have to publicly invoke
national security (read patriotism) as a last refuge from legal process.

--Brien Webb http://www.LA.com/

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

Date: Wed, 26 Jun 2002 15:32:48 -0700
From: "Conrad Heiney" <conrad () fringehead org>
Subject: Identity theft site

According to CNN's website today
  http://www.cnn.com/2002/TECH/internet/06/26/identity.theft.ap/index.html
a nongovernmental organization called CardCops is providing a service in
which consumers can check to see if their credit cards have been abused in
some way.

The check is done by visiting the website and entering your credit card
number.

The RISKS here are bad enough to be humorous. Although CardCops themselves
appear to be a legitimate organization (at least at time of press) , and do
not themselves ask for the expiration date required to complete a
transaction, there's no protection against copycat websites whose intent is
entirely evil, or telephone scams based on the CardCops publicity.  The
quality of the data is another obvious minefield.

  [And as of today, their site is also down due to high volume.]

Conrad Heiney  conrad () fringehead org  http://fringehead.org

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

Date: Mon, 17 Jun 2002 16:59:38 -0400 (EDT)
From: Earle Ake <earle.ake () hcst com>
Subject: Randomly generated 4-letter words in sendmail queue-ids

I was checking the sendmail queue today when I noticed a message with a
certain 4-letter word as part of the queue id that ends in "uck".  I checked
the sendmail logs further and there was another 4 letter word as part of
another queue id that also ends in "uck" and another that ends in "ock" with
a certain letter before it.  I wonder how many people pay attention to queue
IDs and would raise an eyebrow on those.  I also wonder if any of the
filtering software out there might filter out legit mail messages just
because certain random 4 letter words were contained in the queue-id that
are inserted into the mail headers as they pass through each system.

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

Date: Fri, 14 Jun 2002 08:32:37 -0700
From: "NewsScan" <newsscan () newsscan com>
Subject: New virus can infect picture files

McAfee Security is reporting that a new virus called "Perrun" is the first
ever to infect picture files, which, along with other data files, have long
been considered safe from such threats. Researchers at McAfee received the
virus from its creator and say it's what's called a proof-of-concept virus
and does not cause any damage. Up until now, viruses infected and were
spread through program files; data files might be deleted or damaged, but
Perrun is the first to infect them by inserting portions of the virus code
into the picture file. When a .JPG picture is viewed, the virus installs a
file on the victim's hard drive that can infect other pictures. Because the
original picture looks fine, the victim won't know that anything's amiss.
[AP, 13 Jun 2002; NewsScan Daily, 14 June 2002]
  http://apnews.excite.com/article/20020613/D7K4F4EG1.html

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

Date: Tue, 11 Jun 2002 11:37:02 -0400
From: Lillie Coney <lillie.coney () acm org>
Subject: Norwegian history database password lost and retrieved

After the password for accessing a Norwegian history museum's database
catalog for 11,000 books and manuscripts had been lost when the database's
steward died, the museum established a competition to recover it.  Joachim
Eriksson, a Swedish game company programmer, won the race to discover the
password (ladepujd, the reverse of the name of the researcher who had
created the database).  How he arrived at it was not disclosed.  [Source:
Long-lost password discovered: Norwegian history database cracked with help
from the Web, By Robert Lemos, MSNBC, 11 Jun 2002; PGN-ed]

Lillie Coney, Public Policy Coordinator, U.S. Association for Computing
Machinery Suite 510 2120 L Street, NW Washington, D.C. 20037 1-202-478-6124

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

Date: Wed, 12 Jun 2002 08:01:42 -0700
From: "NewsScan" <newsscan () newsscan com>
Subject: Calculators vs. handheld computers

As handheld computers become increasingly competitive with Texas Instrument
(TI) calculators for mathematical graphing, TI has been busy adding features
such as address books, organizers, and a large variety of spreadsheet
programs. The main advantage of handhelds, of course, is that they are
general-purpose devices.  Nelson Heller, who publishes the Heller Report
newsletter on education technology, says that both calculators and handheld
computers are getting better but adds: "The question I see is whether a
specialized appliance like the graphing calculator will in the long run lose
out to a more generalized appliance like a PDA."  Calculators, however, still
have two advantages: lower cost (about half of a PDA's cost) and
acceptability in testing situations, in that students are permitted to use
calculators but not handheld computers when taking the Scholastic Aptitude
Test.  The reason? Fear that some students might use the infrared messaging
capability of handhelds to cheat on the test. (AP/*San Jose Mercury-News*,
12 Jun 2002; NewsScan Daily, 12 June 2002)
  http://www.siliconvalley.com/mld/siliconvalley/3453135.htm

  [And exam proctors will be able to determine that the so-called
  "calculator" is not surreptitiously a general-purpose device?  PGN]

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

Date: Tue, 28 May 2002 13:01:11 -0400
From: "monty solomon" <monty () roscom com>
Subject: England halts distribution of bad money 

The Bank of England asked banks Monday to stop issuing its new
anti-counterfeit 5-pound notes after discovering that serial numbers on the
currency could be rubbed off.  [AP, 27 May 2002]
  http://news.lycos.com/news/story.asp?section=World&storyId=423067

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

Date: Fri, 21 Jun 2002 14:23:45 -0600
From: "Schlake (William Colburn)" <"@ @"@nmt.edu>
Subject: E-mail address parsing

About the same time PGN posted to the list about RISKS SPAM, I got a call
from someone who was going through corporate-education on e-mail addresses.
She had been given a test, and she had to identify which e-mail addresses
were valid.  She was told that half of them were invalid.  The purpose of
the test was to train employees to be able to properly harvest the e-mail
addresses of their elderly customers.  As far as I can tell, all of them
were valid.

The very next day, I made myself a new e-mail address, "@ @"@nmt.edu.  I
like this address, it has been a lot of fun so far.  No
customer-relations software seems able to accept that this is a valid
e-mail address.  People seem pretty trusting, and are willing to try and
(and are surprised when it works).

The risk is that the customer-relations programmers are living in a
world of [a-z0-9_] for mailbox names, while the standard has long
allowed for virtually any character (including NULL).  More and more
services are unavailable if you "don't have an e-mail address", and
usually even the web form to submit a bug won't process because it wants
your e-mail address, so they never even know.  Even if I wasn't taunting
them with "@ @", I'd be giving out my address with a "+" and then the
name of their company to help me sort out where my SPAM is really coming
from. Few pieces of software will allow even the harmless  little "+"
character in an address.

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

Date: Thu, 13 Jun 2002 16:32:40 -0700
From: Ethan Benatan <ethan.benatan () reed edu>
Subject: Risks subscription

  [In attempting to confirm a subscription request, Ethan's mail system
  responded to RISKS and not to majordomo.  This seems to happen from other
  e-mail systems as well.  PGN]

Eudora's recent MacOS X version is broken and ignores reply-to headers;
older versions didn't used to do that.

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

Date: Tue, 11 Jun 2002 17:06:14 +0000 (GMT)
From: tpanton () attglobal net
Subject: Re: NERC + token ring (Ladkin, RISKS-22.12)

In RISKS-22.12, Peter Ladkin mentions NERC's use of a token ring as if this
were obviously a bad thing.  If I remember correctly, a token ring has
better behaviour at high load (as compared to ethernet), because it
implements a round-robin allocation and thus does not waste capacity in
collisions.

Indeed a precursor (the Cambridge ring) had the endearing characteristic
that high loads made the PLL clock drift fast, upping the capacity by a few
percent.  The risk is in assuming the dominant technology is best for all
situations.  URL: http://www.westpoint.ltd.uk/ - Internet recon.

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

Date: Tue, 11 Jun 2002 12:46:25 -0400
From: "Jay R. Ashworth" <jra () baylink com>
Subject: Re: US Navy suffers domain hijacking (Brent, RISKS-22.10)

Thank you, Geoffrey, for you've given me a hook on which to hang one of my
*favorite* rants.  

"navydallas.com" (the proper spelling, for the DNS is case-insensitive by
design) is *not* a "trusted domain", in any remote sense of the word.  Nor
is "myflorida.com" (an alias for www.state.fl.us, which apparently is too
complicated for people) or "largo.com".

I have a *real* dislike for municipal and government web teams who have *so*
little faith in their audience's mentalities that they feel they have to
spurn the TLDs in which they *would* be protected -- and could be trusted
(the ".gov" and ".us" domains which have -- or perhaps in the latter case
"had" -- restrictions on registration) -- for ".com", just because "that's
the only thing people understand".  <sigh>

At least it turned around and bit Largo Florida in the ass about a year ago
when their mail server melted down under the load of 60K+ *bounce* and
complaint messages when someone used "largo.com" as a forged return address
on some spam.

I've seriously thought about registering "yourflorida.com" and putting up a
website that looks very much like myflorida.com, but is parody (when you
look closely enough), and which explains exactly why I think they are doing
wrong... but while that wouldn't even *be* civil disobedience, much less
copyright infringement (based on the Skyywalker Music case), the fact that no
less a legal luminary than Lawrence Lessig thinks that civil disobedience is
no longer a useful approach
  http://www.reason.com/0206/fe.jw.cyberspaces.shtml
scares me to death.

Jay R. Ashworth, Baylink, Member of the Technical Staff, The Suncoast Freenet
Tampa Bay, Florida  +1 727 647 1274  http://baylink.pitas.com  jra () baylink com

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

Date: Thu, 06 Jun 2002 19:21:10 -0700
From: Scott Peterson <scottp4 () mindspring com>
Subject: Re: Please ignore the anti-shoplifting device! (Hendricks, R-22.12)

> I also realized that the alarm would likely sound as I exited at the other
> end of the store.

Which also points out a whole series of other problems.  I worked with 
corporate security for a large supermarket chain in So. Calif. several 
years ago.

I don't think the law has significantly changed, but at the time, you, as 
an individual, could not stop someone for a misdemeanor (like shoplifting) 
unless you saw them take the item and followed them until they exited.  If 
you did, it was quite possible for you to be charged with unlawful 
detention getting both yourself and the company in big trouble. Having an 
alarm go off as you walk through it was not a good enough reason to stop 
someone.  Only a sworn peace officer could stop someone in those 
circumstances.

For this reason and the safety of the employees, they were required to know
the store policy and follow it.  If they suspected someone of shoplifting
they were to call someone in management and let them deal with it. Under no
circumstances were they to take any action on their own.

Bottom line: Those alarm units are often more a psychological barrier than a
legal one.

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

Date: Mon, 17 Jun 2002 08:00:56 -0800
From: Rob Slade <rslade () sprint ca>
Subject: REVIEW: "Developing Trust", Matt Curtin>

BKDEVTRS.RVW   20020514

"Developing Trust", Matt Curtin, 2002, 1-893115-72-0, U$39.95
%A   Matt Curtin cmcurtin () interhack net
%C   175 Fifth Ave., New York, NY   10010
%D   2002
%G   1-893115-72-0
%I   Springer-Verlag/Apress
%O   U$39.95 212-460-1500 800-777-4643 orders () springer-ny com
%P   282 p.
%T   "Developing Trust: Online Privacy and Security"

The title, foreword, preface, and introduction aren't terribly clear
about the purpose of the book.  Ultimately, the key word seems to be
not trust, but privacy: the work appears to be directed at providing
tips for developers, of all stripes, to help maintain the
confidentiality of information.

Part one is a generic introduction to security and privacy.  Chapter
one, entitled "Why Privacy," seems, ironically, to move us even
further away from the topic of privacy.  The emphasis of the chapter
is on intrusions, although the reconnaissance phase does get the most
space.  (The subtitle, "Why This Book," does not appear to be
addressed.)  The discussion of privacy theory, in chapter two, flips
back and forth between the technical issues of identity authentication
and access control, and the social concepts of privacy, failing to
make hard relations between the two ideas.  A partial list of basic
conceptual security terms are reasonably well defined in chapter
three.  Chapter four does start to get into privacy issues, specifying
a number of notions important to protecting confidentiality in an
online (generally Web based) environment.  A number (but not an
exhaustive list) of threats to privacy are discussed in chapter five.

Part two looks at the problem.  Chapter six provides a concise list of
the basic principles of development of secure applications. 
(Interestingly, Curtin uses the principle of least common mechanism as
an argument for the adoption of modular code, where others might say
that it was a reason to avoid modularity.)  Background concepts for
the Internet and Web, the basic development environment assumed for
the book, are given in chapter seven.  Some specific examples of
privacy problems on the Web are presented in chapter eight.

Part three outlines the cure.  Chapter nine reviews some basic
security protections, such as firewalls and constrained systems.  Opt
out systems are criticized in chapter ten.  "Earning Trust," in
chapter eleven, points out that providing privacy for customers is not
just a cost and a nuisance, but good business.  A structure for
analyzing and designing secure Web systems is proposed in chapter
twelve.

Strangely, while the book is disjointed and difficult to pin down as
to the central theme, ultimately it could be quite valuable.  In the
end, the title is appropriate, albeit in a punning fashion: the
content is directed at developing trustworthy applications.  The
literature in the field of developing secure applications is not
extensive, and much of it is either ethereally academic or completely
language specific.  This book attempts to be practical, and, while
hardly ever touching on implementation, the precepts suggested are a
sound foundation.  Security professionals would find the general
background limited, but developers will neither be snowed under by
esoteric discussions nor left with too many vulnerabilities uncovered. 
The specifics in the book deal with the Web, but the tenets of secure
design are applicable to all systems.

copyright Robert M. Slade, 2002   BKDEVTRS.RVW   20020514
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: 29 Mar 2002 (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 Majordomo balks when you send your accept, please forward to risks.
 [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 21" for volume 21]
 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 22.13
************************