Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The moderator recently requested intelligent open discussion
relating to computers and related technologies in SDI. I believe that
there has instead been too much discussion of computers and SDI.
The hardware and software issues raised by Parnas and others are
interesting. They are complex, they defy simple quantification, and they
relate directly to the work of many of the readers of this digest.
Yet, there are much simpler and more easily discussed problems with
SDI. SDI provides minimal protection to Europe. SDI does not appear to
provide protection against nuclear weapons launched at the US from off-shore
submarines. Bombs can be smuggled into the US via, say, Canada, and
reassembled in the hearts of our cities. Clearly, if you heed these
arguments, SDI in no way makes nuclear waepons "impotent and obsolete".
By focusing our attention and that of the general public on
computer-related SDI arguments, we run the *risk* of diverting attention
from more important issues. We as computer technologists are raising the
(weak, esoteric) issues with which we are familiar, when we as intelligent,
informed citizens should be raising more general questions (perhaps
precisely because we *are* less familiar with them).
There is a risk in introducing computers into a discussion in
which they are not really relevant. It is not enough to be able to
discuss an issue intelligently. One must also know when it is
intelligent to raise the issue in the first place. (By the way, it is
not clear to me that this message qualifies, either).
Craig Milo Rogers
[This issue reaches a relative high mark for noninclusion of messages,
as I have omitted several on this topic. However, this one gets accepted
— because it is sound, objective, and coherent, and does not violate
the other requirements. I have stated before that it is impossible to
draw a line around "computer relevance". Craig's point is well taken.
By the way, I squelched the discussions between Michael Scott and
Andy Freeman (plus a comment from Herb Lin) which were getting to
third-order arguments and re-reinterpretations. (Both of the main
participants still feel they have further clarifications to make.)
However, I urge you all to take more care in your INITIAL statements.
That can do wonders at staving off lengthy iterations. PGN]
From: Douglas Humphrey
Swedish Vulnerability Board Report on Complex System Vulnerabilities
Chuck Youman <m14817@mitre.ARPA>
Thu, 23 Oct 86 13:52:32 -0400
The October issue of Signal magazine contains an article by Thomas Osvald on
"Computers, Vulnerability and Security in Sweden." It describes a number of
projects carried out by the Swedish Vulnerability Board. Of particular
interest to RISKS is a project that addressed the vulnerability problems
associated with the complexity of EDP systems. Mr. Osvald writes:
> A system becomes too complex when nobody can intellectually
> understand and comprehend it. Thus, a company will not change a
> system because secondary effects cannot be foreseen. The board
> concluded that one of the problems of conventional, administrative,
> complex systems is that it is difficult or even impossible to
> change these systems in an orderly, controlled way. On the other
> hand, there is a rapid increase in the change rate in our society
> in general and a correspondingly increasing demand for flexibility
> in information systems.
> Therefore, it must be accepted that programs are for standard or
> nonrecurrent use with an ever shorter life expectancy. However,
> data that are the raw material of information will not change as
> quickly as the processing rules. Data are therefore the resource
> that has to be cultivated, protected, tended, preserved, and developed.
> This approach supports recent developments of systems design methods,
> such as fourth generation languages, data dictionaries, and data base
> techniques.
Unfortunately, the article does not include a bibliography. Does
anyone out in RISKS-land know if a English translation of this report
exists?
Charles Youman (youman@mitre.arpa)
Re: Thresher
David Feldman <feldman%dartmouth.edu@CSNET-RELAY.ARPA>
Wed, 22 Oct 86 02:34:25 edt
A friend of my dad's who served in the submarine service once told me his
"version" of the events on the Thresher:
Water had gotten into a compartment (or at least onto a sensor) in the
reactor unit, and that caused the reactor to scram. (According to him, this
type of shutdown is unconditional and irreversible on USN subs). When the
ballast tanks were blown, for some reason the delivery pressure of the air that
cleared the ballast tanks came in higher than normal, and caused a greater
temperature drop at the valves. The valves froze open, allowing all of the air
to escape, leaving the Thresher defenseless.
Note: this is second hand from one submarine officer.
Dave Feldman
feldman@dartvax.edu
Stealth and ATC
Dan Melson <crash!pnet01!dm@nosc.ARPA>
Thu, 23 Oct 86 01:03:13 PDT
If it exists, they are hardly going to put it into heavily travelled airspace
over high population areas, where everybody can see it.
As for radar signatures, civilian ATC relies upon a mode 3/a transponder, and
targets are generated on our PVD's (primarily) as a result of that. If they
want the aircraft visible to civil radar, they simply turn the transponder on.
(There are large areas of restricted airspace and MOA's (Military Operations
Areas) where the military does it's own operations without hindering civil
ATC, and if it exists, would guess that most stealth flights are within
such areas)
The above information is non-classified, freely available to any private
pilot.
DM
Inoperative components
Peter Ladkin <ladkin@kestrel.ARPA>
Thu, 23 Oct 86 18:28:22 pdt
Doug Humphrey wonders whether aircraft need cockpit warnings to tell of
major failure modes. The answer seems to be yes. Multi-engine aircraft
instructors will tell you that a common occurrence with simulated engine
failures in multi-engine aircraft is for the student to feather the prop on
the good engine. The NTSB notes that this happens for real, too.
Peter Ladkin
ladkin@kestrel.arpa
Please report problems with the web pages to the maintainer
x
Top