[1215] in RISKS Forum
RISKS DIGEST 17.90
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Thu Mar 14 17:50:42 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Thu, 14 Mar 96 14:48:59 PST
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Thursday 14 March 1996 Volume 17 : Issue 90
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. *****
====> Paragraph on reuse of RISKS items still in flux. See new version.
Contents:
Response from Strassmann/Marlow on remailers (via Dorothy Denning)
University of California computerized retirement system flawed (PGN)
PGP - the next level... (John Oram)
Re: Possible future risk of virtual reality (Richard Cook)
Re: Denormalising databases (Rob Bagnall)
Hyphenation in names (Wei-Hwa Huang)
Domain Name translation at ISP = Wrong Address (Bob Heuman)
More e-mail address problems (PGN)
Re: Risks of automatically publishing to the Web! (Li Gong)
Netscape White pages "Who Where?" risks (Brian Kelley)
How I lost my Y2K innocence (Cory Hamasaki)
Re: Leap-years and leap-seconds (Mark Brader)
Re: Calendar Act (Mark Brader)
1996 SEPG Conference [abridged] (Carol Biesecker)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 14 Mar 96 14:14:55 EST
From: denning@cs.cosc.georgetown.edu (Dorothy Denning)
Subject: Response from Strassmann/Marlow on remailers
[From Paul A. Strassmann, National Defense University
and William J. Marlow, SAIC, via Dorothy Denning]
We find that a report by a Mr. Viktor Mayer-Schoenberger [e.g., RISKS-17.87]
citing our alleged statements at a Harvard University Conference has been
widely quoted on Internet, out of context.
Specifically, he attributed to us statements that a number of anonymous
remailers in the US are run by government agencies and that the most popular
remailers in France and Germany are also run by government agencies. What Mr.
Viktor Mayer-Schoenberger reported as facts are his interpretations. Our
comments were of a general academic nature. We were not attributing remailer
activities to any specific governments, but rather commenting on the general
situation where much of the research on the use of networks has been paid for
by governments and therefore one can assume that they would know how to make
use of such facilities. We have no specific knowledge of any particular
agency of any government offering remailers services. Whether or how they use
remailers is not known to us. Online users just need to be "aware of the
risks."
Paul A. Strassmann, National Defense University
William J. Marlow, SAIC
------------------------------
Date: Thu, 14 Mar 96 8:01:10 PST
From: "Peter G. Neumann" <neumann@chiron.csl.sri.com>
Subject: University of California computerized retirement system flawed
A University of California computer system administers U.C.'s $20 billion
retirement program. A recent report by Infortal Associates concludes that
the security of the system was very weak, and that the audit trails were
flimsy and easily disabled. Furthermore, no one had responsibility for
reviewing the audit trails. The system can be accessed from the Internet,
and Infortal was able to do so using a widely known password. However, a
University spokesman observed that no adverse penetrations had actually
taken place, no money has been lost, and the security flaws have been fixed.
[Source: *San Francisco Chronicle*, 14 Mar 1996]
[Well, in the absence of good audit trails, you may not know you have been
penetrated. Also, even if a few security flaws may have been fixed,
such a system is never totally invulnerable to attack (whether on the
Internet or not). But you all know that by now? PGN]
------------------------------
Date: Wed, 13 Mar 1996 01:45:05 -0800
From: oram@unixg.ubc.ca (John Oram)
Subject: PGP - the next level...
[This is from mini-AIR (e-mail synopsis of the Annals of Improbable Results).]
1996-03-05 PGP-Y Ill Advised
Reader Andrew Rock has been investigating our foolproof data security
protocol, PGP-Y (Pretty Good Parapsychology). He intuited this missive to us:
"You were ill-advised to release the details of your PGP-Y -- "Pretty Good
Parapsychology" protocol on an international mailing list such as mini_AIR.
US law prohibits the export of such highly secure transmission technology,
defining it as munitions. Your proposal must await government-approved key
espcrow [sic] systems rumoured to be under consideration by the NSA. The
approved systems will prohibit the possession or transmission of ideas
beyond the imagination of government officers. Please do not carelessly put
the publication of AIR at risk while I have nearly two years left on my
subscription."
Investigator Trevor Green and a large team at the University of Saskatchewan
have also been laboring in the field. Green reports:
"After an initial trial period of PGP-Y within our department, we have had
some disappointing initial results. While the transmission rate is nothing
short of paraphenomenal, the security mechanism is, alas, not wholly
foolproof -- everything worked fine, until my friend Steve started imagining
that he was intercepting the telepathically-transmitted data. We are sure
that this technical loophole may be overcome but wish to alert your
paranormal engineers to the oversight. Meanwhile, I am pleased to report
that the credit-card fraud charges against Steve will be settled out of
court."
[And it is not even April yet! PGN]
------------------------------
Date: Mon, 19 Feb 1996 08:17:32 -0600 (CST)
From: ri-cook@uchicago.edu (Richard Cook)
Subject: Re: Possible future risk of virtual reality
Recent discussion of appropriate renaming of v.r. systems prompts one to
note that being an attractive sink for funding often involves production of
a two-word nonsequitur comprising an adjective and a noun. The
juxtaposition of the incompatible modifier with the noun yields a conflicted
notion that makes possible a degree of cognitive friction generating new
ideas, permits wild and unsubstantiated claims to flourish, and empowers
marketing hyperbole that has no equal.
Examples include not only "virtual reality" but also "artificial intelligence"
and "expert systems". In each, the combination is unlikely to the same
degree as a zen koan. Although the metaphor may be a little overextended,
proponents seem to regard contemplation of the terms as one means of
achieving the experience of satori.
While the clever use of language is required to initiate funding flows, it
is generally unable to sustain it for more than about a decade. Skilled
operators are able to generate a new term-pair every decade or so to ensure
continued flow of funds for research and development.
Richard I. Cook, MD Cognitive Technologies Laboratory
Department of Anesthesia and Critical Care University of Chicago
------------------------------
Date: Wed, 13 Mar 1996 11:26:10 +0100
From: "RBAGNALL.BE.ORACLE.COM" <RBAGNALL@be.oracle.com>
Subject: Re: Denormalising databases (Teen convicted, Jewell, RISKS-17.87)
I agree that denormalise database design may be better, but not for the same
reasons Phil suggests. What Phil has described is an example of poor coding
and understanding of relational design rather than a case for
denormalisation. The use of a unique key that refers to the product number
(and name) would overcome this problem.
The RISK here is confusing the theory with the (bad) practice.
Rob rbagnall@be.oracle.com
------------------------------
Date: Wed, 13 Mar 1996 15:13:33 -0800
From: whuang@cco.caltech.edu
Subject: Hyphenation in names
Our school has some servers that run Solaris and some that run SunOS. I
discovered that when I posted to USENET on the Solaris machines, my name
showed up as "-Hwa Huang" instead of "Wei-Hwa Huang". After we traced down
the problem recently, it turned out that inews on the Solaris machines
assumed that the names in the passwd file looked like
foo-John Smith(bar)
where foo and bar are used to mean stuff that doesn't concern the user's name.
On the other hand, inews on SunOS used
John Smith,foo,bar
instead. Obviously, the Solaris machines saw
foo-Wei-Hwa Huang(bar)
and got confused.
The RISKS are obvious. Whomever compiled inews on the Solaris machines made
the assumption that the hyphen was a safe delimiter that would never appear
in a user's name. Of course, with the SunOS method, names with commas in
them would confuse the system instead. If there are people out there with
strange names, or perhaps use 2-byte characters, these "standard" systems
wouldn't fare too well. On the other hand, while using something strange
such as $ for a delimiter would work in more cases, it certainly makes for
difficult reading of the source. What's a designer to do?
Kudos to my excellent sysadmins for pinpointing and fixing the problem so
rapidly, by the way.
Wei-Hwa Huang, whuang@cco.caltech.edu, http://www.ugcs.caltech.edu/~whuang/
------------------------------
Date: Wed, 13 Mar 1996 23:49:08 -0500
From: rsh@inforamp.net (RSH)
Subject: Domain Name translation at ISP = Wrong Address
I recently changed ISPs and suddenly mail from one individual I correspond
with had a change in her address, so that my replies to her messages were
coming back with the User Unknown response. Since I also obtain her
postings at a second ISP, I checked and found that her address was still the
original address at the second ISP.
[Incidentally, my mailer automatically uses the reply-to address if supplied,
or falls back to using the from address. In this case, the "From:" address
was being used, and was being changed at *my* ISP when it was received,
whether in a Usenet message or a personal e-mail message.]
Having discovered this, I called the new ISP's technical support group and
explained my discovery. While laughing, the support person tested my
contention internally on their system and discovered that, lo and behold, I
was correct in my theory. For some reason, the @ns.net was being translated
to @norm.net by their system. They name each of their machines, and one had
been named "norm". For some reason, they had, somewhere in their system, a
conversion where ns=norm. While this may have been required for some
purpose, it was being applied for a different purpose, totally unintended.
[Whether they could have discovered this via testing is unknown to me.]
It took two days, but they HAVE fixed the problem - without letting me know
when they had it fixed, and without letting me know exactly where the
problem occurred.
The risk is obvious, if you only have one ISP... When mail is returned as
undeliverable, it may be that the address is incorrect because of something
your ISP has done and is totally unaware of. Believe me, this CAN result in
annoyance and frustration, both on your part and on the part of the person
you correspond with, half way around the world. Fortunately we were not
involved in any correspondence where time was of the essence, or the problem
would have been far worse.
R.S. (Bob) Heuman Willowdale, ON. Canada
<heuman@mtnlake.com> <rsh@inforamp.net> <rn.1886@rose.com> <aa969@torfree.net>
------------------------------
Date: Thu, 14 Mar 96 12:05:25 PST
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: More e-mail address problems
The message from Bob Heuman reminds your moderator that I have been itching
to grumble again about the ongoing RISKS bouncemail problems -- along the
lines of Phil Agre's posting on the risks of e-mail (Bouncemail Top 10) in
RISKS-16.76. In the past week alone, I have had at least 20 new subscribers
using the majordomo listserv whose "From:" address or other explicitly
provided address was not a valid address, so that they could not receive
mail at their own given addresses! This is truly ridiculous, although it
may be attributed to the rapid growth of the Internet community among folks
not used to the subtleties of life on the net. I sometimes get as many as
100 bounces a day; even if I have just pruned away all the previous hard
bounces, I still get a bunch of *new* ones on the next issue. The good news
is that the Internet is dynamic. The bad news is that the Internet is
dynamic.
If you do not get RISKS for a long while, you should check the archives to
see whether you have been dropped from the list because of prolonged bounces
(or whether I have just been otherwise occupied).
------------------------------
Date: Wed, 13 Mar 1996 14:14:46 -0800 (PST)
From: Li Gong <gong@csl.sri.com>
Subject: Re: Risks of automatically publishing to the Web! (Junt, RISKS-17.89)
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.
Just to expand on the above: ``Live code'' can stealthly come into
documents. Any web site that offers to take online "feedback" or "comments"
has an open invitation to such trojan codes -- for example, an attacker can
simply type in applet code into an online form.
Moreover, it is perhaps more convenient to collect and sort these feedback
automatically and then view them through a web browser (instead of an editor
such as Emacs or MS Wordpad). Thus, the risk is often there if one uses a
java-capable browser to do something useful.
On the other hand, there is the tendency that a newly discovered attack will
quickly lead to a patch that disables a useful feature in the browser or
interpreter. Soon the features list is shortened to almost zero and ones
starts to ask why the language is needed at all.
Li Gong, SRI International, http://www.csl.sri.com/~gong/
------------------------------
Date: 13 Mar 1996 16:21:35 -0500
From: brian@piglet.cam.cornell.edu (Brian Kelley)
Subject: Netscape White pages "Who Where?" risks
A mate of mine, whom I will call Skip and his computer ralph.nomame.edu,
decided to look himself up on the "Who Where?" database.
He found his name, selected it, and was rewarded with the response:
* Name: ??? Console
E-mail: skip@ralph.nomame.edu
Organization: cornell university, ithaca
Last Updated: --
This is all fine and good, except that a) he never registered himself with
the server and b) ralph.noname.edu is not a mail server and all mail there
will bounce. So the question is, how did this E-mail address show up? So,
I looked at my entry.
* Name: Brian Kelley
E-mail: brian@piglet.cam.cornell.edu
Organization: cornell university, ithaca
Last Updated: --
Now, piglet.cam.cornell.edu is also not my e-mail address.
We did a little digging and discovered that the standard unix command
"finger @ralph.noname.edu" responded with
[ralph.noname.edu]
Login Name TTY Idle When Where
skip ??? console 10:30 Tue 22:22
and "finger @piglet.cam.cornell.edu" responds with
[piglet.cam.cornell.edu]
User Real Name What Idle TTY Host Console Location
brian Brian Kelley 4 piglet 357 Theory Center
So, our assumption is, which is also a risk in itself, that some program
is fingering computers and "grep"ing the return info which, in the case
of skip is incorrect.
However, the real question is, how did these machines get registered with
the page? The answer is, Netscape. My best guess is that by selecting the
"Who Where?" page, or some other page, automatically registers your machine
with the database which then fingers your machine for information. To
test this theory, just look up the entries for "root." (Which indicates
many more risks, i.e. root running Netscape, et. al.)
This would be fine if there was a notice that entering this page
automatically registers you (and everyone currently logged onto your
computers) with the database. However, the page highlights and underlines
the phrase "Add Your Listing" which indicates that it has not been added
already.
The risks, in the case of skip, are obvious. However, it was just another
reminder to myself about the propagation of personal information (that
may indeed be inaccurate.)
Brian Kelley 357 Rhodes Hall Cornell University Ithaca, N.Y. a14850
brian@ee.cornell.edu (607) 255-0963
------------------------------
Date: Wed, 13 Mar 96 08:33:36
From: kiyoinc@ibm.net
Subject: How I lost my Y2K innocence
A brief note of appreciation to Bear Giles (RISKS-17.89):
I had been focussed on Y2K as a technical problem. At the risk of showing
my age, here's how I lost my innocence.
Our timesharing mainframe's OS failed on December 1, 1979. Operations was
able to restart it; it would run a short while and fail again in the
supervisor. I won't mention the OS since we had extensively modified it and
it wouldn't be fair to sully the vendor with our self produced problem.
The memory dump showed a data exception in our online accounting routine, it
was doing a packed decimal operation on a field that contained the
hexadecimal sequence '000197AF'. You grey beards (Yes, I have seen *you*,
Mr. Moderator.) out there will recognize the problem. Even though the field
had the century indicator, our assembly language programmer had chosen to
increment only the year portion. He extracted the 4 bits, incremented the
year, and stored the year back. This subroutine worked for years 1970
through 1979 but 197A is not the next year, at least not until we replace
decades with hexadecades.
(sidebar ALC lesson, of '000197AF', the 'F' means a positive number. This
representation is packed decimal; the programmer used binary arithmetic
operators on a packed decimal number.)
This code calculated the billing period, lived in our operating system, and
was executed at the end of each batch job or timesharing logoff.
A lot of the popular writing on the Y2K problem (I'd been calling it, the
century end problem) has focussed on application data, cobol, database,
accounting, and reporting issues. These are certainly the larger part of
the problem and the 'suit' consulting companies will have their hands full.
Because I have seen and debugged an operating system catastrophic failure
caused by a calendar issue, I believe this problem has a darker, more
ominous side. There are subtle Y2K problems that are not revealed by
scanning the external data. Some of these problems are implemented in
assembly language. Some of the assembly language source code has been lost
over the decades. There are very few of us left who can read and write
machine language.
Contrary to reports in the popular press, the world does not run on PCs and
client/server systems. It runs on big water cooled mainframes and a lot of
old, old software maintained by aging staffs. Each year, a substantial
percentage of the machine language programmers leave this business.
Who is going to fix the hard problems?
Cory Hamasaki
------------------------------
Date: Wed, 13 Mar 96 15:36:20 EST
From: msb@sq.com
Subject: Re: Leap-years and leap-seconds (Dellinger, Risks-17.86)
> A leap second is a 61st second in a minute (always just before UT
> midnight), so ... some date specifications such as "23:59:60 Dec 31
> 1972" are actually perfectly valid.
Yep -- but that particular date and time combination is valid only if the
time zone is assumed to be UTC. In the Newfoundland time zone, for example,
23:59:60 would never be a valid time, but on days with a leap second, one of
20:29:60 or 21:29:60 is valid. 22:29:60 could have been valid too if there
had been a leap second in the summer of 1988 when Newfoundland tried double
daylight saving time, but there wasn't one then. In other words, true
validation of a time of day requires knowledge of the time zone.
Of course, this is true anyway even without regard to leap seconds, since
you also need to know about daylight saving time transitions.
Which reminds me of something instructive -- a few weeks ago, Dafydd Price
Jones (dafyddpj@dafyddpj.demon.co.uk) asked in rec.puzzles: "What was the
longest month of 1995 in New York?" The right answer is October, when
daylight saving time ends. But there must have been half a dozen readers
who forgot that, remembered the latest leap second, and leaped to post the
wrong answer "December".
The moral? Merely what we've been saying already. Date and time
computations are surprisingly tricky.
(There was also a wonderful "cook" of the puzzle, with its own Risks
implications. Chris Best (cab@col.hp.com) said that the longest month
was the only 9-letter one, September! Peter will remember the time that
comp.risks itself was bitten by a longer-than-average spelled-out date.)
Joe continues:
| This has worked reasonably well so far, but I've read predictions
| that within only a couple of decades we'll first start needing leap
| seconds every year, then twice a year, then even more and more often...
| What shall we do then? Redefine the second? Keep two separate time
| standards, one with a fixed second and another with a stretchy second
| that changes to accommodate the Earth?
Already done -- those would be TAI and UT1 respectively. Neither one is
what's used for civil time, though. Civil time is based on UTC, which is
called *Coordinated* Universal Time precisely because it is derived from
*both* TAI and UT1. And this is exactly why we have leap seconds. UTC uses
the fixed-size seconds of TAI, but keeps its time within 900 ms of the
current time according to UT1, by using a leap second (or, as Joe noted, in
theory an anti-leap second) when needed.
But maybe Joe meant that people would actually need to use both kinds of
seconds in everyday life. It'll be a *long* time before things come to
that, and I think we can safely defer the problem for now.
Incidentally, while TAI is an acronym in French, UTC is not; it's in
English, but the C is last because it's effectively a subscript. Both UT1
and UTC are considered variations of UT, Universal Time; there are others too.
Mark Brader, msb@sq.com, SoftQuad Inc., Toronto
------------------------------
Date: Wed, 13 Mar 96 15:39:16 EST
From: msb@sq.com
Subject: Re: Calendar Act (Thorsett, Risks-17.84)
| [The] Explanatory Supplement to the Astronomical Almanac ... raises the
| interesting point (in section 12.13) that the U.S. legal code specifies
| no official national calendar. Our use of the Gregorian calendar stems
| from a 1751 Act of Parliament of the U.K.
In 1992, Clive Feather obtained a copy of this Act for me, and I typed it in
and posted it to the net. That posting, with a few additional remarks, can
be found at <http://www.urbanlegends.com/legal/calendar_act.html> or
obtained by e-mail from me.
The for those who don't want to browse through 500-odd lines to find it,
the key part of the Act that defines the leap year pattern decrees:
# That the several Years of our Lord, 1800, 1900, 2100, 2200, 2300, or
# any other hundredth Years of our Lord, which shall happen in Time to
# come, except only every fourth hundredth [sic] Year of our Lord,
# whereof the Year of our Lord 2000 shall be the first, shall not be
# esteemed or taken to be Bissextile or Leap Years, but shall be taken
# to be common Years, consisting of 365 Days, and no more;
# and that the Years of our Lord 2000, 2400, 2800, and every other
# fourth hundred Year of our Lord, from the said Year of our Lord 2000
# inclusive, and also all other Years of our Lord, which by the present
# Supputation are esteemed to be Bissextile or Leap Years, shall for the
# future, and in all Times to come, be esteemed and taken to be
# Bissextile or Leap Years, consisting of 366 Days, in the same Sort and
# Manner as is now used with respect to every fourth Year of our Lord.
except that in the actual Act, all of the numbers are written out in words.
Pope Gregory's original proclamation would also be of interest, but I presume
it was in Latin; anyway, I've never seen a copy of it.
Mark Brader msb@sq.com SoftQuad Inc., Toronto
------------------------------
Date: 12 Mar 1996 16:20:13 GMT
From: cb@SEI.CMU.EDU (Carol Biesecker)
Subject: 1996 SEPG Conference [abridged]
Broadening the Perspective for the Next Century
1996 SEPG Conference, Preliminary Program
May 20-23, 1996, Atlantic City, New Jersey
Trump's World Fair Casino Hotel & The Atlantic City Convention Center
Software practitioners meet once a year to share experiences, discuss
current issues, and explore models and trends for the future. The focus of
the 8th SEPG Conference is exploration of the view of process improvement
for the year 2000 and beyond. The annual event is sponsored this year by
the North Jersey Software Process Improvement Network (SPIN) and the
Software Engineering Institute. The 8th Software Engineering Process Group
(SEPG) Conference includes keynote presentations, speakers, panels,
tutorials, exhibits, poster sessions, and informal birds-of-a-feather
meetings.
Deadline for Registration Discount: 29 April 1996
The SEI is a federally funded research and development center sponsored by
the U.S. Department of Defense and operated by Carnegie Mellon University.
CMM, Capability Maturity Model, and IDEAL are service marks of Carnegie
Mellon University.
Conference Schedule [meals, breaks, etc., omitted]
Monday, May 20, 1996 Tutorials
Tuesday, May 21, 1996 General Sessions, Keynote, Presentations, Reception
Wednesday, May 22, 1996 General Sessions, Keynote, Presentations
Thursday, May 23, 1996 Tutorials
Keynote Presentations:
* Fagan Defect-Free Process, Michael Fagan, Michael Fagan Associates
* The Silver Bullet Experiment - Challenges for the Future, Robert Martin,
Bell Laboratories
* The Software Challenge--The Next Imperative, John Major, Motorola
* Inside the Information Systems Blackhole 1996!, Howard A. Rubin, CUNY
Topics to be addressed include
* IT Performance--how are the frontiers of performance changing?
* An industry-by-industry view of spending patterns, infrastructure, and
priorities.
* 1995 performance--how does the U.S. rate against the world?
* The IT performance "envelope"--how should you assess your position?
* Offshore performance--India, low-wage countries, myths vs. realities, and
outsourcing.
* How to assess and set your performance priorities...forward-looking
measurement.
For information,
Phone 412 / 268-7388 or
Customer Relations-- 412 / 268-5800
FAX 412/268-7401
E-mail registration@sei.cmu.edu or
customer-relations@sei.cmu.edu
World Wide Web http://www.sei.cmu.edu
------------------------------
Date: 14 March 1996 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: ABRIDGED info on RISKS (comp.risks) [REVISED AGAIN]
Illustrative Risks document now available in PostScript form. See 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.
*** LET'S SEE IF THIS IS WORKABLE: ***
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. All redistributed items must include the
Risks Forum masthead line. Explicitly, we hereby declare that the author(s),
the RISKS moderator, and the ACM have no connection with any such reuses; all
commercial reuses must explicitly indicate this to be the case. As a
courtesy, commercial reusers of individual items (as opposed to blanket
forwardings of entire issues) should notify the authors, and should pay
particular attention to any subsequent corrections.
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
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.90
************************
