RISKS-LIST: Risks-Forum Digest Thursday 13 October 2005 Volume 24 : Issue 07
ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy
***** 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/24.07.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Takeoff at Logan aborted by errors (Mac Daniel via Monty Solomon)
Faulty radar serving Logan leaves thousands stranded (via Monty Solomon)
Translation can be hazardous to your identity? (Mark Brader)
NOAA's radio transmitters missing backup power (Danny Burstein)
The number 7 blocks Belgian ATM machines (Lindsay Marshall)
We are from the /Greek/ government and we are here to help. Really!
(Vassilis Prevelakis)
Risks of Web 2.0, or, the MySpace worm (Paul Bissex)
Unusually slick phishing attempt (Nickee Sanders)
Re: Airbus, Whistleblower Dispute A380 Pressurization Controls
(Kurt Doppelbauer)
Re: B777 incident (Peter B. Ladkin)
"One Frequency" (Jay R. Ashworth)
Re: Windows delete command can fail silently (Joe Loughry)
Re: Mea culpa: How we got it wrong on CNID (Geoff Kuenning, Jon A. Solworth)
Criticism of Caller ID Well Founded (Robert Ellis Smith)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
From: Monty Solomon <monty@private>
Date: October 7, 2005 12:51:46 AM EDT
Subject: Takeoff at Logan aborted by errors
An American Airlines jet aborted its takeoff at Logan International Airport
on 4 Oct 2005, after errors by a pilot and a controller allowed another
plane to cross onto its runway. An FAA spokesman could not say how close
the planes had come to colliding, but said the American Airlines flight was
rolling at the time its takeoff clearance was canceled. An aviation source
familiar with the investigation said the planes came within 1,000 feet. The
incident was the second runway incursion in just over a week. On 27 Sep
2005, a FedEx cargo jet that had just started its takeoff came within 2,000
feet of a twin-propeller plane crossing the same runway. The two incidents
bring to 16 the number of runway incursions since Oct 2004 at Logan, a
number that has alarmed airport and federal officials. ... [Source: Mac
Daniel, *The Boston Globe*, 6 Oct 2005; PGN-ed]
http://www.boston.com/news/local/massachusetts/articles/2005/10/06/takeoff_at_logan_aborted_by_errors/
------------------------------
Date: Wed, 12 Oct 2005 04:02:45 -0400
From: Monty Solomon <monty@private>
Subject: Faulty radar serving Logan leaves thousands stranded
Faulty radar serving Logan leaves thousands stranded
Monitors show objects that don't exist; solution uncertain
A malfunctioning radar system serving Logan International Airport caused
flight cancellations and delays of several hours yesterday, stranding
thousands of passengers on a holiday weekend and adding to the woes of an
airport that has logged several runway incidents in the past few months.
[Source: Donovan Slack, *The Boston Globe*, 11 Oct 2005]
http://www.boston.com/news/local/articles/2005/10/11/faulty_radar_serving_logan_leaves_thousands_stranded/
[More: Radar malfunction causes long delays at Logan, *The Boston Globe*, 11
Oct 2005
http://www.boston.com/news/local/massachusetts/articles/2005/10/11/radar_malfunction_causes_long_delays_at_logan/
Airport travelers play the waiting game, Many in the dark about radar
glitch, Heather Allen, *The Boston Globe*, 11 Oct 2005]
http://www.boston.com/news/local/massachusetts/articles/2005/10/11/airport_travelers_play_the_waiting_game/
]
------------------------------
Date: Tue, 11 Oct 2005 15:58:28 -0400 (EDT)
From: msb@private (Mark Brader)
Subject: Translation can be hazardous to your identity?
As is often done in Europe, the agency operating streetcars in the French
city of Grenoble has provided ticket-selling machines that can be operated
in more than one language. It was reported this week in uk.transport.london
that if you select English, the machines welcome you to London's Croydon
Tramlink system! Seen here:
http://www.ajg41.plus.com/images/rail/fr-grenoble-tramlink02.jpg
Mark Brader, Toronto, msb@private
[That is positively Grin-noble. I croyd on it. PGN]
------------------------------
Date: Tue, 11 Oct 2005 13:09:42 -0400
From: danny burstein <dannyb@private>
Subject: NOAA's radio transmitters missing backup power
Background: during the power failure two years ago, the NOAA (National
Weather Service) radio station serving NYC was dead....
These stations are part of the _real_ emergency network and are supposed to
stay up after anything short of a direct nuclear hit...
NYC recently printed a "what to do in a hurricane" booklet and mentioned
tuning into this station, pointing out there were automatic "alert" radios
designed for this..., so...
I wrote to NYC's Office of Management describing the outage. They were kind
enough to reply. [Excerpts attached ]
---------- Forwarded message ----------
Date: Tue, 11 Oct 2005
From: [snip, an OEM address]
Dear Mr. Burstein,
Thank you for your written correspondence to OEM Commissioner Joseph F.
Bruno, regarding your concerns pertaining to the NOAA All-Hazards Radio.
Commissioner Bruno has asked me to look into this issue for you.
[ snip ]
[The NOAA contact rep] advises that the NOAA All Hazards Radio has "dual"
transmitters; a primary and secondary. If the primary transmitter fails,
the NWS can utilize the secondary transmitter. However, at this point in
time, the NWS does not have an emergency power backup for the transmitter.
... The NWS has been in contact with the (owners of the transmitter site),
and are awaiting a cost estimate for this service.
[The RISKS are obvious. Readers in other areas of the country, especially
those prone to hurricanes/tornadoes/other natural disasters, and who rely
on these stations, might want to check them out as well.]
------------------------------
Date: Wed, 12 Oct 2005 15:22:35 +0100
From: "Lindsay Marshall" <Lindsay.Marshall@private>
Subject: The number 7 blocks Belgian ATM machines
The Dexia Bank ATM machines are experiencing a curious problem. The machines
stop functioning when someone enters the number 7, making it impossible for
people with a 7 in their pin (personal identification number) code to
perform a cash withdrawal.
The problem has been occurring for a month. To prevent people from running
out of cash, they are able to perform cash withdrawals inside. "We are
experiencing a problem with the software", a Dexia spokesman admitted last
wednesday in the daily journal Het Laatste Nieuws, "the problems should be
solved within three weeks."
http://www.nu.nl/news.jsp?n=603834&c=122&rss (Dutch, 5 Oct 2005)
------------------------------
Date: Sun, 9 Oct 2005 06:13:34 -0400 (EDT)
From: Vassilis PREVELAKIS <vp@private>
Subject: We are from the /Greek/ government and we are here to help. Really!
The internal revenue service of the Greek ministry of finance is providing
programs on their web site to help Greek citizens and firms fill-in
electronic tax forms. The ministry expects everybody with a computer to
download and run these program as certain tax-forms may only be submitted
electronically.
I have talked to the people at the ministry and they did not appear to think
that there is anything wrong with asking everybody to run programs provided
(only in binary form) by the government.
I asked them if they would consider providing me with the source of the
programs but they were loath to release it because they were afraid that
unscrupulous people would modify it and try to sell it (the programs may be
downloaded for free from the ministry's web site).
When I explained to them my fears that this looks like an Orwellian
nightmare (cf with the TV sets used in Orwell's 1984 to monitor citizens),
they were rather surprised saying that nobody has mentioned this to them
before! (Am I the only paranoid person in Greece?)
Of course, nobody is forced to use the programs, although in many cases they
save so much time, that it is difficult to convince someone not to use them
because of some nefarious threat. Once more convenience trumps security.
Another issue not strictly security related, is that the Greek government
assumes that everybody uses Microsoft Windows. Some parts of their web site
refuse to talk to non-Microsoft browsers (they redirect to an error page),
and the programs they supply run only under Windows.
Conspiracy theorists would surely make something out this, but I strongly
believe that the people at the ministry have the best intentions; they
simply did not think things through.
The Ministry now plans to provide Java-based programs that should run on
non-Microsoft platforms and may make the source code available to academic
institutions or non-governmental organizations for auditing purposes.
Still the whole experience shows how easy it is for state agencies to reach
out in the homes of their citizens.
Vassilis Prevelakis, Computer Science Department, Drexel University
------------------------------
Date: Thu, 13 Oct 2005 15:00:16 -0400
From: Paul Bissex <pb@e-scribe.com>
Subject: Risks of Web 2.0, or, the MySpace worm
An individual "managed within 24 hours to become the most popular civilian
on myspace with the help of a clever bit of viral javascript imbedded into
his myspace page... By the time myspace shut down their site for a few hours
to investigate he had over 1 million requests from unknowing myspace members
for him to be listed as their myspace friend."
Details at:
http://fast.info/myspace/
This seems like a new class of XSS, "Level 3" if you will:
http://e-scribe.com/news/103
Paul Bissex <pb@e-scribe.com> PO Box 847, Northampton MA 01061 USA
http://e-scribe.com/ Database-driven web development Open source software
------------------------------
Date: Thu, 13 Oct 2005 22:07:39 +1300
From: Nickee Sanders <njsanders@private>
Subject: Unusually slick phishing attempt
Whilst clearing out his morning spam collection today, my husband came
across an unusually slick phishing attempt. This one's victim-bank is
Halifax Bank in the UK. The subject line reads "URGENT ATTENTION -
Halifax-Online Fraud Notice" and the body begins by advising of recent
phishing attempts against Halifax customers (which, according to Halifax's
own site, is even true) and then asks the customer to contact Halifax on
receipt of such e-mails!! (The customer service phone number quoted is even
the real one.) Extremely cheeky.
The e-mail continues by advising that Halifax has updated their security
system. They are proud of their new SSL servers "where there is no risk of
fraud and your account details are kept encrypted at all times."
Naturally, because of this update, you are....guess what?..... asked to log
on to the system and "verify your account info at the following link"
Such link being of the usual format -- an IP address (211.35.64.201) hidden
behind a reasonable-looking URL -- which points to a real page on Halifax's
servers.
The e-mail is unusually slick, as well as being cheeky. It's almost devoid
of spelling mistakes ("unauthorized" should be "unauthorised" since it
purports to come from a British company) and likewise of grammar mistakes
("securer" instead of "more secure" and one missing "to"). It could easily
have come from a real person at the bank.
The image at the top of the e-mail actually comes from the real Halifax
servers; as mentioned, the phone number quoted will actually get you to
Halifax customer service, and if the URL is typed in by hand to a browser
it will get you to Halifax's own servers.
This phishing attempt is almost perfect, as far as I can see. Great use of
social engineering. Professionally put together. Very scary. I give them
a grade of 98% for this project.
Nickee Sanders, Software Engineer, Auckland, New Zealand
[I've seen many of very sophisticated Phishing attacks lately, purporting
to be BofA, WellsFargo, etc. Some of them take a lot of study to realize
they are bogus. BEWARE!!!! PGN]
------------------------------
Date: Tue, 11 Oct 2005 15:57:06 +0200
From: Kurt.Doppelbauer@private
Subject: Airbus, Whistleblower Dispute A380 Pressurization Controls (R 24 05)
With respect to RISKS-24.05 and the posting on "Airbus, Whistleblower
Dispute A380 Pressurization Controls" I'd like to point out that Mr. Mangan
is not a whistleblower. Based on the false claims, TTTech has released the
following statement.
Moreover, I am personally disappointed that *LA Times* has published an
article with very strong allegations against TTTech without profound
technical substance. Stefan Poledna CEO TTTech
TTTech defends against false allegations. These allegations were made by a
dismissed former employee one year ago and have been proved to be wrong.
Vienna, Austria -- 6 Oct 2005
Stefan Poledna and Georg Kopetz, members of the executive board of TTTech, a
leading provider of technology and products in the field of Time-Triggered
Technology, have responded to the false allegations about their components
as follows:
1. TTTech's first priorities are safety and adherence to all certification
procedures.
2. TTTech is a producer of time-triggered communication systems. Renowned
international research institutions and companies have participated in the
development of Time-Triggered Technology for more than 25 years. TTTech is
considered to be a leading supplier in the field of data communication
systems for aircraft and other transportation systems. TTTech's products
offer a very high degree of safety. For this reason leading companies have
selected this European leading-edge technology. TTTech does not develop
cabin pressure control systems.
3. The former employee had been employed by TTTech for six months before his
contract was terminated. He made his allegations only after his dismissal on
October 1, 2004. A few days before contract termination, he had praised
TTTech's achievements for Airbus A380 in an e-mail to the management. This
former employee is not a "whistleblower".
4. The allegations made by this former employee have been thoroughly
reviewed by TTTech's customers and the authority EASA (the European Aviation
Safety Agency). Creating aircraft designs is an iterative process. The
TTTech components are certified under the rigors applicable to newly
designed aircraft products, thereby assuring safety of flight. The involved
companies and authorities issued the following official statement several
months ago: "The matters raised by the former TTTech employee have been
thoroughly reviewed by TTTech's customers and EASA (the European counterpart
to the U.S. Federal Aviation Administration). Creating aircraft designs is
an iterative process. The TTTech components will be certified under the
rigors applicable to newly designed aircraft products, and safety of flight
will be assured."
5. The court repeatedly asked the former employee to substantiate his
allegations. But neither in the action for provisional injunction issued by
the civil court of Vienna at the end of October 2004 nor in the common trial
in court was he able to supply any evidence that would prove failures by
TTTech, or any safety defects in the components supplied by TTTech.
6. The court has never forbidden the former employee from discussing safety
issues of TTTech products in public. However, the court imposed an order to
the former employee not to disclose confidential documents and trade secrets
to third parties, nor to make statements that would discredit TTTech, such
as the allegation that ``TTTech participates in a criminal conspiracy.''
see also at:
http://www.tttech.com/press/docs/pressreleases/PR_2005-10-06-TTTech-WDR.pdf
Kurt Doppelbauer, TTTech Computertechnik AG, Schoenbrunner Strasse 7, A-1040
Vienna, Austria +43 1 585 34 34-18 http://www.tttech.com
------------------------------
Date: Sun, 09 Oct 2005 07:59:37 +0200
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: Re: B777 incident (Ladkin, RISKS-24.03, Wright, RISKS-24.05)
For those Risks readers who may not have made the connection, the B777
partial loss of control incident reported by Charles Wright in RISKS-24.05
and that reported by me in RISKS-24.03 are the same incident.
Peter B. Ladkin, University of Bielefeld, Germany
www.rvs.uni-bielefeld.de
------------------------------
Date: Wed, 12 Oct 2005 08:26:06 -0800
From: Rob Slade <rslade@private>
Subject: Disaster comms
The Dutch government is testing a warning system that sends text
messages to mobile phones during public emergencies. Called 'cell
broadcast', the technology will let authorities send messages to
all mobile phone users in a specific zone, and will be used in
conjunction with other emergency warning systems.
http://www.smh.com.au/news/breaking/holland-tests-disaster-text-service/2005/10/06/1128562930005.html
As previously noted, telephone is unreliable in a disaster, and cell service
fails almost completely. Private radio may remain up, as long as repeaters
or other infrastructure is not required (also think about battery
recharging) but there may be contention for bandwidth. However, recent
disasters have demonstrated that SMS service tends to remain functional.
(However, there are also recent studies that note the ability to DoS the
cell service in its entirety with a flood of SMS traffic.)
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: Sat, 17 Sep 2005 15:16:18 -0400
From: "Jay R. Ashworth" <jra@private>
Subject: "One Frequency" (Re: RISKS-24.04)
Clearly, what Rudy Giuliani was incorrectly quoting from his technical
advisors who actually *knew* what they were talking about, was the necessity
to allocate and provision between other categories of agencies what
firefighters have had for years: interagency coordination channels.
Fire fighting has been an inter-jurisdictional issue much longer and more
frequently than law enforcement, and so the fire people have simplex
frequencies on which they can talk with their compatriots borrowed from
other jurisdictions when large fires strike.
There are, though, many other things that caused communications problems
during Katrina and it's aftermath (as the communications engineering people
who were likely begging for the solutions to these problems for years, but
could not get them funded, would likely tell you):
* Trunking radio: While trunking is useful for reducing required spectrum
for an agency (you can assign "a fraction of" a channel to a given
agency), it relies on the same sort of centralized systems as Nextel's
consumer trunked SMR service currently does, and fails the same way.
* Nextel itself: Nextel is great, but is *not* engineered to the standards
necessary to utilize it in life safety applications (and while they *used*
to say this explicitly, these days what I see from them instead seems to
be *marketing* to those sorts of people). If a major emergency hits,
knocking out municipal power and toppling towers, Nextel's going down too.
* Digital public safety radio: While there is now an interoperable standard
for digital radio (APCO 25), there are many legacy digital public safety
systems, both trunked and not, that are not interoperable.
* Lack of prep: how hard you have to prep (spare battery counts; off-grid
recharging, etc) depends on what you're planning *for*. The levies and
dikes in Holland (much of which is also below sea level) are built for a
*4000-year* storm. So you can *do* that sort of thing, if you have the
political will.
Short version: just because the politicians don't know how to phrase it
doesn't mean that the technicians in the background don't know what's
necessary. Give them their heads, and some of the US$200B, and they'll
fix these problems for you.
Ashworth & Associates, St Petersburg FL USA 1 727 647 1274
http://baylink.pitas.com
------------------------------
Date: Wed, 05 Oct 2005 16:00:18 -0600
From: "Loughry, Joe" <joe.loughry@private>
Subject: Re: Windows delete command can fail silently
> The logic behind a correctly-operating implementation of DEL is trivial...
Watch out, though---the way that commands set ERRORLEVEL is *different* from
the way that library functions (and system calls) set the value of "errno."
ISO/IEC 9899:TC2 (currently the most up-to-date C Language standard---
well...committee draft, anyway) says that "errno" behaves this way:
> <em>The value of errno is zero at program startup,</em> [emphasis added]
> but is never set to zero by any library function.[Note 172] The value of
> errno may be set to nonzero by a library function call whether or not
> there is an error, provided the use of errno is not documented in the
> description of the function in this International Standard.
>
> 172: Thus, a program that uses errno for error checking should set it to
> zero before a library function call, then inspect it before a subsequent
> library function call. Of course, a library function can save the value
> of errno on entry and then set it to zero, as long as the original value
> is restored if errno's value is still zero just before the return.
Joe Loughry, Lockheed Martin Trusted Information Systems and Solutions
RADIANT MERCURY, 1-303-971-2951 joe.loughry@private
------------------------------
Date: 05 Oct 2005 14:23:45 -0700
From: Geoff Kuenning <geoff@private>
Subject: Re: Mea culpa: How we got it wrong on CNID (Kuenning, RISKS-24.05)
Lauren Weinstein and Kelly Bert Manning both take me to task regarding
some of the drawbacks of CNID. Kelly Manning states the position
best, I think:
> There are 100s of millions of people in the world with hard line
> phones. The fact that Geoff Kuenning hasn't personally experienced a
> downside of Caller ID doesn't mean that everyone else has been so
> fortunate.
True enough, and you will note that I did NOT issue a call for persons with
unlisted telephone numbers to be forced to reveal them via CNID. In fact, I
support changing ANI so that calls to toll-free lines don't reveal unlisted
numbers.
But there's another side to the counterargument: if 100s of millions of
people have hard-line phones, and a relatively small percentage suffer
problems from CNID, were we correct in campaigning vehemently against the
service? As I recall we actively attempted to keep it from being deployed
_at all_ in California.
Instead, perhaps we should have done a better job of balancing the RISKS and
the benefits. Certainly we need to make sure that people with a legitimate
need to hide from a stalker understand that CNID reveals their location, and
give them an easy and reliable way to prevent that. (That also applies to
new GPS-enabled cellphone services such as "find your friend".) But I would
like to find a balance where an abused spouse's need for safety doesn't
prevent me from taking advantage of CNID's very real benefits.
Kelly also writes:
> The fact that Geoff Kuenning hasn't been murdered doesn't mean that nobody
> should worry about homicide.
No, and it also doesn't mean that I should wander around in disguise for
fear of being murdered by someone I know. Murder and similar crimes are
scary, but they can also disproportionately color our thinking.
There is also an error of logic here: if a person is killed after their
location has been identified via CNID, that doesn't prove that eliminating
CNID would have prevented the murder. Such crimes predated CNID. Has there
been a statistical study demonstrating a CNID-related increase in what we
might call "location-related crimes"?
Finally, as I mentioned to Lauren in private e-mail: just because there are
implementation flaws in the current version of CNID doesn't make the concept
inherently flawed. By that logic, we might as well ban air travel because
of the known flaws in some aircraft.
Geoff Kuenning geoff@private http://www.cs.hmc.edu/~geoff/
------------------------------
Date: Wed, 05 Oct 2005 23:05:58 -0500
From: "Jon A. Solworth" <solworth@private>
Subject: Re: Mea culpa: How we got it wrong on CNID (Kuenning, RISKS-24.05)
I found Geoff Kuenning's retrospective on CNID very interesting. But I
disagree with the "mea culpa" bit. I think we, as part of the intellectual
community which thinks about and studies these issues, do have an important
role to play in public issues. We can identify the risks. We can describe
how a particular risk can be reduced. But at the same time, it is
fundamentally not our decision on how to balance these risks (since in
almost all cases the issues of risks are a tradeoff). We can inform, it is
up to society and to each individual to determine the balance.
Jon A. Solworth, Computer Science Dept., University of Illinois at Chicago
------------------------------
Date: Tue, 11 Oct 2005 15:46:10 -0400
From: "Robert Ellis Smith" <ellis84@private>
Subject: Criticism of Caller ID Well Founded (Re: Kuenning, RISKS-24.05)
Telephone customers have some protections from the negative consequences of
Caller ID precisely because privacy advocates expended a lot of energy to
assure the availability of number-ID blocking and to create a culture of
privacy protection within the new technology. We succeeded. We weren't
mistaken!
Geoff Kuenning's numbered arguments conflict with each other. Many of us
still lead lives in which protecting the identity of our phone numbers from
strangers - not to mention marketers - is vital. I believe that automatic
rejection of incoming ID-blocked calls is irresponsible to one's family and
self. We can't possibly anticipate when a loved one will be in distress,
calling us from a stranger's telephone. Automatic blocking disallows such a
call from reaching us. Geoff says that a parent with a teenager on the loose
at night would be sure to disengage the automatic blocking feature. Maybe
so. But how about the next night, when the kid is safely in bed and an aunt
or a cousin or a business associate is trying to reach us from a strange
phone? The call will not get through.
Geoff's commentary is comparable to saying that Martin Luther King Jr., was
wasting his time because African-Americans now have some degree of equal
opportunity. How do we think that came about, by magic? The efforts of
privacy advocates when Caller ID was first introduced make it possible for
Geoff to blithely proclaim, there's no privacy problem in 2005, the battling
back in the 1980s wasn't important.
Robert Ellis Smith, Publisher, Privacy Journal, www.privacyjournal.net,
privacyjournal@private
Back in the early 90's, U.S. phone companies began rolling out the service
known as "Caller ID" (really Calling Number ID, or CNID). Early adopters
were very pleased with the feature; it helped them to avoid telemarketers
and occasionally to dodge inconvenient friends.
------------------------------
Date: 29 Dec 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. Mailman can let you subscribe directly:
http://lists.csl.sri.com/mailman/listinfo/risks
Alternatively, to subscribe or unsubscribe via e-mail to mailman your
FROM: address, send a message to
risks-request@private
containing only the one-word text subscribe or unsubscribe. You may
also specify a different receiving address: subscribe address= ... .
You may short-circuit that process by sending directly to either
risks-subscribe@private or risks-unsubscribe@private
depending on which action is to be taken.
Subscription and unsubscription requests require that you reply to a
confirmation message sent to the subscribing mail address. Instructions
are included in the confirmation message. Each issue of RISKS that you
receive contains information on how to post, unsubscribe, etc.
INFO [for unabridged version of RISKS information]
.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.
*** NOTE: 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 24.07
************************
This archive was generated by hypermail 2.1.3 : Thu Oct 13 2005 - 17:01:44 PDT