19-Jun-87 00:25:59-PDT,29118;000000000000
Return-Path: <NEUMANN@F4.csl.sri.com>
Received: from csl.csl.sri.com (CSL.SRI.COM) by F4.CSL.SRI.COM with TCP; Fri 19 Jun 87 00:23:39-PDT
Received: from F4.CSL.SRI.COM by csl.csl.sri.com (3.2/4.16)
	id AA12019 for RISKS-LIST@f4; Fri, 19 Jun 87 00:23:52 PDT
Message-Id: <8706190723.AA12019@csl.csl.sri.com>
Date: Fri 19 Jun 87 00:23:11-PDT
From: RISKS FORUM    (Peter G. Neumann -- Coordinator) <RISKS@csl.sri.com>
Subject: RISKS DIGEST 5.3 
Sender: NEUMANN@csl.sri.com
To: RISKS-LIST@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest  Thursday, 18 June 1987  Volume 5 : Issue 3

           FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS 
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents:
  Australian ATM troubles... (David Purdue, Dave Horsfall, John Colville)
  Not paying by Access can ruin your credit limit! (Mike Bell)
  Ex-Directory [Arrested by unwristed phone mumbers!] (Brian Randell)
  Risks of Computerized Airport Gate Signs (Chuck Weinstock)
  DMV Computer Changes Names (John Mulhollen)
  UHB demonstrator flight aborted by software error (Kenneth R. Jongsma)
  Aircraft Transponders and Errors in Setting Codes (Joe Morris, Paul Suhler)
  On the bright side, at least my computer still works... (Jon Jacky)
  Human Factors and Risks (Lindsay F. Marshall)
  Re: Risks of so-called ``computer addiction'' (John Mackin)
  Directions and Implications of Advanced Computing (Douglas Schuler)
  Software Risk Management (Dolores Wallace)

***************************************************************************
* RISKS' HOST NAME HAS CHANGED.  NOTE NEW FTP ADDRESS.  Incoming mailer   *
* should accept OLD ADDRESSES for MAIL to RISKS and RISKS-REQUEST.        *
***************************************************************************
* THE EASIEST WAY TO EXPLAIN THE ABSENCE OF RISKS-5.1 IS TO ASSUME THAT   *
* IT NEVER EXISTED.  OTHER SYSTEM PROBLEMS CONTINUE as we STILL try to    *
* recover from our earlier system disasters...  (Governor Dever signed    *
* signs all over the state, "Please Pardon the Inconvenience While        *
* Massachusetts Forges Another Link in Her Great Highway System." --      *
* including one maliciously attached to the Nantucket Sound Light Ship.)  *
* SORRY FOR CONFUSION & ANNOYANCE.  Some incoming mail was lost Sunday.   *
***************************************************************************
* RISKS STILL BACKLOGGED, but stuff on old subjects seems less relevant   *
* the longer it takes me to get at it.  (I'm just back from travels.)     *
***************************************************************************

The RISKS Forum is moderated.  Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious.  Diversity is welcome. 
(Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM)
===>Back issues Vol i Issue j available in F4.CSL.SRI.COM:<RISKS>RISKS-i.j.<===
    Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97).

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

Date: Tue, 16 Jun 87 16:53:04 est
From: munnari!csadfa.oz!davidp@seismo.CSS.GOV (David Purdue)
To: risks@csl.sri.com
Subject: Australian ATM troubles...

First some background:  The Westpac Bank installed a new software system
for its ATM's which did not do proper checking.  Thus it allowed people
to withdraw more than the daily maximum allowed ($200).  It even allowed
the withdrawl of more than was held in the account.  The ATM's were
supposed to allow customers of the Commonwealth Bank to access their
accounts, but this access was denied by the new software.

From "The Canberra Times", Tuesday, June 16, 1987.

BANK LOSES HEAVILY IN AUTO-TELLER 'HICCUP'
------------------------------------------

