RISKS-LIST: Risks-Forum Digest Thursday 26 February 2004 Volume 23 : Issue 21
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.21.html
The current issue can be found at
http://www.csl.sri.com/users/risko/risks.txt
Contents:
Bar codes for your health (NewsScan)
*Computer Weekly*'s campaign against government incompetence (Pete Mellor)
Malicious IT design in support of the cold war (Sam Garst)
Flaws threaten VoIP networks (Lillie Coney)
Fixed-length fields strike again (Robert Israel)
Toll Collect doesn't (Peter B. Ladkin)
SPF and SRS (Ben Rosengart)
Re: Risks of SPF (Peter da Silva)
Re: SPF and its critics (Dimitri Maziuk)
Theft of Client Information at Israeli Bank's "Information Fortress"
(Gadi Evron)
Re: Interesting device to steal ATM accounts (Gadi Evron)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 26 Feb 2004 08:07:18 -0700
From: "NewsScan" <newsscan@private>
Subject: Bar codes for your health
Federal officials say that the use of bar codes to identify prescriptions
has the potential to cut in half the 7,000 hospital deaths [!] attributed to
medication error every year. The Department of Health and Human Services has
announced a regulation requiring that drugmakers and blood suppliers add the
codes to most of their products within the next two years. HHS Secretary
Tommy G. Thompson says, "The pharmaceutical industry wants it, hospitals
want it, doctors want it -- all we needed was the catalyst to put all it
together." [*The Washington Post*, 26 Feb 2004; NewsScan Daily, 26 Feb 2004]
http://www.washingtonpost.com/wp-dyn/articles/A6995-2004Feb25.html
------------------------------
Date: Sat, 21 Feb 2004 19:14:48 +0000 (GMT)
From: Pete Mellor <pm@private>
Subject: *Computer Weekly*'s campaign against government incompetence
You might be interested to read about *Computer Weekly*'s campaign about the
recent disastrous attempts by various UK Government. departments to procure
large IT systems. CW have submitted evidence to the National Audit Office
(UK equivalent of the GAO). See:
http://www.computerweekly.com/articles/article.asp?liArticleID=128417&liArticleTypeID=1&liCategoryID=2&liChannelID=28&liFlavourID=1&sSearch=&nPage=1
http://www.computerweekly.com/articles/article.asp?liArticleID=128417
&liArticleTypeID=1&liCategoryID=2&liChannelID=28&liFlavourID=1&sSearch=&nPage=1
The URL is for Tony Collins' front-page article on 17 Feb 2004. For the
related articles, just follow the links.
Peter Mellor, Centre for Software Reliability, City University,
Northampton Square, London EC1V 0HB +44 (0)20 7040 8422
------------------------------
Date: Thu, 19 Feb 2004 11:26:22 -0500
From: Sam Garst <samgarst@private>
Subject: Malicious IT design in support of the cold war
On 2 Feb 2004, *The New York Times* printed an editorial by William Safire
entitled "The Farewell Dossier" describing a CIA campaign in the early 1980s
that supplied Russia with deliberately flawed technology; this lead directly
to the massive explosion of a Siberian gas pipeline. The CIA became aware
that the KGB was purchasing technology on the black market, and endeavored
to supply the KGB with technology that would pass inspection, and later fail
catastrophically.
Two risks leap out at me (trying hard to separate out several moral issues):
- I may test for poor design, or poor manufacturing, but these products were
designed to pass testing, and then fail. Should I start testing for
malicious design (perhaps, if you're building sensitive infrastructure,
this is common practice)?
- These intentional flaws could 'leak' into the legitimate product
lines. Hopefully, these companies had (and still have) good software build
processes and code repositories.
The article is no longer available at New York Times, but is available:
http://seclists.org/lists/isn/2004/Feb/0011.html
Safire indicates the story is from a soon-to-be published book:
Thomas C. Reed's "At the Abyss".
------------------------------
Date: Wed, 14 Jan 2004 11:45:24 -0500
From: Lillie Coney <lillie.coney@private>
Subject: Flaws threaten VoIP networks
[Source: Robert Lemos, Flaws threaten VoIP networks, CNET News.com,
13 Jan 2004; PGN-abstracted]
http://news.com.com/2100-1002_3-5140284.html?tag=nefd_lede
A technical review conducted by the British government has found several
security flaws in products that use VoIP and text messaging, including those
from Microsoft and Cisco Systems. The flaws affect software and hardware
that support the real-time multimedia communications and processing
standard, known as the International Telecommunications Union (ITU) H.323
standard.
The security problems can cause a product that supports H.323 to crash. For
example, in Cisco telecommunications products running its IOS operating
system, the vulnerability could be used to cause the devices to freeze or
reboot. However, on Microsoft's Internet Security and Acceleration Server
2000, which is included with Small Business Server 2000 and 2003 editions,
the vulnerability could allow an attacker to take control of the system.
------------------------------
Date: Sun, 8 Feb 2004 18:54:42 -0800 (PST)
From: Robert Israel <israel@private>
Subject: Fixed-length fields strike again
According to a recent report in the Israeli paper Haaretz
<http://www.haaretzdaily.com/hasen/spages/392009.html>
the Israel Defense Forces will have to pay tens of millions of shekels to
fix a two-year-old automated system for calling up reservists: the system
allocates 9 digits for a reservist's cell-phone number, but in a few months
all Israeli cell phones will have 10 digits. According to the article, "The
army will also look into expanding the fields for personal and other
telephone numbers to prevent future problems."
Robert Israel, Department of Mathematics, University of British Columbia
Vancouver, BC, Canada V6T 1Z2 http://www.math.ubc.ca/~israel
------------------------------
Date: Wed, 25 Feb 2004 20:22:41 +0100
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: Toll Collect doesn't
Headline news last week in Germany, as well as in papers with an eye on
Europe [1,2,3], has been the failure of the Toll Collect consortium to
deliver a toll-collection system for heavy goods vehicles that use the
German Autobahn network. (Autobahns are the German equivalent of U.S.
freeways.)
The system is based on GPS tracking of heavy goods vehicles, using
boxes ("On Board Units", OBU) carried in the vehicles. The OBUs
contain GPS receivers, and forward their data to a central data
installation using European standard GSM mobile telephony.
The consortium consists of Deutsche Telekom, Germany's quasi-privatised
ex-public telephone operator, DaimlerChrysler, which own 45% each, and
France's autoroute toll system operator Cofiroute (a concern of Vinci SA),
which has 10%. The consortium has some 24 major subcontractors, amongst
whom are such well-known names as HP, Siemens/VDO, Sun, Vodaphone,
T-Mobile, Oracle, Peoplesoft, and SAP [4].
In-service date was supposed to be 31 August 2003. There are estimated to
be 1.4 million trucks which should pay a toll, of which 400,000 are from
other lands. It was planned to deliver 450,000 OBUs by the in-service date;
other users were to use static machines at entry points. There were
problems with the OBUs, and even five weeks after in-service date only
210,000 had been installed. There were also problems with the
bookkeeping software at the data center, which turned out not to have
appropriate interoperability with other systems used by truck
operators [4].
The contractual arrangements for developing the system were, to someone
like me, cause for concern. Although details of the call had been known in
essence since August 2001, a call for proposals was issued in April 2002
after a law putting the government's "Anti-Traffic-Jam Program" into force
had been passed. The contract was awarded to the consortium on 8th July
2002. The government apparently wanted a twelve-month development schedule.
One of the two final bidders said this was "unrealisable"; the winner (Toll
Collect, or Electronic Toll Collect as it was then known) proposed an
eleven-month development schedule, with a four-month trial period during
which the usual contractual penalties for non-performance would be waived.
Legal challenges held off starting work in earnest until September 2002.
The contract was slated to employ about 350 programmers and 80 SW testers.
The development costs are said to lie somewhat over EUR 600M (which is the
value of the low-price offer from a Swiss toll-system company, that
couldn't provide the necessary insurance and was eliminated early) [4,5].
Talks have taken place between the government and the consortium to
establish the rate of compensation for default and how things shall move
forward. The talks broke down on 17th February, with the government
declaring it would cancel the contract and declaring damages of around
EUR 6.5 billion ($8.2 billion) [8,9].
The consortium is already paying EUR 250K/day in fines since December 1,
2003, increasing to EUR 500K/day in March 2004. The government rejected the
consortium's offer of EUR 600M per year in compensation [2]. At least one
German journal is reporting a week after talks supposedly "broke down" that
the fine payment has increased to EUR 1M/day [6], but that represents only
some 60% of the rejected compensation offer, so it is hard to tell what is
happening.
The consortium says it has "solved software problems causing the delay"
[2]. DaimlerChrysler chairman Jürgen Schrempp, one of the most well-known
figures in German industry (and maybe in U.S. industry also) says "there
is a chance, even with this long delay, to make the system work" [1]. The
consortium has offered to deliver a system with reduced functionality by
31 December, 2004, with full functionality implemented a year later [2].
There are lots of figures floating around concerning revenue lost, and
costs, and such like. Numbers are seemingly hard-edged things, that bring
with them the aura of independence from politics and suchlike. I like to
perform arithmetic on such figures to see how they add up. When they
don't - and they often don't in this case - one can suspect that they
represent negotiating positions rather better than they represent a true
accounting. Here are a few, which I recommend treating with caution.
The project worth was said to be EUR 7.73 billion, with a service lifetime
of 12 years [5]. This figure amounts to ~EUR 54M/month. The government
estimates foregone revenue at EUR 156M per month [2] (derived from EUR 6M
per day over a 26-day truck-driving month). Lost revenue from the former
"vignette" (sticker) system, which was taken out of service by 31 August
2003, amounts to EUR 30-38M/month. All new road projects and related
public-works projects have been put on hold because of the "revenue
shortfall" [3]. Some estimate that up to a quarter of transport ministry
projects may be cancelled in 2004, putting 70,000 jobs on the line [3].
One major problem appears to be that the government wrote this
EUR 156M/month anticipated revenue into its budget already. That is why
those road-building projects are on hold and those 70,000 jobs are
"endangered". Yes, that's right. Someone let a contract for a complex,
highly-distributed system, of a sort which did not exist anywhere before,
with a non-trusted, indeed partially non-trustworthy, user group
numbering in the millions, that would cost of the order of a billion
euros and ~450 technical-person-years to develop, which was to be in
full revenue service inside a calendar year from development start date.
And then apparently allowed the whole road-construction industry to become
dependent on that anticipated revenue, as well as part of the railways.
Another major problem appears to be that a consortium containing two
giants of German industry signed up to that astonishing contractual
schedule.
As Andreas Hagen wrote, concerning this so-called Public-Private
Partnership (also in German), the contractual politics "didn't do
citizens any favors. [It was] badly negotiated, and besides that, the
bear's hide was shared out before the bear was shot" [6, my translation].
The contract, by the way, has remained secret, although there is nominally
a requirement that it be public. Even the German parliament has not seen
it [5]. So few, if any, independent people with the capacity to evaluate
them know what the system requirements were or how well they were met. Or,
for those interested in the future rather than the past, how close the
technology is to meeting them.
The contract is so remarkable that few tech-savvies believe that the
consortium can have negotiated it in good faith. Some even have a hard time
believing that the government negotiated it in good faith, although more
are inclined to believe it just didn't know what it was doing.
The stories of the negotiations over default bring to mind the game of
chicken, in which two drivers drive their cars head-on towards each other
at full speed, and the first to swerve loses (everyone cites [7], but I
have just failed to find the example). One sees evidence of the strategy
of removing one's steering wheel and visibly throwing it out the car
window. But the current case is not a two-player game, nor even a zero-sum
game. It is a game of partial coordination, in the terminology of [7].
There is a dealer who owns both cars, employs one of the drivers, and keeps
the other in business. He is very concerned about the outcome, and prefers
not to lose either of his cars, but is likely to care much less about the
drivers. His name is Joe Public. Both sides have an obligation to Joe to
fix what is wrong, whether it be technical, contractual or political. It is
unlikely to impress Joe over the long term if one of the drivers throws his
steering wheel out of the window and then claims the other driver loosened
it.
It is clear that the risks of the contract were poorly calculated by
both sides. The government appears to have believed there was no risk
to itself, even though it can hardly seriously have expected
DaimlerChrysler and Deutsche Telekom to finance the entire German road
construction industry in the event of a default. It stands convicted of
bad planning. The consortium members appear to have underestimated the
damage to their reputations and consequences for future business that a
significant default would entail. There is even a suspicion that they
negotiated the original contract knowing, but not adequately conveying,
the odds that it could not be fulfilled. At the least, it exhibited
either hubris or bad faith, even though we do not know which.
As Chairman Schrempp said, "mistakes were made by all sides" [1].
Many technology-savvies have no problem in believing that such a system
could be delivered in good working order in three or four years. But for
many people including some of my colleagues there now appears to be
difficulty in believing anything Toll Collect says on the matter, not
necessarily for technical reasons.
Oh, yes, a word or two on the technical issues. Putting the blame
on "software problems" tells us little. It could have been that the
software development process did not measure up to best practice; it could
also have been that difficult engineering issues that could not be solved
in the hardware were pushed into the software and the software development
team didn't know how to solve them either. It could also have been that
there were design or specification problems which first manifested
themselves, or needed to be solved, in SW. Most likely, it was all three.
The Economist says that "important features were left out of the software,
such as the ability to work with the payment cards and accounting systems
used by most trucking firms. Worse, gremlins charged trucks for being near
motorways, rather than on them, or drained batteries while engines
were switched off" [3]. German sources give a more specific, longer list
of particular problems [4].
It also probably didn't help that the European Union issued a requirement
during system development that the design enable the data to be made
available to a variety of processing companies, presumably to enable
competition in the data-processing phase. In the original design the data
would be shared with just one processing company, DaimlerChrysler Services
Mobility Management [4].
It seems to me to be premature to sum up. I'll just leave it here,
with thanks to Heiko Holtkamp and Jan Hennig, who helped me in
finding sources.
PBL
References
[1] German engineering loses luster, Mark Landler, International Herald
Tribune, Friday, February 20th, 2004,
http://www.iht.com/articles/130404.html
[2] Berlin kills contract to build satellite-based toll system,
International Herald Tribune, Wednesday February 18th, 2004,
http://www.iht.com/articles/130098.html
[3] Road rage: European road tolls; Germany's truck tolls crash, The
Economist, January 24th-30th, 2004, available for a fee through
www.economist.com
[4] Detlef Borchers, Verursachbedingt verspätet, c't No. 22, 2003
(in German), available for a fee through www.heise.de
[5] Joachim Budeck, Dr. Egbert Meyer, Ausgebremste Automatik, c't
No. 21, 2002 (in German), available through www.heise.de
[6] Andreas Hagen, Zwischenspiel oder letzter Akt mit Toll Collect?
(in German), Telepolis magazine, 25th February 2004,
http://www.heise.de/tp/deutsch/special/eco/16827/1.html
[7] Thomas C. Schelling, The Strategy of Conflict, 1960 & 1980,
Harvard University Press.
[8] Stolpes Brief an Toll Collect [German Transport Minister Manfred
Stolpe's letter to Toll Collect] (in German), 17 February 2004, published
by N-TV news channel and CNN Germany, available at
http://www.n-tv.de/5215294.html
[9] Der Kündigungsbrief von Manfred Stolpe an Toll Collect [also a copy
of Stolpe's letter] (in German), 17 February 2004, published by the
Süddeutsche Zeitung, available at
http://www.sueddeutsche.de/wirtschaft/artikel/880/26854/
Peter B. Ladkin, University of Bielefeld, http://www.rvs.uni-bielefeld.de
------------------------------
Date: Wed, 18 Feb 2004 18:47:17 -0500
From: Ben Rosengart <risks@private>
Subject: SPF and SRS
Much of the controversy around SPF <http://spf.pobox.com/> focuses on the
"Sender Rewriting Scheme" <http://spf.pobox.com/srs.html>. I don't like SRS
either, but I think SPF can be used without it. Maybe I'm wrong, but here's
my argument, let's see if anyone can shoot it down.
Rationale for SRS: mail that is forwarded with the envelope sender unchanged
may appear to violate SPF policy. If we rewrite the envelope sender address
at forwarding time, we can change it to something that will conform to SPF
policy.
Anti-rationale for SRS: since we know where our forwarded mail will come
from, we can tell SPF to accept mail from those sites "uncritically". Every
forwarder -- be it a forwarding address or a mailing list -- has an e-mail
address associated with it. We can look up the SPF data for that address
and extend extra trust to the authorized clients, by letting them send us
mail with any envelope sender.
What's wrong with this picture? One possible criticism: a forwarding site
has a permissive policy, perhaps its SPF record ends with ?all. Solutions:
1. Instead of using SPF to determine your forwarded-mail policy, write your
own SPF-style policy and apply that to mail which fails ordinary SPF.
2. Pressure the forwarding site to adopt a more restrictive policy.
Another criticism: this gives a lot of trust to the forwarding site(s). The
trust could be abused. I have no answer for this except that it's worth it
to dump SRS.
[MORE From Ben on Wed, 18 Feb 2004 21:22:46 -0500]
I realized after I sent you the previous note that there are some
points I neglected to address; specifically, more problems with my
proposal.
o It requires SPF to be configurable on a per-user basis. This will
annoy people who want to simply slap SPF into their Internet-facing
MTA and forget about it.
o It requires explicit end-user configuration, while SRS is theoretically
transparent.
I still think it's worth considering -- SRS is really ugly.
------------------------------
Date: Wed, 18 Feb 2004 18:53:45 -0600 (CST)
From: Peter da Silva <peter@private>
Subject: Re: Risks of SPF (RISKS-23.18-19)
Implementing SPF would do nothing for the people receiving thousands of
bounces (myself included). It would simply add another filter that bounced
messages back to us because "we" weren't using the right server.
What, that wouldn't happen? You'd think not, but then you'd think that the
antivirus companies sending us "bounces" would have caught on some time in
the past three or so years that the majority of viruses have been forging
sender addresses too...
The only anti-spam scheme that I have found that works even remotely well is
requiring some kind of personally chosen token for every incoming message,
along with an accept list (whitelist, greenlight list) for special cases
like mailing lists. Anything else, including a standardised
challenge-response based system, can be bypassed often enough for spammers
to keep trying.
The token can be anything, something on the subject line, something added to
an e-mail address, an extra header line... just so long as it can't be
automated in bulk it's fine. Eventually spammers will catch on and we'll
have to come up with a cryptographically secure message signature... but
that's for the future.
The "notsp" token RISKS uses is a simple example of this scheme. I set
up something barely more elaborate for my family months ago and their spam
load has almost vanished. As I recall there's been one or two hopeful
"419" spammers who read the bounce and actually bothered to negotiate
the 'firewall'... over a period of months, down from hundreds of spams
(including of course several 419-ers) every day.
------------------------------
Date: Fri, 20 Feb 2004 11:40:46 -0600
From: dmaziuk@private (Dimitri Maziuk)
Subject: Re: SPF and its critics (Kestenbaum, RISKS-23.19)
E-mail was not designed with spammers in mind, just like the rest of TCP/IP
was not designed with 1337 h4x0rz and script-kiddies in mind.
We know that slapping a band-aid onto implementation to fix deficiencies in
design doesn't work and creates more problems, we've seen it over and over
again. Every time I see a proposal like SPF I can't help wondering where its
authors have been in the last couple of decades so that they managed to miss
this important piece of knowledge.
On the other hand, there's no reason to believe anyone will rush to
implement new and improved SMTP when/if ever that comes along -- nobody's in
a hurry to switch to IPv6, are they?
> The critics of SPF suggest that spammers would simply find or invent other
> addresses to use. Frankly, I don't care about that, so long as they stopped
> plastering my personal address on hundreds of thousands of fraudulent and
> disreputable spam messages and viruses, and clogging my server's net
> connection with vast piles of misdirected bounces.
We can do it without breaking anything. We already have directory servers,
we already have digital signatures. All we need is a way to query Domain
Name Service for directory server of a domain, and a standard directory
query-response for an e-mail address and associated public crypto key.
Get your domain administrator to publish domain's e-mail addresses
and associated public keys on a directory server (BTW, contrary to
the popular belief, X.509 was intended for this sort of thing, and
not for storing login passwords).
Digitally sign your messages. Recipient's mail server then queries directory
server to find out if From address is valid, and verifies digital signature
to make sure message is signed with key associated with that address. This
is as much as SPF will really do, but without breaking SMTP headers, forcing
users to send mail via their domain's mail forwarder, etc. -- i.e. without
any of SPF's obvious problems. Message integrity check using strong crypto
is just an added bonus.
Apart from technical problems with implementing (large scale, in
case of e.g. aol.com domain) PKI (see e.g.
http://www.mit-kmi.com/articles.cfm?DocID=385),
expect a lot of political resistance to this scheme. It is putting weapons
of mass destruction^W^W^W^W crypto software in the hands of Joe A. User --
law-enforcement agencies ain't gonna like that. Commercial certificate
authorities won't like it because it effectively makes every sysadmin their
own CA. And then there is a whole lot of crypto standards to choose from:
ssh, ssl, pgp...
And then, here's the real clincher: legislature _wants_ to legalize e-mail
spam. Fax spam is illegal because it puts the costs on the recipient: you
have to pay for toner and paper. But so does e-mail spam: you have pay your
ISP for bandwidth. So if they wanted to ban spam, they'd simply apply
existing law to it. Ergo, they don't want to ban spam, and all "anti-spam"
legislations are really there to legalize it. Ergo, all you're going to
achieve by implementing SPF, blocklists, blacklists, whatever, is to open
yourself to lawsuits from "legal" spammers.
To get back where I started: we know that technical solutions for
non-technical problems don't work. We are clearly dealing with non-technical
problem here.
Do not expect another Perl wrapper around good old sendmail to fix anything.
------------------------------
Date: Thu, 19 Feb 2004 12:39:08 +0200
From: Gadi Evron <ge@private>
Subject: Theft of Client Information at Israeli Bank's "Information Fortress"
According to reports, a break-in occurred at the Israeli Bank Leumi's
"Information Fortress". The perpetrators accessed the perimeter physically
and proceeded to steal and delete critical client information from the "main
server", using a laptop computer they allegedly hooked into the network.
You can find an article I put together, with known facts on the story:
http://www.math.org.il/leumi-breakin.html.
Phone: +972-50-428610 (Cell).
http://vapid.reprehensible.net/~ge/Gadi_Evron_Emails.asc
------------------------------
Date: Thu, 19 Feb 2004 13:05:01 +0200
From: Gadi Evron <ge@private>
Subject: Re: Interesting device to steal ATM accounts (RISKS-23.19)
> Bank ATMs Converted to Steal Bank Customer IDs
> http://www.utexas.edu/admin/utpd/atm.html
Israeli news site Ynet has a story on an ATM theft that has an uncanny
resemblance to what's described in the article I am replying to.
(In Hebrew: http://www.ynet.co.il/articles/0,7340,L-2877093,00.html)
Apparently such a system was installed at a branch of the Israeli Bank
HaPo`alim in the city of Ramat Gan, resulting in the theft of 200,000 INS
(approximately 44,500 USD).
The bank mentioned in its press release that suspicious activity was
detected in three other branches of the bank, but no signs of such an ATM
theft system was found. Furthermore, since any bank customer can draw money
from any bank's ATM, a portion of the customers belonged to other Israeli
banks.
The Ynet article also mentions that the crime was apparently committed by a
Romanian gang.
------------------------------
Date: 28 Jan 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 the Lindsay Marshall's Newcastle archive
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., 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.21
************************
This archive was generated by hypermail 2b30 : Thu Feb 26 2004 - 16:43:38 PST