[1479] in RISKS Forum
Risks Digest 20.48
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Thu Jul 15 18:20:54 1999
From: RISKS List Owner <risko@csl.sri.com>
Date: Thu, 15 Jul 99 15:18:46 PDT
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Thursday 15 July 1999 Volume 20 : Issue 48
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.48.html>
and at ftp.sri.com/risks/ .
Contents:
London Underground sequence rollover (Lloyd Wood)
Software disaster leaves new Australian submarine unfit (Quentin David Jones)
Computer glitch causes severe train delays in Melbourne (Stuart Lamble)
Medical paper retracted following discovery of programming error (John Doyle)
Life-threatening flaw in implantable cardioverter-defibrillator (John Doyle)
Potentially life-threatening medical equipment failure (John Doyle)
Toyota smog-warning computer suit (Taz Daughtrey)
Financial Engines: Should I jump off the bridge or live it up? (Susan Gerhart)
Cancelling errors, serendipity in avoiding risks, and Kepler (Henry Baker)
Traffic signals going all-green (Jeff and Glenn Grigg)
Privacy statement risk, quoted without comment (Andrew Koenig)
Re: Garciaparricide in All-Star balloting? (David Cassell)
Re: Space Station AOL hack (Leonard Erickson)
Re: Electronics startup transient kills spacecraft (Fernando Pereira)
Re: E-mail writer arrested for starting panic (Cameron Hayne, J.D. Abolins,
John O'Connor)
Webmail is not the same as anonymous e-mail (Scott A Crosby)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sat, 10 Jul 1999 16:49:15 +0100 (BST)
From: Lloyd Wood <L.Wood@surrey.ac.uk>
Subject: London Underground sequence rollover
Surprise! London Underground Travelcards that are at least 2 years old just
happen to work. As a result, the cards are being sold on the black market
for over 50 pounds for four-zone cards. The mag stripe information format
just happens to match, giving unlimited free rides. However, not of the all
old cards work. Estimates of fare fraud already exceed 25 million pounds a
year, just over 3 million of which is offset by 10-pound fines for misuse.
[Source: Touts cash in on old Tube Travelcards, by Dick Murray, Transport
Editor, London *Evening Standard*
http://www.yahoo.co.uk/headlines/19990709/london/newsstory154274.html]
[As usual, the suggested fix is to completely replace the system -- with a
new smart-card system. Interesting that the cards aren't specifically
tied to the calendar date, which would have prevented this. Risks lie in
costs of manual achecks to safeguard the intent of the system... Lloyd.]
<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
------------------------------
Date: Mon, 5 Jul 1999 06:53:19 +0800
From: "Quentin David Jones" <quentinj@opera.iinet.net.au>
Subject: Software disaster leaves new Australian submarine unfit
The latest (and independent) report to the Australian Gov. concerning the
problems with its new Collins class submarine project recommends the entire
combat system be scrapped and replaced with a new off-the-shelf system (at a
cost of hundreds of millions).
The McIntosh-Prescott report, released 1 Jul 1999, also notes other major
problems with the new submarines, including unreliable diesel engines,
excessive noise, cracking propellers, poor communications and periscope
vision. Deficiencies in project management and procurement were also
criticised.
The hardware issues, though serious, can be fixed -- but the software for
the combat system is considered unlikely to ever work. Currently Boeing is
working on an interim fix which is described as a "short-term band-aid"
which should provide some quick improvements, but which will not lead to a
satisfactory solution. We also have an urgent joint US/Aus. Navy project
which will spend $A 80 million to help rectify some of the key software
problems inter alia.
The major conclusion of the report however, is to completely dump the
software and start again - "A preferred new system would be configured with
less-integrated architecture and would utilise more off-the-shelf
equipment".
Note the comment "less-integrated".
The plans for the combat system called for a tightly integrated system
which instead of having dedicated stations for specific tasks (i.e. a sonar
station, a separate torpedo control station, comms station, etc.), would
have 7 general purpose workstations which could each be configured to
perform any (or all) tasks as required. At the time this ambitious plan was
rightly criticised.
Fears of cost over-runs led to an insistence on a fixed-price contract
originally signed in 1987. Computer technology advanced significantly during
the life of the project, so that many components were out-of-date by the
time they came into use.
It appears that the top brass failed to respond quickly enough to many
warning bells about the combat system.
The result is that Australia has only 1 obsolete submarine in service, and
if the problems on the Collins are not fixed quickly, may end up with no
working submarines at all for some time.
Quentin David Jones
------------------------------
Date: Mon, 12 Jul 1999 11:22:22 +1000
From: slamble@csc.com
Subject: Computer glitch causes severe train delays in Melbourne
On 8 July 1999, a glitch in a computer system caused train signals in the
area around Flinders Street Station (a major station in the central business
district of Melbourne, Australia) to fail. The glitch occurred at 5:40pm,
and was not rectified until 6:20pm -- right in the middle of peak hour. The
congestion was not completely cleared until 7pm, and even then, trains were
running up to two hours behind schedule. The glitch affected trains
traveling to and from the south-eastern and eastern suburbs (definitely
Lilydale, Belgrave, Glen Waverley, and Alamein lines; also the Hurstbridge
and Epping lines, according to the local tabloid). In addition, trains
traveling through the underground city loop to northern and western suburbs
had to be re-routed to travel direct, bypassing the loop.
There have, apparently, been other similar glitches in the past, lasting
for up to five minutes; this is (to the best of my knowledge) the first
lengthy delay, certainly in the middle of peak hour. Speaking as somebody
who was caught in a train for half an hour between Richmond and East
Richmond, I have to say that I've discovered a new swear word: "Public
Transport". :-)
Standard RISK: all the eggs in one basket, with no backup (electronic _or_
manual) in place.
Time to move closer to work and start using my bicycle, I think.
------------------------------
Date: Sat, 10 Jul 1999 12:37:24 -0400
From: "Dr D John Doyle" <djdoyle@home.com>
Subject: Medical paper retracted following discovery of programming error
The 14 Jan 1999 issue of the *New England Journal of Medicine* (arguably the
most prestigious medical journal published) contained an unusual
retraction. This time at issue was not the discovery of fraudulent research,
a nasty problem afflicting top medical journals for some time now, but the
discovery of a computer programming error in a study of suicide rates
following natural disasters. The mistake resulted in the software
erroneously counting some deaths twice.
When the data was restudied following the correction of the error, the
conclusion of the original paper was found to be incorrect. The authors
acted ethically in reporting this error and retracting their paper, despite
the embarrassment and career implications involved. How many others would
have merely kept quiet and not issued a retraction, especially knowing that
failure to weed out this misinformation would not likely result in any
patient harm (as compared to, say, an error in a dose-finding study)?
This problem also raises the issue of the role of senior clinical
investigators, most with very limited programming skills, in supervising the
efforts of the programmers that work on their research team.
REFERENCE: Krug EG, Kresnow M, Peddicord JP, Dahlberg LL, Powell KE, Crosby
AE, Annest JL Retraction of "Krug EG, Kresnow M, Peddicord JP, Dahlberg LL,
Powell KE, Crosby AE, Annest JL. Suicide after natural disasters. N Engl J
Med 1998 Feb 5;338(6):373-8 " N Engl J Med 1999 Jan 14;340(2):148-9
D. John Doyle MD PhD, Associate Professor, University of Toronto
djdoyle@home.com
------------------------------
Date: Sat, 10 Jul 1999 17:10:18 PDT
From: "John Doyle" <djdoyle@hotmail.com>
Subject: Life-threatening flaw in implantable cardioverter-defibrillator
A recent report in a medical journal describes a life-threatening event in a
70-year old man in whom an implantable cardioverter-defibrillator had been
previously placed to regulate the patient's erratic heartbeat following a
previous cardiac arrest. Unfortunately, a software malfunction in the unit
later occurred such that the patient developed an "acute onset of dizziness"
from "loss of ventricular output due to an internal software problem". The
problem was corrected by reprogramming the unit via the external programmer.
REFERENCE: Coppess MA, Miller JM, Zipes DP, Groh WJ Software error resulting
in malfunction of an implantable cardioverter defibrillator. J Cardiovasc.
Electrophysiol. 1999 Jun;10(6):871-3
D. John Doyle MD PhD, Associate Professor, University of Toronto
djdoyle@home.com
------------------------------
Date: Sat, 10 Jul 1999 17:53:07 PDT
From: "John Doyle" <djdoyle@hotmail.com>
Subject: Potentially life-threatening medical equipment failure
Patient monitors are used extensively in acute care medicine, especially
during surgical procedures or when transporting critically ill patients. In
an interesting report by two anesthesiologists a potentially
life-threatening situation is described whereby a transport monitor provided
data that did not seem to match the doctors' clinical assessment of the
patient. Among other things, the digital pressure display never varied from
120/70. Suspicious that something was wrong, the doctors rechecked
everything only to find that on close inspection of the fine print on the
transport monitor's screen the words "demo mode" appeared intermittently.
They then realized that all of the waveforms and data on the screen were
simulated! Even worse, attempts to turn off the "demo mode" failed because a
password is needed both to enter and to leave the simulation mode! The
doctors switched to another monitor. No harm came to the patient.
An investigation later revealed that "the hospital biomedical engineer had
used the internal password to place the monitor into the simulation mode for
testing, but had neglected to return it to normal patient monitoring mode
before certifying it as fit for clinical use."
The following comments from the authors are worth heeding:
"Anesthesiologists should be aware of this novel form of monitoring
"failure." . . . Obviously, human failures were involved in this incident,
but improved equipment design could have helped prevent our patient from
being exposed to the risk of not being monitored. In particular, we believe
it is inappropriate for a password to be needed to exit from an internal
simulation mode. We also recommend that manufacturers make "demo mode"
messages more obvious when a monitor is in a simulation mode by appropriate
use of text size, color, and/or brightness and by having it flash. Such
messages should be present continuously, not intermittently. A high state of
vigilance continues to be warranted, particularly around the time of patient
transport."
REFERENCE: Ramundo GB, Larach DR. A monitor with a mind of its
own. Anesthesiology 1995 Jan;82(1):317-8
D. John Doyle MD PhD, Associate Professor, University of Toronto
djdoyle@home.com
------------------------------
Date: Mon, 12 Jul 1999 22:22:11 EDT
From: Sqpeditor@aol.com
Subject: Toyota smog-warning computer suit
The Justice Department has filed a civil suit under the Clean Air Act (on
behalf of the EPA) against Toyota for faulty smog-control computers on 2.2
million 1996-1998 vehicles (Camry, Avalon, Corolla, Tercel, Paseo; Lexus;
Sienna minivans, etc.). The suit seeks repairs and fines up to $58.5
billion for faulty software that failed to detect above-threshold emissions.
California had apparently approved the systems based only on simulations.
Toyota claims the rules were altered after the initial approvals. [AP item,
12 Jul 1999, PGN-ed]
Taz Daughtrey, SOFTWARE QUALITY PROFESSIONAL, SQP_Editor@asqnet.org
------------------------------
Date: Wed, 14 Jul 1999 15:12:16 GMT
From: slger@mindspring.com (Susan Gerhart)
Subject: Financial Engines: Should I jump off the bridge or live it up?
Many financial planning articles, including a recent Jane B. Quinn Newsweek
column, tout a new retirement planning service at
http://www.financialengines.com. This operation uses risk-driven models from
co-founder Bill Sharpe, a Nobel Laureate, and is strongly VC
funded. Incorporating risk gives a probability of certain annual income with
ranges and "what-if" scenarios for various portfolio allocations. The
on-line implementation is a Java applet with portfolio data held and updated
on their server.
I put in my approximate data and ran the forecast. Amazingly, no matter how
*high* I cranked the annual income goal, e.g. $200K, the result was >95%
sunny (literally) forecast. Not real, I was sure, so I ran it on another
PC. Same data, held on their site, but this time no matter how *low* the
annual goal, e.g. $5K, the applet always gave <5%, very stormy, forecast. In
other words, complete opposite results depending upon PC (MICRON pentium-I
was more optimistic than Gateway Pentium-II, independent of
browser). FinancialEngines tech support responded quickly to the problem and
in a few days the schizophrenic forecasts settled down, apparently fixed and
downloaded. I'm still hoping for a technical explanation but haven't heard
from customer support.
Clearly the program didn't have any built-in guards against ridiculous
answers. Some people using the model might be blissfully over-spending and
others suicidal depending upon their Java/Pentium interaction. But most
users of these planners know they have to try several, examine assumptions
and models carefully, and pray.
Even well-funded Nobel Laureates have QA problems.
susan gerhart
------------------------------
Date: Mon, 12 Jul 1999 16:28:39 -0700
From: Henry Baker <hbaker@netcom.com>
Subject: Cancelling errors, serendipity in avoiding risks, and Kepler
Subtitle:
Serendipity = Error2 - Error1 ? (or
Serendipity = [Error1,Error2] using commutators!)
RISKS spends a lot of time bemoaning the negative side of errors. Perhaps
more time should be given to "serendipity" which I loosely translate as
"order from chaos". Serendipity is celebrated by authors and film-makers as
the way to find love after some disastrous mistake. But science also
proceeds in such ways.
A famous example is that of Kepler. I quote from "Fundamentals of
Astrodynamics" by Roger Bate, Donald Mueller, and Jerry White, 1971, Dover
ISBN 0-486-60061-0 (Sec 4.1, p. 178):
"Kepler's first task was to determine the radius of the circle [of the
orbit] and the direction of the axis connecting the perihelion and
aphelion. At the beginning of a whole chapter of excruciating
trial-and-error calculations, Kepler absentmindedly put down three
erroneous figures for three vital longitudes of Mars, never noticing his
error. His results, however, were nearly correct because of several
mistakes of simple arithmetic committed later in the chapter which
happened very nearly to cancel out his earlier errors.
"At the end he seemed to have achieved his goal of representing within 2
arc-minutes the position of Mars at all 10 oppositions recorded by Tycho.
But then without a word of transition, in the next two chapters Kepler
explains, almost with masochistic delight, how two other observations from
Tycho's collection did not fit: there was a discrepancy of 8 minutes of
arc. Others might have shrugged off this minor discrepancy between fact
and hypothesis [or fudged his numbers a la Newton's Moon]. It is to
Kepler's everlasting credit that he made it the basis for a complete
reformulation of astronomy. He decided that the sacred concept of
circular motion had to go. [...]
"Forgetting his earlier resolve to abandon circular motion he reasoned,
again incorrectly, that, since speed was inversely proportional to
distance, the line joining the sun (which was off-center in the circle)
and the planet swept out equal areas in the orbit in equal times.
This was his famous Second Law--discovered before the First--a law of
amazing simplicity, arrived at by a series of faulty steps which he
himself later recognized with the observation: 'But these two errors--it is
like a miracle--cancel out in the most precise manner, as I shall prove
further down.'
The correct result is even more miraculous than Kepler realized since his
explanation of why the errors cancelled was also erroneous!"
The search for the source of errors is often times hugely more valuable than
the original error. The progress of science is pretty much fueled by
errors. How many times have you searched for a minor bug and in the process
of correcting it fixed a major bug? (I seem to recall that David Moon, ex
of Symbolics and Apple, used to call these "dead bears", probably having
something to do with letting sleeping and/or dead bears alone.)
Henry Baker
------------------------------
Date: Tue, 13 Jul 1999 09:04:32 -0500
From: Jeff Grigg <jeff@michelob.wustl.edu>
Subject: Traffic signals going all-green
I noted the old RISKS postings in the archive about traffic signals going
"all green," allowing conflicting traffic:
RISKS-18.94:
Traffic signals, red-runners & all-greens (J. DeBert)
RISKS-18.95:
Re: all-ways green lights (Robert Miller, Sean Ercanbrack, Barak Pearlmutter)
RISKS-19.01:
Re: all-ways green lights (Mark Brader, Steve Summit, Dik T. Winter)
RISKS-19.03:
All-ways green lights ... it's all in the timing (Richard Cook)
So, I thought to ask my uncle, a recently retired traffic consultant living
in the San Francisco area. This is his response:
>From: Glenn Grigg [SMTP:glennmg@juno.com]
Date: 25 June 1999
Subject: Re: "all-green" on traffic lights
First of all let me tell you, after a collision at an intersection, [...]
they ALL say [they had a green light]! Now, lets talk chips and
software. The modern traffic signal controller IS software driven, however,
they are rather simple machines with "if this, do that, but not the other"
kinds of decisions to make. Bugs? Maybe, but I've never seen conflicting
greens due to controller software! I have seen wires get crossed, like when
someone knocks a signal pole down and the insulation on the wires get
stripped.
NOW, let me tell you about the conflict monitor. This is a device that is
connected to the field wires at the terminals where the 110v AC wires go
from the cabinet directly to the light bulbs that illuminate the signal
faces. This device does NOT monitor the controller or its software, it
monitors the 110v AC lines. If a software bug were to direct the load
switches close and send 110v AC to green signal faces that face conflicting
traffic, this monitor would detect this conflict and put the intersection on
flash. Do conflict monitors fail? Are they made by Humans? That's why we
test our conflict monitors on a regular basis. Well, how do we do this? The
sophisticated way is to bring it in the shop and hook it up to a special
monitor tester. However, there is a simple way to do this in the field. You
take a short piece of wire, preferably insulated, and you stick one end in
the 110v AC terminal of any green indication wire. With the other end, you
stick it to any other green indication terminal. You have 110v AC in your
hands, that's why I use an insulated wire. When you stick it on a
conflicting green terminal the monitor will "trip" and the intersection will
go immediately to flashing. DON'T do this during the rush hour! You'll be
getting off lightly if people only curse at you!
Glenn
------------------------------
Date: Tue, 13 Jul 1999 15:44:25 -0400 (EDT)
From: Andrew Koenig <ark@research.att.com>
Subject: Privacy statement risk, quoted without comment
From a website's privacy statement:
Children 12 years of age and younger are not permitted to opt in
for these future e-mailings because the opt-in software requires
users to fill in their age and only users above 12 years of age
are able to submit opt-in authorizations.
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark
------------------------------
Date: Sat, 10 Jul 1999 15:03:45 -0700
From: David Cassell <cassell@mercury.cor.epa.gov>
Subject: Re: Garciaparricide in All-Star balloting? (RISKS-20.47)
The Chris Nandor who deluged the All-Star ballot site with 22,000-some votes
for the Red Sox shortstop is not only a huge Red Sox fan [no kidding - his
e-mail handle is 'pudge' for Carlton Fisk], but also a known Perlite. He is
the Chris Nandor who co-wrote "MacPerl: Power and Ease" with Vicki Brown.
He merely used the LWP::Simple module with a few lines of Perl code to
produce his anti-Jeter machine. He clearly didn't try to obscure his
identity. It would have been trivial for him to spoof his e-mail address,
as well as generating random valid numbers for phone number and zip code.
Given this thought, one has to wonder how many people actually made the
effort to conceal the fact that they were making multiple votes. I see a
major-league RISK just around the corner for the All-Star voting site. What
happens when someone makes the effort mentioned above and dumps 500,000
votes in on the last day to get their favorite player(s) in?
In 1957, the Cincy fans did such a good job of ballot-stuffing that the
commissioner had to step in and hand-select other players to start. The
names of some of the players who had been pushed out? Oh, no one big, just
Musial, Aaron, Mays, ... Now it will only take one person and a 40-line
Perl script to do the same thing.
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist, mathematical statistician
------------------------------
Date: Sun, 11 Jul 1999 00:02:36 PST
From: shadow@krypton.rain.com (Leonard Erickson)
Subject: Re: Space Station AOL hack (Passy, RISKS-20.47)
> Similar to problems AOL has had, it seems that someone, most likely
> someone involved with the ISS program, obtained the name of a user with
> administrator access, then called the help desk and asked for a password
> reset. They were promptly given that new password, after which they
> proceeded to do something objectionable with the password file. (That
> part's still not quite been released.)
Argggh!
I know I'm preaching to the choir here, but when I've been administering a
system, the policy was that to get a new password, you did one of three
things:
1. Show up at my desk and have my hand you the new password.
2. Call me *directly*. This was *only* allowed for people I could
recognize over the phone.
3. Call or e-mail me, and the new password would go out via internal
*physical* mail sealed inside a use once envelope wit CONFIDENTIAL
on it in large letters.
At one time we allowed people to informally request accounts & passwords for
people working under them. This was stopped after someone slipped in a
request for an account for "John Tuttle" (M*A*S*H reference) into the
system. They then posted some inappropriate messages to the internal e-mail
system.
After that, we went *strictly* formal on new account requests.
> [... PIN for resets ...]
Yeah. Some folks just don't get it. :-(
Leonard Erickson (aka Shadow) shadow@krypton.rain.com
------------------------------
Date: Sat, 10 Jul 1999 20:16:18 -0400
From: Fernando Pereira <pereira@research.att.com>
Subject: Re: Electronics startup transient kills spacecraft (RISKS-20.47)
> [...] leaving the circuit in a non-deterministic state [...]
A question for those who know about such things: is current education in
digital circuit design sufficiently attuned to the subtleties of the
physical world, or do students have an overly simplistic view of how bits
are represented in hardware? Given the deterioration of continuous math
education in high school and universities, I wonder...
------------------------------
Date: Sat, 10 Jul 1999 14:23:03 -0400
From: "Cameron Hayne" <hayne@crim.ca>
Subject: Re: E-mail writer arrested for starting panic (RISKS-20.47)
> 2. Since Hotmail accounts are notoriously anonymous, how was this tracked
> back to him so that he could be arrested?
> [Anonymity is generally only a relative concept. Who pays the bills? PGN]
You don't seem to know that Hotmail accounts are free, hence truly
anonymous.
Cameron Hayne (hayne@crim.ca), Centre de recherche informatique de Montreal
------------------------------
Date: Sat, 10 Jul 1999 17:05:10 -0700 (PDT)
From: "J.D. Abolins" <jda-ir@njcc.com>
Subject: Re: E-mail writer arrested for starting panic (Todd, RISKS-20.47)
Couple of comments regarding this interesting item...
1. Hotmail and many other Web-based e-mail accounts aren't really anonymous.
They can be pseudonymous in that the user can choose whatever handle and
registration info he may want. It is not unique. There are other Internet
access resources where identity is not particularly verified. Sounds like
end of all accountability but it isn't. There are still many clues available
if an incident draws enough attention.
2. Many Web-based e-mail services do give some useful clues in their e-mail's
headers. The most useful is the IP address of the system from which the
e-mail was submitted via HTTP. I have used this to trace a series of e-mail
harassment using Hotmail.com. A form of whois lookup can provide the info
for who has the set of IP addresses that include the one listed in the
header. The owner of the IP address can be contacted and they can use their
logs to find out whose account was used. That is probably what happened in
this e-mail panic case.
J.D. Abolins
------------------------------
Date: Mon, 12 Jul 1999 02:43:33 PDT
From: "John O'Connor" <jp0c@hotmail.com>
Subject: Re: E-mail writer arrested for starting panic (Todd, RISKS-20.47)
Every e-mail sent out from the hotmail system carries, in the e-mail
headers, the IP address of the machine hosting the web browser used to
compose the message.
This is another risk, isn't it. The risk of assuming that a system is
anonymous just because it is notoriously anonymous. :-)
Get Your Private, Free E-Mail at http://www.hotmail.com
------------------------------
Date: Sun, 11 Jul 1999 00:48:25 -0400 (EDT)
From: Scott A Crosby <crosby@qwes.math.cmu.edu>
Subject: Webmail is not the same as anonymous e-mail.
I've been using a trick to identify abusers who used hotmail already. And
the recent Risks article: 'E-mail writer arrested for starting panic' showed
that this trick isn't as well known as I thought.
Many webmail providers I have seen tend to introduce interesting headers
into e-mail sent by them. For example, hotmail appends the following header
to outgoing e-mail. Past this, identification is trivial.
X-Originating-IP: [206.47.244.30]
Regardless of whether or not the webmail provider actually appends such a
header, they are very likely to log e-mails anyways. Thus it is very easy
for legal or political pressure to grab the logs and identify the user.
So perhaps the risk here is that people have been thinking that webmail
means anonymous e-mail.. It doesn't.
The most reliable way I can find to truly send e-mail anonymously is
through the anonymous e-mailer network. (Or maybe a mixmaster network).
If you wish to also get responses anonymously, supply a reply-block that
sends responses through a web-forwarder service dumping into a webmail
dropbox. Then access the dropbox through onion-routing.
Scott
------------------------------
Date: 23 Sep 1998 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: Abridged info on RISKS (comp.risks)
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Alternatively, via majordomo,
SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
INFO [for unabridged version of RISKS information]
.MIL users should contact <risks-request@pica.army.mil> (Dennis Rears).
.UK users should contact <Lindsay.Marshall@newcastle.ac.uk>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
[volume-summary issues are in risks-*.00]
[back volumes have their own subdirectories, e.g., "cd 19" for volume 19]
or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
PostScript copy of PGN's comprehensive historical summary of one liners:
illustrative.PS at ftp.sri.com/risks .
------------------------------
End of RISKS-FORUM Digest 20.48
************************