Westpac's recent automatic-teller-machine "hiccup" cost the bank more than a
red face.  According to Westpac's electronic banking manager, Mr Bill Paget,
the bank would lose several hundred thousand dollars of overdrawn cash.

Westpac's troubles began on Saturday, May 30, when programmers installed the
IMS version 2.2 of IBM's software.  The following Thursday, after a week
long crisis, Westpac decided to close all its automatic tellers throughout
Australia, suspecting widespread fraud.  Because of the costs of recovering
debts, Mr Paget said the bank would probably not take legal action to get
its money back from people who were unable to repay it.

The Federal Treasury ordered an immediate inquiry on the situation as it
developed.  "We were concerned for the cardholder where there was a
technical malfunction and the cardholder lost money," a Treasury official
said.  However he warned that the Treasury might get involved again if
legitimate customers had rights abused during that period.

It seems the "hiccup" was more extensive than first reported.  "Computing
Australia" was told by Mr John Kosh, assistant manager of electronic banking
for the Commonwealth Bank, that the Westpac system was malfuctioning for the
whole of the week before Westpac closed the machines.

Because of this, he said, Commonwealth cardholders had been unable to use
Westpac automatic tellers.  At first, the Commonwealth believed it to be a
communications problem.  "We didn't know what was happening," he said.

The SWIFT network for the international transfer of funds was also hit, with
Westpac unable to send funds overseas while the host computer was down.  Mr
Paget said this caused "some inconvenience" to corporate customers.

Westpac has blamed insufficient software testing for the disaster and
maintains it will reinstall the offending software later.  Mr Paget admitted
that "somehow or other the testing didn't cover the problem".

"The new software is back with the technicians:  we're saying we don't like
what happened, and we don't want this to happen again," he said.  "There's
no doubt it will go back in at some stage, but they've got to find out why
it didn't work and try to work out how to fix it.  From where I sit, we'll
be looking at test upon test upon test." 

He said Westpac would not seek compensation from IBM.  "When you are in a
long term relationship with a supplier, this is going to happen," Mr Paget
said.  "Our people were involved with the software all the way along.  We
have to be big boys and live with it."
						DavidP

Mr. David Purdue	   Phone ISD: +61 62 68 8165
Dept. Computer Science	       Telex: ADFADM AA62030
University College	ACSNET/CSNET: davidp@csadfa.oz
Aust. Defence Force Academy	UUCP: ...!seismo!munnari!csadfa.oz!davidp 
Canberra. ACT. 2600.		ARPA: davidp%csadfa.oz@SEISMO.CSS.GOV
AUSTRALIA		       JANET: davidp@oz.csadfa

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

Date: 11 Jun 87 09:29:38 +1000 (Thu)
From: munnari!astra.necisa.oz!dave@seismo.CSS.GOV (Dave Horsfall)
To: risks@csl.csl.sri.com
Subject: Australian ATMs...                            [Another version!]

Although stories about bank ATM's swallowing customer's money are common
enough, you don't see too many stories about the opposite situation
happening.  Here is a story from the "Sydney Morning Herald" (Sydney,
Australia) dated Friday 5th June:

  The day Westpac's computer gave away money

  Westpac Banking Corporation is believed to have lost millions of dollars
  in international transactions, and will be forced to recover an undisclosed
  amount from customers who withdrew unauthorised cash from automatic teller
  machines, following a serious fault in the bank's computer system.

  A major failure in a new software system introduced last weekend forced
  the closure of all the bank's 650 automatic teller machines (ATMs) across
  Australia yesterday.  The fault also affected other ATMs with which the
  Westpac computer is linked.

  After the fault developed earlier in the week, customers suddenly found
  themselves able to make multiple withdrawals of amounts beyond the usual
  daily limit of $200, even if the account held no money.  They were also able
  to withdraw from cheque accounts they did not have.

