RISKS-LIST: Risks-Forum Digest Wednesday 28 April 2004 Volume 23 : Issue 34
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.34.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
EFF Pioneer Awards for 2004
Fire trucks collide (Russ Perry Jr)
Innocent Brits labelled as crooks (Fuzzy Gorilla)
UK firms face weekly attacks (Graeme Wearden via Keith A Rhodes)
Quizzed upon sending e-mail (Dan Jacobson)
Aussie banking group scales up against 'phishing' (Keith A Rhodes)
Sans-serif font hides phishy text (Andrew Collier)
Risks of tax-preparation software (Paul D. Smith)
Automated Copyright Notice System (Steve Klein)
Automotive "black box" data used in trial (Fuzzy Gorilla)
Earthlink SpamBlocker (Paul Wexelblat)
Re: Unfortunate MTA behavior (Drew Dean)
Boy trapped in public bathroom (Fuzzy Gorilla)
Re: Runaway car from Hell (Bernard W Joseph, Carl Fink)
REVIEW: "Network Security Essentials", William Stallings (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Mon, 26 Apr 2004 9:06:20 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: EFF Pioneer Awards for 2004
The three winners of this year's EFF Pioneer Award (announced at Computers,
Freedom, and Privacy 2004 on 22 Apr 2004) are Kim Alexander, David Dill, and
Avi Rubin. The three were honored for their "pioneering work spearheading
and nurturing a popular movement for integrity and transparency in modern
elections."
Relating to the question of whether the vendors' claims that pre-testing and
post-testing demonstrate that nothing can go wrong during an election, Kim
Alexander's acceptance speech cited this quote: 'An extra bias routine could
be added to the vote-counting program that would have certain
characteristics to make it undetectable by the official "logic and accuracy"
test. This routine could be arranged so as not to go into effect until a
larger number of ballots had been counted than were in the logic and
accuracy test sample, or could be prevented from being operative during the
test and be activated by a computer operator only for the official count.'
Her speech continued as follows:
"It sounds like something Dave Dill, or Avi Rubin or David Jefferson,
or Rebecca Mercuri or any number of computer scientists might have
said in the past year or two. But it dates back to 1970, when
computer experts, working with civil rights leader Dr. James Farmer,
first sounded the alarm over computerized vote counting risks.
"When I first read this passage in a 1975 study by Roy Saltman, I had a
sinking feeling. People have been warning of the potential to accidentally
or deliberately alter election results through computer software for
decades, ever since we started using software to count punch card ballots in
the 1960's.
"This is not a new problem. It's an old problem that never got solved. But
I'm optimistic we will solve it. And the reason is because we have the
tools to do so. We have the Internet. We have the ability to share
information, to connect with each other, and to make a public problem so
apparent that it can no longer be ignored.
"The history of this country has been one long struggle for freedom. It
continues today through the efforts being made by thousands of people across
this country who are working to ensure we have voting systems which produce
results which can be verified."
-------------------------------
Date: Tue, 27 Apr 2004 21:01:11 -0500
From: Russ Perry Jr <slapdash@private>
Subject: Fire trucks collide
Melrose Park, IL, was recently (today) the scene of a collision between two
fire trucks heading to the same fire. There may be an inherent risk just in
emergency vehicles not following the standard rules of the road in which one
vehicle should have yielded, or possibly going too fast to an intersection
despite being an emergency vehicle and having the right of way over normal
traffic.
But more interesting is that the intersection has the Opticon (assuming I
heard that right on the news) system, which changes the light to green for
emergency vehicles, and no one is (yet) sure what happened as the two
vehicles approached the intersection from perpendicular directions -- might
it have changed to green both ways? We'll hopefully know soon, but I hope
not -- shouldn't there be a failsafe that wouldn't allow two greens no
matter what?
Russ Perry Jr 2175 S Tonne Dr #114 Arlington Hts IL 60005
1-847-952-9729 slapdash@private
------------------------------
Date: Sun, 25 Apr 2004 14:42:09 -0400
From: Fuzzy Gorilla <fuzzygorilla@private>
Subject: Innocent Brits labelled as crooks
193 Brits have been wrongly labelled as criminals because of mistakes in
records between Jan 2003 and Feb 2004. By incorrectly linking these people
to various crimes recorded on the police national computer (PNC), the
Criminal Records Bureau (CRB) may have inadvertently blighted the employment
prospects of scores of innocent individuals. (The CRB vets the records of
people hoping to work with children or vulnerable members of society, and
made over 2.5M queries during 2003.) Some of the mistakes are the result of
clerical error while others are the result of offenders giving false details
to police in an attempt to avoid getting a criminal record. [Source: John
Leyden, *The Register*, 16 Apr 2004; PGN-ed]
http://www.theregister.co.uk/2004/04/16/criminal_records_snafu/
------------------------------
Date: Wed, 28 Apr 2004 07:38:22 -0400
From: "Keith A Rhodes" <RhodesK@private>
Subject: UK firms face weekly attacks (Graeme Wearden)
The UK business sector is suffering more hacking attacks, viruses and
network breaches than ever before, with large companies typically being
compromised every week, according to this year's official survey of British
IT security. The DTI Information Security Breaches Survey 2004 (ISBS 2004),
published in full on 27 Apr 2004, showed that two-thirds of firms fell
victim to a network attacks in the last year. The average cost of a serious
breach has actually fallen to 10,000 pounds ($17.900), compared to 30,000
pounds ($53,600) in 2002, but with the number of malicious incidents on the
rise the overall cost of IT security breaches remains broadly static. The
results from ISBS 2004 show that many major firms are losing millions
through failed IT security. The average cost of a serious break to a large
company is 120,000 pounds ($214,500), and these large firms are suffering
around four breaches a month--compared to one a month for all businesses.
According to e-commerce minister Stephen Timms, "We can't yet say on the
base of this survey that risks are being well-managed by UK companies."
[Source: Graeme Wearden: UK firms face weekly attacks, ZDNet (UK), 27 Apr
2004]
http://zdnet.com.com/2100-1105-5200649.html
------------------------------
Date: Thu, 29 Apr 2004 02:54:30 +0800
From: Dan Jacobson <jidanni@private>
Subject: Quizzed upon sending e-mail
I found a misspelled word on a web page so sent e-mail to the author.
I got back a message with an https address for me to confirm my mail,
Being Dan 'Batch Jobs' Jacobson, I rigged up a batch job to fetch that
page, as I am not going to be hurried into clicking on things during my
brief modem sessions. But no, there lay a further quiz with
Enter the text you see below into the box to its right.
This step is for added security.
Visually impaired? Click here
My batch job did not retrieve their image... and alas too late,
dwindling resources upstairs say I'm no match for this.
In other news, Mom will be proud of me as I receive lots of "VIP conference
invitation" spam whereas others certainly just get regular spam.
------------------------------
Date: Wed, 28 Apr 2004 07:40:17 -0400
From: "Keith A Rhodes" <RhodesK@private>
Subject: Aussie banking group scales up against 'phishing'
The Australia and New Zealand Banking Group has reinforced its commitment to
fighting online fraud and beefed up its scrutiny of large and high-risk
technology projects. The "growing trend in electronic fraud" has forced it
to focus very heavily on fraud prevention and detection, in response to
incidents such as hoax e-mails, false Web sites and computer viruses.
[Source: Iain Ferguson and Kristyn Maslog-Levis, ZDNet Australia, 27 Apr
2004; PGN-ed]
http://zdnet.com.com/2100-1105-5201041.html
------------------------------
Date: Tue, 27 Apr 2004 19:05:33 +0100
From: Andrew Collier <lists@private>
Subject: Sans-serif font hides phishy text
I recently was e-mailed an obvious (to me) phishing attempt, which is
nothing new in itself but what raised my eyebrows was the way the URL was
hidden. Not by exploiting browser display bugs, not by clever use of
username syntax or any of the unusual URL formats, but by hiding all the
information in plain sight.
http:// www.personaI.barcIays.co.uk/goto/pfsoIb_Iogin
To anyone using a sans-serif font, that URL might look completely genuine --
even if that person carefully reads the source code of the incoming html
e-mail. In fact, throughout the whole message each lower case "l" was
replaced with capital "I" (so even if the mailer draws those characters in a
slightly different way, there is no discrepancy in the way they are written
in the URL, so the visual cue is lost).
Risk? Throwing information away by mapping different characters onto
excessively similar glyphs (though used to great effect in endless
obfuscated contest entries, no doubt).
Andrew Collier http://www.intensity.org.uk
[It was a real glyph-hanger! PGN]
------------------------------
Date: Mon, 26 Apr 2004 08:37:45 +0100
From: "Paul D.Smith" <paul_d_smith@private>
Subject: Risks of tax-preparation software
I'm British and fill in a UK tax form. My wife is American and fills in
both UK and US tax forms.
A British tax for is typically 20-odd pages, large type, lots of whitespace,
with an instruction booklet that is pretty simple to comprehend. My wifes
"simple" US tax form and instructions looks like a badly written, small
font, thin paper telephone directory for a small city.
Having seen the two, I can't imagine how anyone can describe the UK form as
difficult. Now the standard of the UK Inland Revenue's website and support?
That really is another matter! Last year it was impossible to determine
whose electronic software had been validated for use, unless you first
registered with the website. Problem was I wanted to at least investigate
the options before deciding whether to bother with electronic filing.
BTW, electronic filing will do the calculation for you. In the UK, the
Inland Revenue will do this for you anyway but I was interested to know and
the "do it yourself calculation guide" is always cryptic.
------------------------------
Date: Mon, 19 Apr 2004 15:42:38 -0400
From: Steve Klein <steveklein@private>
Subject: Automated Copyright Notice System
Vivendi Universal Entertainment and Universal Music Group have
developed a software solution to automatically disable net access for
people accused of illegally sharing copyrighted material.
According to the description found here:
<http://news.com.com/2100-1027_3-5194341.html?tag=macintouch>
the software, called ACNS (Automated Copyright Notice System) would be
run by universities. When a notice of copyright infringement is
received, the system automatically cuts off network access for the
accused.
The ACNS software is open source. The claims of infringement are
submitted in a special XML-format, also open source.
There is no apparent attempt to verify the accuracy of the claim.
Which means that presumably anyone can be denied net access simply by
accusing them of piracy. RISKS aplenty.
Steve Klein, Phone (248) YOUR-MAC-EXPERT (or 248-968-7622)
------------------------------
Date: Sun, 25 Apr 2004 14:37:23 -0400
From: Fuzzy Gorilla <fuzzygorilla@private>
Subject: Automotive "black box" data used in trial
*The Montreal Gazette* recently reported that a man was convicted in a recent
traffic accident case based on data from an automotive "black box".
"Eric Gauthier, 26, was sentenced yesterday [April 14, 2004] to 18
months...." "...police [used] information culled from the data recorder,
better known as a black box, from Gauthier's car." "The recording device,
which stores data on how a car is driven in the last five seconds before a
collision, showed four seconds before impact, Gauthier had the gas pedal to
the floor. He didn't brake before impact."
References:
http://www.canada.com/montreal/montrealgazette/news/story.html?id=6a58a759-3fb5-4862-bbc0-39238d048874
------------------------------
Date: Mon, 26 Apr 2004 10:59:43 -0400
From: Paul Wexelblat
Subject: Earthlink SpamBlocker
Stupidity/cluelessness = Risk?
I sent off an e-mail message to an acquaintance, and got, as a response a
message that said that the recipient was using spamBlocker and gave me a URL
to go to. When I got there I saw a form with the following (in pretty HTML}
(Asterisk strings mine)
Please complete the short form below. If mj******@earthlink.net
chooses to allow e-mail from your address, the message(s) that have
been intercepted will be delivered immediately, and any future
message(s) will be delivered without delay.
Your First Name: P&G M.I. Your Last Name: W********
Enter your additional e-mail addresses here:
Address 1: w**@***********.com
Add other addresses (if you have more than one).
Please type a short message to mj***********@earthlink.net. (100
characters, max.)
This step is for added security. Enter the text you see below into
the box to its right.
[the usual large, but distorted anti-OCR text]
Visually impaired? Click here
I duly filled out the form, clicked submit and was told that the name field
had illegal characters - only alphas, - and _ were permitted. i.e. although
the & was in the e-mail as part of my name, Earthlink would not send the
request message to the recipient. There was no indication as to whether
theis screening actually used the name in incoming e-mail messages to filter
or not. (there's nothing in the standard that would limit & from the name).
The insensitivity/cluelessness issue is that, although the distorted text is
quite large, the "Visually impaired? Click here" option is in their normal,
small text - only a bit of thinking would have made them realize that
increasing the size of a message to a visually impaired person might help.
The RISK - there may be no way for an unsophisticated Internet user (who has
an "illegal" character in their name) to get a message to the spamBlocker
subscriber to add their name to the pass list.
------------------------------
Date: Wed, 28 Apr 2004 15:01:33 -0700 (PDT)
From: Drew Dean <ddean@private>
Subject: Re: Unfortunate MTA behavior (Dean, RISKS-23.33)
I've received a number of replies, and so thought it might be helpful to
summarize.
Peter Ladkin points out this problem is all too common. Ben Kamen points
out that Sendmail can do reverse DNS (user configurable), but many domains
have messed up DNS records that make this less useful.
Przemek Klosowski says: "I believe Drew is misinterpreting the Received:
header. I don't know if it is written up somewhere, but in practice, most
Received: headers are of the form:
Received: from <claimedDomain> (<lookedUpDomain> [<observedIP>]) ..."
[<claimedDomain> comes from the remote MTA's SMTP HELO command.]
Uh, no, I'm not. 16 years of SMTP mail has conditioned me fairly well. I'm
complaining that the MTA in question (a commercial, "anti-virus" MTA), is
doing nothing to note that the <claimedDomain> may have absolutely nothing
to with the numeric IP address displayed next to it. In fact, this happens
all of the time -- the same is true of legitimate mail that I receive. In
Przemek's terminology, <lookedUpDomain> is always the empty string. It
should do forward and/or reverse DNS lookup(s), and it would be really nice
if it noted discrepancies when they occur. That this MTA is suboptimal in
its use of DNS is a common RISK -- improper DNS use was one of the first
bugs we (Dan Wallach, Ed Felten, and I) found in Sun's early JVM.
Patrick LoPresti points out that the behavior I observed is all too common,
and probably the reverse DNS lookup failed. It worked immediately the next
morning (when I first read the mail), but I can't rule out a transient
failure. The really clever spammer might even launch a DoS attack against
the appropriate DNS servers to try to hide their tracks. Patrick also notes
experience similar to Ben's (above), that things often aren't configured
properly, and goes on that he found too many false positives when he tried
to use this as a spam filter.
Malcom Pack received 2 copies of the mail (from very different places), and
starts along the same line as Przemek Klosowski. However, he goes on to
give a concrete example where a mismatch is actually legitimate. I do,
however, rather like how the MTA he uses handled the phishing mail:
| Received: from barclays.co.uk (wbar1.nyc1-4.15.213.240.nyc1.elnk.dsl.genuity.net [4.15.213.240])
| by smtpserver.homeip.net with SMTP (Mailtraq/2.5.0.1568) id SMTPF3B8F140
| for n@by-users.co.uk; Wed, 21 Apr 2004 08:58:38 +0100
Now that's what I'd like the Received: header to look like. (If you
notice in the headers I provided earlier, a different SRI mail server,
running a different MTA, does something similar.) And if the reverse
DNS lookup fails, (as it apparently did for my mail server), I'm just
asking for a warning (e.g., (reverse DNS failed [w.x.y.z]). Is that
really too hard?
Jonathan de Boyne Pollard also replied. His reply starts along the
same lines as Malcom Pack's, and points out that at one point this was
meant for loop detection, although that has many related problems. He
goes on to say:
But that's not the risk here at all. The risk here is erroneously
assuming that the "HELO"/"EHLO" domain names recorded in "Received:"
headers tell one _anything at all_, let alone that they tell one something
about the legitimacy of messages. In other words: The risk is that of
false conclusions being drawn from the mis-use of a protocol element for
something other than its actual purpose.
Of course, the way to check a mail message, purporting to come from
Barclays Bank (or anyone else), for legitimacy is the same as it always
has been (both for SMTP-based Internet electronic mail and for physical
mail): check that the message is signed and that the signature is valid.
These are certainly reasonable points. However, I still believe that the
observed MTA behavior I originally reported is just about the worst possible
thing to do. I'm not necessarily asking for information to judge the
validity of the mail message (after all, someone could break into the
target's mail server, or an insider could launch a phishing scam, etc.), but
to give me all observable information about the mail servers a message
traversed. There are simple improvements (already present in other MTAs)
that would significantly mitigate the RISK I observed.
Alas, S/MIME is still not widely deployed: I note that Jonathan's message
wasn't signed. :-) And yes, I do have it (mostly) working on my end,
although only in the last week or so.
My thanks to all who took the time to respond.
------------------------------
Date: Sun, 25 Apr 2004 14:18:30 -0400
From: Fuzzy Gorilla <fuzzygorilla@private>
Subject: Boy trapped in public bathroom
*The Register* and the BBC recently covered a story about a boy who was
trapped in an automated public bathroom.
"A young boy [thought to be 10 or 12] had to be freed by the Fire Service
after becoming trapped inside an automated public lavatory in Devon... in
Plymouth's Central Park on Saturday [April 17, 2004]."
They do not yet know why the boy was trapped, but apparently there is some
sort of weight sensor to detect if someone is present or not.
References:
http://www.theregister.co.uk/2004/04/22/cyberloo_kidnaps_kiddie/
http://news.bbc.co.uk/1/hi/england/devon/3648633.stm
------------------------------
Date: Sat, 24 Apr 2004 18:05:21 -0400
From: Bernard W Joseph <k8lix@private>
Subject: Re: Runaway car from Hell
I was the project manager for high speed testing for one of the Big 3 car
makers. I was driving home in a company car on an Interstate highway under
cruise control when a similar thing happened. Fortunately, my driver
training enabled me to make my way through traffic until I found a clear
spot where I could safely turn towards the median and turn off the
ignition. We towed the car back to the garage.
Our garage manager told me that the small, plastic, speed-transducer gear in
the transmission had disintegrated. The computer thought that the car was
slowing down and moved the pedal to the metal. Now here's the risk: The
computer didn't understand what the problem was. As the manager explained to
me, stepping on the brake should have reset the computer speed control. But
through a programming glitch, the computer did not obey the brake signal
because it thought that I was already stopped. What was obviously needed was
a hard electrical-reset, not a signal to reset if the program indicated that
conditions are suitable.
This was an early production of a new transmission model. When investigation
showed several similar failures, the manufacturer went back to the
powdered-metal drive gear. I don't know if the software was corrected.
Thank goodness, for other drivers' sakes, that the police have learned the
blocking technique to stop runaway vehicles. According to several news
stories over the years since my misadventure, they have used it several
times. It leads me to think that there are still glitches in drive-by-wire
schemes.
Bernard W. Joseph http://www.appliedgrammar.com
------------------------------
Date: Sat, 24 Apr 2004 17:40:07 -0400 (EDT)
From: Carl Fink <carlf@private>
Subject: Re: Runaway car from hell -- or fantasyland? (Knowlton, RISKS-23.33)
I read the original coverage of this, and I don't believe it. Reports at
the time also claimed the car later attacked a mechanic and pinned him to
the wall of the garage.
Can anyone in RISKS-land come up with a malfunction that would
simultaneously interfere with the car's ignition, transmission, and both
braking systems, including the parking brake, WHICH IS MECHANICAL AND HAS NO
LINKS TO ANY OTHER SYSTEM?
I strongly suspect this of being a hoax/urban legend.
Carl Fink, carlf@private, Manager, Dueling Modems Computer Forum http://dm.net
------------------------------
Date: Wed, 28 Apr 2004 08:41:44 -0800
From: Rob Slade <rslade@private>
Subject: REVIEW: "Network Security Essentials", William Stallings
BKNTSCES.RVW 20031210
"Network Security Essentials", William Stallings, 2000, 0-13-016093-8,
U$48.00/C$75.81
%A William Stallings ws@private
%C One Lake St., Upper Saddle River, NJ 07458
%D 2000
%G 0-13-016093-8
%I Prentice Hall
%O U$48.00/C$75.81 201-236-7139 fax: 201-236-7131
%O http://www.amazon.com/exec/obidos/ASIN/0130160938/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0130160938/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0130160938/robsladesin03-20
%P 366 p.
%T "Network Security Essentials: Applications and Standards"
The existence of this book is a bit odd, particularly in view of the
fact that it shares so much material with Stallings' "Cryptography and
Network Security." The (clear and structured) preface, however,
states that the intent is to provide a practical survey of network
security applications and standards, particularly those in widespread
use. As with the earlier work, this book is intended to serve both as
a textbook for an academic course of study, and as a self-study and
reference guide for practicing professionals. There is reduced detail
in regard to cryptography.
Chapter one is an introduction, and provides a good list of basic
concepts and vocabulary. It may not be completely apparent to all
readers that the emphasis is on threats to data transmissions and
there is limited review of attacks on functioning systems.
Part one deals with cryptography. Chapter two covers symmetric block
ciphers in fundamental but sound terms, illustrated by an explanation
of DES (Data Encryption Standard). The logic is heavily symbolic at
times, but that should not be an impediment to the reader. It is
interesting that chapter three views asymmetric cryptography as an
extension of message authentication codes, but the explanations are
articulate, including both algebraic and numeric examples, although
the numeric illustrations could be fuller.
Part two deals with network security applications. Chapter four looks
at authentication applications, concentrating on Kerberos and X.509.
The examples of e-mail security systems given in chapter five are PGP
(Pretty Good Privacy) and S/MIME (Secure/Multipurpose Internet Mail
Extension). Security provisions for the Internet Protocol (IP) itself
are reviewed in chapter six. Web security, in chapter seven,
discusses SET (Secure Electronic Transaction) and SSL (Secure Sockets
Layer). Chapter eight reviews SNMP (Simple Network Management
Protocol) both in terms of network management for security purposes,
and in regard to cryptography for authentication of the application
itself.
Part four outlines general system security. Intruders and malicious
software are lumped together in chapter nine, with a reasonable
outline of the types of malware, but not dealing as well with viruses
themselves. (Activity Monitors are referred to as "third generation"
tools, when they actually predate both signature scanners ["first
generation"] and heuristics ["second generation"].) Chapter ten
finishes off the book with a description of firewalls, but has a
rather odd inclusion of basic access control and trusted systems.
Each chapter ends with a set of recommended readings and problems.
Many chapters also have appendices giving additional details of
specific topics related to the subject just discussed.
A very reasonable guide, although possibly less practical than it
intended to be.
copyright Robert M. Slade, 2003 BKNTSCES.RVW 20031210
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.34
************************
This archive was generated by hypermail 2b30 : Wed Apr 28 2004 - 18:36:59 PDT