_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
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
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 (email@example.com) Program Co-Chairs: Nancy Leveson, UC Irvine (firstname.lastname@example.org) Peter Neumann, SRI International (email@example.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.
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 firstname.lastname@example.org or from email@example.com, or FTPed from the CRVAX.SRI.COM machine (see masthead instructions) with file name "conf.esorics". PGN]
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...
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)
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
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
Eugene N. Miya <firstname.lastname@example.org> 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.
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
Please report problems with the web pages to the maintainer