The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 4 Issue 29

Sunday, 14 December 1986

Contents

o America's Cup: Left-over Digital Filter
Bruce Wampler
o Some additions to the "bug" taxonomy
Dick King
o Re: uninterruptible power
Ted Lee
o Trade-offs between BMD architecture and software tractability
Herb Lin
o Re: Criminal encryption
Garry Wiegand
o Computerised Discrimination
Scott Preece
o More on Incompatible Plug-Compatible Monitors
Al Stangenberger
o Info on RISKS (comp.risks)

 

<ames!rutgers!seismo!unmvax.unm.edu!wampler@cad.Berkeley.EDU>
Fri, 12 Dec 86 09:07:06 MST
      (Bruce Wampler)
To: RISKS@ucbvax@csl.sri.com
Subject: America's Cup: Left-over Digital Filter

This story is from the NOVA "Sail Wars" of 9 Dec 1986:

This NOVA was about the design of Stars & Stripes, one of our entries in the
current America's Cup event in Australia.  There were two interesting
stories, both having to do with modelling and tank testing of scale models.

Apparently in the early 70's, Ted Turner had a boat built directly from a
tank model.  The boat worked wonderfully in the tank, but was a total dog in
full size.  This design disaster soured American designers on tank
modelling, ultimately resulting in the loss of the America's Cup 3 years ago
to the Australian boat, which had been designed using modelling.  In the
70's, the models were apparently on a 1:13 scale.

The current entry was designed using tank modelling (1:3 Scale).  Stars &
Stripes went through 3 versions.  Much of the design was aided by computer
modelling, followed by building of scale models for tank testing.  The tank
testing was closely measured, and the results again fed through
computer-analysis programs.  The design was getting down to the wire for the
3rd version of the boat.  Measurements fed through the analysis programs
indicated a serious problem with the stern of the boat.  The designers were
visibly depressed.  After some modifications, new measurements indicated the
problem got worse.  At this point, they really were out of time - either
give up the 3rd version, or find the problem.

In a sort of "sanity test", the designers refused to believe the computer
output.  This was apparently standard naval architecture software and well
trusted, given the reluctance shown to disbelieve the results.  At any rate,
after a long all-night session, they discovered that "a digital filter used
previously for an oil platform test had inadvertly been left in the computer,"
thus causing the wrong results.  With the filter removed, the measurements
showed better than expected performance. (Not good enough, apparently.  The
yacht New Zealand seems to be cleaning up in the challenger races.)

                      [Moral: Don't forget to change the oil filter.  PGN]


Some additions to the "bug" taxonomy

Dick King <king@kestrel.ARPA>
Sat, 13 Dec 86 11:35:12 pst
"mugs"  -- Trojan horses and other intentionally introduced anomalies

"plugs" -- interface errors

"ugs"   -- a bug isolated to a small piece of code, the sort of thing you can
           stare at for hours, and all of a sudden someone walks up to ask you
           if you want to go to lunch, glances at your work, points to the
           offending line of your CRT or listing, and says "you know, ..."
                                                                       [ughs?]


Re: uninterruptible power

<TMPLee@DOCKMASTER.ARPA>
Sat, 13 Dec 86 00:41 EST
And in the case of a large installation the back-up power is most impressive. 
I had a chance to visit Air France's computer center (somewhere near the
Riveria) several years ago (pure boondoggle, I admit.)  As I recall there were
about three floors (basketball court size, maybe) of Univac 11xx's and disk
farms (two approximately duplicate systems, each at least two processors) and
comm gear etc.  On the ground floor were at least two, maybe three diesel
generators that would do a small city proud.  Short of a nuclear attack that
system was not going to be shut down by anything! (and yes, they made sure the
fuel tanks were full and periodically tested the generators -- I don't remember
the mechanism used to keep power up while the generators were starting.)


Trade-offs between BMD architecture and software tractability

<LIN@XX.LCS.MIT.EDU>
Sun, 14 Dec 1986 11:48 EST
It has been generally accepted that software for BMD must perform a variety
of functions, including tracking targets, discriminating between decoys and
RVs, and so on.  As importantly, the software must be constructed in such a
way that all the parties are confident that it will perform these functions
when called upon to do so.

