[risks] Risks Digest 23.38

From: RISKS List Owner (risko@private)
Date: Thu May 27 2004 - 12:48:57 PDT


RISKS-LIST: Risks-Forum Digest  Thursday 27 May 2004  Volume 23 : Issue 38

   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 <http://www.risks.org> as
  <http://catless.ncl.ac.uk/Risks/23.38.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
Paris Airport collapse: Analogy collapses (Marshall D Abrams)
FBI fingerprint screwup: Brandon Mayfield no longer a suspect (PGN)
GAO looked at DoD and off-shored software (James Paul)
So what's new with Pittsburgh Verizon DSL (David Farber)
The lighter side of electronic voting (Jason T. Miller)
Florida law bans deceptive subject lines in e-mail (NewsScan)
Spam being rapidly outpaced by 'spim' (Nico Chart)
Another method of password theft (James Renken)
Window smashed, data lost (David Lazarus via Monty Solomon)
Spamming the referrer logs (Diomidis Spinellis)
And a Mac Sniffer in a Pear Tree ... (Paul Kedrosky via Dave Farber)
Speed cameras: fines refunded, licenses restored (Stuart Lamble)
Re: Radar Gun Follies (Chris Meadows)
Re: New UK driving licence puts identity at risk (Chris Malme)
Re: Challenge-response is a bad idea (Jonathan de Boyne Pollard)
REVIEW: "Beyond Fear", Bruce Schneier (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 24 May 2004 09:39:17 -0400
From: Marshall D Abrams <abrams@private>
Subject: Paris Airport collapse: Analogy collapses

In decrying the state of software quality we often make analogy to [the more
solid engineering disciplines in] other professions. Years of experience
have not made these other professions free from occasional catastrophic
failure. The collapse of a 'Showcase Jewel' building is sobering.

A 98-foot section of the vaulted roof of the new $890M terminal at the Paris
Charles de Gaulle Airport collapsed just before 7am on 23 May 2004, killing
at least five people and forcing authorities to revisit problems that
preceded the fanfare opening of Terminal 2E less than a year ago.  Cracks in
the ceiling began to be noticed appearing only a few minutes before the
collapse -- which affected outerwalls and several cars parked below.  The
terminal opened 25 Jun 2003, and is referred to as a "showcase jewel".  In
the past, a huge light fixture had fallen in the departure area as
inspectors were checking the facility before its opening, and there had been
leaks in the ceiling.  [Source: Jocelyn Gecker, Roof at Paris Airport
Collapses, Killing 5; Terminal Described as 'Showcase Jewel', Associated
Press, 24 May 2004; PGN-ed]

Marshall D. Abrams, The MITRE Corporation, 7515 Colshire Drive
McLean, VA  22102-7508  1-703-883-6938

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

Date: Tue, 25 May 2004 09:11:34 -0700 (PDT)
From: "Peter G. Neumann" <neumann@private>
Subject: FBI fingerprint screwup: Brandon Mayfield no longer a suspect

After the Madrid train bombings that killed 191 people, a partial
fingerprint was found in Spain on a plastic bag of detonators.  Spanish
authorities were unable to make a match on the print, and sent a digital
copy to the FBI.  The FBI claimed "100 percent" confidence that the
fingerprint was that of Brandon Mayfield, a lawyer in the Portland Oregon
area, although this was doubted by the Spanish authorities (who more
recently fingered an Algerian national as the actual bearer of the print).
Mayfield was arrested on 6 May and jailed for two weeks.  (FBI agents were
subsequently in Madrid on 21 Apr, meeting with Spanish investigators, but
reportedly did not check the original print.)  FBI officials indicated
digital matching was not unusual and within accepted policies and
procedures, although this is reportedly being reconsidered.  [Sources: Spain
Had Doubts Before U.S. Held Lawyer in Madrid Blasts, Sarah Kershaw and Eric
Lichtblau, *The New York Times*, 26 May 2004, and Oregon Lawyer Speaks Out
About His Ordeal Behind Bars, Associated Press, 25 May 2004; PGN-ed]

  [In past issues, RISKS has reported various cases of mistaken identities
  resulting from false biometric identifications, but also cases in which
  biometrics were successful in identifying culprits.  In Mayfield's case,
  certain Muslim associations seem to have added circumstantial credibility
  to the confidence associated with the presumed match.  Once again, some
  caution is needed in believing in digital evidence -- especially with only
  partial prints.  PGN]

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

Date: Tue, 25 May 2004 14:27:02 -0400
From: "James Paul" <James.Paul@private>
Subject: GAO looked at DoD and off-shored software

The U.S. General Accounting Office has released the following report:

Defense Acquisitions:  Knowledge of Software Suppliers Needed to Manage
Risks.  GAO-04-678, 25 May 2004:
  http://www.gao.gov/cgi-bin/getrpt?GAO-04-678
Highlights:
  http://www.gao.gov/highlights/d04678high.pdf

  [Interesting report.  PGN]

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

Date: Thu, 27 May 2004 09:18:04 -0400
From: David Farber <dave@private>
Subject: So what's new with Pittsburgh Verizon DSL [IP]

Nothing. As of 0830 this am, access to some (maybe a large number) of
Pittsburgh Verizon DSL customers has been down for 34 hours. When I called
them I asked whether such service outages are appropriate for a
communications company. After all there would be a major headline event if
the telephone service was out that long due to human error. I was told that
"after all, there is a federal requirement on telephone service not on data
service.

I wonder what will happen as VOIP gets larger and outages like this take
place.

Archives at: http://www.interesting-people.org/archives/interesting-people/

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

Date: Wed, 19 May 2004 15:48:15 -0500 (EST)
From: "Jason T. Miller" <jasomill@private>
Subject: The lighter side of electronic voting

It's a serious topic.  One of the Onion items on foreseen problems [such as
the possibility of electronic voting machines electing a robot president] at
  http://www.theonion.com/infograph/index.php?issue=4020
