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…
Around 7:30 p.m. on 28 May, a white single-engine Cessna with West German markings buzzed Lenin's mausoleum and landed near the Kremlin wall on the 750-yard-long Red Square in central Moscow. The pilot was a West German teenager named Matthias Rust. The plane had flown 550 miles from Helsinki to Moscow across ``one of the most closely guarded borders in the world''. Ironically it was a Soviet holiday honoring the nation's border guards, who were evidently less than alert. [Adapted from an article by Carol J. Williams, Associated Press Fri 29 May 1987 and subsequent reports]
Seeing that the Soviets also have a lookdown radar capability and this man
flew for hours in Soviet airspace, this makes me wonder more about the
limitations of such systems (also in the Stark incident). I have not seen a
topographic map of the area he flew in, nor have ideas about traffic
patterns in the SU, but I think there are computers and software in this
(still probably not a computer problem but a C^2I problem which the Stark
incident has resolved into), and it's too bad we don't have Soviet
correspondents to flame about this.
--eugene miya
[Apparently the plane was observed at various points along the way,
but was flying so SLOWLY that air reconnaissance was difficult!
I omitted this item from RISKS-4.92 because it seemed only marginally
relevant at the time. The computer part of the Soviet air defense system
seems not to have been a problem. However, I become more convinced
with each passing RISKS Forum that it is human failings that underly
our most interesting RISKS cases — requirement errors, design flaws,
implementation bugs, operational glitches, system misuse, or just plain
human screw-ups, whether or not a system is heavily automated. From now
on I will no longer work so hard to justify inclusion of human misuses
of technology (or human misuses of what should have been done by technology
but was not). In this case several heads have rolled — the Soviet
defense minister retired, the air defense commander was fired, and other
jobs are considered in jeopardy.
It is interesting to contrast this case with the KAL 007 — there are
similarities and significant differences. There are also some parallels
with the Stark episode. ``Who would ever think that a plane approaching
Moscow was not properly authorized?!'' PGN]
[With respect to it having been "National Border Guard Day":]
[There's an old Swedish joke that the Norwegians will invade on a summer
weekend, when the entire Swedish army is on vacation. Martin Minow]
I've watched the discussion in RISKS about the Exocet, the performance of
the PHALANX system, and missile defense, and in a number of cases have
wished that less of what I knew was classified, so I could correct mistakes
that have been put into comments. There are, however, some details that I
can talk about freely.
The Phalanx system installed aboard ships has a theoretical arc of fire of
270 degrees, subject to cutouts from ship structure. The placement of the
system aboard the FFG-7 class results in the system retaining most of its
theoretical arc of fire. Unfortunately, the design of the FFG-7 precludes
installing a second Phalanx - there's no place to put it. However, the lack
of a forward firing arc is not serious in most cases, as I will show below.
As the author of the only interactive chaff-launcher training simulator in
use by the Navy at this time (at least, according to the information I get
from the Fleet Combat Training Center here, where the program is in use), I
think I am qualified to comment on the use of chaff as a missile defense.
The effective use of chaff in missile defense depends on several factors -
the speed and direction of the relative wind, the specific design of the
ship's superstructure, and above all, detecting the missile as soon as
possible.
The two basic tactics for decoying a missile with chaff are to 1) give the
missile a 'better' target than the ship to track and 2) use the chaff to
pull the missile's aim away from the ship after the missile has locked on
to the ship. To do this, the chaff must present a larger radar cross
section (RCS) than the ship.
All ships have a variable RCS, depending on the angle the ship makes with the
missile's course. The smallest RCS occurs with the bow or stern about 15-20
degrees off the line of the missile's course. If the ship is beam-on to the
missile, in most cases, all the chaff the ship can fire isn't going to help.
The relative wind is important because, first, the idea is to get the
missile to follow the chaff away from the ship, and since the chaff moves
at the speed of the relative wind, its movement is dependent on the wind,
and second, the chaff launchers don't throw the chaff rounds that far away
from the ship - a good relative wind is necessary to give the chaff enough
separation to allow it to appear as a separate target for the missile to
pick to track instead of the ship.
Finally, the missile must be detected as soon as possible. The chaff rounds
aren't immediately effective. It takes time for the round to reach its
'bloom' point, and another second or two for the chaff cloud to bloom. If
the missile is close enough, there won't be enough time for the chaff cloud
to form at all, or the chaff cloud won't have enough separation to be
useful. From the information gathered from the chaff simulation I wrote,
you generally need between 30 and 60 seconds of warning to be able to
deploy chaff effectively.
The big advantage in the use of chaff, however, is that it's simple and
quick to use, if you get the warning. A four-position rotary switch, an ARM
button, and six firing buttons for the six rounds in a launcher box
comprise the entire console, which is part of the SLQ-32 console. The
SLQ-32, the ELINT and ECM equipment, should have been manned while the
Stark was in the Gulf. It is the responsibility of the ECM operator to
detect the lock-on of the firing aircraft, and to use chaff and other
soft-kill measures against an incoming missile. From the information I've
seen on the Stark incident, whoever was at the SLQ-32 console has to have
been asleep at the switch, and is probably going to get raked over the
coals, along with the CO and the OOD.
Sean Malloy, Naval Personnel Research & Development Center,
San Diego, CA, 92152-6800 (VOICE) (619)225-6434
(soon to be malloy@nprdc.mil)
[Thanks for letting us in on what you could.
I noted with interest the articles in this morning's paper, which
imply that there were no technological failures, only human failures...
Does that sound familiar? PGN]
[Subsequent messages from Sean Malloy]
The paper here this morning says that the CO, the XO, the TAO, and the WCO
can all be held culpable. I'm not sure, because I don't know how the
watchbill is set up aboard an FFG-7, but I think that the Tactical Action
Officer and Weapons Control Officer may be the same person under normal
circumstances - there may not be more than one officer on duty in CIC, and
the designation of TAO is dependent on who is on duty - all of the command
officers should have been through TAO school.
It all goes to show that having fity million dollars worth of technological
support doesn't do you any good if you don't use it [properly].
> Years ago, the US Army had a weapon called the "Chapparal", which > was a 20mm gatling mounted on an armored personnel carrier.... You may be confusing the Chapparal with something else. The Chapparal had 4 Sidewinder missiles mounted on an armored personnel carrier. My dad worked on it when it was being designed and tested. There was talk at one time of putting some kind of guns on it for self-defense. Mike Iglesias, University of California, Irvine
I was at a local computer dealer recently. I'm friends with some of the
people who work there, so I was in back in the repair shop. Someone had
brought in an Apple LaserWriter to be fixed. They had purchased it about
six months before, and at that time purchased a security device consisting
of a plate with some (allegedly) permanent adhesive, attached to a thick
steel cable. Unfortunately, when they installed the device, they placed it
in such a position that the steel cable extended over an access door in the
bottom of the LaserWriter, making it impossible to repair the machine. But,
as anyone good repairperson knows, if something's in the way, you take it
off. In about ten seconds, with only a normal slotted screw driver, the
"permanent" security device had been removed, leaving only a few scratches
on the bottom of the LaserWriter!
The moral is two-fold: first, be careful when installing any security device,
so it can be removed, or isn't in the way for normal use or repair, and
second, no security device is perfect, and some are less perfect than others.
Brian L. Matthews Computer X Inc. - a division of Motorola New Enterprises
...{mnetor,uw-beaver!ssc-vax}!cxsea!blm +1 206 251 6811
I'd like this information too, but I don't think people should have to pay
$35 a year for this service. I think that TRW and other credit bureaus
ought to be required to send you a notice, for free, whenever your credit
record is queried or modified.
At present, we treat databases containing personal information as though
they were (almost) equivalent to any other corporate asset belonging to the
company that compiles the data base. Existing regulations on data privacy
are a moderately weak compromise between commercial interests and privacy
rights. I think the balance needs to shift.
-Jonathan
Please report problems with the web pages to the maintainer