[1219] in RISKS Forum
RISKS DIGEST 17.94
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Mon Mar 25 20:33:52 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Mon, 25 Mar 96 17:32:24 PST
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Monday 25 March 1996 Volume 17 : Issue 94
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. *****
Contents:
Technology "deterioration" (Lauren Weinstein)
Someone may steal your life! (Ka-Ping Yee)
The risks of misquoting/mispointing on the Web (Thomas H. Slone)
The risks of too-smart printers (Dwight Brown)
An uncertainty principle for risks (Dick Mills)
Lemmings -- Re: Java/JavaScript woes (A. Padgett Peterson)
Comments on Netscape, list-bombing, another attack (Fred Cohen)
Re: More on list-bombing (A. Padgett Peterson, Frederick Roeber,
Leonard Erickson)
Free spam-cancelling shell scripts (Fred Cohen)
Re: Jury duty (Shannon Nelson, Paul Franklin, Dorothy Klein)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sun, 24 Mar 96 16:49 PST
From: lauren@vortex.com (Lauren Weinstein)
Subject: Technology "deterioration"
The example of answering machines that can be easily "talked-off" by speech
is but one case of a broader category -- which I'll call "technology
deterioration". It's not that the proper techniques for avoiding DTMF
(Touch-Tone) talk-off haven't been designed (when's the last time you
talked-off a dialtone on a central-office switch?), but rather that many
inexpensive devices don't bother implementing all of the specs for proper
performance. Many answering machines also provide a wide selection of other
implementation deficiencies as well, including the frequent use of two-digit
security codes, and often a total lack of incorrect entry lockouts, making
"exhaustive" search trivial.
The same sorts of problems can be found in a wide spectrum of devices, from
computer keyboards to automobiles. In many (perhaps most) cases, the root
cause is simply the desire to cut production costs. But there is evidence
that in a significant number of cases the designers simply didn't know
better. To the extent that the NIH ("Not Invented Here") philosophy
prevails around the world, this is an easily observed phenomenon.
What's of particular concern is how the results of these attitudes can
impact devices and systems with significant RISKs associated with their use.
--Lauren-- http://www.vortex.com
------------------------------
Date: Fri, 22 Mar 1996 20:13:30 -0500
From: Ka-Ping Yee <kryee@novice.uwaterloo.ca>
Subject: Someone may steal your life!
A possible RISK of placing your own personal information on the WWW?
Today, I received a message from a concerned person (anonymized through
the anonymous forwarding service in Finland).
> Are you member of Waterloo's three-person team
> took first place at the East-Central Regionals [1995]
> in ACM Programming Contest?
[...]
> If so, I think you may be feel a little bit upset after looking at this:
> http://www.undergrad.math.uwaterloo.ca/~ecstsui/resume.html
[...]
> I noticed his resume was like this since early February;
> the first time it was copied verbatim; now, about 2 months later, it's
> not, but it's even more misleading than the first one, since he mixed
> his own information with your information.
If you dare to compare, the original is at:
http://www.csclub.uwaterloo.ca/~kryee/resume.html
I had posted my resume on the WWW hoping to be able to provide convenient
information for interested people and potential employers; while I
imagined it feasible for someone else to imitate the style I used, I had
no idea that someone would be so brazen as to copy the entire thing.
It shocked me that this had actually been happening on my very own site
for over a month! Occasionally I use the search engines to check for my
name to find other people's references to me, but since there is no
mention of my name in ecstsui's document, it never showed up.
Beware -- someone may steal your life!
(I did not previously have explicit copyright notices on my pages, but I
added them today. While they may make little legal difference because
copyright is automatic, they may help to deter this sort of incident.)
Ping (Ka-Ping Yee): 3A Computer Engineering, University of Waterloo, Canada
CWSF 89 90 92; LIYSF 90 91; Shad Valley 92; DOE 93; IMO 91 93; ACMICPC 94 96
------------------------------
Date: 25 Mar 1996 21:33:57 GMT
From: tom@potency.berkeley.edu (Thomas H. Slone)
Subject: The risks of misquoting/mispointing on the Web
Greg Campbell wrote a cover story for the Boulder (Colorado) Weekly on
the city's sale of its sewage sludge as fertilizer
(http://www.earthnet.net/~altnews/012596/cover.html). The article
quotes EPA toxicologist Suzanne Wuerthele:
"We don't understand fully at what point individual people will
be at risk," she says. "Theoretically, for any carcinogen,
there are no safe limits. ... One or two asbestos fibers could
do it (cause cancer)." [ellipsis is Campbell's]
The word "carcinogen" in the above quote is a link to our Web site, The
Carcinogenic Potency Database Project (http://potency.berkeley.edu/cpdb.html);
we are unaffiliated with Suzanne Wuerthele. The information at our site, if
anything, would cause one to doubt the veracity of her statement.
Misquoting or misattribution is not unusual in newspapers. The widespread
availability of newspapers on the Web potentially facilitates the ability to
see where one is being quoted and how it's being done (a risk for the
reporter).
Those who are not versed in the technology or who are not diligently Web
browsing can be misquoted without their knowledge. This is true for
hard-copy too -- people don't always know where they're being (mis)quoted
unless it's in a periodical that they happen to read.
The fact that our Web site was being pointed to by the Boulder Weekly
was discovered using an AltaVista advanced query
(http://www.altavista.digital.com/cgi-bin/query?pg=aq&what=web) on the
following:
link:potency.berkeley.edu and not url:potency.berkeley.edu
tom@potency.berkeley.edu
------------------------------
Date: Thu, 21 Mar 1996 21:35:37 -0600
From: stainles@bga.com (Dwight Brown)
Subject: The risks of too-smart printers
My organization has to print and mail several thousand postcards every
working day, so we want to get the best postage rates we can. This means not
only sorting by zip code, but adding a full ZIP+4 whenever possible, and
printing postal barcodes (Delivery Point Bar Code, or DPBC, as the post
office calls it) on the cards. The program that generates the postcards is
custom written by an outside group, but we use standard software (Postware
Presort) to do zip code presorting and get the ZIP+4 information on the
cards, and a standard printer (Mannesman Tally MT691) to print the cards
(including the barcodes).
We've been doing this for quite a while, without major problems, until one
day a few weeks ago when the Post Office rejected our outgoing postcards
because "the barcode had too many bars". This caused us a great deal of
concern. (Several thousand postcards a day, with us paying about $.02 extra
postage per card, can really add up.) So, for the past few weeks, our
outside group has been working with us to try and figure out what the
problem was. Yesterday, everything clicked.
The standard for DPBC is one start bar, then five bars per digit, and one
stop bar. The digits in a DPBC are: the ZIP+4 (9 digits), two digits from
the street address, and a "correction digit" (for a total of 62 bars). We
had configured our zip code package to automatically figure out the
"correction digit", and were inserting the correction digit on the
postcards after the street address and zip code data.
The MT691 printer has POSTNET barcoding (for DPBC) built-in. All you have to
do is send it a control code to turn on POSTNET barcoding, send it the data
you want barcoded, and a control code to turn off POSTNET barcoding, and it
will print nice POSTNET barcodes on your forms. Which is what we were doing.
It turns out that the MT691 has a nice feature: in POSTNET barcode mode, it
*automatically* calculates the correction digit for you. So we were sending
it data that included an already calculated correction digit, and the
printer was calculating a correction digit based on the data it was being
sent...and adding an extra spurious correction digit.
It also turns out that this behavior is documented *nowhere* in the manual.
The moral? As Tom Clancy said, "You can't even trust the manual." (Or, for
that matter, the Post Office, which took a year and half to notice this
problem.)
Dwight Brown, Texas Automobile Insurance Plan Association
------------------------------
Date: Thu, 21 Mar 1996 06:02:44 -0500
From: rj.mills@pti-us.com (Dick Mills)
Subject: An uncertainty principle for risks
The radio in my car displays either time of day or the tuned frequency.
After changing channels, it automatically shows the frequency for 10
seconds, then reverts to time. There is also a button to manually toggle
display modes. Yesterday I happened to press the button to view time
precisely 10 seconds after changing channels. My action canceled the
automatic action thus causing a result opposite to my intention.
Unfortunate timing deprived me of visual feedback of what happened. Most
people would blame the radio for misbehaving.
I tried to think of a way to redesign the toggle and automatic functions to
be infallible. I couldn't. This made me despair. If we can't make such a
mundane device behave perfectly, what can we achieve?
Soon thereafter, I read Mr. Cross' article in CPD 17.91. He discussed
inadvertent activation of a machine and continued to say:
>It is possible to say that we have advanced to such a point in so
>many areas that seemingly innocuous things in one (such as a track of
>music on a CD) can trigger *very* unexpected results in another.
This made me wonder where the *real* complexity limit lies. The boundary
between reliable expected behavior and the risk of unexpected behavior. I
concluded that it lies somewhere between a simple inanimate object like a
knife, and a folding knife. A simple knife doesn't *do* anything, we do
things to it. It has no behavior. A folding knife will, some day, fold
unexpectedly and someone will blame the knife. This leads to the seemingly
obvious result:
Any object, capable of any behavior, is capable of unexpected behavior.
Disregard of this simple principle is the root cause of all other risks.
It could be an alternative way to define the *meaning* of the word risk.
Dick Mills +1(518)395-5154 O- http://www.pti-us.com
AKA dmills@albany.net http://www.albany.net/~dmills
------------------------------
Date: Sun, 24 Mar 96 20:24:11 -0500
From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Subject: Lemmings -- Re: Java/JavaScript woes
I keep seeing all of these scary postings about netscape, but few point out
that Netscape 2.0 and 2.01 do not support Java on Windows 3.x and Macintosh
platforms at all. Further with 2.01, in addition to curing the two
problems, you can turn JavaScript off (Options/Security).
Do you suppose that in the future, when warnings are posted for such
cross-platform applications that the poster could specify *which* platforms
are affected? Padgett [Excellent idea. Thanks. PGN]
------------------------------
Date: Sun, 24 Mar 1996 17:25:22 -0500 (EST)
From: fc@all.net (Fred Cohen)
Subject: Comments on Netscape, list-bombing, another attack (RISKS-17.93)
>Java/Netscape security flaw (Ed Felten):
Indeed there is a more basic flaw in the URLs used in the Internet that
appears to make firewalls very weak prey for attackers and enables Web
sites to launch highly distributed and hard-to-trace attacks. The basic
flaw was published some weeks ago (e.g., gopher://localhost:79/0 for
example) and extensions have now been used to launch probes and attacks
by the thousands from sites all over the net. For more details, see:
http://all.net/ -> Incident at all.net
> More on list-bombing (Phil Agre):
A discussion of list spams has been started on the LACC@suburbia.net
mailing list. The ideas presented to date include:
* E-mail spams can be eliminated by refusing large-volume e-mail
from unknown senders. Whenever e-mail arrives from a new sender,
the user is told about it, and further e-mail from the same
sender is refused until and unless the recipient signals the
system to allow ongoing e-mail from that source. (At least one
such mailer exists today.)
* E-mail receivers can be rigged to refuse e-mail from known lists
unless specifically configured to allow it by the user (or in
the alternative, configured to allow mail unless specified to
not be received from a list of sites/users). The problem with
this is maintaining a good list of lists. (I know of one mailer
that does this as well.)
* Automated e-mail spams can also be prevented by sending back a
"user ID" to the sender of e-mail which must be used in subsequent
communications. (This is unlikely to be effective.)
* Mailing lists could eliminate their use in signup spams rather
easily. Instead of the single signon protocol they use now,
they could send a confirmation e-mail containing a unique
identifying string to the proposed list member. The new member
would have to reply before being added to this list. This would
be a simple and effective method of limiting e-mail spams to one
notification per list. (This would work, but would require fixes
for the common mailing list handlers.)
* For the techies among us, there is always the extensive use of
digital signatures. If every e-mail were signed, we could
authenticate sources before allowing them to post to lists, and
trace them back to their sources. (Unlikely to happen soon.)
Then there is the moderated list. Notice that the RISKS list
has never been spammed. (Although perhaps a few users have been
spammed by getting signed up, I doubt if they have been
negatively impacted.)
[Fred, the USENET readers of comp.risks were spammed recently,
along with many other USENET groups, but our direct-mail
subscribers never saw it, and I know about it only because
several folks forwarded it to me! PGN]
All lists should include details on how to sign off the list in
each mailing.
Finally, an optional X-Mailing-List header for mail to allow lists
to be easily differentiated and identified. (Again requires
participation by all list owners but could work.)
-> See: Info-Sec Heaven at URL http://all.net/
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
[Fred's fourth bulleted item was also suggested by
Rick Russell <rickr@is.rice.edu>,
hien@ncddenver.ncd.com (Hien D. Ngo), and
przemek@rrdjazz.nist.gov (Przemek Klosowski).
Rick added a little more discussion (but not markedly different from
others), and Przemek suggested checking out an item by Don Libes,
(http://www.cme.nist.gov/pub/msid/pubs/libes96b.ps). PGN]
------------------------------
Date: Sun, 24 Mar 96 19:45:03 -0500
From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Subject: Re: More on list-bombing (Agre, RISKS-17.93)
A couple of years ago I posted some information on forged e-mail and the
fact that the header almost always contains sufficient information to
determine if the message is bogus. For instance examination of the
"Received: from" lines in the header is generally sufficient to raise
doubts.
The problem is that e-mail is essentially sent "blind" and unlike
interactive sessions encourages "fire and forget". Further RFC821 makes it
clear that the information sent by the mailer such as the "Reply" entry was
intentionally made user configurable ("isn't a bug, it's a feature").
In normal messaging this is not a problem however I have seen several
newsgroups which routinely generate over a hundred messages a day.
To me, the simplest possible mechanism would be to require confirmation
with a unique message. I suspect that few will be willing to go to this
length so have a fallback: if the subscribing message was "Received: from"
a domain other than that of the apparent requestor, then require confirmation.
Padgett
------------------------------
Date: Mon, 25 Mar 1996 09:58:27 GMT
From: roeber@iea.com (Frederick Roeber)
Subject: Re: More on list-bombing (Re: RISKS-17.93 and RISKS-17.83)
Perhaps the simple solutions of a simpler world just aren't applicable in
the new, now-massively-popular internet. Many protocols on the net -- from
e-mail to usenet to more basic routing issues, all familiar to RISKS -- are
based in trust. When the net was small, trust worked; now, I have my
doubts.
A couple years ago I proposed a new system to the team at CERN that created
the WWW. I won't bore everyone with the details, but basically 1)
discussion forums existed on an invisibly sliding scale between a
single-host web-annotations to a network-wide usenet group; and 2) user
access varied on a scale between completely-user-initiated "browsing"
through user-merely-notified "newsreading" to sent-to-the-user "mailing
lists."
However, the user interaction was with the local newshost, which then if
necessary dealt with remote servers. All articles, digests, summaries, etc.
that are mailed to a user are sent by that users' local newshost -- which
incidentally gives the user one central control point. (It also completely
automates mirroring and caching, which was my original aim.)
This certainly won't stop anyone from sending bogus mail. But it would be
more difficult to illicitly subscribe someone to a mailing list, and it
would be much easier for the user to clean up the problem.
Frederick Roeber roeber@iea.com | roeber@cern.ch
------------------------------
Date: Mon, 25 Mar 96 02:15:34 PST
From: shadow@krypton.rain.com (Leonard Erickson)
Subject: Re: More on list-bombing
Fidonet suffered *massive* list-bombing attacks on dislike administrators a
couple of months back. What made this worse than the usually list-bombing is
that once the mail entered the Fidonet,org domain, it was transported via
dial-up Fidonet connections, not via the Internet.
This resulted in effective denial of service attacks, as as some of the
systems couldn't handle the traffic levels, and even where they could,
trying to find legitimate mail was difficult when it was mixed into the list
traffic.
This was aggravated due to a couple of design "features" of Fidonet. Most
Fidonet nets (the .nxxx level in the addresses) don't have a local
fidonet<>Internet gateway system. So traffic for
user@f111.n222.z1.fidonet.org all went to the default gateway. That system
then stuck it into the low-priority routed mail system rather than wasting
his money dialing direct all over North America. The routing system is
hierarchical, so lots of nodes got *really* jammed by this. Even nets with
local gateways still had that poor gateway system trying to make phone calls
to the recipients.
This sort of thing wasn't anticipated, except that policy was that the
gateways were *not* to be used for mailing lists. The end result was that on
March 1st, the default gateway was discontinued. Now, only fidonet nets with
explicit MX records are reachable.
Gateway operators are *still* getting huge amounts of list traffic,
much of it aimed at addresses that have *never* existed. This has
apparently been an organized attack by some party, and it is at least
successful to the extent that it annoys the gate-ops.
My advice to list maintainers is to lock out *all* addresses in the
fidonet.org domain, and if you get complaints, check to see which system the
MX record points at and ask the postmaster there if he allows list traffic
through his system. Nine times out of ten the answer will be along the lines
of "Hell, no!". And you can then report to the complainer that he is
violating the rules under which the gateway operates.
If you get a yes response from a gate-op, great. Just remember to check
occasionally to see that the gateway system hasn't changed.
It's a pity that things are like this, but too many people are abusing what
was meant to be a conduit for low-volume *personal* mail. <sigh>
Leonard Erickson (aka Shadow) shadow@krypton.rain.com
leonard@qiclab.scn.rain.com <--last resort
------------------------------
Date: Mon, 25 Mar 1996 16:54:02 -0600 (CST)
From: Rick Russell <rickr@is.rice.edu>
Subject: Re: More on list-bombing (Agre, RISKS 17.93)
It's just as easy to forge e-mail from a mainframe as from a personal
computer (*). The basic problem is not simply on the client side; it's on
both sides. The mail client and mail server must implement a system that
confirms and records the identity (insofar as it can be determined) of the
mail sender, and _rejects e-mail for which the identity cannot be
confirmed_. Further, the system would have to have wide implementation, or
the malicious e-mail sender could just find a non-authenticating server to
his or her e-mail.
As usual, the price of security is convenience; such a system would be
substantially more complex than the common SMTP protocol we have now, and
would require software changes on both the client and server sides. For
safety in a lab or office environment, it might also require that users
enter a confirmation password each and every time they send e-mail, although
Kerberos-style authentication tickets can be used to get around that problem
to a limited extent.
(*) Admittedly, using a password-authenticated system for the forgery
provides a better record of what transpired, leaving the miscreant open to
capture. But what if the miscreant were to send e-mail via an open SMTP
server in, say, Singapore? I would imagine that getting a sysadmin in a
distant country to give you his or her system logs would be awfully difficult.
Rick R.
------------------------------
Date: Mon, 25 Mar 1996 10:31:04 -0500 (EST)
From: fc@all.net (Fred Cohen)
Subject: Free spam-cancelling shell scripts
To assist in those who need to cancel spams, we have set up a free
(donations accepted) spam-cancelling capability on the all.net Web site.
We considered handing out a convenient shell script along with the list of
over 10,000 mailing lists we are now able to cancel subscriptions to, but we
decided this might add to spams instead of eliminating them.
Instead, we opted to have the user provide the site name and we provide a
shell script to unsubscribe from the lists coming from that site.
For full details, use: http://all.net/ and look under CanSpam.
-> See: Info-Sec Heaven at URL http://all.net/
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
[Can spam attacks be stopped?
Canned spam controls would be of interest to Monty Python. PGN]
------------------------------
Date: Fri, 22 Mar 1996 13:30:13 -0800
From: Shannon Nelson <shannon_nelson@ccm.ra.intel.com>
Subject: Re: Jury duty (RISKS-17.91,92)
Another pool used in Oregon is the list of registered car owners. This,
combined with a zip code that overlaps two counties, got me a Jury Duty
summons for Multnomah county while I live in Washington county. Of course,
the Department of Motor Vehicles representative had trouble fixing our
record because the computer "knew" that our zip code was a Mult. Co.
zip. As it turns out, probably everyone in our zip code in Wash Co. has
this problem but doesn't know it yet. And no, the DMV would not change us
all - they told us that each person has to call in individually. They
didn't want to hear from a Wash. Co. official requesting a blanket change.
Risks (in any order):
1. Computers that can't deal with humanity's political deviances (zip
boundary not matching county boundary)
2. Stubborn bureaucratic clones that won't take the 'risk' to fix the system
3. Bad information propagating from one system to another
4. Licensing tax money going to the wrong county
5. probably more...
Shannon Nelson Portland Technology Development, Intel Corp.
snelson@ptd.intel.com (503) 642-8149
------------------------------
Date: 23 Mar 1996 15:06:06 -0800
From: Paul Franklin <paul@cs.washington.edu>
Subject: Re: Jury duty (RISKS-17.91,92)
In most (all?) states, whatever agency issues drivers' licenses also issues
official ID cards for people who aren't eligible to drive or don't wish to.
For people who don't wish to drive, or for children who look several years
older/younger than they are, these cards are a necessity for things such as
writing checks, watching movies with their peers, etc.
If Emily had a state-issued ID card, it doesn't take much imagination to
figure out why she got called. One might try to fault a computer. But the
real risks are nothing new:
* politicians (or others) not thinking through what they do
* people trying to blame the computer
--Paul
------------------------------
Date: Sun, 24 Mar 1996 13:02:23 -0500 (EST)
From: Dorothy Klein <dklein@pluto.njcc.com>
Subject: Re: Jury duty
Jury summoning and selection procedures are set by New Jersey state law.
New Jersey has recently greatly expanded the lists from which jury duty
lists may be composed. Three were concerns about non-representative juries
in some urban counties, and claims that the expanded lists would add 30%
more bodies to the jury pool. The new state law also ended the exemption
for police officers and other professions. (Like a cop wouldn't be
challenged right off a jury -- what a waste of time!)
The youthful juror problem is occurring because just about any official
contact with the state government now gets you onto the jury list. Little
Emily's case is only one of several, but hers came to public attention
because her parents are lawyers and pointed out the idiocy publicly. It
seems Emily had to file a state income tax return, probably for interest
income, and got onto the massive jury list that way.
[Above info as I remember it being reported in the Star-Ledger last Sunday
-- any errors are mine.]
One wonders how well the new expanded jury lists have been winnowed. I can
see an active citizen, who drives, owns property, files taxes, has wages
reported, votes, etc., being present on the list many times. It seems to me
that this would lead to a non-representative jury pool, biased toward people
with multiple jobs and owning property.
While a NJ juror is now exempt for three years after actually serving,
certain counties in NJ are notorious for summoning large pools, then
excusing most of them because the court-load is not what was expected. I
for one am sick of turning my planned work schedule upside-down, then
calling the juror tape on the morning of my first day and finding I'm
excused, then 9-12 months later, going through the whole process again
because I haven't actually _served_. I had the honor of receiving two jury
summonses in the same month, so I am already unimpressed with Middlesex
county's juror data handling skills, and that was _before_ the new law, when
only voter and driver registrations were used. The juror questionnaire asks
for SSN, but utterly lacks a privacy act statement, showing just how "up" on
data issues this county is.
I'm betting that Emily's parents will be making more "Please excuse my child
from jury duty" calls to the courthouse before she's 18. After all, every
year she'll file a tax return, and get back onto the jury summons list.
Aside from pointing out the problems of using data collected for one purpose
for an unrelated purpose, the new juror selection lists and criteria risk
further annoying citizens of this state.
Dorothy Klein dklein@pluto.njcc.com
[If you wonder why all these messages made it into RISKS, it might be
once again to illustrate how difficult it is for bureaucracies to deal
with regulations and procedures -- let alone computers! PGN]
------------------------------
Date: 18 March 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.
Particularly relevant contributions may be adapted for the RISKS sections
of issues of ACM SIGSOFT Software Engineering Notes or SIGSAC Review.
* Submissions: By submitting an item that is accepted for publication
in RISKS, the author grants permission for unlimited public distribution
and redistribution in electronic or other form.
* Reuse: Blanket permission is hereby granted for reuse of all materials
in RISKS, under the following conditions. All redistributed items must
include the Risks-Forum masthead line. All reuse must be accompanied by
the following statement:
Reused without explicit authorization under blanket permission
granted for all Risks-Forum Digest materials. The author(s), the
RISKS moderator, and the ACM have no connection with this reuse.
As a courtesy, reusers of individual items (as opposed to forwardings of
entire issues) should notify the authors, and should pay particular
attention to any subsequent corrections.
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
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
get illustrative.PS
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.94
************************
