[1185] in RISKS Forum
RISKS DIGEST 17.62
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Wed Jan 10 14:18:13 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Wed, 10 Jan 96 11:07:48 PST
To: RISKS-1:;@csl.sri.com
RISKS-LIST: Risks-Forum Digest Weds 10 January 1996 Volume 17 : Issue 62
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:
E-Mail-Tap Nets Criminals (Edupage)
Pacific Northwest air-traffic outage (Mich Kabay)
Sting-Re: "ghoti"?
Microsoft continues to mislead public about Windows security bugs (Rich Graves)
Configuration files may travel (Kurt Tekolste)
Re: Brunnstein / Compuserve / Germany (Martin Virtel)
Attacking CompuServe Subscribers (Mich Kabay, Henry G. Baker)
Re: Floating Point Number formats (Phillip C. Reed)
Reliable development methodology (Andrew Robson)
New Security Paradigms '96 -- Call for papers (Yvo Desmedt)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 4 Jan 1996 14:32:51 -0500 (EST)
From: Educom <educom@elanor.oit.unc.edu>
Subject: E-Mail-Tap Nets Criminals (Edupage, 4 January 1996)
The first-ever court-approved wiretap of an e-mail account has resulted in
the arrest of three people charged with running a sophisticated
cellular-fraud ring. The alleged mastermind, a German electrical engineer,
advertised his illicit wares on CompuServe, where they caught the attention
of an engineer at AT&T's wireless unit. The Secret Service and the Drug
Enforcement Agency then got into the act and obtained the Justice Dept.'s
permission to intercept e-mail messages between the alleged perpetrator and
his accomplices. "This case represents the challenges in the future if we
can't get ahead of the curve in technology," says a U.S. attorney, whose
office is prosecuting the case. (*Wall Street Journal*, 2 Jan 1996, p.16)
------------------------------
Date: 09 Jan 96 14:58:56 EST
From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
Subject: Pacific Northwest air-traffic outage
>From the Associated Press news wire via CompuServe's Executive News Service:
Air Traffic Outage (by George Tibbits, Associated Press Writer)
SEATTLE (AP) -- A technician won't be disciplined for an accident that cut
off all power to an air-traffic control center and delayed flights
throughout the Pacific Northwest, an FAA spokesman said Sunday. The power
outage early Saturday darkened radar screens and silenced radios and
telephones at the Federal Aviation Administration center, leaving
controllers completely in the dark for at least five minutes.
Key points:
o Over 50 planes and 150 flights delayed 1 hour or more because
of accident at 06:53.
o Controllers used car cell phones to get info to pilots through
other air-traffic control centers.
o Technician accidentally pulled a circuit board from what he
mistakenly though was a backup unit; was actually functioning.
o Electrical batteries/generators failed to kick in because the
damaged unit also controlled switchover to backup power.
o Effects of accident lasted 2.5 hrs.
o FAA "developing procedures to make sure that won't happen again."
M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA)
------------------------------
Date: Mon, 8 Jan 96 19:33:36 PST
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Sting-Re: "ghoti"?
Not surprisingly, many folks hastened to remind me that the "o" in "ghoti"
is properly pronounced as the "o" in "women". Yes, of course, but I was
seeking a minimalist alternative, noting that pronouncing "ghti" as "fsh"
sounds pretty much like "fish" in most dialects -- although phonetically the
"o" in "women" might be considered necessary for precision in high english.
Incidentally, for those of you who are language buffs (in any language),
pick up a copy (in paperback) of Anthony Burgess' "A Mouthful of Air". It
is a truly marvelous book about language and languages. PGN
------------------------------
Date: Mon, 8 Jan 1996 19:16:50 -0800
From: Rich Graves <llurch@Networking.Stanford.EDU>
Subject: Microsoft continues to mislead public about Windows security bugs
Please do not dismiss this as mere "Microsoft Bashing." c2.org has
similar promotions running for Netscape, DigiCash, and Java.
The following is a quote from Microsoft's "Knowledge Base" technical
support and marketing database, which is online in CompuServe and at:
http://www.microsoft.com/kb/peropsys/windows/q90271.htm
Security of the Windows for Workgroups Password Cache
_____________________________________________________
The password list file is encrypted with an algorithm that meets the U.S.
government Data Encryption Standard (DES). This encryption technology is
the highest security allowed in software exported from the United States.
The odds of breaking the encryption algorithm are less than those for
random guesses of what the password might be.
Even if your logon password is blank, Windows for Workgroups generates
seemingly random data in your PWL file, so you cannot discover the
passwords if you look at the PWL file using a file viewer. Currently, no
user interface exists that allows you to unencrypt passwords in the PWL
file, so password caching in Windows for Workgroups is as secure as the
choice of the password used to encrypt your PWL file.
As Microsoft well knows, this is completely untrue. The rest of the world
has known that this is untrue since November 29th. Microsoft quietly
acknowledged on December 7th (after a day of much "Internet Strategy"
hype, and after the deadline for the morning papers) that the exact same
implementation was insecure in Windows 95, and claims to have released a
patch that fixes the problem (the efficacy of the Win95 patch does not
appear to have been verified by anyone outside Microsoft, however).
Microsoft has not even admitted that this bug in both Windows 95 and
Windows for Workgroups affects Windows for Workgroups, apparently because
they have decided not to fix it.
Information on the .PWL implementation bugs was first broached on the
sci.crypt newsgroup in late November 1995, then discussed on the
cypherpunks list and refined for Community ConneXion's "Hack Microsoft"
promotion, http://www.c2.org/hackmsoft/.
We have since been given a sample trojan horse that will very efficiently
exploit this bug in Windows for Workgroups. Distributed as a Word Basic
virus, MIME attachment, or downloadable archive (note that Exchange and
Internet Explorer unwisely execute downloaded binaries without even a virus
check, a problem that Sun's Java has long acknowledged and addressed), this
trojan horse could collect passwords and other sensitive information from
.PWL files and other sources and send them out via e-mail, possibly through
an untraceable chain of remailers or to a throwaway trial account on, for
example, America "Online."
We believe that it would be highly irresponsible to release the full version
of this hack, but we will soon release a crippled demonstration-only version
if Microsoft does not at the very least admit that this problem has always
affected Windows for Workgroups, correct their online documentation, publish
the specifications of the Win95 security patch for review by outside
security experts, and issue a public retraction.
See also:
http://www.microsoft.com/kb/peropsys/windows/90210.htm
http://www.microsoft.com/windows/pr/clarifications.htm
http://www.c2.org/hackmsoft/
http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html
{mirror of above} http://www.mari.su/guide/win95/
{mirror of above} ftp://ftp.demon.co.uk/pub/mirrors/win95net/
{more mirrors are under construction in Australia and elsewhere}
In other news, I assume everyone knows by now that NT's claimed C2 security
rating was granted *for use a standalone workstation only*. It has been
widely reported that its NetWare Services implementation does not ask for
passwords for nonexistent usernames, making a potential cracker's job that
much easier. The correct response, which is given by real NetWare servers
and other servers that are certified C2-secure on networks, is to silently
ask for a password in all cases.
I started getting copies of hackmsoft@c2.org mail on December 20th. It's
really depressing.
We've also seen problems with Microsoft Access 95's security. Basically,
there is none. Anyone can access the network-enabled Access as any user
without knowing the password. We don't think it would be responsible to
publicly release this hack, either, until Microsoft has had another chance
to patch the hole (they've known about it for some time).
These are far, far worse than the widely publicized bugs in Netscape's SSL
implementation, which have been fixed. Yet the only place I've seen them
mentioned is the lapdog Seattle Times, which only reports bug *fixes* in
glowing terms.
Is anybody listening?
- -rich
owner-win95netbugs@lists.stanford.edu
ftp://ftp.stanford.edu/pub/mailing-lists/win95netbugs/
gopher://quixote.stanford.edu/1m/win95netbugs
http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html
------------------------------
Date: Tue, 09 Jan 96 11:27:23 PDT
From: tekolste.kurt@ist.vf.mmc.com
Subject: Configuration files may travel
I have not been a participant in this newsgroup, so I am trusting the advice
of someone who is that the following constitutes a risk of interest.
Concerned about the amount of disk space on my laptop, I opted to use the copy
of Netscape on my company's server. I configured Netscape to my parameters
and used it this way until I realized that it was important enough to live on
my C: drive.
A few months after running Netscape from the server, I began to get an
occasional e-mail which seemed to be intended for someone else. It took me a
while to realize that my netscape.ini file had been saved on the server, not
on my laptop. Apparently, other employees were copying the INI file and, not
knowing how to properly set it up, were leaving my return address in place.
The primary risk here is clear: saving various .cfg, .ini, etc. files in the
default location determined by the application may result in the information
in those files being made available to the public. Since these files may
include logon names and passwords, care must be taken to ensure that they are
saved in appropriate locations.
There is also a secondary risk: by intentionally supplying a .cfg or .ini
file of his/her own design to the common server, a hacker could configure the
apps of the unwary in ways which are not wanted.
------------------------------
Date: Tue, 09 Jan 1996 23:38:54 +0100
From: M.VIRTEL@bionic.zerberus.de (Martin Virtel)
Subject: Re: Brunnstein / Compuserve / Germany
Klaus Brunnstein's work is of great value for the computing community, but
he messed up some concepts of German criminal law.
KB: CompuServe OVERREACTED in blocking access to ALL these
electronic fora WORLDWIDE. As most national laws (with
exception of some laws requesting universal applicability :-),
German law deliberately applies to Germany :-)!
Wrong. In special cases, German criminal law claims international validity.
One of these cases (listed in Par.6 of the Criminal Code) is the
distribution of pornographic material containing "violent actions, sex of
human beings with animals or child abuse" ["Gewalttaetigkeiten, den
sexuellen Misbrauch von Kindern oder sexuelle Handlungen von Menschen mit
Tieren"].
KB: Either was CompuServe TECHNICALLY UNABLE to react ONLY FOR
GERMAN users (and leave worldwide users unaffected).
This was the case, according to German media reports. TV newscast "Frontal"
reported Tuesday evening that CompuServe is rewriting its Software to allow
Internet access control according to the nationality of the user. But
regarding child pornography and the german law, this wouldn't help
CompuServe much. - see above -
KB: The procedure of Bavarian State Attorney may have one week point
in whether the term "writing" (evidently meant by legislators as
applying to traditional paper-work) may apply to "electronic
documents" even in "virtual form".
Wrong again. Par. 11 Sentence 3 of the Criminal Code defines the word
"writing" ["Schriften"] as applying to audio and video storage systems,
pictures or any other form of representation ["Ton- und Bildtraeger,
Abbildungen und andere Darstellung"]. Technically, this is a so-called "open
catalog" definition, this means that any attorney or judge can add any form
of representation of a contents he or she chooses appropriate - even
non-physical representations on screens.
So, where's another RISK?
Any CompuServe Executive reading comp.risks? No?
RISK! RISK!
Martin Virtel
[Etliche Mispelungen von PGN korrektiert (hoffentlich!).]
------------------------------
Date: 09 Jan 96 08:15:43 EST
From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
Subject: Attacking CompuServe Subscribers
In an excellent analysis of the stupidity of CompuServe staff in
overreacting to the Bavarian request for cooperation in stopping the
distribution of child pornography in their jurisdiction <Metaphorplay on
Compuservile>, Henry Baker wrote the following dismaying text:
> Copyright (c) 1996 by Henry G. Baker. All rights reserved.
> ** Warning: Due to its censorship, CompuServe and its subscribers **
> ** are expressly prohibited from storing or copying this document **
> ** on CompuServe in any form. **
I and many other CompuServe (CIS) users despise the decision to apply a
blanket prohibition against the news groups. At the same time, I protest
the inclusion of this prohibition in the RISKS FORUM DIGEST.
1) CompuServe is a private organization, not a government agency. If
CompuServe management were to decide to prevent access to news groups with,
say, the letter "k" in the third place of the name, its customers could (a)
protest to CIS management; (2) obtain Internet access through another
supplier; and (3) cancel their subscriptions. However, there would be no
violation whatever of free speech in such action, even though it would be
stupid, counter-productive and offensive. A commercial service has no
requirement to provide all possible services--it merely supplies services
and takes the commercial consequences of its actions.
In the current case, if enough CIS users require access to the banned
groups, the economic consequences will be borne by CIS owners and
shareholders. Treating us CIS subscribers as pariahs because we find the
balance of services at CIS acceptable even with the stupid ban is itself a
bizarre overreaction.
So Mr Baker wants to punish subscribers to CIS because it DOESN'T provide
access to all news groups. What's next, punishment of subscribers to
services who provide access to new groups that he _dislikes_? Is Mr Baker
aligning himself with the lunatics in the far-right religious fringe who
would jump on _him_ for subscribing to an Internet access provider which
_does_ allow access to news groups _they_ disapprove of?
How would Mr Baker respond to a suggestion that CompuServe ban all postings
from people with netcom.com addresses? Would that seem fair? Why not?
2) CIS is not simply an Internet access provider. Many users depend on
the service for access to databases simply unavailable on the Internet. Why
should Baker or anyone else single us out for punishment in this way?
3) The internal response from CIS subscribers on CIS management has
been enormous--and negative. There have been thousands of messages all over
the service in which the ban is dissected; there have also been public
meetings in the CIS Conference Rooms where the issues are analyzed.
Baker's prohibition prevents me from supplying ammunition to the very forces
who are on Baker's own side of the argument. His article would normally be
posted in the NCSA Forum where it could be read by 50,000 members who could
then build on his contribution. Now it will be available only in the
archive copy of RISKS instead of in the public Forum. Pity.
4) Because many of us receive the RISKS FORUM DIGEST via e-mail on
CompuServe, we simply cannot comply with Baker's prohibition even if we
wanted to. The DIGEST did indeed reside on CIS computers until I downloaded
it from my e-mail in-basket. Since I certainly will not unsubscribe to the
DIGEST simply because one correspondent wishes to punish all CIS users, I
will continue to receive his occasional contributions whether he wants me to
or not. I suggest that Baker either stop publishing his messages in the
DIGEST or stop appending his offensive signature text.
5) The National Computer Security Association (NCSA) makes RISKS FORUM
DIGEST archives available in a Library in the NCSA FORUM. Is Mr Baker
proposing that we _edit_ the RISKS FORUM DIGEST to remove his contributions?
Preposterous. I refuse to tamper with the contents of the DIGEST simply
because one individual is in a snit about some jerk of a CIS manager's
decision to go into hysterics over a request from a Bavarian prosecutor.
If Mr Baker has a problem with that, I suggest he contact a lawyer.
6) The NCSA extracts certain individual articles from the RISKS FORUM
DIGEST and other Internet publications for inclusion in specific sections of
the Forum; for example, this message will appear in the PRIVACY/ETHICS
section of the NCSA Forum. Contrariwise, several Sysops from the NCSA Forum
cross-post our summaries of news wire service articles to RISKS and other
new groups. The arrangement makes the information and opinions available to
a wider audience than would otherwise see the contributions.
One contributor to RISKS has requested that we NOT post his contributions to
the Forum and we have complied with his request even though we think it is
ridiculous for him to stop the 50,000 people in the NCSA Forum from seeing
his public postings. We will comply with Mr Baker's implicit request as
well even though it's a nuisance to have to remember that these two
individuals have such a prohibition in place. I shudder to think what will
happen if lots of people append this kind of restriction on their postings.
The more fundamental issue for RISKS FORUM DIGEST and news group moderators
and users in general is whether it is acceptable for a contributor to (1)
post a message for worldwide distribution and simultaneously to demand that
it not be received by or redistributed to users of specific services.
Mr Baker's prohibition is an example of the very problem he attacks in his
message. Carried further, one might see demands that a message not be
available to subscribers of a service because specific users of that service
have spammed the Net; or because the managers wear ties; or because people
who eat meat subscribe to the service; or .... the possible targets of
prejudice are infinite.
If Mr Baker doesn't want his message to be public then he shouldn't post it
in public.
I hope that Mr Baker will reconsider his offensive signature string and that
no one else will include such prohibitions in their contributions to RISKS.
M.E.Kabay,Ph.D. / Dir. Education & Chief Sysop of CompuServe NCSA Forums
Natl Computer Security Assn (Carlisle, PA)
------------------------------
Date: Tue, 9 Jan 1996 09:38:22 -0800 (PST)
From: hbaker@netcom.com (Henry G. Baker)
Subject: Attacking CompuServe Subscribers
[Henry's response to Mich's message follows. I generally truncate most
of the unusual trailers, and reject a priori all messages with restrictive
redistribution, but I ran Henry's message with its "copyright" notice
sensing that it might just help to raise the level of awareness to this
particular issue. However, don't expect other messages to get by with
such restrictions. PGN]
I have nothing against Compuserve subscribers themselves. I hope to
continue fruitful dialog with them through other ISP's. There is currently
a wide choice of excellent, inexpensive, non-censoring ISP's, but how long
this choice will remain due to government interference is very much in
doubt.
Compuserve apparently lost their backbone and refused to fight for their
subscribers, so why should their subscribers fight for Compuserve?
Subscribers should all put their subscriptions 'in escrow' until full
Internet service is provided, the same way that tenants put their rent in
escrow until the landlord fixes their electricity, their water, or their
sewer(!) ;-)
Paraphrasing Shakespeare, Compuserve should screw their courage to the
sticky post.
Re: minor inconveniences
Our forefathers fought and _died_ for the right to free speech. Do you
think anyone should have any sympathy for this whining about the minor
inconvenience of changing ISP's?
Henry Baker www/ftp directory: ftp.netcom.com:/pub/hb/hbaker/home.html
------------------------------
Date: Mon, 08 Jan 1996 08:26:11 -0500
From: Phillip C. Reed <reedpc@libbey.com>
Subject: Floating Point Number formats (Bowmer, RISKS-17.60)
> "Microsoft had their own floating point format for a while.
> What was it? Was it binary, too? Or did it have a BCD-type storage?"
Writing as somebody who once had to convert a database from an old Microsoft
Fortran format to a more standard system, I can state with some authority
that the floating point number format Microsoft used to use was indeed
binary, and it was indeed some goofy format that nobody else used. I can't
say whether it was subject to the same kind of inherent errors that the IEEE
floating point format has, but it did have the generic floating point
conversion problems.
Phil Reed Libbey, Inc reedpc@libbey.com
------------------------------
Date: Mon, 8 Jan 1996 21:54:59 -0800 (PST)
From: Andrew Robson <arobson@Gateway.Uswnvg.COM>
Subject: Reliable development methodology (Mellor, RISKS-17.60)
Your article "Re: X-31 crash follow up" in RISKS-17.60 tends to trivialize
the importance of development methodology for reliable systems in favor of
more thoughtful programmers. While this attitude may be appropriate to your
role in training programmers, I would hope that the majority of RISKS
readers would not give it too much weight.
Locating the source of a design fault is not a futile waste of time in many
cases. You do, however, have a clue as indicated by your parenthetical
"except perhaps during an internal post-mortem to decide whose head is going
to roll!" The identification of the source of the problem often determines
who pays for the change, and perhaps pays damages for the failure. More
importantly it can identify flaws in the development methods used and
prevent future failures.
Your first point is very dependent on *who* thinks the flaw is obvious. For
every user experience problem fixed, two problem reports get satisfied with
a change to the documentation to remove reference to a non-existent feature
deemed unimportant.
You may believe that "The omission of an obviously desirable feature IS A
DESIGN FAULT." but the user will probably pay for an upgrade to get that
feature.
What constitutes "required behaviour" *is* merely "what is in the
specification" when deciding whether you have to pay the invoice, and
usually in the test plan. Whether you get "WHAT A REASONABLE USER WOULD
EXPECT" depends on the quality of both the vendor and the specification. If
it is in the specification, it is likely to get tested and actually work
correctly when needed.
High reliability systems cost much more to develop than systems that only
need to work fairly well. I would prefer to anticipate this, and invest in
attempting complete and accurate specifications, than to hope that every
programmer will understand the big picture well enough to make their own
design decisions. I would like the programmer to be rewarded for
identifying a specification flaw to the designers, but proceed to build the
design until it changes.
Andy Robson
------------------------------
Date: 9 Jan 1996 02:25:06 GMT
From: desmedt@cs.uwm.edu (Yvo Desmedt)
Subject: New Security Paradigms '96 -- Call for papers
PRELIMINARY CALL FOR PAPERS
NEW SECURITY PARADIGMS '96
A workshop sponsored by ACM SIGSAC, the Department of Defense, and the
Aerospace Institute:
UCLA Conference Center
Lake Arrowhead, CA
September 16-19, 1996
Paradigm shifts disrupt the status quo, destroy outdated ideas, and open the
way to new possibilities. This workshop explores radical new models for
computer security, such as strategies for securing very large networks,
providing software safety in large systems, and developing ethics in
international cyberspace. The goal is to develop transcendent solutions
that provide the flexibility and interoperability users require in trusted
systems.
We offer a creative and constructive workshop environment for about
25 participants at the beautiful UCLA Conference Center on lake Arrowhead
in the San Bernardino Mountains, California. Dress is casual. The tone is
exploratory rather than critical. The refereed papers will be printed in a
workshop proceedings. To participate, submit either a research paper or a
5-10 page position paper, preferably via e-mail, to Program Chairs Catherine
Meadows and David Bailey at the e-mail addresses listed below by April 1,
1996. Alternately, submit five copies of a hard-copy paper to either
program chair by March 24, 1996. The Program Committee will referee the
papers and notify authors of acceptance status by June 9, 1996.
Scholarships are available.
As it becomes available, more information will be provided on-line.
E-mail to: newparadigms96@itd.nrl.navy.mil
Use anonymous FTP from: chacs.itd.nrl.navy.mil
in directory /pub/newparadigms96
Use World Wide Web from:
http://www.itd.nrl.navy.mil/ITD/5540/acm/new-paradigms.html
NEW SECURITY PARADIGMS '96
WORKSHOP ORGANIZERS
Steering Committee: Hilary Hosmer, John Dobson, Catherine Meadows,
David Bailey
Workshop Co-Chair:
Tom Haigh, Secure Computing Corp., 2678 Long Lake Road, Roseville, MN
(612) 628-2738 (voice) (612) 628-2701 (fax) Haigh@sctc.com (e-mail)
Workshop Co-Chair:
Hilary Hosmer, Data Security Inc. 58 Wilson Road, Bedford, MA
(617) 275-8231 (voice and fax) Hosmer@dockmaster.ncsc.mil (e-mail)
Program Committee Co-Chairs:
Catherine Meadows Naval Research Laboratory
Code 5543 Washington, D.C. 20375
(202) 767-3490 (202) 404-7942 (FAX)
e-mail: Meadows@itd.nrl.navy.mil
David Bailey, Galaxy Computer Services
PO Box 21069, Albuquerque, NM 87154
(505) 296-8805 (voice) (505) 298-4834 (fax)
daveb@gcsi.com (e-mail)
Program Committee:
Rebecca Bace, Department of Defense
Dimitris Gritzalis, Univ. of the Aegean
Deborah Hamilton, Hewlett Packard
Victoria Jones, Univ. of Illinois
Tom Lincoln, M.D., Rand Corporation
Ruth Nelson, Information System Security
Pierangela Samarati, Universita di Milano
Marvin Schaefer, Arca Systems
Jeff Williams, Arca Systems
Jim Williams, MITRE
John Yesberg, DSTO, Australia
Local Arrangements: Daniel Essin (UCLA) (213) 226-3188
Scholarships: Ravi Sandhu (George Mason University) (703) 993-1659
Publications Chair: Marv Schaefer, Arca Systems
Publicity: Yvo Desmedt (Univ. of Wisconsin) (414) 229-6762
Treasurer and Registration Chair: Dixie Baker (SAIC) (310) 613-3606
ACM SIGSAC Chair: Ravi Sandhu (George Mason Univ.) (703) 993-1659
ACM Senior Program Director: Julie Goetz (ACM, 1515 Broadway, NY)
(212) 626-0610
------------------------------
Date: 6 September 1995 (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 further 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, and nonrepetitious. Diversity is
welcome, but not personal attacks. [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
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://unix.sri.com/risks [if your browser accepts URLs.]
------------------------------
End of RISKS-FORUM Digest 17.62
************************