is this:
  "Not enough outlets in most high-school gymnasiums to plug in machines",
This made me think. Obviously the number of *plugs* isn't much of an issue
[nor the age of the students], but forgetting to check the capacity of the
electrical infrastructure is exactly the kind of bird-brained planning
failure that would surprise no one on RISKS.

Lampooning serious topics is of course *The Onion*'s raison d'etre
(for example,
  http://web.archive.org/web/20010927221133/http://www.theonion.com/
was considered for a Pulitzer prize), and they do it so well.

One View, Inc., The Document Archiving Company, 8531 Bash Street
Indianapolis, IN / 46250   http://theoneview.com  1-317-915-9039 x302

  [This item was PGN-ed.]

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

Date: Wed, 26 May 2004 08:17:14 -0700
From: "NewsScan" <newsscan@private>
Subject: Florida law bans deceptive subject lines in e-mail

Legislation signed by Florida Governor Jeb Bush will allow the state's
attorney general to bring civil action against anyone in Florida who sends
spam e-mail with a subject line intended to give the message recipient a
false idea of what the message is about.  [AP/*USA Today*, 26 May 2004;
NewsScan Daily, 26 May 2004]
  http://tinyurl.com/2jj6l

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

Date: Thu, 27 May 2004 10:58:39 +0100
From: "Nico Chart" <NicholasC@private>
Subject: Spam being rapidly outpaced by 'spim'

We have seen a lot of discussion about spam in RISKS lately, but no mention
of spim, the instant messaging equivalent, said to be outgrowing spam at the
present time. See this *New Scientist* article:
  http://www.newscientist.com/news/news.jsp?id=ns99994822
"While the torrent of unsolicited spam e-mails continues to rise, it is being
far outpaced by the surge in unwanted messages sent to the users of instant
messaging programs, analysts have warned."

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

Date: Fri, 21 May 2004 18:24:40 +0000 (UTC)
From: James Renken <jrenken@private>
Subject: Another method of password theft

Yesterday, I discovered that one of my Web hosting customers had placed a
directory full of (copyrighted) MP3s on his site, open to everyone.  In
addition to the usual warnings and removals, we added basic HTTP password
protection to the directory.

The MP3s had been around for a few months, long enough to make it onto some
search engines, so we're still seeing quite a few visitors - many of whom
are trying to log in using their own ISP/e-mail usernames and passwords.  I
haven't tested the passwords, of course, but I'm almost certain that this is
the case, especially where people are entering their full e-mail addresses.

Although financial information isn't involved, this suggests a method of
password theft that I haven't yet seen mentioned.  One could easily post
some MP3s, wait for search engine listings, and then record the passwords
submitted.  Human factors strike again!

James Renken, System Administrator  Sandwich.Net Internet Services
http://sandwich.net/    1-760-729-4609  jrenken@private

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

Date: Thu, 13 May 2004 00:21:29 -0400
From: Monty Solomon <monty@private>
Subject: Window smashed, data lost (David Lazarus)

David Lazarus: Window smashed, data lost, *San Francisco Chronicle*,
12 May 2004

A thief smashed the rear window of Larry Saltzman's Saab not long ago and
stole his gym bag, a gold watch, credit cards, a few hundred dollars and the
names, addresses and Social Security numbers of about 95,000 Bay Area
residents.  At issue -- yet again -- is the question of whether people's
personal information can ever be truly safe once it's handed to an outside
contractor, as a local insurer did with Saltzman.

A series of thefts involving confidential data in recent months suggests
that no matter how extensive a company's security measures may be, they can
be easily undone by human error, negligence or random circumstances.
Consumers, in turn, face the very real possibility of their personal info
falling into the wrong hands.  ...

http://sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2004/05/12/BUG8O6JPV71.DTL

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

Date: Tue, 25 May 2004 11:49:54 +0300
From: Diomidis Spinellis <dds@private>
Subject: Spamming the referrer logs

A new form of spamming pollutes web server referrer logs, tricking Web sites
to publish pages with links to unrelated commercial content.

Every day I receive an e-mail report summarizing the activity at my personal
Web site.  This allows me to see how the day's activities, such as the
release of a new software update, or a new blog entry, contribute to the
popularity of various areas.  It is also a security monitoring tool: an
unexpected surge in traffic could mean something was amiss in its content.

Over the last year the contents of this report were becoming less reliable
as a proliferation of different distributed crawling engines began taking up
a noticeable percentage of the site's traffic.  A bit of filtering corrected
that issue: a "user agent" trying to read the robots.txt file could safely
be excluded from the site's statistics.

Over the last days a more sinister form of noise has made its appearance.
Part of the report I receive contains a listing of the top-10 referrer
sites: the foreign URLs that were followed to land on my site.  This is a
useful feature, because it allows me to see which foreign links contribute
to the traffic.  Here is an example, from the day I announced a new release
of UMLGraph, an open-source declarative UML diagramming tool, on
freshmeat.org:

Top 10 Referrals:

         77
http://freshmeat.net/projects/umlgraph/?branch_id=48663&release_id=160174
         59 http://javanews.jp/
         63 http://www.cafeaulait.org/
         50 http://www.ibiblio.org/javafaq/
         33 http://freshmeat.net/daily/2004/05/09/
         23 http://freshmeat.net/projects/umlgraph/
         15 http://www.javanews.org/
         14 http://www.freebsd.org/ports/sysutils.html
         [...]

Yesterday, following one of the links in the day's referral list, landed me
on a typical popup window-infested porn Web site.  It was the first time I
had to enable Mozilla's popup window blocking feature to escape from the
deluge of popups.  The same happened with another site appearing in the
referral list. Scanning the content of both referring pages confirmed my
suspicion: none of the two did in fact contain a link to my Web site.  The
referrals were generated by Web server log entries like the following:

66.230.218.66 - - [15/May/2004:23:10:54 +0300] "GET / HTTP/1.1" 200 3132
"http://www.mixtaperadio.com/" "Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.1; .WONKZ)"

A Google search for a .WONKZ user-agent predictably showed more than a
hundred entries, typically containing Web site usage statistics.  With many
sites automatically generating lists of referring sites and posting them
on-line, the spamming of a site's referrer log is apparently an easy way to
increase the number of links pointing to a Web site, and thereby increase
the site's performance in search query results that base their results on
this number (e.g. pagerank).  An entry in an article on "spamdexing" at
http://www.tutorgig.com/encyclopedia/getdefn.jsp?keywords=Spamdexing refers
to this practice as "Referrer log spamming" and gives a similar rationale.

The risk: the ability to crawl the Web generating millions of spammed
referrer entries will further diminish the utility of two up to now useful
data sources: referrer logs, and incoming link counts as a measure of a
site's importance.

Diomidis Spinellis - http://www.dmst.aueb.gr/dds

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

Date: Sun, 16 May 2004 09:21:41 -0700
From: Paul Kedrosky <pkedrosky@private>
Subject: And a Mac Sniffer in a Pear Tree ... (From Dave Farber's IP)

The following is a laundry list of just some of the wireless network attacks
and shenanigans that went on at this week's Networld + Interop trade show in
Las Vegas. It is from an AirDefense press release
(http://www.airdefense.net/newsandpress/05_13_04.shtm):

- 189 separate attacks on different devices
- 112 separate MAC spoofing attacks
- 89 Denial of Service attacks
- 42 authentication attacks, likely due to brute force attacks or
  misconfigured clients
- 20 separate AirSnarf attacks
- 4 separate Hotspotter attacks
- 3 large Ad-Hoc mesh networks were re-established on day two with an
  average of 10 stations connected.
- Another association was made with the Sear Service Toolbox (SST-PR-1) and
  the - network was attacked twice
- One Virtual Routing Redundancy Protocol (VRRP) attack, a routing tool
  attack to redirect traffic
- 165 BlueJack attacks
- 12 Blue Snarf attacks

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

Date: Fri, 14 May 2004 20:00:48 +1000
From: Stuart Lamble <Stuart.Lamble@private>
Subject: Speed cameras: fines refunded, licenses restored (RISKS-23.35,36)

The Victorian (Australia) government is set to spend over $AU19 million
(approx $US13 million) in compensation and refunding speeding funds for
those affected by recent speed camera "glitches": $13.7 million in refunding
fines paid, and $6 million in compensation for those who have suffered
financial loss through loss of their driving licenses.

The fines being refunded are those on the Western Ring Road, from the date
the fixed speed cameras were installed (2002), and those on the city's
tollway and South Eastern (aka Monash) Freeway during the period that the
cameras were being tested (from November last year).

Details at the Melbourne Age's Web site:
  http://www.theage.com.au/articles/2004/05/14/1084289868873.html
and at the ABC News Web site:
  http://www.abc.net.au/news/newsitems/s1108467.htm

Both reports were published on the 14 May 2004.

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

Date: Sun, 2 May 2004 02:10:48 -0500
From: Robotech_Master <robotech@private>
Subject: Re: Radar Gun Follies

The comments in 23.33 (about the incorrectness of the radar gun for one stop
casting doubts on its correctness for subsequent stops) are quite correct.

In point of fact, even when a radar gun is working *correctly*, it is fairly
easy to cast doubt upon its efficacy.  There are plenty of "How to beat a
speeding ticket" tracts available on the Internet, and the typical "beat a
ticket" tract includes a lengthy section on questions to ask in
cross-examination to throw doubt upon the radar reading.  How well was the
officer trained, when was the unit calibrated, and so forth.

A typical such document can be found here:
    http://www.jesbeard.com/29ab.htm
and makes interesting reading irrespective of the Risks issue.

One noteworthy quote, which relates to the "137 miles per hour" story
from 23.33, comes from Section 9 on Cross-Examinations:

| NOTE: While it probably should become painfully obvious to both the
| officer and the court that he is simply unqualified to use a radar
| gun or to or testify regarding its use.... the reality is that the
| officer and the judge are both likely to think the radar gun is just
| a magic gizmo you simply point and shoot....

Chris Meadows aka Robotech_Master http://www.eyrie.org/~robotech 

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

Date: Wed, 19 May 2004 00:31:36 +0100
From: Chris Malme <cim001@private>
Subject: Re: New UK driving licence puts identity at risk (Laurie, R-23.37)

The DVLA already give an option where for an admin fee of 4GBP, you can have
your passport (or other ID) inspected without risking it to the post. This
is actually detailed on the DVLA site the original poster referred to:

  "Premium Service at Post Office Branches: If you are applying for your
  first photocard driving licence, or already have a paper driving licence
  in your present name, and you do not wish to send your identity documents
  through the post, you may be able to use the premium service available at
  selected Post Office branches. Your application will then be checked and
  your evidence of identity will be returned to you immediately."

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

Date: Mon, 17 May 2004 09:17:15 +0100
From: Jonathan de Boyne Pollard <J.deBoynePollard@private>
Subject: Re: Challenge-response is a bad idea (Dean, RISKS-23.36)

DD> If auto-blacklisting challenge-responses systems become the norm,
DD> there will be interesting risks related to the combination of
DD> forged mail, and auto-blacklists: [...]

That depends from one's publicly stated policy on responding to
challenge-response Internet mail messages.  If one has the publically stated
response policy of the RISKS List ("SPAM challenge-responses will not be
honored."), or the publically stated (or implicit) response policy of only
responding to challenges where the original message really was one that one
sent onesself, then this particular situation is a problem (especially with
respect to the latter policy).

However, and somewhat ironically, other publically stated response policies
do not cause the problems alluded to in this situation.  Challenge-response
systems, and their impacts upon unsolicited bulk mail, have been discussed
at length in the "comp.mail.misc" and "news.admin.net-abuse.email" Usenet
newsgroups (where it has been pointed out that such challenge messages
*themselves* fulfill the criteria for being defined as "unsolicited bulk
mail").  One poster has been so persuaded by the arguments that he has
publically stated that he will now respond to *all* such challenges, whether
for messages that he sent or not, on the grounds that (JdeBP précis - all
misrepresentations are mine) since challenge-response systems are
essentially reflecting all UBM forged in his name to him, the way to stop
them doing so is to confirm the challenge and thereby ensure that the
challenge-response system allows the UBM through to the original recipient
without forwarding it to him (or simply sending the UBM that is the
challenge messages themselves) any more.

That person in this situation can thus point to his publically stated policy
and assert to any recipient of mail with his name in the headers that the
fact that a message passed a challenge response system does *not* imply that
he actually originated it.

Of course, the tool for proving whether someone did or did not write a
message is not challenge-response at all, and (as the preceding
demonstrates) it is erroneous to assume otherwise.  As I pointed out back in
RISKS-23.23 (with respect to the SPF, which flawed system is also falsely
labelled as a means for stopping forgery), the tool for proving *that* has
long since been invented, and is signed message bodies.

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

Date: Tue, 25 May 2004 14:05:57 -0800
From: Rob Slade <rslade@private>
Subject: REVIEW: "Beyond Fear", Bruce Schneier

BKBYNDFR.RVW   20031219

"Beyond Fear", Bruce Schneier, 2003, 0-387-02620-7, U$25.00/C$38.95
%A   Bruce Schneier schneier@private
%C   115 Fifth Ave., New York, NY   10003
%D   2003
%G   0-387-02620-7
%I   Copernicus/Springer-Verlag
%O   U$25.00/C$38.95 800-842-3636 212-254-3232 fax: 212-254-9499
%O  http://www.amazon.com/exec/obidos/ASIN/0387026207/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0387026207/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0387026207/robsladesin03-20
%P   295 p.
%T   "Beyond Fear"

It is instructive to view this book in light of another recent publication.
Marcus Ranum, in "The Myth of Homeland Security" (cf. BKMYHLSC.RVW)
  [See Rob's review in RISKS-23.02 and Marcus's response in RISKS-23.14. PGN]
complains that the DHS (Department of Homeland Security) is making mistakes,
but provides only tentative and unlikely solutions.  Schneier shows how
security should work, and does work, presenting basic concepts in lay terms
with crystal clarity.  Schneier does not tell you how to prepare a security
system as such, but does illustrate what goes on in the decision-making
process.

Part one looks at sensible security.  Chapter one points out that all
security involves a balancing act between what you want and how badly you
want it.  An important distinction is also made between safety and security,
and the material signals the danger of ignoring the commonplace in order to
protect against the sensational but rare.  Fundamental security concepts are
outlined as well as risk analysis.  Chapter two examines the effect (usually
negative) that bias and subjective perceptions have on our inherent judgment
of risks.  Security policy is based on the agenda of the major players, and
chapter three notes that we should evaluate security systems in that light.

Part two reviews how security works.  Chapter four introduces systems and
how they fail.  "Know the enemy," in chapter five, is not just a platitude:
Schneier shows how an understanding of motivations allows you to assess the
likelihood of different types of attack.  Chapter six is less focused than
those prior: it notes that attackers reuse old attacks with new
technologies, but it is difficult to find a central thread as the text
meanders into different topics.  Finding a theme in chapter seven is also
difficult: yes, technology creates imbalances in existing power structures,
and, yes, complexity and common mechanisms do tend to weaken security
positions, but the relationships between those facts is not as lucidly
presented as in earlier material.  The point of chapter eight, that you
always have to be aware of the weakest link in the security chain, even when
it changes, is more straightforward, but the relevance of the illustrations
surrounding it is not always obvious.  Resilience in security systems is
important, but it is not clear why this needs to be addressed in a separate
chapter nine when it could have been discussed in eight with defence in
depth (or "class breaks" and single-points-of-failure in seven).  The
hurried ending is also very likely to confuse naive readers in regard to
"fail-safe" and "fail- secure": Schneier does not sufficiently stress the
fact that the two concepts are not only different, but frequently in
conflict.  Chapter ten notes that people are both the strongest and weakest
part of security: adaptable and resilient but terrible at detail; frequently
surprisingly intuitive but often randomly foolish.

At this point the book is not only repetitive, but loses some of its earlier
focus and structure.  Detection and prevention are examined, in chapter
eleven, not as part of the classic matrix of controls, but as yet another
example or aspect of resilience.  Most of the rest of the types of controls
in the preventive/detective axis are listed in chapter twelve, lumped
together as response.  Chapter thirteen looks at identification,
authentication, and authorization (but not accountability, which was seen,
in the form of audit, in chapter eleven).  Various types of countermeasures
are described in chapter fourteen.  Countermeasures with respect to
terrorism are examined, in chapter fifteen, both in general terms and in
light of the events of 9/11.  What works is discussed, as well as what does
not, and there is an interesting look at the different roles of the media in
the US as contrasted with the UK.

Part three, entitled "The Game of Security," is not clear as to purpose.
Chapter sixteen starts off by pointing out that the five step assessment
process is constant and never-ending--which begs the question of how to
determine when diminishing returns start to set in on assessment itself.
However, there is good material in regard to the actions you can take to
influence decisions about security.  A concluding editorial, in chapter
seventeen, encourages the reader to move beyond fear and think realistically
about security and the tradeoffs you are willing to make.

Some of the terms Schneier uses or invents may be controversial.  His use of
"active" and "passive" failures for the concepts more commonly known
respectively as false rejection (false positive) or false acceptance (false
negative) is probably much clearer, initially, to the naive reader.  The
concept is an important one, and so the presentation of it in this way could
be a good thing.  On the other hand, does "active failure" completely map to
what is meant by "false acceptance," and, if not, how much of a problem is
created by the use of the new term?  Similarly, "class break" does indicate
the importance of new forms of attack, but the concept seems to partake
aspects of defence in depth, single point of failure, and least common
mechanism, all important constructs in their own right.  Schneier's
invention of "default to insecure" is not really any more understandable
than the more conventional terms of fail-safe or fail- open.

I recommend this book.  Unlike Ranum's, "Beyond Fear" has a more significant
chance of informing and educating the public on vital issues of security.
Security educators will find a treasure trove of ideas and examples that
they can use to explain security concepts, to a variety of audiences.
Security professionals are unlikely to find anything new in this material,
but Schneier's writing is always worth reading, and this work is
refreshingly free of the grating of erroneous ideas.

copyright Robert M. Slade, 2004   BKBYNDFR.RVW   20031219
rslade@private      slade@private      rslade@private
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

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

Date: 5 Apr 2004 (LAST-MODIFIED)
From: RISKS-request@private
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@private> with one-line body
   subscribe [OR unsubscribe]
 which requires your ANSWERing confirmation to majordomo@private .
 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.
   .UK users should contact <Lindsay.Marshall@private>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> The INFO file (submissions, default disclaimers, archive sites,
 copyright policy, PRIVACY digests, etc.) is also obtainable from
   <http://www.CSL.sri.com/risksinfo.html>
 The full info file may appear now and then in future issues.  *** All
 contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risks@private with meaningful SUBJECT: line.
 *** NEW: Including the string "notsp" at the beginning or end of the subject
 *** line will be very helpful in separating real contributions from spam.
 *** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
   Lindsay 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/> .
==> 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 23.38
************************



This archive was generated by hypermail 2.1.3 : Fri Jan 28 2005 - 10:19:52 PST