FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
/** comp.risks: 7.0 **/
** Topic: RISKS DIGEST 10.17 **
** Written 10:20 am Aug 2, 1990 by risks in cdp:comp.risks **
RISKS-LIST: RISKS-FORUM Digest Thursday 2 August 1990 Volume 10 : Issue 17
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
A Tough Roach to Ho-Ho Your PC; more on bugs in sendmail (PGN)
BMW's 'autopilot' (Chaz Heritage via Richard Busch)
SIGSOFT '91, conference on critical systems preliminary announcement (PGN)
European Symposium on Research in Computer Security, program (Yves Deswarte)
Pilots vs. automation (Bob Sutterfield)
Altitude violations and TCAS (Andrew Koenig)
Risks of Research vs Errors (Hubble) (Dave Davis)
Re: Hubble Trouble (Brinton Cooper, Bryce Nesbitt)
RISKS of slanting computer related excerpts (pigeons) (Jay Schmidgall)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome.
CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line
(otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM.
TO FTP VOL i ISSUE j: ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR>
cd sys$user2:[risks]<CR>GET RISKS-i.j <CR>; j is TWO digits. Vol summaries in
risks-i.00 (j=0); "dir risks-*.*<CR>" gives directory listing of back issues.
ALL CONTRIBUTIONS ARE CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
----------------------------------------------------------------------
Date: Wed, 1 Aug 1990 17:39:32 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: A Tough Roach to Ho-Ho Your PC; more on bugs in sendmail
_New York Woman_ (presumably the current issue) addresses a problem common to
women (and men) in the Big Apple: roaches in your personal computer. The
recommended solutions include traplike surrounds, replacing oxygen with carbon
dioxide in an airtight container (with the computer OFF), spiders (even if you
have aRACFhnophobia?), or find a specialist to take it apart and "administer a
nice, roach-repelling pesticide." Also included are disrecommendations, such
as not enclosing it in an airtight plastic container with the power on, and not
putting it in the fridge. [Source: San Francisco Chronicle, 1 August 1990, p.
A10.]
RISKS has dealt with all sorts of bugs, but I don't recall mention of roaches
in our five-year roadshow (roach-ho!). Oh, yes, 1 August 1990 marks the FIFTH
ANNIVERSARY OF THE VERY FIRST RISKS ISSUE. This is our 774th issue, averaging
about 3 a week through thick and thin. Sheer heroism on the part of your
moderator? Or masochism? Either way, its been fun (except for the mailer
headaches).
So, let me take this opportunity to report on sendmail bugs. We installed a
patch that deletes from the in-progress list any address for which successful
mailing appears to have been accomplished. A few of the addresses on one of
the sublists (but not consecutive ones) still managed to get multiple copies of
RISKS-10.16, one of the copies bearing a botched (incomplete) last line of the
header routing information. This looks like a NEW bug, so we have backed off
to the old mailer for a while longer -- because it had seemingly been reliable
lately. At this point I'm ready to try the plastic bag approach. I know that
pesticides don't provide a very sound solution, ecologically or otherwise. PGN
------------------------------
Date: 31 Jul 90 10:33:32 PDT (Tuesday)
Subject: BMW's 'autopilot'
From: "Richard_Busch.SD"@Xerox.COM
Really-From: Chaz Heritage <chaz heritage:wgc1:RX> via Richard Busch
In RISKS-10.15 Rodney Hoffman quotes from 'Business Week', 30 July 1990:
>[BMW have]already installed an early version of their Heading Control
system in cars...A camera above the rearview mirror tracks the center
stripe and the line along the right side of the road. If a driver gets too
close to either marker, a small electric motor integrated into the steering
system is activated...Later versions will gauge road conditions...<[etc.]
There are two possible problems here. Assuming (as one has no right whatever to
do) that the system as implemented is technically perfect and never fails, one
is still left with some difficulties to do with the nature of driving:
1. If, as it would seem, the system relies on the uniformity of the road
construction then it will be unable to work on roads other than motorways
(freeways, autobahnen, autostrada, etc.) which are of modern construction and
uniform design. It will definitely not work in many urban or suburban areas in
which roads are usually far from uniform. It is on such roads (probably for
similar reasons) that most accidents occur. Motorways have very low accident
rates per vehicle-mile. It is therefore odd seemingly to address only the
problem of course loss (often due to sleep) on otherwise rather safe roads.
2. Even if the course loss problem were the main concern, then without some
method of detecting a vehicle ahead and slowing or stopping the guided vehicle
automatically, the system seems likely to ensure that a sleeping driver will be
unerringly guided into a nose-to-tail collision with the first slower-moving
vehicle encountered in the same lane.
3. The decision to overtake is prompted not primarily by the absolute legality
of the operation (i.e. over which type of line one proposes to pass), but by
the view of the road ahead, which is not available to this system. A mechanical
veto on overtaking, particularly taking the form of a 'twitch' of the steering
at the critical moment when the front wheel crosses the line, seems almost
certain to bring about accidents. The system could not reasonably be expected
to distinguish between the solid line in the centre of a minor road, which one
may not cross, and the solid line around the edge of the warning zone at the
junction of a motorway and its sliproad, which line one may cross in emergency.
It could thus intervene at a critical moment during an emergency; hardly a
contribution to road safety.
4. The experience of the introduction of ABS strongly suggests that if the
system is installed then it will be systematically abused. ABS appears to
encourage some drivers both to take unreasonable risks of loss-of-control
accidents, and to demonstrate their 'machismo' by charging the last vehicle in
a stationary queue, making an 'ABS stop' at the last moment. The introduction
of BMW HCS would infallibly bring about a perception on the part of such people
that they can (a) use as many handheld telephones as they wish; (b) read the
newspaper while driving; (c) drink more alcohol before attempting to drive,
since the car can 'find its own way home'.
In my view this development and many like it are fatuous, and are not an
acceptable substitute for responsibility on the part of drivers. Expecting
people (indeed, allowing them to be encouraged) to behave competitively and
aggressively on the road and then proposing by technical means to prevent them
from causing accidents are not the correct solution to a high accident rate.
Chaz
------------------------------
Date: Tue, 31 Jul 1990 10:56:01 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: SIGSOFT '91
PRELIMINARY ANNOUNCEMENT
SIGSOFT '91: Conference on Software for Critical Systems
Location: Washington, D.C. area
Dates: 10-12 December, 1991
General Chair:
Mark Moriconi, SRI International (moriconi@csl.sri.com)
Program Co-Chairs:
Nancy Leveson, UC Irvine (leveson@ics.uci.edu)
Peter Neumann, SRI International (neumann@csl.sri.com)
Computers are being introduced into systems that affect nearly every aspect of
our lives. There are very good reasons to do so ranging from economics to
efficiency to enhancing effectiveness and capability. But in the enthusiasm to
take advantage of computer capabilities, we are becoming increasingly
vulnerable to errors and deficiencies in the software.
The SIGSOFT '91 Conference will provide a forum in which research on all
aspects of quality in critical systems can be presented. A critical system is
a system that must exhibit, with very high assurance, some specific qualities
such as safety, reliability, confidentiality, integrity, availability,
trustworthiness, and correctness. The conference will focus on architectures,
design methodologies, languages, analysis techniques, processes, and experience
that can increase the likelihood that a system exhibits its required qualities.
Papers will be due in the Spring of 1991. More details will follow. Please
save the dates.
------------------------------
From: deswarte@tsf.laas.fr
Date: Mon, 16 Jul 90 10:32:04 +0200
Subject: Program of the European Symposium on Research in Computer Security
EUROPEAN SYMPOSIUM ON RESEARCH IN COMPUTER SECURITY ESORICS-90
October 24-26, 1990, Toulouse, FRANCE
The aim of this symposium is to further the progress of research in
computer security by establishing a European forum for bringing
together researchers in this area, by promoting the exchange of ideas
with system developers and by encouraging links with researchers in
related areas. To achieve this aim in the best conditions, ESORICS-90
will be a single track symposium and the selected papers will be
presented in a conference hall whose capacity is 250 attendees.
Computer security is concerned with the protection of information in
environments where there is a possibility of intrusions or malicious actions.
* HONORARY CHAIRMAN GILLES MARTIN (deceased on February 7, 1990)
* CHAIR AND PROGRAMME CHAIR Gerard Eizenberg, ONERA/CERT
* ORGANIZATION CHAIR Marie-France Kalogera, AFCET
* LOCAL ARRANGEMENTS Brigitte Giacomi, Ghyslaine Picchi, ONERA/CERT
* ORGANIZED BY AFCET, IN COOPERATION WITH
AICA Associazione Italiana per l'Informatica ed il Calcolo Automatico
BCS The British Computer Society
ESA European Space Agency
GI Gesellschaft fur Informatik
IEEE-CS The IEEE Computer Society
DISSI Delegation Interministerielle pour la Securite des Systemes
d'Information
DRET Direction des Recherches Etudes et Techniques
FRANCE TELECOM
INRIA Institut National de Recherche en Informatique et Automatique
TECHNICAL PROGRAMME
WEDNESDAY, OCTOBER 24, 1990
8:30 Registration
9:40-10:00 Welcome and Introduction
10:00-11:00 Database I, Robert Demolombe, Chair
Teresa F. Lunt, Donovan Hsieh - "The SeaView Secure Database System:
A Progress Report"
Kioumars Yazdanian - "Relational Database Granularity"
11:30-12:30 Database II, Teresa F. Lunt, Chair
Udo Kelter - "Group-Oriented Discretionary Access Controls for Distributed
Structurally Object-Oriented Database Systems"
Joachim Biskup - "A General Framework for Database Security"
2:00-3:30 Secure Systems I, Dennis Steinauer, Chair
R. W. Jones - "A General Mechanism for Access Control: Its Relationship to
Secure System Concepts"
Jorg Kaiser - "An Object-Oriented Architecture to Support System Reliability
and Security"
Zoran Savic, M. Komocar - "Security Kernel Design and Implementation in the IBM
PC Environment"
4:00-6:00 Secure Systems II, David Bailey, Chair
G. Hoffmann, S. Lechner, M. Leclerc, F. Steiner - "Authentification and Access
Control in a Distributed System"
I. Akyildiz, G. Benson - "A Security Level Reclassifier for a Local Area
Network"
Laurent Blain, Yves Deswarte - "An Intrusion-tolerant security server for an
open distributed system"
E. Stewart Lee, Brian Thomson, Peter I. P. Boulton, Michael Stumm -
"An Architecture for a Trusted Network"
6:15 Poster Sessions
THURSDAY, OCTOBER 25, 1990
9:00-10:30 Models I, Franz-Peter Heider, Chair
Brian Thomson, E. S. Lee, P. I. P. Boulton, M. Stumm, D. M. Lewis - "Using
Deducibility in Secure Network Modelling"
Vijay Varadharajan - "A Petri Net Framework for Modelling Information Flow
Security Policies"
Anas Tarah, Christian Huitema - "CHIMAERA : A Network Security Model"
11:00-12:00 Models II, Luis Farinas del Cerro, Chair
Frederic Cuppens - "An epistemic and Deontic Logic for Reasoning about Computer
security"
Colin O'Halloran - "A calculus for information flow"
1:30-3:00 Cryptography, Louis Guillou, Chair
D. de Waleffe, J.-J. Quisquater - "Better login protocols for computer
networks"
Marc Girault, Jean-Claude Pailles - "An Identity-Based Scheme Providing
Zero-Knowledge Authentication and Authenticated Key-Exchange"
Jacques Patarin - "Generateurs de permutations pseudo-aleatoires bases sur le
schema du DES"
3:30-5:00 Panel : "Update on Public-Key know-how", Paul Camion, Chair
5:15 Poster Sessions
FRIDAY, OCTOBER 26, 1990
9:00-10:00 Software Engineering for Security, Rene Jacquart, Chair
E. S. Hocking, J. A. McDermid - "Towards an Object Oriented Development
Environment for Secure Applications"
G. P. Randell - "A Case Study in the Formal Refinement of a Distributed Secure
System"
10:30-11:30 Security Verification and Evaluation, Peter Bottomley, Chair
Pierre Bieber - "Epistemic Verification of Cryptographic Protocols"
Eric Deberdt, Sylvain Martin - "Methodologie "Minerve Securite": Demarche
d'Evaluation de la Securite des Logiciels"
11:30-12:30 Panel : "Security in Software Developments Environments"
Chris Sennett, Chair
2:00-2:45 David Bailey (invited) - "Managing Computing Security: What
is Needed from the Research Community?"
2:45-3:15 Jean-Francois Pacault (invited) - "Harmonizing the Information
Technology Evaluation Criteria"
3:45-5:15 Panel : "Impacts of Evaluation Criteria on Research"
Christian Jahl, Chair
5:15-5:30 Closing Remarks
SYMPOSIUM LOCATION : F.I.A.S. (Formation Internationale Aeronautique et
Spatiale) - 23, avenue Edouard-Belin - 31400 Toulouse - France
telephone : +33 61 55 00 87 - telefax : +33 61 55 16 97
CONTACTS: For other general information concerning the symposium, contact :
Veronique SEGAUD - AFCET - tel : +33 1 47 66 24 19, fax : +33 1 42 67 93 12
[Full registration information and application form can be obtained on-line
from deswarte@tsf.laas.fr or from risks-request@csl.sri.com, or FTPed from
the CRVAX.SRI.COM machine (see masthead instructions) with file name
"conf.esorics". PGN]
------------------------------
Date: Wed, 1 Aug 90 17:13:38 GMT
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Pilots vs. automation (Henry Spencer, RISKS DIGEST 10.16)
This isn't a promise not to enforce the laws, it's a fairly straightforward
interpretation of some of the most fundamental aviation regulations in
existence (and long-standing, harking back to days of captains on the high
seas, out of touch with their admiralties for months running).
By U.S. Federal Aviation Regulation 91.3(b), "In an in-flight emergency
requiring immediate action [such as a TCAS alert], the pilot in command may
deviate from any rule of this part [including clearances] to the extent
required to meet that emergency." I suspect that the ALPA's beef is that
they'd just like it more explicitly worded with respect to TCAS and other
automated aids, and perhaps changed to "a perceived in-flight emergency."
This brings to mind an interesting thought: who gets the blame if
(when) a TCAS warning *causes* a collision, through either
electronic or human confusion?
By FAR 91.3(a), "The pilot in command of an aircraft is directly
responsible for, and is the final authority as to, the operation of
that aircraft." If Air Traffic Control instructs a pilot to fly into
the side of a mountain, the pilot is at fault if he follows along. If
TCAS says "CLIMB!" it's still the pilot's responsibility to decide
whether to obey. It's the pilot's job not to be confused.
General aviation pilots have voiced the concern that TCAS will lead to
complacency on the part of air carrier crews, depending too much on
the technology, leading to a breakdown of the basic "see and avoid"
(FAR 91.113(b)) means of avoiding collisions, which is still the only
method that will work when flying near non-transponder-equipped
aircraft. Air carrier pilots respond, as expected, that everyone
should have a transponder. And so it goes...
------------------------------
Date: Wed, 1 Aug 90 10:21:45 EDT
From: ark@research.att.com
Subject: Altitude violations and TCAS
It's not clear that deviating from a clearance is violating the regulations at
all. My evidence:
From the Pilot/Controller Glossary:
Emergency: a Distress or Urgency condition
Distress: A condition of being threatened by serious
and/or imminent danger and of requiring immediate
assistance
Urgency: A condition of being concerned about safety,
and of requiring timely but not immediate assistance;
a potential Distress condition.
So, if your TCAS has just told you that you might hit another
airplane if yuo don't change course, that's an emergency.
Now we turn to Federal Aviation Regulations, Part 91: General
Operating and Flight Rules. Section 91.123 is where it says
you can't leave an assigned altitude:
(a) When an ATC clearance has been obtained, no pilot in
command may deviate from that clearance, except in an
emergency....
(b) Except in an emergency, no person may operate an aircraft
contrary to an ATC instruction in an area in which air
traffic control is exercised.
(c) Each pilot in command who, in an emergency, deviates
from an ATC clearance or instruction shall notify ATC
of that deviation as soon as possible.
And section 91.3 gives blanket authorization:
(a) The pilot in command of an aircraft is directly
responsible for, and is the final authoriaty as to,
the operation of that aircraft.
(b) In an in-flight emergency requiring immediate
action, the pilot in command may deviate from any
rule of this part to the extent required to meet
that emergency.
(c) Each pilot in command who deviates from a rule under
paragraph (b) of this section shall, upon the request of the
Administrator, send a written report of that deviation
to the Administrator.
This seems pretty clear. A pilot who realizes the possibility of a midair
collision has the authority and responsibility to do whatever is necessary to
prevent it. After deviating from course one must notify ATC (``New York
Center, Cessna 5-7-Tango turning right 2-0 degrees to avoid traffic'') and file
a written report if requested, but emergency deviations are explicitly allowed
by the regulations.
Andrew Koenig (private pilot, instrument airplane single-engine land)
------------------------------
Date: Wed, 01 Aug 90 09:55:25 EDT
From: Dave Davis <davis@mwunix.mitre.org>
Subject: Risks of Research vs Errors
In the 10.16 edition of Risks, Mr. Miya points out that about 90%
of research fails. However, the Hubble telescope's problems are
a bit more mundane, NASA just goofed. When a research experiment
fails to give us the answers we expected, we must adjust our theory
and possibly our hypothsis and begin again. Hubble's problems
indicate to many in Congress as well as the public that NASA has
problems managing itself as well as its contractors. Ironically,
it seems that a part of the difficulty stems from the use of a
notoriously secretive Air Force affilliated contractor to do the
critical mirrors.
Dave Davis, MITRE Corporation, 7525 Colshire Dr., McLean, VA 22102
------------------------------
Date: Tue, 31 Jul 90 22:53:42 EDT
From: Brinton Cooper <abc@BRL.MIL>
Subject: Re: Hubble Trouble
RE Gene Miya's "hindsight" arguments:
I agree that complex projects have "problems" and that many (not
"every") projects involve "compromises." These are EXACTLY the reasons
for ADEQUATE and THOROUGH TESTING. The lack of testing and the
fuzzy-headed thinking that rationalized away the need for testing are
nothing new to observers of the DoD (MY employer, folks). Our systems
have been failing for years because of inadequate independent testing
and evaluation.
I wonder if there's a connection between NASA's increasingly
poor performance and the increasingly large number of ex-DoD types
working there in VERY high places?
"Lastly," we all agree that much "research" ends in "failure"
according to the uninformed definition of "success." But building the
Hubble was no research project. It was an ENGINEERING job.
Needless to say, these opinions are mine and do not constitute an official Army
position, etc, etc.
_Brint
------------------------------
Date: Wed, 1 Aug 90 00:21:13 EDT
From: bryce@cbmvax.cbm.commodore.com (Bryce Nesbitt)
Subject: Hubble Trouble (Mirror, mirror, on the wall)
Eugene N. Miya <eugene@wilbur.nas.nasa.gov> writes:
>I worry about the "climate" for any
>research in this country, because research tends to fail 90% of the time (if
>you really need a reference for this I have it)....
>[Perkin-Elmer] is making mirrors and equipment for other project, I would
>worry about Keck for instance.
I agree with your point about research, but I view Hubble as "screwed up
research" instead of "a good try that failed". The mirror was only the latest
serious screwup. I have no inside track on Hubble; that's just an outside
impression.
The Keck mirrors have been a concern. There is a difference from Hubble,
however. Keck uses asymmetrical mirror segments. Each of the 36 segments
is a slice of the final shape. Weights are hung from each segment, the
mirror is conventionally ground, then the weights are released. All this
is very new, and very research oriented. (Perkin-Elmer is not involved,
unless it happens to own Itek, the primary mirror contractor).
Hubble's mirrors are precise, but nothing special. I find it ironic to
go back to some glowing magazine articles about how well the the mirrors
were built... they exceeded spec on several points (including reflectivity).
The builders seemed very proud.
------------------------------
Date: Wed, 1 Aug 90 08:38:26 CDT
From: "Jay Schmidgall" <shmdgljd@rchvmw3.iinus1.ibm.com>
Subject: RISKS of slanting computer related excerpts
In a recent digest, "Richard_Busch.SD"@Xerox.COM writes
> [...] Joe, a four-year-old Blue Chequer pigeon.
>
> [...] Joe beat the fax in a one mile challenge race, arriving more
> than a minute before the caricature drawing of him emerged from the
> machine.
It should be noted that the pigeon was given a two-minute head start
before the fax company began its transmission. As I read the actual
article, it appeared that the pigeon had arrived before the company even
began it transmission.
While we all may enjoy that good old-fashioned methods can sometimes
subvert the best efforts of modern technology, we should not let this be
portrayed in unrealistic examples. The referenced excerpt made it sound
as if the two had started at the same time, requiring the pigeon to be
flying near light speed (exaggeration for dramatic effect!).
-- My opinions are my own and do not necessarily reflect those of IBM --
Jay Schmidgall
------------------------------
End of RISKS-FORUM Digest 10.17
************************
** End of text from cdp:comp.risks **
** Topic: RISKS DIGEST 10.17 **
** Written 10:20 am Aug 2, 1990 by risks in cdp:comp.risks **
RISKS-LIST: RISKS-FORUM Digest Thursday 2 August 1990 Volume 10 : Issue 17
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
A Tough Roach to Ho-Ho Your PC; more on bugs in sendmail (PGN)
BMW's 'autopilot' (Chaz Heritage via Richard Busch)
SIGSOFT '91, conference on critical systems preliminary announcement (PGN)
European Symposium on Research in Computer Security, program (Yves Deswarte)
Pilots vs. automation (Bob Sutterfield)
Altitude violations and TCAS (Andrew Koenig)
Risks of Research vs Errors (Hubble) (Dave Davis)
Re: Hubble Trouble (Brinton Cooper, Bryce Nesbitt)
RISKS of slanting computer related excerpts (pigeons) (Jay Schmidgall)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome.
CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line
(otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM.
TO FTP VOL i ISSUE j: ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR>
cd sys$user2:[risks]<CR>GET RISKS-i.j <CR>; j is TWO digits. Vol summaries in
risks-i.00 (j=0); "dir risks-*.*<CR>" gives directory listing of back issues.
ALL CONTRIBUTIONS ARE CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
----------------------------------------------------------------------
Date: Wed, 1 Aug 1990 17:39:32 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: A Tough Roach to Ho-Ho Your PC; more on bugs in sendmail
_New York Woman_ (presumably the current issue) addresses a problem common to
women (and men) in the Big Apple: roaches in your personal computer. The
recommended solutions include traplike surrounds, replacing oxygen with carbon
dioxide in an airtight container (with the computer OFF), spiders (even if you
have aRACFhnophobia?), or find a specialist to take it apart and "administer a
nice, roach-repelling pesticide." Also included are disrecommendations, such
as not enclosing it in an airtight plastic container with the power on, and not
putting it in the fridge. [Source: San Francisco Chronicle, 1 August 1990, p.
A10.]
RISKS has dealt with all sorts of bugs, but I don't recall mention of roaches
in our five-year roadshow (roach-ho!). Oh, yes, 1 August 1990 marks the FIFTH
ANNIVERSARY OF THE VERY FIRST RISKS ISSUE. This is our 774th issue, averaging
about 3 a week through thick and thin. Sheer heroism on the part of your
moderator? Or masochism? Either way, its been fun (except for the mailer
headaches).
So, let me take this opportunity to report on sendmail bugs. We installed a
patch that deletes from the in-progress list any address for which successful
mailing appears to have been accomplished. A few of the addresses on one of
the sublists (but not consecutive ones) still managed to get multiple copies of
RISKS-10.16, one of the copies bearing a botched (incomplete) last line of the
header routing information. This looks like a NEW bug, so we have backed off
to the old mailer for a while longer -- because it had seemingly been reliable
lately. At this point I'm ready to try the plastic bag approach. I know that
pesticides don't provide a very sound solution, ecologically or otherwise. PGN
------------------------------
Date: 31 Jul 90 10:33:32 PDT (Tuesday)
Subject: BMW's 'autopilot'
From: "Richard_Busch.SD"@Xerox.COM
Really-From: Chaz Heritage <chaz heritage:wgc1:RX> via Richard Busch
In RISKS-10.15 Rodney Hoffman quotes from 'Business Week', 30 July 1990:
>[BMW have]already installed an early version of their Heading Control
system in cars...A camera above the rearview mirror tracks the center
stripe and the line along the right side of the road. If a driver gets too
close to either marker, a small electric motor integrated into the steering
system is activated...Later versions will gauge road conditions...<[etc.]
There are two possible problems here. Assuming (as one has no right whatever to
do) that the system as implemented is technically perfect and never fails, one
is still left with some difficulties to do with the nature of driving:
1. If, as it would seem, the system relies on the uniformity of the road
construction then it will be unable to work on roads other than motorways
(freeways, autobahnen, autostrada, etc.) which are of modern construction and
uniform design. It will definitely not work in many urban or suburban areas in
which roads are usually far from uniform. It is on such roads (probably for
similar reasons) that most accidents occur. Motorways have very low accident
rates per vehicle-mile. It is therefore odd seemingly to address only the
problem of course loss (often due to sleep) on otherwise rather safe roads.
2. Even if the course loss problem were the main concern, then without some
method of detecting a vehicle ahead and slowing or stopping the guided vehicle
automatically, the system seems likely to ensure that a sleeping driver will be
unerringly guided into a nose-to-tail collision with the first slower-moving
vehicle encountered in the same lane.
3. The decision to overtake is prompted not primarily by the absolute legality
of the operation (i.e. over which type of line one proposes to pass), but by
the view of the road ahead, which is not available to this system. A mechanical
veto on overtaking, particularly taking the form of a 'twitch' of the steering
at the critical moment when the front wheel crosses the line, seems almost
certain to bring about accidents. The system could not reasonably be expected
to distinguish between the solid line in the centre of a minor road, which one
may not cross, and the solid line around the edge of the warning zone at the
junction of a motorway and its sliproad, which line one may cross in emergency.
It could thus intervene at a critical moment during an emergency; hardly a
contribution to road safety.
4. The experience of the introduction of ABS strongly suggests that if the
system is installed then it will be systematically abused. ABS appears to
encourage some drivers both to take unreasonable risks of loss-of-control
accidents, and to demonstrate their 'machismo' by charging the last vehicle in
a stationary queue, making an 'ABS stop' at the last moment. The introduction
of BMW HCS would infallibly bring about a perception on the part of such people
that they can (a) use as many handheld telephones as they wish; (b) read the
newspaper while driving; (c) drink more alcohol before attempting to drive,
since the car can 'find its own way home'.
In my view this development and many like it are fatuous, and are not an
acceptable substitute for responsibility on the part of drivers. Expecting
people (indeed, allowing them to be encouraged) to behave competitively and
aggressively on the road and then proposing by technical means to prevent them
from causing accidents are not the correct solution to a high accident rate.
Chaz
------------------------------
Date: Tue, 31 Jul 1990 10:56:01 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: SIGSOFT '91
PRELIMINARY ANNOUNCEMENT
SIGSOFT '91: Conference on Software for Critical Systems
Location: Washington, D.C. area
Dates: 10-12 December, 1991
General Chair:
Mark Moriconi, SRI International (moriconi@csl.sri.com)
Program Co-Chairs:
Nancy Leveson, UC Irvine (leveson@ics.uci.edu)
Peter Neumann, SRI International (neumann@csl.sri.com)
Computers are being introduced into systems that affect nearly every aspect of
our lives. There are very good reasons to do so ranging from economics to
efficiency to enhancing effectiveness and capability. But in the enthusiasm to
take advantage of computer capabilities, we are becoming increasingly
vulnerable to errors and deficiencies in the software.
The SIGSOFT '91 Conference will provide a forum in which research on all
aspects of quality in critical systems can be presented. A critical system is
a system that must exhibit, with very high assurance, some specific qualities
such as safety, reliability, confidentiality, integrity, availability,
trustworthiness, and correctness. The conference will focus on architectures,
design methodologies, languages, analysis techniques, processes, and experience
that can increase the likelihood that a system exhibits its required qualities.
Papers will be due in the Spring of 1991. More details will follow. Please
save the dates.
------------------------------
From: deswarte@tsf.laas.fr
Date: Mon, 16 Jul 90 10:32:04 +0200
Subject: Program of the European Symposium on Research in Computer Security
EUROPEAN SYMPOSIUM ON RESEARCH IN COMPUTER SECURITY ESORICS-90
October 24-26, 1990, Toulouse, FRANCE
The aim of this symposium is to further the progress of research in
computer security by establishing a European forum for bringing
together researchers in this area, by promoting the exchange of ideas
with system developers and by encouraging links with researchers in
related areas. To achieve this aim in the best conditions, ESORICS-90
will be a single track symposium and the selected papers will be
presented in a conference hall whose capacity is 250 attendees.
Computer security is concerned with the protection of information in
environments where there is a possibility of intrusions or malicious actions.
* HONORARY CHAIRMAN GILLES MARTIN (deceased on February 7, 1990)
* CHAIR AND PROGRAMME CHAIR Gerard Eizenberg, ONERA/CERT
* ORGANIZATION CHAIR Marie-France Kalogera, AFCET
* LOCAL ARRANGEMENTS Brigitte Giacomi, Ghyslaine Picchi, ONERA/CERT
* ORGANIZED BY AFCET, IN COOPERATION WITH
AICA Associazione Italiana per l'Informatica ed il Calcolo Automatico
BCS The British Computer Society
ESA European Space Agency
GI Gesellschaft fur Informatik
IEEE-CS The IEEE Computer Society
DISSI Delegation Interministerielle pour la Securite des Systemes
d'Information
DRET Direction des Recherches Etudes et Techniques
FRANCE TELECOM
INRIA Institut National de Recherche en Informatique et Automatique
TECHNICAL PROGRAMME
WEDNESDAY, OCTOBER 24, 1990
8:30 Registration
9:40-10:00 Welcome and Introduction
10:00-11:00 Database I, Robert Demolombe, Chair
Teresa F. Lunt, Donovan Hsieh - "The SeaView Secure Database System:
A Progress Report"
Kioumars Yazdanian - "Relational Database Granularity"
11:30-12:30 Database II, Teresa F. Lunt, Chair
Udo Kelter - "Group-Oriented Discretionary Access Controls for Distributed
Structurally Object-Oriented Database Systems"
Joachim Biskup - "A General Framework for Database Security"
2:00-3:30 Secure Systems I, Dennis Steinauer, Chair
R. W. Jones - "A General Mechanism for Access Control: Its Relationship to
Secure System Concepts"
Jorg Kaiser - "An Object-Oriented Architecture to Support System Reliability
and Security"
Zoran Savic, M. Komocar - "Security Kernel Design and Implementation in the IBM
PC Environment"
4:00-6:00 Secure Systems II, David Bailey, Chair
G. Hoffmann, S. Lechner, M. Leclerc, F. Steiner - "Authentification and Access
Control in a Distributed System"
I. Akyildiz, G. Benson - "A Security Level Reclassifier for a Local Area
Network"
Laurent Blain, Yves Deswarte - "An Intrusion-tolerant security server for an
open distributed system"
E. Stewart Lee, Brian Thomson, Peter I. P. Boulton, Michael Stumm -
"An Architecture for a Trusted Network"
6:15 Poster Sessions
THURSDAY, OCTOBER 25, 1990
9:00-10:30 Models I, Franz-Peter Heider, Chair
Brian Thomson, E. S. Lee, P. I. P. Boulton, M. Stumm, D. M. Lewis - "Using
Deducibility in Secure Network Modelling"
Vijay Varadharajan - "A Petri Net Framework for Modelling Information Flow
Security Policies"
Anas Tarah, Christian Huitema - "CHIMAERA : A Network Security Model"
11:00-12:00 Models II, Luis Farinas del Cerro, Chair
Frederic Cuppens - "An epistemic and Deontic Logic for Reasoning about Computer
security"
Colin O'Halloran - "A calculus for information flow"
1:30-3:00 Cryptography, Louis Guillou, Chair
D. de Waleffe, J.-J. Quisquater - "Better login protocols for computer
networks"
Marc Girault, Jean-Claude Pailles - "An Identity-Based Scheme Providing
Zero-Knowledge Authentication and Authenticated Key-Exchange"
Jacques Patarin - "Generateurs de permutations pseudo-aleatoires bases sur le
schema du DES"
3:30-5:00 Panel : "Update on Public-Key know-how", Paul Camion, Chair
5:15 Poster Sessions
FRIDAY, OCTOBER 26, 1990
9:00-10:00 Software Engineering for Security, Rene Jacquart, Chair
E. S. Hocking, J. A. McDermid - "Towards an Object Oriented Development
Environment for Secure Applications"
G. P. Randell - "A Case Study in the Formal Refinement of a Distributed Secure
System"
10:30-11:30 Security Verification and Evaluation, Peter Bottomley, Chair
Pierre Bieber - "Epistemic Verification of Cryptographic Protocols"
Eric Deberdt, Sylvain Martin - "Methodologie "Minerve Securite": Demarche
d'Evaluation de la Securite des Logiciels"
11:30-12:30 Panel : "Security in Software Developments Environments"
Chris Sennett, Chair
2:00-2:45 David Bailey (invited) - "Managing Computing Security: What
is Needed from the Research Community?"
2:45-3:15 Jean-Francois Pacault (invited) - "Harmonizing the Information
Technology Evaluation Criteria"
3:45-5:15 Panel : "Impacts of Evaluation Criteria on Research"
Christian Jahl, Chair
5:15-5:30 Closing Remarks
SYMPOSIUM LOCATION : F.I.A.S. (Formation Internationale Aeronautique et
Spatiale) - 23, avenue Edouard-Belin - 31400 Toulouse - France
telephone : +33 61 55 00 87 - telefax : +33 61 55 16 97
CONTACTS: For other general information concerning the symposium, contact :
Veronique SEGAUD - AFCET - tel : +33 1 47 66 24 19, fax : +33 1 42 67 93 12
[Full registration information and application form can be obtained on-line
from deswarte@tsf.laas.fr or from risks-request@csl.sri.com, or FTPed from
the CRVAX.SRI.COM machine (see masthead instructions) with file name
"conf.esorics". PGN]
------------------------------
Date: Wed, 1 Aug 90 17:13:38 GMT
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Pilots vs. automation (Henry Spencer, RISKS DIGEST 10.16)
This isn't a promise not to enforce the laws, it's a fairly straightforward
interpretation of some of the most fundamental aviation regulations in
existence (and long-standing, harking back to days of captains on the high
seas, out of touch with their admiralties for months running).
By U.S. Federal Aviation Regulation 91.3(b), "In an in-flight emergency
requiring immediate action [such as a TCAS alert], the pilot in command may
deviate from any rule of this part [including clearances] to the extent
required to meet that emergency." I suspect that the ALPA's beef is that
they'd just like it more explicitly worded with respect to TCAS and other
automated aids, and perhaps changed to "a perceived in-flight emergency."
This brings to mind an interesting thought: who gets the blame if
(when) a TCAS warning *causes* a collision, through either
electronic or human confusion?
By FAR 91.3(a), "The pilot in command of an aircraft is directly
responsible for, and is the final authority as to, the operation of
that aircraft." If Air Traffic Control instructs a pilot to fly into
the side of a mountain, the pilot is at fault if he follows along. If
TCAS says "CLIMB!" it's still the pilot's responsibility to decide
whether to obey. It's the pilot's job not to be confused.
General aviation pilots have voiced the concern that TCAS will lead to
complacency on the part of air carrier crews, depending too much on
the technology, leading to a breakdown of the basic "see and avoid"
(FAR 91.113(b)) means of avoiding collisions, which is still the only
method that will work when flying near non-transponder-equipped
aircraft. Air carrier pilots respond, as expected, that everyone
should have a transponder. And so it goes...
------------------------------
Date: Wed, 1 Aug 90 10:21:45 EDT
From: ark@research.att.com
Subject: Altitude violations and TCAS
It's not clear that deviating from a clearance is violating the regulations at
all. My evidence:
From the Pilot/Controller Glossary:
Emergency: a Distress or Urgency condition
Distress: A condition of being threatened by serious
and/or imminent danger and of requiring immediate
assistance
Urgency: A condition of being concerned about safety,
and of requiring timely but not immediate assistance;
a potential Distress condition.
So, if your TCAS has just told you that you might hit another
airplane if yuo don't change course, that's an emergency.
Now we turn to Federal Aviation Regulations, Part 91: General
Operating and Flight Rules. Section 91.123 is where it says
you can't leave an assigned altitude:
(a) When an ATC clearance has been obtained, no pilot in
command may deviate from that clearance, except in an
emergency....
(b) Except in an emergency, no person may operate an aircraft
contrary to an ATC instruction in an area in which air
traffic control is exercised.
(c) Each pilot in command who, in an emergency, deviates
from an ATC clearance or instruction shall notify ATC
of that deviation as soon as possible.
And section 91.3 gives blanket authorization:
(a) The pilot in command of an aircraft is directly
responsible for, and is the final authoriaty as to,
the operation of that aircraft.
(b) In an in-flight emergency requiring immediate
action, the pilot in command may deviate from any
rule of this part to the extent required to meet
that emergency.
(c) Each pilot in command who deviates from a rule under
paragraph (b) of this section shall, upon the request of the
Administrator, send a written report of that deviation
to the Administrator.
This seems pretty clear. A pilot who realizes the possibility of a midair
collision has the authority and responsibility to do whatever is necessary to
prevent it. After deviating from course one must notify ATC (``New York
Center, Cessna 5-7-Tango turning right 2-0 degrees to avoid traffic'') and file
a written report if requested, but emergency deviations are explicitly allowed
by the regulations.
Andrew Koenig (private pilot, instrument airplane single-engine land)
------------------------------
Date: Wed, 01 Aug 90 09:55:25 EDT
From: Dave Davis <davis@mwunix.mitre.org>
Subject: Risks of Research vs Errors
In the 10.16 edition of Risks, Mr. Miya points out that about 90%
of research fails. However, the Hubble telescope's problems are
a bit more mundane, NASA just goofed. When a research experiment
fails to give us the answers we expected, we must adjust our theory
and possibly our hypothsis and begin again. Hubble's problems
indicate to many in Congress as well as the public that NASA has
problems managing itself as well as its contractors. Ironically,
it seems that a part of the difficulty stems from the use of a
notoriously secretive Air Force affilliated contractor to do the
critical mirrors.
Dave Davis, MITRE Corporation, 7525 Colshire Dr., McLean, VA 22102
------------------------------
Date: Tue, 31 Jul 90 22:53:42 EDT
From: Brinton Cooper <abc@BRL.MIL>
Subject: Re: Hubble Trouble
RE Gene Miya's "hindsight" arguments:
I agree that complex projects have "problems" and that many (not
"every") projects involve "compromises." These are EXACTLY the reasons
for ADEQUATE and THOROUGH TESTING. The lack of testing and the
fuzzy-headed thinking that rationalized away the need for testing are
nothing new to observers of the DoD (MY employer, folks). Our systems
have been failing for years because of inadequate independent testing
and evaluation.
I wonder if there's a connection between NASA's increasingly
poor performance and the increasingly large number of ex-DoD types
working there in VERY high places?
"Lastly," we all agree that much "research" ends in "failure"
according to the uninformed definition of "success." But building the
Hubble was no research project. It was an ENGINEERING job.
Needless to say, these opinions are mine and do not constitute an official Army
position, etc, etc.
_Brint
------------------------------
Date: Wed, 1 Aug 90 00:21:13 EDT
From: bryce@cbmvax.cbm.commodore.com (Bryce Nesbitt)
Subject: Hubble Trouble (Mirror, mirror, on the wall)
Eugene N. Miya <eugene@wilbur.nas.nasa.gov> writes:
>I worry about the "climate" for any
>research in this country, because research tends to fail 90% of the time (if
>you really need a reference for this I have it)....
>[Perkin-Elmer] is making mirrors and equipment for other project, I would
>worry about Keck for instance.
I agree with your point about research, but I view Hubble as "screwed up
research" instead of "a good try that failed". The mirror was only the latest
serious screwup. I have no inside track on Hubble; that's just an outside
impression.
The Keck mirrors have been a concern. There is a difference from Hubble,
however. Keck uses asymmetrical mirror segments. Each of the 36 segments
is a slice of the final shape. Weights are hung from each segment, the
mirror is conventionally ground, then the weights are released. All this
is very new, and very research oriented. (Perkin-Elmer is not involved,
unless it happens to own Itek, the primary mirror contractor).
Hubble's mirrors are precise, but nothing special. I find it ironic to
go back to some glowing magazine articles about how well the the mirrors
were built... they exceeded spec on several points (including reflectivity).
The builders seemed very proud.
------------------------------
Date: Wed, 1 Aug 90 08:38:26 CDT
From: "Jay Schmidgall" <shmdgljd@rchvmw3.iinus1.ibm.com>
Subject: RISKS of slanting computer related excerpts
In a recent digest, "Richard_Busch.SD"@Xerox.COM writes
> [...] Joe, a four-year-old Blue Chequer pigeon.
>
> [...] Joe beat the fax in a one mile challenge race, arriving more
> than a minute before the caricature drawing of him emerged from the
> machine.
It should be noted that the pigeon was given a two-minute head start
before the fax company began its transmission. As I read the actual
article, it appeared that the pigeon had arrived before the company even
began it transmission.
While we all may enjoy that good old-fashioned methods can sometimes
subvert the best efforts of modern technology, we should not let this be
portrayed in unrealistic examples. The referenced excerpt made it sound
as if the two had started at the same time, requiring the pigeon to be
flying near light speed (exaggeration for dramatic effect!).
-- My opinions are my own and do not necessarily reflect those of IBM --
Jay Schmidgall
------------------------------
End of RISKS-FORUM Digest 10.17
************************
** End of text from cdp:comp.risks **
Comments
Post a Comment