This list of functions raises an interesting point.  I agree with the list, but
am troubled by its dependence on system architecture.  Specifically, we could 
imagine a "BMD" system that consisted of thick orbiting shells of gravel at 500
km altitude.  No ballistic missile now known could penetrate that, and we could
have confidence that it would work.  The software would not need to perform
any of the functions that both critics and supporters of SDI agree must be
performed.  The sole issue is the cost of putting all that junk in space.

The existence of this "alternative" BMD suggests that the "software" needed
to control it need not be complex, extensive or unreliable; the system just
proposed doesn't need it at all.  However, no one thinks that an actual BMD
will not require software.  Thus, we conclude that for deviations that are
"large enough" from "prototypical" architectures, the software problem can
be made tractable.  An interesting question arises:  How can we develop more
precise measures for the phrase "large enough deviations" and the word
"prototypical"?

The Eastport Study used such an approach; they said that an unconventional
architecture would make the software problem tractable.  The argument above
suggests that for a sufficiently unconventional architecture, they are
right.  My problem with the Eastport study is that they have not made an
argument that their preferred architecture is even in the right direction of
"unconventionality", let alone "far enough"; indeed, I think they have gone
in the wrong direction.  But my problem with my own position on BMD software
(i.e., very critical) is that I have constructed an existence proof that
says that in some circumstances, I am wrong.

What are those circumstances?  I can't speak in general, but obviously
one issue is cost.  If you are willing to spend enough money (in the
case above, on lift costs), the software problem is tractable.  My
intellectual question is "Where do I draw the line?" 


Re: Criminal encryption

Garry Wiegand <garry@tcgould.tn.cornell.edu>
Fri, 12 Dec 86 23:43:18 EST
I noticed in the paper recently that the former mayor of Syracuse (Lee
Alexander??) was fighting a federal court order. The court, on prosecution 
request, had ordered him to instruct a foreign bank to tell the prosecution 
all about his bank transactions. The paper said that the ability of the feds 
to require this was a matter of "settled law"; Mr. Alexander was merely 
fighting for the privilege of adding the words "under protest" before signing. 

Seems like the same rules might apply to other forms of records, such as 
computer disks. The penalty would be contempt-of-court.

garry wiegand   (garry%cadif-oak@cu-arpa.cs.cornell.edu)
Cornell Engineering & Flying Moose Graphics


Computerised Discrimination

"Scott E. Preece" <preece%mycroft@GSWD-VMS.ARPA>
Fri, 12 Dec 86 09:38:09 CST
Brian Randell writes:
>   The St. George's claim is particularly worrying because the school has a 
> better record on discrimination than most other colleges.
>   The computer selection programme was designed to mimic the decisions of
> the school's panel which screened applicants to see who merited an interview.
>   It matched the panel's results so closely that the panel was scrapped and 
> for several years all St. George's applicants have been screened by computer.

One is tempted to say that the two statements, (1) they were better than
average on discrimination and (2) they were following a process that was well
modelled by a discriminatory program, are contradictory.  Of course, they
aren't.  Assuming the program was just based on assigning weights to a lot of
factors typically used in admissions decisions, it's not hard to imagine that 
they hit on a set of weights which happened to work well on the training set 
but were not really reflective of the pre-existing judgment process.

This is dangerous, though, in that it may appear to courts and other bodies
that the inference can be drawn; that the existence of a biased model which
would explain a behavior is proof that the behavior was biased.  This would
make the concept of de facto discrimination much more broadly applicable
(though it is, in fact, the general basis of that concept).

It does remind one that testing the results of an "expert" system should be
coupled with review of its rules.

scott preece, gould/csd - urbana          uucp: ihnp4!uiucdcs!ccvaxa!preece


More on Incompatible Plug-Compatible Monitors

<forags%violet.Berkeley.EDU@berkeley.edu>
Sun, 14 Dec 86 15:21:47 PST
It's quite easy to damage an IBM Monochrome monitor by plugging it into an
adapter (like an Enhanced Graphics Adapter) which is configured for a color
monitor.  Both types of monitors use the same D-connector.

Admittedly, there is a warning in the manual about this, but, after setting
up about fifteen other PC's, I had pretty much given up reading the manual
in detail .....

Al Stangenberger, Forestry, Univ. of Calif., Berkeley

Please report problems with the web pages to the maintainer

Top