The article went on to describe how "normally impoverished inner-city types
(were) suddenly treating themselves to cocktails in expensive restaurants
and buying new clothes at the QVB (a trendy boutique)", and that the SWIFT
system (Society of Worldwide International Financial Transactions) was
inaccessible.  However, the bank denies losing millions of dollars this way.

Apparently, parts of the new software could not cope with carrying three or
four times the number of transactions they had been tested for, and the ATMs
were forced to work in isolation, unable to communicate with the host
processor.  This raises a few important points:

1) Why was the real-life situation so much worse than what had
   been expected?  Don't banks test software until it fails?

2) Why were the ATMs permitted to work on their own, happily
   dispensing cash from empty accounts?

And more importantly ...

3) Assuming these ATMs have an internal audit trail, how much reliance can
   be place on them, in order to recover the money from customers who
   (knowingly) defrauded them?  I can see the court case now:

   "But, m'lud, Westpac has ALREADY ADMITTED that its software was
   at fault.  How can we trust these little bits of paper inside
   their machine, claiming that my client had defrauded them?"

ATMs *DO* have an internal audit trail, don't they?

Dave Horsfall (VK2KFU)    TEL: +61 2 438-3544   FAX: +61 2 439-7036
NEC Information Systems Aust.    ACS: dave@astra.necisa.oz (also CSNET) 
3rd Floor, 99 Nicholson St      ARPA: dave%astra.necisa.oz@seismo.css.gov
St. Leonards  NSW  2064  UUCP: {enea,hplabs,mcvax,prlb2,seismo,ukc}!\
AUSTRALIA munnari!astra.necisa.oz!dave

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

Date: Fri, 12 Jun 87 09:17:42 EST
From: munnari!nswitgould.oz!colville@seismo.CSS.GOV (John Colville)
To: RISKS@csl.csl.sri.com
Subject: Australian ATMs...

[...] Since then they have been running large ads in the newspapers with a
funny drawing of an ATM with 'HIC' coming from its dispenser slot.

Westpac tried the new version of IMS2 against their test data transactions
but not against a load approximating anything like the actual loads. (One of
my students, who works with another of the Big Four banks, says that his bank
always tests against live load levels before they bring in changes: perhaps
reasonable validation does take place sometimes)

John Colville, N.S.W. Institute of Technology, colville@nswitgould.oz.AUS

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

To: comp-risks@ukc.ac.uk
From: Mike Bell <mcvax!camcon!mb@seismo.CSS.GOV>
Subject: Not paying by Access can ruin your credit limit!
Date: 12 Jun 87 09:24:03 GMT

The UK Consumers' Association magazine Which? has the following cautionary
tale about use of credit cards [precis].
	
   "Sally Allen booked into a hotel near Paris for the night. As well as
taking her passport overnight, the hotel asked for her Access card. They
took an imprint on a payment voucher, even though she had no intention of
paying by Access, explaining that it was a safeguard against non-payment of
her bill."

   "When she returned home and tried to use her Access card she was refused
credit, even though she had next to nothing charged on her card. She
contacted Access and demanded an explanation. Apparently the hotel in France
had *reserved credit* on her account for the cost of her stay, and been
given an authorisation number from the Access computer in the UK. The amount
reserved had been deducted from her credit limit. The only way her credit
could be restored was for the hotel to contact them, and to cancel the
transaction. She wrote to the hotel immediately, but it took six weeks for
the credit to be restored."

   Which? reports that Access and Visa both think the hotel was operating
outside the agreed conditions of use, but that because they have no direct
contract with the French hotel, all they can do is lobby their respective
international organisations (Mastercard and Visa International) for a ban.

Anybody else come across this problem of uncancelled "transactions"?

It seems very wrong that someone can screw up your credit without
you ever signing or agreeing anything, and that the matter can't be
put right because of the national boundaries involved.

Mike Bell --Email: mb%camcon.co.uk        Phone: +44 223 358855
UUCP:  ...seismo!mcvax!ukc!camcon!mb
Organization: Cambridge Consultants Ltd., Cambridge, UK

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

