Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!hogg
From: hogg@utcsri.UUCP (John Hogg)
Newsgroups: can.politics
Subject: Re: problems with Star Wars #2 (part 2: the crux)
Message-ID: <1240@utcsri.UUCP>
Date: Wed, 10-Jul-85 16:57:56 EDT
Article-I.D.: utcsri.1240
Posted: Wed Jul 10 16:57:56 1985
Date-Received: Wed, 10-Jul-85 17:41:44 EDT
References: <1197@utcsri.UUCP> <5772@utzoo.UUCP>
Reply-To: hogg@utcsri.UUCP (John Hogg)
Organization: CSRI, University of Toronto
Lines: 71
Summary: 


First, a retraction: in my posting of Ric's paper that started all this,
there was a reference to an airplane crash caused by faulty software.  Upon
digging further, I can't find the incident.  The example is retracted; the
point about the inconceivable cost of BMD failure remains.

"Having dealt with some side issues", I will rebut Henry's rebuttal.

First, the matter of the need for absolute correctness, given that
verifiability is virtually impossible.  If we are to protect our cities
from attack, a "small" leakage is absolutely unacceptable.  Thus, the
battle management software must be perfect.
If we use such follies as pop-up missiles, matters are much worse.  A
missile rising out of a submarine is going to look hostile, no matter what
it does.  In fact, the mere starting up of ANY sort of BMD system is going
to look hostile; remember, current bets are that a BMD system adequate to
cope with a retaliatory strike is probably feasible, so firing it up may be
the first step of a first strike.  In which case, the only way for the
Soviets to preserve their deterrent is to go to launch-on-warning so that
something will get through.  They may consider some stage of BMD startup to
be "warning".  And then they may not... did you play "chicken" in your
younger days?  Did you play it with the population of the Northern
Hemisphere in your car?

Note, by the way, that no straw-man tying of BMD to retaliatory ICBMs is
needed to cause an "accidental" war.

Now for the point that, given the source, shocks me.  Henry asks
>Furthermore, why should the decision to activate an SDI system against
>a major attack have to be automated at all?

ALL proponents of SDI (with the possible exception of ol' Sixgun)
including fanatics such as Daniel Graham, consider a boost-phase defence to
be the only feasible approach.  Boost phase can most comfortably be
measured in seconds.  By the end of that time, the rising missiles must be
destroyed - not identified as being worthy of destruction.  If the Soviets
go to simultaneous launch (difficult, but much simpler than SDI!) the
decision must be made within the first few seconds of boost.  What kind of
meaningful information can a human absorb, let alone digest, in this time?
And multiple decisions by multiple observers is even more ridiculous.

Henry's speculation that humans could even handle the battle management
functions is surely the product of a hallucinogens in the Ramsey Wright
water supply.  Read the Fletcher Report on Battle Management to get an idea
of the magnitude of the problem; ask me to expand on this if you wish.

The REAL "crux of the matter" is perhaps that

>If one assumes an attack in progress, the benefits of success clearly
>outweigh the possibility of failure.

On the other hand, if an attack isn't yet in progress, but is made far more
likely by a system that won't work perfectly for ICBMs and not at all for
bombers, cruise missiles and SLBMs, then the benefits of this incredibly
expensive system become very hard to see.  (Of course, I don't work for
Lockheed.)  And the phrase, "won't work perfectly" is much weaker than it
needs to be.  Numerous counters to SDI as currently envisaged have
already been proposed, many of them cheap and simple.  "Won't work at all"
might well be less in error.


>I have discussed elsewhere the interesting reasoning: "because some
>types of SDI systems would be very dangerous, any SDI system would be".

Henry, in light of what I've said here, please propose a non-dangerous SDI
system!
-- 

John Hogg
Computer Systems Research Institute, UofT
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsri!hogg