Subject: RISKS DIGEST 17.14
REPLY-TO: [email protected]

RISKS-LIST: Risks-Forum Digest  Friday 19 May 1995  Volume 17 : Issue 14

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

************ Probably NO RISKS ISSUES NEXT WEEK ************

 Contents:
Positive-Ion Dangers: Computers and stress / depression (Dan S)
Automated Loan Applications (Rick Russell)
The Risks of random PINs (Bill Fenner)
Denial of Service attack at AOL (Ben Blout)
Computer-controlled lock failure in hotel (Rick Simpson)
Same scam, new venue (Bob Frankston)
Name matching, again... (Bob Frankston)
Nielsen, others to rate Internet, related RISKS (Mark Seecof)
Integrity of archived data, standards for media retirement (Patrick Casey)
Re: Year 2000? Don't forget 1752! (Melvin Klassen)
Date and time and MS-DOS (Erling Kristiansen)
RISKS in Microsoft's Windows95 (Steve Loughran)
Re: Microsoft plans corporate espionage (Raymond Chen)
SAFECOMP 95 (Martyn Dowell)
ABRIDGED Info on RISKS (comp.risks) [See other issues for full info]

----------------------------------------------------------------------

Date: 17 May 1995 15:53:24 -0400
From: [email protected] (DanielS222)
Subject: Positive-Ion Dangers: Computers and stress / depression

As an engineer who spent 12 hour days programming Fortran in college, and
who now sits in front of a computer all day at work, I thought this would be
of great interest to you.

On 2/14/95 CBS Evening News with Connie Chung, Dr. Bob Arnot did a story
about negative ions and their effect on mood.  They talked about a study
done at Columbia University where exposure to a high density negative ion
generator was as effective in treating winter depression as medication.

I became very interested because I have suffered from depression and
anxiety for years, and I did extensive research on the benefits of
negative ions.

This research turned out to be especially interesting to me because I
found a newspaper article discussing the fact that computer monitors emit
positive ions - the opposite of negative ions.  In the article, a
consultant to the FDA says that computer monitors give off large amounts
of positive ions and can actually cause depression, stress, fatigue, etc.
in people who sit in front of computers a lot - like all of us Netters -
and that we need negative ion replenishment.

After reading the newspaper article, I realized that I always felt
especially irritable, stressed, and depressed after long days in front of my
computer.

In doing the research, I found that negative ions have shown to be
therapeutic for stress, irritability, fatigue, depression, etc.  So I
purchased a small, high density generator and it has given me substantial
relief from my symptoms.

If any of you would like me to e-mail you that newspaper article, the
transcript of the CBS news story, as well as the other research that I
have compiled, just e-mail me at [email protected].

-dan

------------------------------

Date: Thu, 18 May 1995 14:54:55 -0500 (CDT)
From: [email protected] (Rick Russell)
Subject: Automated Loan Applications

Headline News reported today (18 March 1995) that the nation's two largest
home mortgage underwriters, Fannie Mae and Freddie Mac, will shortly be
deploying computer systems that will allow for instantaneous analysis of
one's loan application. It appears that, given a user's name, recent
paycheck stub, W-2 form, appraisal etc, the system will perform automated
checks and approve mortgages without the intervention of a human
underwriter.

"The machine never says no," we are told, if a loan application is
"questionable" it is referred to a human underwriter for review.

I guess the RISKS are obvious, but I'll state them anyway -- if business is
good, and the human underwriter feels like playing golf instead of reviewing
loans, the loan application may be "referred" to the circular floor-mounted
file cabinet with no substantive explanation to the applicant. The news
story didn't mention whether the algorithm used some simple set of minimal
requirements, or if a neural net or expert system was involved. If the
latter, an even larger and potentially nastier set of RISKS are apparent.

Rick R.  [email protected]

------------------------------

Date: Tue, 16 May 1995 10:59:30 PDT
From: Bill Fenner <[email protected]>
Subject: The Risks of random PINs

I received a letter in the mail the other day from my credit card company,
kindly informing me that I can get cash with my credit card from any ATM,
and that they had selected a nice random PIN for me.  Lo and behold, the
randomly-selected number was my birthday!  I called the credit card people
up, and the operator was somewhat amused, as she claimed that the number was
"picked by a computer" and it was an "amazing coincidence" that it was my
birthday.  I asked them to pick me a new random PIN, and just yesterday
received a new letter from the bank with my new random PIN, which was
exactly the same as my old random PIN.

