[1214] in RISKS Forum
RISKS DIGEST 17.89
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Tue Mar 12 22:47:03 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Tue, 12 Mar 96 19:46:08 PST
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Tuesday 12 March 1996 Volume 17 : Issue 89
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. *****
***** THAT LAST ITEM HAS BEEN MODIFIED. PLEASE REREAD IT CAREFULLY. *****
Contents: [Thanks for all the e-mail! Perhaps we can slow down a little?]
Graduate Record Examination screwup (George Janczyn)
"What's new" in web pages is not necessarily reliable (Mordechai T. Abzug)
Digital Flight Control Systems help the U.S. Navy (Peter Ladkin)
Re: CIA & NSA run remailers (Jim Thompson)
Re: Rail safety controlled by satellite (Don Root)
Re: bleep-year (Bear Giles)
Re: UNIX struct tm (Keith Neufeld)
Re: COBOL Dates (Owen Leibman)
Re: Teen `convicted' by computer (Richard Cox, Phil Herring)
Lotto computer errors (Tim Pietzcker)
Risks of automatically publishing Risks newsletter to the Web! (Jennifer Hunt)
Re: Netscape's too-lenient syntax checking (Jonathan Kamens,
A. Padgett Peterson, Eric Tilton, Torrey McMahon)
Re: Yet another Trojan horse in Netscape 2.0 (David Wood, Stanton McCandlish,
Jon Reeves, John Mainwaring)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 12 Mar 1996 08:19:11 -0800 (PST)
From: George Janczyn <gjanczyn@oclcgate.ucsd.edu>
Subject: Graduate Record Examination screwup
An acquaintance of mine who is visiting from Russia was in Boston a few
weeks ago to take the Graduate Record Examination. The examination is taken
solely on a computer. No doubt you can see what is coming.
When the computer display asked my friend whether she would like to see test
results, she answered "yes" but nothing happened. She asked a staff member
for assistance, but was told not to worry, because the test results "will be
mailed to you."
Yesterday's mail brought a form letter from GRE stating that her test
results had been "cancelled at your request."
My friend called to ask what this meant, and was told that there had been
"some problems" during the snowstorm, that all information about her test
was "gone", and she would have to retake the examination.
The RISK? Perhaps it is unwise to schedule a GRE in Boston in the winter.
George J. Janczyn University of California, San Diego gjanczyn@ucsd.edu
------------------------------
Date: Mon, 11 Mar 1996 22:24:27 -0500
From: "Mordechai T. Abzug" <mabzug1@gl.umbc.edu>
Subject: "What's new" in web pages is not necessarily reliable
I have a little web robot running to keep track of changes to web pages.
This came in very handy this semester, as I have an instructor who puts all
assignments on the web: instead of having to check manually when the
instructor put up the assignment, I just set up to monitor his "What's new"
page and get mailed within 25 hours of a change. This worked for a while
..., then a homework assignment was added to a different page without being
mentioned in the what's new. Oops. He was very understanding, but this
class of problems is something robot users -- as well as people using
netscape 2's update feature -- will want to keep in mind.
Mordechai T. Abzug http://umbc.edu/~mabzug1 mabzug1@umbc.edu
------------------------------
Date: Tue, 12 Mar 1996 12:08:12 +0100
From: ladkin@TechFak.Uni-Bielefeld.DE
Subject: Digital Flight Control Systems help the U.S. Navy
While many of us may be concerned about the consequences of increasing
computerisation of aircraft systems, one must not forget the other side.
Digital flight control can sometimes unequivocally improve safety.
Flight International, 13-19 March, p9, reports that the USN is upgrading the
F-14 flight control system with a digital system developed by GEC-Marconi
Avionics of the UK. "Three accidents within a month have prompted [.. the]
upgrade [..] to prevent flat spins and improve carrier-approach handling
qualities". The DFCS [..] has been flight-tested by the USN [..] and a
production contract awarded to upgrade 211 aircraft [..]."
Peter Ladkin
------------------------------
Date: Tue, 12 Mar 1996 10:48:26 -0600
From: jthompso@netcom.com (Jim Thompson)
Subject: Re: CIA & NSA run remailers (Raph Levien, RISKS-17.88)
>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.
Unless I completely misunderstand remailers (I don't use them), one honest
remailer in a chain is sufficient only if you want to hide your identity
from the ultimate recipient. However, if you also wish to hide from
government-run remailers, then it's necessary that the *first* remailer in
the chain be honest. The first remailer has access to all your message's
original header fields.
Jim Thompson, jthompso@netcom.com
------------------------------
Date: Tue, 12 Mar 96 00:48:34 PST
From: der@oes.ca.gov (Don Root)
Subject: Re: Rail safety controlled by satellite (RISKS-17.88)
Anyone trying to implement GPS as a means of collision avoidance for
trains will have their share of 'features' to work out. The possibility of
trains operating on parallel track (such that they will pass each other), or
operating on rails that cross each other (grade separation) suddenly going
into "collision avoidance" may be accented by the known "dither" factor
found in commercial GPS equipment (a concept that wobbles the mind).
------------------------------
Date: Tue, 12 Mar 96 12:48:57 EST
From: byrnes@escmail.orl.mmc.com
Subject: Re: Rail safety controlled by satellite (RISKS-17.88)
As someone who has worked for the railroad, I find it is scary to see this
type of technology touted as a "cure-all". Most railroad collisions do not
involve "train vs. train", they involve train vs. "some other vehicle that
has crossed the track". And most train vs. train incidents occur because
of driver error or signal failure. (Will satellite failure soon cause a rash
of high-speed train wrecks?)
The railroads call their train drivers "Engineers" -- yet many (most?) are
not degreed or even trained in much more than an apprentice type program.
It is a boring repetitive job, and the railroads drive to reduce costs, by
reducing crew numbers, may have as much or more to do with rail safety than
any other factor.
If my computer crashes, (even on a leap/non year) I may have a little "clean
up" to do. But a 5-mile-long multihundred-thousand-pound piece of
technology crashing can really mess up your day. :-)
Arthur J. Byrnes
------------------------------
Date: Tue, 12 Mar 1996 04:12:53 -0700
From: Bear Giles <bear@indra.com>
Subject: Re: bleep-year (Mulligan, RISKS-17.88)
> ... 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.
While this was written in jest (hopefully), this is an extremely common
perception which is going to bite software professionals in the very near
future. Anyone who subscribes to any Y2K discussion for more than a few
days will be struck by the large number of people desperately seeking any
viable solution to a problem which (most) upper management steadfastly
denies exists.
Or upper management will accept that it might be a problem, but _their_
bonus comes through with good returns this fiscal year and it's easier to
cut costs by eliminating "incompetent" employees whining about how a problem
in their own department will jeopardize the company years from now.
Besides, if everyone is in the same boat what's the harm if the worst
happens -- the company's competitors will be just as screwed up!
It's time people recognize that Y2K isn't a technical problem, it's a
management problem. Technical people know that losing source code is a
Bad Idea. Technical people know that compilers change, and that new
compilers (e.g., a COBOL compiler which can return CCYYMMDD instead of
only YYMMDD) may break other parts of the system. Technical people know
that it's penny-wise, pound-foolish to toss away information (and that
the reason experienced analysts can command high salaries is they know
what you can safely toss, and what you need to keep even if that means
buying another disk and/or tape drive... and they know to keep an eye
open for changing technologies.) Finally, technical people know that
it's ____________F_____A_____R_____________ cheaper to fix that bug today
than to wait even a month.
If we're serious about fixing the Y2K problem, we need to address this as a
business/management problem, not a technical problem. If a large company
loses $2/share overnight because an auditing firm announces (and the
networks carry the story) that the company isn't ready for Y2K, we'll see
action. Unfortunately, the first action will probably be to fire the
current technical people for letting the company get into this situation
despite repeated pleas for adequate resources being ignored for years. :-(
The RISKy moral of Y2K: software developers are like backcountry guides --
you tell them where you want to go and what you want to see and they'll take
you there _and back_ safely.... It might be expensive, but it's a heck of a
lot less expensive than talking a wrong turn and being stranded in the
wilderness with a broken leg.
But upper management is often like the legendary idiot from the big city who
hires a professional guide and then insists on the guide doing it like he
saw "in a movie once" instead of trusting the guide's experience and
training... and then complaining to everyone back home how the guide wasn't
any good since everything took twice as long and he only got to see a third
of what he was promised.
Bear Giles bear@indra.com
------------------------------
Date: Tue, 12 Mar 1996 13:59:42 -0600 (CST)
From: neufeld@fast.pvi.org (Keith Neufeld)
Subject: Re: UNIX struct tm (Urlichs, RISKS-17.88)
> UNIX holds the time internally as the number of seconds since 1970-01-01.
> "struct tm" is just a library abstraction. IMHO, if the library is changed
> to return a four-digit date instead of modulo 100, not much will break --
> typical Unix software frequently says "if year < 1900 year += 1900" or some
> such.
[I think Matthias meant "since 1900", as already
noted by Steve Loughran in RISKS-17.85. PGN]
Actually, tm.tm_year is defined as the number of years since 1900.
The real year-keeping problem for UNIX machines isn't the library
routines that populate a struct tm; the first is programs that use
statements like
printf("%02d", tm.tm_year); [which will print ``100'' in the year 2000]
instead of
printf("%02d", tm.tm_year % 100);
and
printf("19%02d", tm.tm_year) [which will print ``19100'' in the year 2000]
instead of
printf("%4d", 1900 + tm.tm_year);
And the zeroeth, as mentioned before, is machines that set real
time on boot from hardware clocks that will fail near 2000.
Keith Neufeld, Prairie View, Inc., 1901 E. 1st, Newton, KS 67114
(316) 284-6375 neufeld@pvi.org neufeld@bethelks.edu neufeld@acm.org
------------------------------
Date: 12 Mar 96 14:04:48 EST
From: Owen Leibman <75140.365@compuserve.com>
Subject: Re: COBOL Dates (Urlichs, RISKS-17.87)
The COBOL standard has been amended twice since the adoption of the 85
StandardIn particular, the first amendment (ANSI X3.23a-1989, ISO
1989/Amendment 1) added numerous functions including date functions which
deal with centuries. Many vendors offer COBOL compilers which support these
functions.
------------------------------
Date: Tue, 12 Mar 96 08:22 GMT
From: richardcox@cix.compulink.co.uk (Richard Cox)
Subject: Re: Teen `convicted' by computer
> With modern cheap storage media, room for say, a 16-letter string instead
> of a single-letter code would make it hard to misconstrue
All this "throw hardware at the problem" attitude is a risk in itself. After
all never every computer system can have a $200 Gb HDD added to it. I'm sure
the disks systems for fault tolerant systems are somewhat more expensive.
But more significantly for data collection small hand-held computer systems
have very expensive storage: perhaps UKP 100 for 2Mb of FLASH (which has its
own problems with rapidly changing data).
Coding is here to stay until no computer system has storage limitations.
The real problem in the original article (coded data transferred from one
system to another had different meanings) is assuming that one code set
matches someone else's for the same purpose. The solution: manual checking or
a dictionary (which introduces yet more potential problems).
Richard Cox SMS United Kingdom Limited richardcox@cix.compulink.co.uk
------------------------------
Date: Wed, 13 Mar 1996 09:59:29 +1100 (EST)
From: revdoc@uow.edu.au (Phil Herring)
Subject: Re: Teen convicted: a similar example (Jewell, RISKS-17.87)
While data normalisation has its place, it also has its limits; in fact, it
is often better to denormalise database designs to some extent. Why?
Because the values to which codes refer change - departments change their
names, products cease to exist, employees come and go. For example, if you
just keep a product number, and the product name changes, last year's orders
will suddenly start referring to the new product name, which is usually the
Wrong Thing.
In addition, in this age of end-user access to data warehouses, excessive
normalisation imposes a burden on the end user, who will have to grovel all
over the place to decode all the values that they want to see. This is
precisely the problem that occurred in the current case: namely, people were
given the code numbers rather than the values to which they referred. This
is a wholly different problem to normalisation, and is related more to
presenting data in a human-readable form.
Normalisation is fine in theory, but in practise, it should be treated as a
useful, but limited, design tool.
Phil Herring http://www.ozemail.com.au/~revdoc revdoc@ozemail.com.au
------------------------------
Date: Tue, 12 Mar 1996 18:42:44 +0100 (MET)
From: Tim Pietzcker <pietzcke@ruf.uni-freiburg.de>
Subject: Lotto computer errors
I remember that a few weeks ago somebody in Germany sued the lotto agency
because his winning lottery numbers were misread by the computerized lotto
ticket scanner. His chances for success were rated quite slim - he should
have read the receipt...
Tim Pietzcker Turnseestr. 9 D-79102 Freiburg Phone/Fax ++49+761 77345
------------------------------
Date: Tue, 12 Mar 1996 18:19:16 -0500
From: "jennifer (j.) hunt" <stud6x1@bnr.ca>
Subject: Risks of automatically publishing Risks newsletter to the Web!
RISKS-17.88 has an article about the Netscape forms 'feature' that
automatically sends e-mail upon loading a document. Risks kindly provides an
HTML code fragment which exhibits this behaviour. When I loaded up this
newsletter in my browser, that code fragment was executed! Given that this
code represented a form of trojan horse, it is hardly appropriate for Risks
Newsletter to be perpetuating it!
The first risk is that of including 'live' code fragments in a publication,
especially one which is subject to several media.
The second risk is that of using an automated process to construct and
publish information on the Web -- especially if the input to that process is
e-mail.
Jennifer Hunt Systems Design Engineering University of Waterloo
jehunt@zeus.uwaterloo.ca
------------------------------
Date: Tue, 12 Mar 1996 06:26:30 GMT
From: Jonathan Kamens <jik@annex-1-slip-jik.cam.ov.com>
Subject: Re: Netscape's too-lenient syntax checking (Baker, RISKS-17.88)
> I have nothing against Netscape trying to be smart,
What Netscape does isn't merely "smart"; it's also a violation of the HTML
specification.
That specification defines what is or is not legal in an HTML document.
Programs which purport to be HTML viewers are supposed to confirm that the
document being viewed conforms to the HTML specification (e.g., not missing
"</A>" markers after "<A>" markers) and complain if it doesn't.
Unfortunately, Netscape decided, "Why should we write something which checks
the HTML for validity, which we can just write a smart interpreter which
figures out what the author of a document *wanted* to do, even if they
didn't actually say that?"
Henry Baker has already pointed out one problem with this -- it allows
webmasters who use Netscape to test their HTML to be lazy about ensuring its
correctness. Since Netscape is the most popular browser, and therefore more
webmasters use it than any other browser to check HTML, users who don't use
Netscape are often "shut out" of sites.
Worse, Netscape has intentionally implemented numerous features that are not
conformant with the HTML specification, that their browser supports but
others do not. Instead of working through the process recognized by the
HTML-design community for adding functionality to HTML, they just added the
functionality they thought was needed. Since many sites take advantage of
this additional functionality (it *is* pretty neat, after all), once again,
users who do not use Netscape are "shut out".
Rectifying the latter problem isn't simply a matter of adding Netscape's
functionality to the HTML specification, because they've added functionality
which is difficult, if not impossible, to implement in SGML (the Standard
Generalized Markup Language, which is the meta-language in which HTML is
defined). That doesn't matter to Netscape, since (as I mentioned above)
their browser interprets the HTML in a do-what-I-mean fashion, rather than
in a "Is this valid HTML?" fashion, but it matters to the rest of the Web
community, since browsers which are trying to remain true to what HTML is
supposed to be simply may not be able to implement the features which more
and more sites are using.
{Begin politics.}
I find what Netscape has done totally reprehensible. There was a recognized
body of people defining the HTML standard, a recognized procedure for
implementing changes to that standard, and a recognized "proper" way to
parse and display HTML code. Netscape threw that all away, and I believe
that they were fully conscious when they did so that they were breaking the
standard and causing lots of grief for the other HTML developers in the
world. What they're doing is nothing more than an attempt to make Netscape,
a commercial product, the only browser that can be used to access the full
potential of the Web, which is supposed to be free. The sad thing is that
they may very well end up succeeding.
{End politics.}
(Thanks to Andrew Greene for teaching me most of this and proofreading
this message.)
------------------------------
Date: Tue, 12 Mar 96 09:13:27 -0500
From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Subject: Re: Netscape too lenient syntax checking? (Baker, RISKS-17.88)
> ... The problem is fixed, although I don't recommend
> looking at the site with anything but Netscape 1.1N and higher.
That won't always work either. After putting 2.0 on a machine I noticed
large chunks of text on one site disappearing. Seens That with Netscape 1.x
if it encountered a syntactical mistake such as <A HREF="foo.gif> instead of
<A HREF="foo.gif"> it would realize that a double quote was missing on the
end and, having reached the end of the anchor, "assume" one.
Not 2.0. If the double quote is missing, things go wonky. So the *real* risk
is to assume that "smarts" will propagate along with versions instead of
correcting errors.
Padgett
------------------------------
Date: Tue, 12 Mar 96 20:28:38 EST
From: tilt+@UX3.SP.CS.CMU.EDU (Eric Tilton)
Subject: Re: Netscape's too lenient error checking (Baker, RISKS-17.88)
> ... Perhaps Netscape should have a `careful' mode for helping web page
> maintainers to provide `squeaky clean' pages.
It is for this very reason that I put together "Composing Good HTML," a few
years ago (http://www.cs.cmu.edu/~tilt/cgh/). Netscape pays at least token
attention to the problem, since they do have a reference to CGH in their own
documentation. Also, several HTML syntax checkers exist. The real RISK seems
to be that there is a popularly perceived "standard" -- HTML -- which is in
reality incredibly balkanized, with each browser choosing to interpret
different subsets and supersets of it in slightly (or not so slightly)
different ways. And that people's perceptions of that standard are largely
influenced by a WYSIWYG mentality that HTML only somewhat incidentally
supports.
------------------------------
Date: Tue, 12 Mar 96 20:37:26 -0500
From: Torrey McMahon <tm8025a@mailhost.soc.american.edu>
Subject: Re: Netscape's too-lenient syntax checking (Baker, RISKS-17.88)
I recently was involved in a lengthy discussion in
comp.infosystems.authoring.html about this very subject. Someone posted to
an other mailing list I subscribe to that Netscape allows such sloppy
behavior, in this case it was allowing a <b> to be closed by a </i>. The
argument given to me in the USENET group was "Netscape is a HTML browser,
not a validator. You can't fault it for correcting an author's bad HTML!" Of
course most people don't use a validator they just fire up Netscape, load
the page, and if it "works" they put it on their server. The compromise we
seemed to settle on was the browsers should correct HTML to some extent but
should also state that fact in a dialog box similar to the Arena browser.
I was also taken back by their "Netscape bigotry". My favorite message was
one person stating that since I don't use Netscape I shouldn't be
complaining because I'm not using the Internet standard browser!!! (I'm
using Omniweb 2.0 on a NeXT machine in case you're wondering.
The risks? Taking one person's, or company's, HTML parser as the correct
one. Netscape bigotry in use of tags, poor HTML, and attitude is an obvious
other.
Torrey McMahon American University School of Communication
------------------------------
Date: Tue, 12 Mar 1996 06:54:28 -0800 (PST)
From: David@thermoteknix.co.uk
Subject: Re: Yet another Trojan horse in Netscape 2.0 (Reeves, RISKS-17.88)
It would be possible to get the unsuspecting reader to make multiple
mailings - mail bombing. ISP are shutting down/deleting/revoking/stopping
accounts at the moment due to a spate of mail bomb attacks. I hope they know
about this.
Risk: watch what you download or watch your account close.
David Wood david@thermoteknix.co.uk
------------------------------
Date: Mon, 11 Mar 1996 17:21:03 -0800 (PST)
From: Stanton McCandlish <mech@eff.org>
Subject: Re: Yet another Trojan horse in Netscape 2.0 (Reeves, RISKS-17.88)
>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".
Funny thing is, even though this is clearly not meant to be a real mailbox,
there really *is* is a secret.org, run by a friend of mine in DC. I don't
think there's a user ID of "nasty" there, but anyway, I thought it rather
curious. Small world. Small net anyway. I suppose an additional risk
inherent is silly cookies like this is that even when done as a joke, it's
actually possible to create unintended bad effects, such as revealing user
IDs to any actual nasty@secret.org who happened to appear, or inundating
poor nasty with a form of "autospam", due to innocent Netscape users playing
with the cookie and actually sending the suggested e-mail.
Stanton McCandlish Electronic Frontier Foundation Online Activist mech@eff.org
------------------------------
Date: Tue, 12 Mar 1996 12:36:15 -0500
From: Jon Reeves <reeves@zk3.dec.com>
Subject: Re: Yet another Trojan horse in Netscape 2.0 (Reeves, RISKS-17.88)
I've gotten a couple of messages suggesting that altering the e-mail address
in my Netscape identity configuration will defeat this trojan. Maybe on
some platforms, but certainly not on a UNIX platform.
However, I did get a helpful suggestion: setting your outbound mail SMTP
server to a nonexistent machine (e.g., mailtrojan) will prevent this attack
by disabling all mailto URLs. Of course, this makes Netscape useless as a
mail program. [...]
------------------------------
Date: Tue, 12 Mar 1996 18:14:00 -0500
From: "john (j.g.) mainwaring" <crm312a@bnr.ca>
Subject: Re: Yet another Trojan horse in Netscape 2.0 (Reeves, RISKS-17.88)
The problem Jon Reeves points out in RISKS-17.88 certainly is insidious. In
my case, I think there's a slightly different risk. I don't use e-mail
associated with the internet account I use for Netscape. I am one of three
people in the world that use a mail handler written as a learning exercise a
few years ago. I get my e-mail from a different dial up connection from the
one I use for Netscape. I have a userid on the sytem I connect to through
Netscape, and I'm willing to believe that Netscape is clever enough to get
e-mail out 'from' that userid, even though I've done nothing to help it. If
Netscape is able to send mail purportedly from me, not only would I never
see it -- I'd never be aware if anyone replied (perhaps threatening me with
some dire consequences of having 'sent' the e-mail?) On the other hand, I
may have hidden access to e-mail well enough that even Netscape can't find it
on my machine. If so, it would be a way to work around the problem Jon
found, but probably not one that most people would find convenient.
By the way, this posting is from a completely different machine than
the one I described, but I don't run Netscape at all on this one.
John Mainwaring
------------------------------
Date: 12 March 1996 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: ABRIDGED info on RISKS (comp.risks)
*** Illustrative Risks document now available in PostScript form. Below. ***
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.
***** DRAFT NEW TEXT, IN RESPONSE TO A STICKY SITUATION *****
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. Other reuses normally require
explicit permissions from the author. Anyone redistributing RISKS items
for other than personal purposes should indicate that the material is
derived from RISKS (the Risks Forum), that it is freely available, and that
the author(s), the RISKS moderator, and the ACM have no connection with
such reuse.
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
***** NEW ITEM *****
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.89
************************