From: Brian Randell <brian%kelpie.newcastle.ac.uk@Cs.Ucl.AC.UK>
Date: Wed, 17 Jun 87 10:41:34 bst
To: RISKS@csl.sri.com
Subject: Ex-Directory             [Arrested by unwristed phone mumbers!]

     I've been told that seven terrorists (belonging to Action Directe?)
were recently caught in France after the police took possession of an
electronic wrist-watch/calculator in which one of the terrorists had stored
a set of telephone numbers. Can anybody confirm this, and provide details? I
don't recall discussion in RISKS of any such incident, and its a nice Gallic
equivalent to the Irangate archived messages incident, if it's true.

Brian Randell - Computing Laboratory, University of Newcastle upon Tyne

  ARPA  : brian%cheviot.newcastle.ac.uk@cs.ucl.ac.uk
  UUCP  : <UK>!ukc!cheviot!brian
  JANET : brian@uk.ac.newcastle.cheviot

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

Date: 18 Jun 1987 11:12-EDT 
From: Chuck.Weinstock@sei.cmu.edu
To: risks@csl.sri.com
Subject: Risks of Computerized Airport Gate Signs

Last night I had the pleasure(?) of trying out United Air Lines new
O'Hare terminal.  The terminal is extremely modern, complete with
computerized departure signs for each gate (in a red color that can't
be read when the sun backlights it!)  In the closet behind each gate
check-in counter there is an IBM PC (I think) with a menu driven
program used to set the information on the departure sign.
Unfortunately, any gate computer can control any gate sign, and the
result is that a simple operator error can cause lots of trouble.
In particular, last night, while I watched, the Pittsburgh flight
indicated behind the counter turned magically into one for Columbus.

I should also point out that the low tech solution of a sign board to
be slipped into a slot took only about 30 seconds per flight
changeover.  I watched the attendent take almost 5 minutes to
changeover under the new and improved high-tech solution.  (To be fair,
the terminal has only been operating since Monday.)

Aside: if you are unfortunate enough to have to connect from United
gates E-F to United gates B, plan on missing your flight unless you've
added an extra 15-20 minutes for the hike.  The terminal won't be fully
operational until 1989, though much UAL operations will switch there in
August of this year.

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

From: "IMS/John Mulhollen" <johnm@afsc-bmo.arpa>
Subject: DMV Computer Changes Names
Date:   11-JUN-1987 16:33 PDT

Article in 11 June 1987 Los Angeles Times:

  "N.J. Computer Gives Drivers the Business

  "Trenton, N.J. - Hundreds of drivers who notified Department of Motor
  Vehicles last month of new addresses found that a computer had changed
  their names -- to Watkins Leasing Co.

  "The computer error has been corrected and new address labels are being
  sent this week to all of the drivers affected, a department spokesman said.

  "Watkins Leasing Co. is a truck dealership and leasing concern with
  offices in Chester, PA and Wilmington and Harrington, Del."

Interesting. Why Watkins Leasing Co since apparently Watkins isn't even
located in New Jersey???  JohnM

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

Date: Thu 18 Jun 87 21:12:52-PDT
From: Peter G. Neumann <Neumann@csl.sri.com>   [from Kenneth R. Jongsma]
Subject: UHB demonstrator flight aborted by software error
To: RISKS@csl.sri.com

On 18 May 87 a demonstrator flight of the McDonnell Douglas UHB twin-jet
(with one GE prototype unducted fan engine) was cut short when a cockpit
light indicated a potential problem with the UDF engine.  The warning was
triggered by a pressure sensor when the aircraft climbed above 12,000 feet.
Subsequent testing showed there was a software error in the annunciation logic.

[Source: Aviation Week & Space Technology, 1 June 87, courtesy of Kenneth 
R. Jongsma]

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