Would it really cut the random number space down too far to remove all
"obvious" dates?  Heck, in this day and age, they probably *know* my
birthday...

 Bill

------------------------------

Date: Tue, 16 May 1995 01:59:12 -0400
From: [email protected]
Subject: Denial of Service attack at AOL

I learned the hard way that one can apparently cancel the account of any AOL
(America On Line) member with a simple phone call.  About two weeks ago I
suddenly could not log on to AOL.

Following the on-screen directions, I called the 800 number for customer
service.  A nice gentleman there explained that someone had called in
earlier in the day and asked for my account to be canceled.  It was!  This
was even though the person calling could not (according to AOL's own
records), provide the credit card number used to pay for the account as
verification of their identity.  The gentleman helping me also volunteered
that an account could be canceled by leaving after-hours voice mail at the
customer service number.

My woes were exacerbated by an error made when my account was reactivated.
My account was reactivated 10 minutes after my phone call, but my incoming
mail service was not turned on for an additional week.  I had to make a
second (30 minute) phone call to correct this, and wait another day.

The total lack of verification of who is calling seems to be a poor policy.
What if I had not logged in for three weeks?  I would have lost three weeks
of RISKS!  I tried to suggest that they leave incoming mail enabled for a
few weeks after an account is cancelled without complete verification.  The
people I spoke to didn't seem too interested.

-Ben Blout

------------------------------

Date: Tue, 16 May 95 11:08:05 -0500
From: "Rick Simpson" <[email protected]>
Subject: Computer-controlled lock failure in hotel

When I checked into my hotel on a recent business trip, I was told that the
hotel was "having a problem with the locks" and that my room would be
re-keyed sometime the next day.  The room locks in this particular hotel use
plastic cards with magnetic stripes rather than traditional metal keys.

Sure enough, when I came back the next evening my key wouldn't work; the
room had been re-keyed.  The hotel sent a security person up to let me in
and give me a new key.  He was unable to open the door: the new key didn't
work, nor did any of his master keys.  More security people came, more
master keys, same result; the door would not open.

Next to arrive were the maintenance people with the lock re-keying device.
This turned out to be a lap-top computer with a special adapter attached to
the serial port.  The locks, it seems, contain battery-operated
microcontrollers.  Re-keying consists of inserting a special master key,
then a second special master key, and then the lap-top computer's re-keying
adapter.  The lap-top then communicates with the processor in the lock and
causes it to register a new key code.

All this was to no avail -- the lock failed to open regardless of what key
was inserted, whether ordinary room key or master key.  Eventually the
maintenance people had literally to break into the room.

In discussions with the security people, I learned that what started all
this off was a head crash on a disk.  The hotel had lost track of which key
codes went with which rooms because of the unreadable disk.  As a result,
the front desk couldn't just "write" new keys as guests checked in.  The
hotel started the process of re-keying all the locks in order to create a
new key code file.  This worked OK for all but a couple of the 600+ rooms,
mine being one of the failures.

Risks?  Obviously, not having a usable backup for the crashed disk is the
first risk.  This cost the hotel lots of employee-hours and some ill will
from frustrated guests, not to mention the physical damage to the door of my
room caused by breaking in.

The more subtle risk is in the locks themselves.  I had stayed in this hotel
many times before, but I had not noticed that the locks operated ONLY on
magnetic stripe cards.  Many such mag-stripe locks in hotels also have a
traditional, mechanical lock that can be used by the cleaning and security
people even if the mag-stripe mechanism fails completely.  These locks had
no such redundancy.  I'm surprised that the hotel would ever allow itself to
be in the position of being unable to enter a room in an emergency due to
the simple failure of a battery-operated lock controller, other than by
breaking down the door.

Rick Simpson, IBM T. J. Watson Research Center, P.O. Box 704,
Yorktown Heights, NY 10598  +1 914 784 6712  [email protected]

------------------------------

Date: Sat, 13 May 1995 19:49 -0400
From: [email protected]
Subject: Same scam, new venue

