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…
Joseph Weizenbaum states that he would be against SDI "even if it worked." I agree. The premise that "IF the SDI could work, then we must have it (at any price)" is naive. It seems that many people are willing to accept that premise hoping that it will anchor the discussion in the technical area. One factor which is rarely addressed is that of intermediate systems which the SDI will spawn. There is a tendency to think of the SDI system as being one big system that one day appears overhead as a whole, integrated system. I have little doubt that the SDI plan includes many deliverables along the way. These intermediate systems will both be arguably non-defensive and pose a large problem for integration. I.e., the system must not only be trustworthy when "fully deployed" but at a multitude of intermediate steps. Thus risks will exist in advance of the full delivery (if there ever is to be one). Another factor is the so-called defensiveness of the system. If two people are armed with guns and one suddenly dons a bullet proof vest this act will be perceived as an offensive act. Pro-SDI people almost always accuse SDI critics of being politically motivated. Given the immense (and possibly impossible) technical task of getting the system to work, and the guarenteed proliferation of offensive weapons (designed to penetrate the system), it is very, very difficult for me to believe that the pro SDI folk are not motivated primarily from political (and economic!!) grounds. - Doug Schuler
To: risks@SRI-CSL.ARPA
To quote from RISKS Vol 1 #8:
2. I can disagree only with one aspect of Weizenbaum's contribution.
He says that he would be against SDI even if it would work, but his
arguments mainly show even more reasons why it won't "make nucelar weapons
impotent and obsolete." It is probably useless to argue about how we
would feel about the system if it would work, but I feel the decision
would be much harder to make than it is now. [Dave Parnas]
I think this touches on the crux of the matter: what problem is SDI meant to
solve? If we could guarantee that SDI would not only "make nuclear weapons
impotent and obsolete", but would in fact reduce the risks associated with
war (not necessarily the same thing) then I would not be against SDI.
However, I argue (and I suspect this is Weizenbaum's point, too) that an SDI
that worked according to the current specification would actually increase
risks, even though the system performed "flawlessly".
This is not the place to discuss the strategic implications of SDI, but I
think it's important to realize that there are those of us who believe both
that SDI is not likely to meet its current specification, nor that it would
be a good idea even if it did.
[I] would see some truth in the argument that the non-technological
solutions also have a clear risk of failure. [Parnas]
I am afraid that there is no failure-proof solution, technological or not,
to the problem of "war". John McCarthy is right that we must compare
the risks of the technological solution (e.g., SDI) to its non-use. My
fear is that, in this case, the problem is not that the use of technology
might fail to solve the problem, but that it might actually make things
worse.
To: risks@SRI-CSL.ARPA
There has been some discussion of comparing alternative risks on the
RISKS mailing list lately. For example, what is the risk associated
with the introduction of a new technology versus not introducing the
technology? Risk assessment and risk management need not be
"guesstimates" nor "a number picked out of the air."
The insurance industry has had to assess and manage risks for years.
In fact, they have made quite a science out of these two areas. I
would recommend that those who wish to find out more about risk
management and risk assessment read:
RISK MANAGEMENT AND INSURANCE, Fourth Edition, by C. Arthur
Williams, Jr. and Richard M. Heins, McGraw-Hill, 1981.
Don't let the title put you off. Virtually the entire book is
dedicated to risk management, with only a few pages on insurance. You
will also find that there are entire professional societies dedicated
to managing and assessing risk, e.g., the American Risk and Insurance
Association and the Risk and Insurance Management Society.
— Ed Berard
EBerard at ECLB
(301) 251 - 1626
To: LIN@MIT-MC.ARPA
cc: Risks@SRI-CSL.ARPA, Security@RED.RUTGERS.EDU
Date: Sun, 8 Sep 85 16:40:44 EDT
From: Herb Lin <LIN@MIT-MC.ARPA>
My naive model is that I have a special program that intercepts the
raw bit stream that comes in from my communications port. It then
translates this into ASCII, and then prints it on my screen.
If this is all that my program does, I can't see what harm can be done.
Several kinds of terminals are programmable from the host, in that
certain escape sequences can be sent to them to get them to perform
actions such as defining the terminal's function keys.
If a user inserts the appropriate escape sequences in a mail message
to his system manager, or into a file which will be displayed by the
manager, when the manager reads that mail message it will reprogram
a function key on the manager's terminal, which the manager may have
programmed to do some common harmless function, to instead do some
other command such as give the user unauthorized privileges.
This is a fairly well known bug, and many mail systems are now
protected against it, in that they will not transmit any control
characters or escape sequences to the terminal.
The moral is that there are many subtle ways to break security,
and even things that seem to be quite safe may not really be.
...Keith
Please report problems with the web pages to the maintainer