To: risks@csl.csl.sri.com
Subject: Yet another air-traffic-controller foul-up (revisited)
Date: Mon, 15 Jun 87 11:33:42 EDT
From: Joe Morris (jcmorris@mitre.arpa) <jcmorris@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.

A short tutorial on aircraft transponders...

In RISKS 5:2 Roy Smith asks:

>> ...why isn't the plane part of the info sent by the on-board transponder?
>> Aren't these id's simply the flight numbers assigned by the airlines?  Why
>> should it require any manual intervention to assign an id to a blip?

The transponder presently in use by all aircraft in the US has been around
for many years.  It has the ability to:
 
- Receive an unaddressed query pulse from a ground radar site and respond
  with a pulse of its own. 

- Include with its response the transponder code set by the pilot.  (This
  is the code which was incorrectly assigned at O'Hare.)  The code is 
  a 4-digit octal number, and has no relationship to the aircraft registration
  number or the (airline-assigned) flight number.
 
- Report if a special button (marked IDENTIFICATION) has been pressed within 
  the past few seconds.  This can be used by a controller to positively
  identify an aircraft, since its receipt causes the radar display to change
  the shape of the blip which represents the return.
 
- Report the pressure altitude of the aircraft, referenced to a barometer 
  setting of 29.92" Hg.  This ability is not required in low-altitude
  flights and is an extra-cost feature.
 
Work is being completed by the FAA on a replacement for the present transponder
design.  The new transponders (called "Mode S") will include a permanently-
assigned identification, unique to the aircraft, which will be transmitted
along with the other data when the transponder decodes a query.  Until the
Mode S gear comes into use, however, we are still limited to a transponder
code address space of 4096 discrete codes to identify an aircraft.
 
The effective address space is smaller, since several blocks of 100(8) are
reserved for special purpose.  Code 1200 is the general VFR (visual, not
under radar control) code; 75xx, 76xx, and 77xx are emergency codes,
and so forth.
 
A feature of most radar display systems is the ability to use the transponder
codes to DE-select a return so that a controller's display does not show the 
transponder data for aircraft not under his/her jurisdiction.  Such aircraft
might be separated horizontally (in another controller's sector) or vertically
(as in an overflight above an airport).  In places like Southern California,
this can be used to suppress the clutter caused by VFR (code 1200) aircraft
which would otherwise obscure the returns of controlled aircraft.  It has
been reported (and denied) that the controller involved in the Cerritos crash
had suppressed the VFR returns such as that of the intruding Piper.
 
Yes, it would be nice if the system could set off alarms when the data
became ambiguous.  But at what point should it delay the alarm against
the possibility of a transient failure (e.g., the second aircraft might
have been changing the code setting and been on AA637's code just as the
radar beam swept past)?  A real problem in aviation system engineering is
the incredible number of alarms which some pilots consider to be a safety
risk in themselves since they can go off in combinations which distract
the aircrew.

There's an O*L*D joke about the pilot who was hauled up before a board
after landing his airplane with the landing gear still up.  His defence
was that the gear-up warning horn was so loud that he was distracted
from performing the "gear down and locked" item in his pre-landing checklist.

Joe Morris (jcmorris@mitre.arpa)

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

Date: Fri, 12 Jun 87 16:07:31 cdt
From: suhler@im4u.utexas.edu (Paul A. Suhler)
To: RISKS@csl.sri.com
Subject: Aircraft Transponders and Errors in Setting Codes   [Some duplication]

Before takeoff on an IFR (instrument flight rules) flight, an aircraft's
pilot is given a "squawk", a four octal digit code to enter into his
transponder.  This is also entered into the ATC system's computer so the
code returned by the transponder when interrogated by radar is automatically
translated into the airline and flight number displayed on the controller's
radar scope.

As there are 4096 possible codes and probably lots more aircraft flying IFR
than that, pilots sometimes have to change squawks in mid-flight when
going from one region to another.  And, as airlines have duplicate flight
numbers that range from one to four decimal digits, they can't use those
for their squawks.   [...]

VFR aircraft receiving terminal radar service also use this facility,
although they are only using it at the beginning and end of the flight.
Also, codes 75XX are reserved for hijacked aircraft, 76XX for those with
communication failures, and 77XX for those declaring emergencies, so
that the total number of squawks available is actually less than 4096.
 
Paul Suhler        suhler@im4u.UTEXAS.EDU	512-474-9517/471-3903
Organization: Univ of Texas Elec & Comp Engr Dept

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

From: jon@june.cs.washington.edu (Jon Jacky)
To: ... risks@csl.sri.com
Subject: On the bright side, at least my computer still works...
Date: Wed, 17 Jun 87 20:36:02 PDT

I got an ad from Raytheon today for a Mil-Spec version of the VAX (built
under license from DEC).  It is described as an "extreme performance machine
which survives tactical levels of nuclear weapons effects (NWE)."

On a related note, the June 15, 1987 issue of the trade paper ELECTRONIC 
ENGINEERING TIMES has an article called "Reveille for Military ASICs" (by
Terry Costlow, pps. 1 and 16).  It notes "Radiation hardening has been
viewed largely as an aerospace application, but it is now being included in
smaller weapons that are being produced in higher volumes than one-of-a-kind
spacecraft. 'We're seeing more nuclear weapons being designed for tactical 
battlefield conditions.  In the past, rad-hard was just used in weapons like
intercontinental missiles.  We feel this may be a nice emerging niche', says
(semiconductor vendor) NCR's (director of marketing Patrick) Riley."

Jonathan Jacky

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

From: "Lindsay F. Marshall" <lindsay%kelpie.newcastle.ac.uk@Cs.Ucl.AC.UK>
To: risks@csl.csl.sri.com
Date: Mon, 15 Jun 87 9:49:41 BST
Subject: Human Factors and Risks

Nothing to do with computers, but a very important point for system
designers. I was reading a book the other day in which the author
mentions the pang of fear that struck him on a plane one day, when
he noticed that the screws holding the ashtray to the seat did not
match. He instantly thought "Is this how they fix the engines too??".

Moral: Attention to the cosmetic details can play a great part in re-assuring
users (no matter how falsely!).

Lindsay F. Marshall, Computing Lab., U of Newcastle upon Tyne, Tyne & Wear, UK
JANET: lindsay@uk.ac.newcastle.cheviot  ARPA: lindsay%cheviot.newcastle@ucl-cs
PHONE: +44-91-2329233     UUCP: <UK>!ukc!cheviot!lindsay

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

From: munnari!basser.cs.su.oz!john@seismo.CSS.GOV (John Mackin)
Date: 16 Jun 87 18:09:47 GMT
To: munnari!comp-risks@munnari
Subject: Re: Risks of so-called ``computer addiction''
Organization: Dept. of Comp. Science, Uni of Sydney, Australia

I'm surprised that no one has mentioned the book ``Computer Power and Human
Reason'', by Joseph Weizenbaum.  Weizenbaum calls the phenomenon ``compulsive 
programming'', and devotes quite a large part of the book to discussion of it.

John Mackin, Basser Dept of Computer Science, Univ.of Sydney, Sydney, Australia

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

Date: Thu, 18 Jun 87 13:12:36 pdt
From: Douglas Schuler <douglas@BOEING.COM>
To: risks@csl.sri.com
Subject: Directions and Implications of Advanced Computing

            DIRECTIONS AND IMPLICATIONS OF ADVANCED COMPUTING 
	    A One Day Symposium - July 12, 1987
	    University of Washington, Seattle, Washington

PROGRAM

On-Site Registration (8:00 - 9:00)

PLENARY SESSION (9:00 - 10:30)
  Robert Kahn and Terry Winograd with Gary Chapman

The featured speakers will discuss the role of funding on computer science
research.  How and why are projects selected for funding?  What are the
roles of the Department of Defense, civilian agencies and private sources?
Does it matter where research money comes from?

Robert Kahn is the founder of the non-profit Corporation for National
Research Initiatives, in Washington, D.C.  Until 1985, Kahn was director of
the Information Processing Techniques Office at the Defense Advanced
Research Projects Agency (DARPA).

Terry Winograd is an associate professor of computer science at Stanford
University.  He is author of "Understanding Natural Language", "Language as
a Cognitive Process" and (with Fernando Flores) "Understanding Computers
and Cognition".  Winograd is the national president of Computer
Professionals for Social Responsibility (CPSR).

The discussion will be moderated by Gary Chapman, Executive Director of
CPSR.  He is co-editor of the book, "Computers in Battle" to be published
this fall.  Chapman is a former member U.S. Special Forces.

PARALLEL SESSIONS

FUNDING (11:00 - 12:00)
David Bushnell - The Promise and Reality of ARPANET: A Brief History
Joel Yudken and Barbara Simons - Project on Funding in Computer Science: 
  A Preliminary Report

AI PROSPECTS I (11:00 - 12:00)
Juergen Koenemann    Artificial Intelligence and the Future of Work
Reinhard Keil-Slawik    An Ecological Approach to Responsible 
  Systems Development

MILITARY/RELIABILITY  (1:30 - 3:00)
Richard Hamlet - Testing for Trustworthiness
David Bella - Fault-tolerant Ballistic Missile Defense
Erik Nilsson - The Costs of Computing Star Wars

EXPERT SYSTEMS  (1:30 - 3:00)
Matthew Lewis and Seth Chaikin - Will There Be Teachers in the Classroom 
  of the Future?
Rolf Engelbrecht - Expert Systems in Medicine - A Technology Assessment
Carole Hafner and Donald Berman - The Potential of AI to Help Solve the
  Crisis in Our Legal System

RESEARCH PRIORITIES (3:30 - 4:30)
Douglas Schuler - A Civilian Computing Initiative: Three Modest Proposals
Jack Beusmans and Karen Wieckert - Artificial Intelligence and the Military

AI PROSPECTS II (3:30 - 4:30)
Susan Landau - The Responsible Use of 'Expert' Systems
K. Eric Drexler - Technologies of Danger and Wisdom

VIDEO
Daressa    Computers in Context
CPSR	   Reliability and Risk
videotape on DBNET (a computer mail network for the deaf-blind)

REGISTRATION FEES: Regular $50, CPSR Member $30, Student/Low Income $20
Proceedings only (cannot attend symposium) $15   Proceedings will be
distributed to symposium registrants on day of symposium.  Lunch is included.

DIAC '87, CPSR/Seattle, P.O. Box 85481, Seattle, WA  98105
Sponsored by Computer Professionals for Social Responsibility

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

Date: Thu, 18 Jun 87 08:38:21 edt
From: wallace@ICST-SE
Subject: Software Risk Management

The National Security Industrial Association (NSIA), in cooperation with the
National Aeronautics and SpaceAdministration (NASA), DOD, the National
Bureau of Standards(NBS), the Library of Congress, Society for Software
Quality, the Aerospace Industries Association of America (AIA), the G-34
Computer Resources Committee of the Electronic Industries Association (EIA),
and the American Society for Quality Control, is sponsoring the Fall Joint
National Conference on Software Risk Management.  The conference will be
held September 30 - October 2,1987 in Los Angeles at the Los Angeles Airport
Hilton Towers, on Century Boulevard.

Dr. Barry Boehm of TRW will be the keynote speaker of the conference beginning 
at 1:30 PM on Wednesday, September 30. The conference features key government 
officials and world renowned speakers from academe, consortia and industry.

For information on the conference program and registration, contact Jerry Smith
at QSOFT, Suite 206, 2755 Hartland Road, Falls Church, VA 22046, (703) 560-4440
or Jerry Raveling, UNISYS, Sperry Park, St. Paul, MN 55164-0525, (612) 681-6800

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

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