>From the New York Times

 One 29-year-old woman in Brooklyn in the Home Relief welfare program was
 sent more than 200 checks totaling $350,000 over seven months, prosecutors
 said.  Five other got $96,950 to $246,925 each, according to the
 authorities, who said the welfare recipients then shared the money with
 the clerks.  By yesterday evening, 62 welfare recipients were under arrest
 and more than 30 were being sought.  [...]

 "It was very easy for the data entry person to do this because there were
 absolutely no controls or checks on the computer system," said Howard
 Wilson, the Commissioner of the City's Department of Investigation, which
 began the inquiry 18 months ago.  "That corrupt employee being at that
 critical point in the process was able to literally push the button and
 out came the money."

 Prosecutors would not discuss many aspects of the scheme, including how
 the clerks and the welfare recipients started working together.

The risks are obvious, but how much is it a risk of technology vs standard
procedure? Would a supervisor have been more likely to check in a manual
system? Is there more leverage for fraud in the computer-based system? Or is
it just one more example of lax procedures. One can, in fact, argue that
much of the value in computerizing a system is doing a critical evaluation
of existing and new procedures. This step seems to have been omitted in this
case.

------------------------------

Date: Wed, 10 May 1995 16:35 -0400
From: [email protected]
Subject: Name matching, again...

US News & World Report, May 15th had a story about a known terrorist being
granted a visa because there wasn't a match on his name in the State
Department's database. To quote the article:

"The State Department, which issued Khalifa his visa, declines to discuss the
case. A knowledgeable official says that when the U. S. Embassy in Riyadh ran
a check to see if its computer would flag Khalifa's name on the State
Department's terrorism watch list, it failed. The problem is the English
rendering of Arabic names. One State Department official explains, "Mohammad
has several different spellings in English." (My spelling checker had
Mohammed).

The risks are obvious especially when compared with the small costs for
better (but not perfect) matchin. The more interesting question is the
process by which these things happen. There has been lots of
government-sponsored research into far more difficult problems. Why does this
knowledge not extend to critical systems outside the well funded security
services? Perhaps for the same reasons that our air traffic control system is
a creaky antique.

Usual caveat: the news article might be wrong and maybe there are entirely
different issues here. With very nonEnglish common names and mixed standards
for identification, the problem is more difficult than just soundex.

------------------------------

Date: Thu, 18 May 1995 17:05:20 -0700
From: Mark Seecof <[email protected]>
Subject: Nielsen, others to rate Internet, related RISKS

In an article by Susan Carey headlined "Three Market Researchers Team Up to
Provide Data for On-Line Services" the Wall Street Journal reported on page
B7, Wednesday 17 May 1995, that ``Three of the nation's leading
market-research concerns have teamed up to develop research services for the
on-line world.''

(Errors in the following summary may be M. Seecof's fault.)  Since measuring
``hit rates'' on WWW pages and like resources isn't a very effective or very
informative method of measuring interest or usage (especially with large
ISP's planning to cache data from popular servers to improve response time
to their customers--effectively masking such usage from the real
providers--and, BTW, the copyright and other issues here deserve a separate
discussion to which I hope to contribute at another time), Neilsen Media
Research (yes, the TV ratings folks), Yankelovich Partners, and ASI Market
Research plan to develop and deploy means of measuring first WWW and later
other kinds of Internet resource usage and provide such information to
clients.  Their joint venture is called ANYwhere Online.

(The article did NOT say...) I think this is interesting.  Ideally, one
wants data not just from servers instrumented by ANYwhere Online
(hereinafter ANY-O) but from other servers as well.  In the TV world,
Neilsen measures usage of all servers (TV stations/videotape) by a sample of
the client population and extrapolates by statistical inference to usage by
the whole client population.  One could certainly do this in the Internet
world.  But consider another tactic.  One could instrument Internet routers
or links and measure traffic to various destinations.  I suspect that Bill
Gates intends to instrument UUNET/AlterNet's backbone to gather data on his
competitors.  For a fee, he could provide a digest of such information to
ANY-O (or anyone).  Other commercial ISP's could do likewise.  This kind of
traffic analysis could be exploited for commercial or other purposes.  I
look forward to learning from ANY-O whether they will use TV/
radio-measuring tactics, data from selected servers, data from backbone
traffic analysis, or some combination.

I would like to point out what I see as a big RISK for people who don't want
their traffic analyzed (whether for personal, or commercial-competitive
reasons): no current commercial ISP promises NOT to collect and sell
information about net usage by customers.  We can use end-to-end encryption
(e.g., PGP) to limit content snooping by ISP's but typical public-access or
commercial services, via e.g., WWW protocols use cleartext.  Even if we
expect the quantity of such traffic to hamper content-snoops, traffic
analysis by or with the cooperation of ISP's could have grave competitive or
privacy implications.  I think that commercial Internet users should demand
privacy clauses in their contracts with ISP's *NOW*, because tomorrow it'll
be too late.

Mark Seecof <[email protected]>  My employer may not share my opinions.

------------------------------

Date: Mon, 15 May 1995 10:23:44 -0600
From: [email protected] (Patrick Casey)
Subject: Integrity of archived data, standards for media retirement

A few months ago, our computing organization invited our EDP auditors in to
have a look at backup procedures. One of the findings in the auditor's
report was "there are no established procedures for preservation of magnetic
media to provide assurance of the long-term integrity of archived data.
Also, no written standards exist that denote when specific types of magnetic
media are to be retired. The only procedure observed is that generally
magnetic media are not reused if a read or write error has occurred."

We are wondering what other organizations have in the way of established
procedures to provide assurance of the long-term integrity of archived data,
and standards on when specific types of magnetic media are to be retired.

Any comments or suggestion would be greatly appreciated.

Patrick Casey, Indiana University, University Computing Services, 750 North
SR 46 Bypass, Bloomington, IN 47405  (812) 855-8745  [email protected]

------------------------------

Date: Tue, 9 May 95 17:11:12 PDT
From: [email protected] (Melvin Klassen)
Subject: Re: Year 2000? Don't forget 1752! (RISKS-17.11)

Switch to the SAS(r) software.  It correctly calculates back to 1582 AD,
nearly 200 years "better" than Sybase(r) software.

------------------------------

Date: Tue, 9 May 95 09:50:23 +0200
From: [email protected] (Erling Kristiansen)
Subject: Date and time and MS-DOS

I was recently plotting some data originating from a measurement and data
logging program on a PC under MS DOS.

To my surprise, the time on my plot was not increasing monotonously;
rather, it was occasionally jerking backwards by a considerable amount
for a single data point. I took a look at the raw data file to try to
discover what happened. It appeared that the first data point after
each midnight (the test was running for several days) still had the
date of the previous day.

I consulted the author of the software who gave the following, rather
alarming explanation:

In DOS, the time and the date are updated by separate interrupts. The
time update has higher priority than the date update (I wonder what the
logic behind the different priorities is?? The only explanation I can
think of is: The date is updated less frequently, so it has less
priority, which is not a very sound reasoning).

It is, therefore, possible to read out the date and time at a moment
just after midnight where the time has been updated, but the date is
still the old one.

In our application, a measurement is triggered at given times, one of
which is exactly midnight. The measurement generates a lot of activity
for a few seconds, preventing the date interrupt from getting served
for some time.

As a result, the first measurement of each new day consistently has the
time 00:00:06, and the date of the previous day.

Our application is probably rather exceptional in allowing the wrong day to
persist for seconds. More common applications may only see this for
milliseconds or microseconds, so not many people are likely to ever see the
problem. (We could get into a long discussion, similar to the Pentium
arguments, whether this is good or bad. I will spare you this).

I will also spare you a discussion of possible work-arounds. What remains is
the amazing fact that anybody can dream up a system in which the updating of
date and time is not an atomic operation.

------------------------------

Date: Fri, 19 May 1995 12:01:31 +0100
From: "Steve Loughran" <[email protected]>
Subject: RISKS in Microsoft's Windows95

I've been using win95 for over year now, so can probably make some fairly
accurate comments.

Firstly, I don't know about the "Registration Wizard", but that's because
I can't connect to the Microsoft Network. It seems that whoever entered
the table of area codes got Bristol's revised code wrong.

Secondly, the latest beta releases are a lot easier to install than the
early builds, and a lot of legacy hardware and software does work -more
than with Windows NT for example. It is of course useful to have a sheet
of paper listing your IP address, subnet mask and DNS server, because you
will be asked these questions near the end of the installation, when it
is too late to look at the old files to find these facts out.

Finally, Autorun does seem a nice concept, and certainly for home users
it makes sense in terms of ease of use. It's cool for audio disks.

It is claimed to work on any "disk drive" which supports removable media
and automatic insertion notification. That means CD-ROMS, PCMCIA Cards
and perhaps floppy drives on "Windows 95" PCs which can indicate the
presence or absence of a floppy disk.

Now personally I like the idea of scanning a new disk for viruses, even
if it does take forever on a large CDROM, so was a bit unhappy about the
concept of autorun disks. After a bit of research I found that there is
an entry in the Registry which lets you choose which program gets run, or
possibly disable autoplay altogether. So in fact it may be possible to
configure autoplay to run a virus scanner over every new disk...

       -Steve

References (relevant quotations on request):
       Windows 95 guide to programming
       Microsoft Developer Network CD, April 1995

[Disclaimer: Windows 95 is still only in Beta, so any details which I or
anyone else provide about it may not be valid by the time the product is
released.]

Steve Loughran Hewlett-Packard Laboratories, Bristol, UK
[email protected]  +44 (117) 922 8717

------------------------------

Date: Thu, 18 May 1995 18:09:15 -0700
From: [email protected] (Raymond Chen)
Subject: Re: Microsoft plans corporate espionage

"In Short" column, page 88, _Information Week_ magazine, May 22, 1995:
:   Microsoft officials confirm that beta versions of Windows 95 include a
:   small viral routine called Registration Wizard.

The word `viral' here is quite inappropriate.  Moreover, the column makes
it seem as if this information is collected covertly and secretly uploaded.

Here's what happens, or at least, what happens today.  (Things might change
before the final release.)  When you select "Online Registration", the
"Registration Wizard" fires up and asks you the same sorts of questions that
would be asked by a paper registration form: name, address, etc.  It then
does a hardware scan, displays its findings, and asks you, "Do you wish to
include this information with your registration?"  Then it does a software
scan of the local machine (not "every system on a network" as originally
reported), displays its findings, and asks for the same confirmation to
upload.  This is all quite explicit, and users are required to confirm
whether or not to include the information in the registration.  There is no
default response, so an inattentive user cannot just keep hitting Return and
end up uploading the information by mistake.

After the questions are answered, additional prompts and confirmations
appear before the phone is dialed.

Other points for debate/discussion: There is no way to edit the hardware or
software inventory.  So if the hardware or software list is incorrect or
contains information that you'd rather not upload (e.g., beta hardware or
software), your only recourse is to suppress the information entirely.

 [As is customary here, Raymond's extensive disclaimers have been deleted
 by PGN, but are globally implied by the standard RISKS info item.]

------------------------------

Date: 19 May 95 15:04:15 +0000
From: [email protected]
Subject: SAFECOMP 95

The 14th International Conference on Computer Safety, Reliability and Security
Villa Carlotta, Belgirate, Italy  11-13 October 1995

Sponsors: European Workshop on Industrial Computer Systems Technical
Committee 7 (EWICS TC7) and European Commission Joint Research Centre -
Institute for Systems Engineering and Informatics (JRC-ISEI) Co-Sponsored by
IFIP Technical Committee 5 WG 5.4 and OCG, the Austrian Computer Society.
Organized by the European Commission - Joint Research Centre, and Institute
for Systems Engineering and Informatics.

Safecomp is an annual event which reviews the state of the art, experiences
and new trends in the areas of computer safety, reliability and security.
Safecomp was initiated by EWICS TC7 (European Workshop on Industrial
Computer Systems, Technical Committee 7) in 1979 and since then has been
held in Germany (Stuttgart, Fulda), UK (Cambridge, Manchester, Gatwick), USA
(West Lafayette, Anaheim), Italy (Como), France (Sarlat), Austria (Vienna),
Norway (Trondheim), Switzerland (Zurich), Poland (Poznan). The conference
focuses on critical computer applications. It is intended to form a platform
for technology transfer between academia, industry and research
institutions.  Safecomp is a one-stream conference and typically attracts up
to 150 participants.

ADVANCE PROGRAMME (preliminary)

Wednesday, October 11

09:15 Invited presentation :
A. Servida (EC) :  Dependability of safety-critical applications in the
IT Programme of the European Commission.

09:45 GENERAL ISSUES, GUIDELINES
E. Schoitsch (A): Software Best Practices in dependable systems:
The European Research Projects: ENCRESS, OLOS, ESPITI from the partners'
perspective.
H. Krebs  (D) : Assessment on the basis of standards   - Gaps and how
to bridge them

11:15 SAFETY ANALYSIS
A. Saeed, R. de Lemos, T. Anderson (UK) :  Safety Analysis for requirements
specifications: Methods and techniques

M. Chudleigh, J. Catmur, F. Redmill (UK) : A guideline for HAZOP studies on
systems which include a Programmable Electronic System

J.M.  Voas, K. W. Miller (USA) : An automated code-based fault-tree
mitigation technique

14:15 FORMAL METHODS
C.  Fencott, B. Hebbron, K. Chan (UK) :  Formal support for the safety
analysis of requirements model

J. Gorski, J. Magott, A. Wardzinski  (PL) : Modelling fault trees using
timed Petri Nets

I. D. R.  Shannon, A.J. Harrison  (UK) : The application of formal methods
to railway signalling systems specification and the ESPRIT III project CASCADE

16:15 HUMAN & LEGAL ASPECTS
R.J. Tiezema  (NL) : Eliminating the unexpected

S.J. Westerman, C.M. Crawshaw, G.R.J. HocKey, N.M. Shryane (UK) : Cognitive
diversity: A structured approach to trapping human error-

D. Davis  (UK) : Legal aspects of safety critical systems

Thursday, October 12

09:00 Invited presentation :
B. Littlewood (UK): How I learned to start worrying and fear the computer....

09:30 DESIGN
M. Heisel (D) : Six steps towards provably safe software

W. A. Halang, B. Kramer, N. Volker (D) : Formally verified building blocks in
functional logic diagrams for emergency shutdown system design

11:00 ASSESSMENT
G. Picciolo, P. Giannino  (I) : Programmable electronic controllers (PEC)
performance assessment - An approach for reliability quantification

W.  Schynoll  (D) : BOOTSTRAP: Europe's software process assessment &
improvement method, experiences and further developments

K. M. Hobley, P. H. Jesty (UK) :  Analysis and assessment of advanced road
transport telematic systems

14:00 SAFE SOFTWARE
J. Blieberger (A) :  Loops for safety critical applications

M. Viola  (CAN) : Ontario Hydro's experience with new methods for engineering
safety critical software

15:20 APPLICATIONS I
E. Ruiz Morales  (EC) : A software development approach for robotics control
systems

J.  Christmansson, Z. Kalbarczyk, J. Torin (S) :  An attempt to evaluate
functional diversity employed in a reactor protection system

A. Coombes, J. A. McDermid, J. Moffett (UK), P. Morris (EC): Requirements
analysis and safety: A case study (using GRASP)

17:10 APPLICATIONS II

A. J. C. Sharkey, N. E.Sharkey, O. C. Gopinath (UK) : Neural nets and diversity

C.  Rabejac (F)  :  On-line software error detection by executable assertions:
from theory to practice

Friday, October 13

09:00 Invited presentation :
J Heckmann, S. Shirlaw (F) : An industrial view on requirements engineering
and safety.

09:30 CASE STUDIES

F. Fenelon, J. A. McDermid  (UK) : Safety cases for software application reuse

P. G. Bishop, R. E. Bloomfield (UK) : The SHIP case study - A combination of
system and software methods

11:00 VALIDATION & VERIFICATION
R. Tiusanen, M.  Hietikko (FIN) :  Practical approach for the evaluation of
safety related programmable electronics

A. Anselmi, C. Bernardeschi, A. Fantechi, S. Gnesi, S. Larosa, G. Mongardi,
F. Torielli (I) :
An experience in formal verification of safety properties of a railway
signalling control system

A. Bondavalli, Chiaradonna, F. Di Giandomenico (I) :  Dependability of
iterative software: A model for evaluating the effects of input correlation

Request for full registration information should be addressed to
Safecomp'95, c/o M. Dowell, TP 361, Joint Research Centre, I-21020 Ispra
(VA) Italy, [email protected] .

Telephone and fax contact:

Dorit Schlittenhardt
JRC-Public Relations and Publications Unit
Tel:+39-332-789370 - Fax:+39-332-782435

Martyn Dowell
JRC-Institute for Systems Engineering and Informatics
Tel: +39-332-789478  - Fax:+39-332-789991  E-mail: [email protected]

------------------------------

Date: 24 April 1995 (LAST-MODIFIED)
From: [email protected]
Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info]

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.  [...]
REQUESTS to <[email protected]> (which is not yet automated).  [...]

CONTRIBUTIONS: to [email protected], 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
  Individual issues can be accessed using a URL of the form
  http://catless.ncl.ac.uk/Risks/VL.IS.html  [...]

RISKS ARCHIVES: "ftp unix.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.]

------------------------------

End of RISKS-FORUM Digest 17.14
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.