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 10 Issue 48

Tuesday 9 October 1990

Contents

o Global warming or bad hardware?
Bob Campbell
o Equinox on A320
Pete Mellor
o Ada and multitasking
Erling Kristiansen
o Re: Arbitration Myths
Bernie Cosell
o California DMV and Italian publicity
Jon
o Government routinely ignores Privacy Act
Clifford Johnson
o Computer sound editors are appropriate technology, not deceipt
David A. Honig
o Operation Sun Devil invades the InterNet?
Jonathan I. Kamens
o Loving Little Egypt - phone freaks
Dick Karpinski
o CERT Advisory Update - NeXT Systems
Ed DeHart
o Info on RISKS (comp.risks)

Global warming or bad hardware?

Bob Campbell <campbelr@grendel.cup.hp.com>
Tue, 9 Oct 90 15:12:54 mdt
Deep inside the October 9th, 1990 San Jose Mercury News was this piece
under the heading of "Unbelievably hot".

All sorts of explanations have been offered for record high temperatures across
the country - the greenhouse effect, the growth of cities, even chance.  But
the National Weather Service is examining and additional theory: The
thermometers were wrong.  The service is studying the thermometer at issue, an
electronic sensor called the Ho83.

Bob Campbell                campbelr@hpda.cup.hp.com


Equinox on A320 (UK Channel 4, Sun., 30th Sep)

Pete Mellor <pm@cs.city.ac.uk>
Sat, 6 Oct 90 21:22:55 PDT
The 'Equinox' series of documentary programmes on science and technology on
Channel 4 of UK TV was devoted to the Airbus A320 last Sunday (30th Sep., 7 pm).
The one-hour film was made by Box Productions, main researcher Ben Hamilton.

A good summary of the programme has already appeared in RISKS-10.47, submitted
by someone identified only as 'Paul'. He observed that:

> BTW, one of the interviewees had a box file labeled "RISKS" in the
> background.  Perhaps he could fill in the holes in my report.

That interviewee would have been Prof. Bev Littlewood, Director, Centre for
Software Reliability, City University. We monitor RISKS at the Centre,
and that box file does, in fact, contain printouts of the digests, so I can
fill in the holes (although Paul hasn't left many for me to fill in!).

The programme updated an earlier programme on 6th Nov. 1989 and included
much new material, in particular an independent analysis of transcripts of the
data on the Digital Flight Data Recorder (DFDR) and Cockpit Voice Recorder
(CVR) recovered after the crash at Mulhouse-Habsheim on 26th June 1988.
This was done by Ray Davis, ex-Accident Investigation Bureau, UK Department of
Trade and Industry, and now an independent consultant. He produced a written
report which was submitted to Airbus Industrie (AI) for comment.

Davis concluded that:
- The flight control systems were not obeying the pilot's commands to lift the
  aircraft just prior to impact. (This supports the contention of the pilot,
  Michel Asseline, that he had requested 'nose up' and hadn't got it.)
- The DFDR recording stops 4 seconds *prior* to impact with the trees. (Davis
  added that, in his entire career, he had *never* come across a similar
  instantaneous stoppage of a recorder.)
- There is no indication of longitudinal deceleration, such as would have
  occurred due to impact with the trees, at the end of the recording.
- During the last part of the recordings, the DFDR and CVR are 4 seconds out of
  sync. (This is interesting in the light of the claim by AI that Asseline had
  not allowed sufficient time (7 sec.) for the engines to spool up to full
  power.)

Bernard Ziegler (Vice President, Engineering, Airbus Industrie) predictably
dismissed Davis' report, describing it as 'pitiful'. He claimed that Davis
had misunderstood the sign convention for acceleration/deceleration. In fact,
according to the ARINC international conventions, Davis was right, and Ziegler
was wrong. The point was put to Ziegler five times by the Equinox team, and
each time he repeated this assertion. He then ended up with egg on his face
when his own organisation, AI, were obliged to retract, explaining that
Ziegler had misunderstood, and had been using a French convention instead of
the international one.

On one point, Ziegler appeared to accept Davis' findings, when he claimed
that the safety systems were working to prevent a stall (i.e., overriding
the pilot's request for 'nose up'). Asseline claims that the aircraft had
sufficient speed and power to clear the trees without stall.

Air France, and the Bureau Enquetes Accidents who produced the original
accident report, refused to be interviewed. The copilot at Mulhouse, Jaques
Mazieres, is still flying for Air France, and so also not available.

Davis stated that there must now be another enquiry, and that this must take
account of the improper pressure being applied in certain quarters. (Asseline
has received threats; Norbert Jaquet, an Air France pilot who spoke out in
Asseline's support, was suspended from duty and had his licence withdrawn on
the grounds of 'mental instability'.)

Even the authenticity of the recorders was called into question. The boxes
were filmed last year by Equinox in the boot of the car of the director of
the DGAC at the scene of the crash, and a French journalist also saw them.
According to Asseline, those produced at the enquiry do not resemble these.
The original investigating magistrate at Mulhouse, Germain Sengelin, said
that there was a 'problem in relation to justice'. (The present magistrate
has obtained an independent report on the evidence used by the commission
of enquiry, which also concludes that there is serious doubt over the
authenticity of the recorders and the readouts made from them.)

The programme went on to consider the crash of the A320 at Bangalore. A pilot
was interviewed saying that it was virtually unknown for an aircraft to lose
height in such a way in clear conditions on a landing approach. Air India has
now grounded all its A320s at enormous cost. Prince Dandonda (sorry - no note
of his job title) was interviewed saying that they have never seen this amount
of failures in an aircraft. One example was of a bird strike on the windscreen
resulting in a shut-down of three display computers, and causing the system to
shut down one engine.

There was an interesting example of Ziegler's logic concerning the Bangalore
crash: we know it wasn't bad weather, we know it wasn't bird strike, it
*can't* have been the aircraft systems, *therefore* it *must* have been
pilot error.

Davis' view is that a crash should be ascribed to 'pilot error' *only*
where there is positive proof. 'If you don't fully establish the cause of an
accident, then that accident will happen again.'

The programme concluded that, in the meantime, 'Air France and Airbus Industrie
must live with the fact that there is a question mark over the safety of the
A320.'

Peter Mellor, Centre for Software Reliability, City University, Northampton
Sq., London EC1V 0HB +44(0)71-253-4399 Ext. 4162/3/1 p.mellor@uk.ac.city (JANET)

    [My humblest apologies to Paul.  The From: field was deleted instead
    of the To: field and paul accidentally remained anonymous.  PGN]


Ada and multitasking

<KRISTIA@ESTEC.BITNET>
Mon, 08 Oct 90 10:28:12 CET
Re: "Ada's fundamental language structures build reliable systems", article by
    Benjamin M.Brosgol in EDN, September 3, 1990, international edition.

 The article starts:
 >  Ada's principal goals are program reliability, readability, efficiency, and
 >  portability. Many real-time application programs, such as those used in
 >  avionics, telecommunications, and manufacturing, need these features
 >  because of the large, complex, and long-lived pieces of software involved.

 The author then describes several features of the Ada language, such as data
 typing, separate compilation units, and concurrent tasks.
 The RISKy bit comes in the discussion of task priorities. It becomes clear that
 the Ada language falls short of completely and unambiguously defining how the
 task scheduler must deal with the priority issue, and that some freedom is left
 to the implementor in this area.

 The following quotes from the article give a flavour of the problem:

 >  In addition, when a select statement has several open alternatives,
 >  implementations need not take priorities into account when deciding which
 >  one to accept. Instead, for example, they can take fairness criteria into
 >  account.

 and

 >  Ada language implementations can solve the problem of nondeterminism when
 >  there are several open alternatives by providing directly or letting you
 >  dictate the use of task priorities.

 The author does not seem to realize the contradiction between the
 *reliability* and *portability* quoted as features of Ada on one hand, and
 the lack of definition of crucial features on the other.

 Stated briefly, the RISK that I want to address is:
 A language which boasts high portability and reliability includes features
 which mean that there is no guarantee that a program will work the same way if
 ported to another compiler and/or run-time environment.

 Even worse:
 The potential differences are are hidden deeply below the "visible surface"
 of the program, and are implicit in nature. This means that the program will
 probably compile and link after being ported. It is also likely to show a very
 similar behaviour to the original so that a superficial testing may not reveal
 any problems. But problems may still be lurking in the dark corners of
 infrequent (but perfectly possible and legal) sequences of events. For example,
 superficial validation testing is likely to test mainly rather "quiet" modes
 with stimuli applied one at a time. But scheduler-related problems are more
 likely to show up when the software is very "busy", e.g. due to an abnormal
 or emergency situation creating many stimuli, such as alarms.

 A further RISK is that a language which is claimed to be designed for
 portability may encourage reduction in (costly and time-consuming) in-depth
 validation testing after porting the software to a different environment.

 In fact, the real RISK is maybe not that Ada has these shortcomings. The
 RISK, to my opinion, is that Ada, in spite of its shortcomings, claims to be
 highly portable and reliable.

 Does anybody have any experience (good or bad) in porting Ada programs, in
 particular real-time programs?

 Erling Kristiansen, European Space Research and Technology Centre,
 Noordwijk, The Netherlands.
 Usual disclaimers apply.


Re: Arbitration Myths (Peter Denning, RISKS-10.42)

<cosell@BBN.COM>
Fri, 5 Oct 90 12:27:25 EDT
}As Peter observes, the only way to build a computer that is safe from
}"arbitration failure" is by making choice 1, which means that the computer must
}turn off its clock while waiting for an arbiter to decide.  Note that the
}computer can't keep its clock ticking while waiting for the arbiter to make up
}its mind, since it would then require another arbiter to decide within the
}current clock cycle whether or not the first arbiter had made up its mind.  I
}know of no computer that turns off its clock in this way.

The DEC PDP-6 line worked this way.  It was a fully asynchronous CPU
and would happily wait for as long as it took for an operation to
complete.  At MIT they had one word of memory implemented out of
elevator relays [2 second read time or the like].  The 'flow chart' for
how long a simple 'add' instruction took took up two pages in the
manual [including delays for waiting for the memory, delays for carry
propagation, etc].
                                                      /Bernie\


California DMV and Italian publicity

A Product of Society <jon@pacbell.UUCP>
Sat, 06 Oct 90 15:39:06 PDT
I have nothing against Italians, only against ignorant Public Relations people.

    A month ago my mom got a letter in the mail, from the California DMV.  On
behalf of the Italian community, it said, (who had recently launched a PR stunt
against anti-italian bumber stickers and etc) she would have to change her
license plate.  Her plate read "WOPER1", comming from a feminist's word "WOman
PERson".  The '1' was there because the "lisence plate bible" reported that
someone already had WOPER.
    The Italian PR guy had the DMV search their computers for any string
containing WOP.  There's a risk here, no doubt: My mom's plate had *nothing* to
do with Italians, and there are plenty of words that grep might pick up, all
containing WOP.
    My mom wrote an extremely formal letter (she's an attorney, after all, and
that's good for *something* :) to the DMV, and they apologized over the phone.
They would change the plate, however, to "WO PER", with half a space, to
distinguish this word from any anti-Italian slang.  They also reported that
the first person having "WOPER" no longer had the plate, and "WOPER" was
available for use.
    The plate arrived last week.  It read "WOPER".  Nice job on behalf of the
DMV.  The bill for the plate read $1,200.  There's a connection here...
    The *actual* bill was $108.xx, because of the recent computer foul up,
posted in the last issue.

    Should agencies like the DMV be allowed to just 'grep' a database on behalf
of a PR stunt for *any* phrase containing "WOP"?  Something is wrong here.
Next thing you know, colleges will be scanning their applications for last
names ending in "ez" to fill some quota of Mexican students.  Mexicans aren't
the *only* people whose last names might end in --ez, just as WOP-- isn't
*always* a derogatory slang against Italians!

    Computers are becomming more useful to the tools of prejudice.

Jon   ..?$!..ames!pacbell!sactoh0!vector0!jon     vector0!jon@sactoh0.SAC.CA.US


Government routinely ignores Privacy Act

"Clifford Johnson" <A.CJJ@Forsythe.Stanford.EDU>
Tue, 9 Oct 90 15:01:14 PDT
Excerpted from Gov't Computer News, 10/1/90:

    Agencies violated the Privacy Act 292 times last year by
    failing to notify the public about a third of their largest
    personal record systems . . . The report by GAO's Information
    Management and Technology Division, Computers and Privacy
    said many agencies ignored the Privacy Act's publication
    requirements and did not issue Federal Register notices for
    35 percent of their personal records systems . . .

    The Defense Department reproted the most systems covered by
    the law with 360, followed by the the departments of Health
    and Human Services with 210, Justice with 169,, and
    Agriculture with 87.  However, agencies published notices for
    only 535 systems . . .

    46 agencies told they participated in computer matches . . .
    The report said 4.32 million matches, 78% of the total, were
    done for law enforcement purposes.  Another 16,245 were for
    tax purposes, and 10,028 involved queries on delinquent
    payments.  The Drug Enforcement Administration and Farmers
    Home Administration accounted for 97% of all matches.

I observe that many federal criminal databases are not even covered by the
Privacy Act's provisions, and that computer matching of government databases
was supposedly prohibited by the Privacy Act.  [CJ]


computer sound editors are appropriate technology, not deceipt

"David A. Honig" <honig@ICS.UCI.EDU>
Mon, 08 Oct 90 16:43:44 -0700
In RISKS-10.47, Ed Hall <edhall@rand.org> writes:
> There is a computer RISK here.  According to today's Los Angeles Times:

    ...  Sound Analyst Evans [a lecturer at Univ. of Nevada with
    masters degrees in physics and computer science] said she had
    spent about a month analyzing audio subliminal messages
    allegedly implanted on the "Blizzard of Oz" cassette using the
    same home-computer software package employed in the Judas Priest
    case. ...

>I can only guess at what this "home-computer software package" is. (If
>anyone has additional information about it, please let me know).

There are several programs that allow one to aquire, process, and
play-back sound on various PCs.  The analyst in this case would be
most interested in playing sound back time-reversed, perhaps with some
equalization afterwards.  She would try different transforms
exhaustively to see if she could hear any nasties.

This of course is identical to what one can do with a magnetic tape player,
or a phonograph if one is willing to trash the disk and needle.

I would expect that the expert witness would have to explain her
methods and tools to the court.  I see nothing even implicitly
deceitful in using a Macintosh to play sound backwards...

He continues:

>thing I'm sure of, however: it hardly affords an accurate model of human
>auditory perception (unless its author has managed to leapfrog what
>would no doubt be decades of neurophysiological research).

Huh?  The analyst is just playing the sound back, not doing
*pattern-matching* for curses in latin backwards...

>Its use in court no doubt arises from the persisting association of
>The Computer with unchallengeable accuracy and authority.

Its use in court is a result of the expert sound analyst using up to
date tools.  If there were sounds encoded in the music, digital signal
processing techniques are better tools to use than analog ones.

The whole business is the pathetic process of ill families trying to
put the blame for their kids' suicides on the Evils of Rock and Roll (tm)...

&isclaimer: I don't listen to the stuff...>


Operation Sun Devil invades the InterNet?

"Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
Mon, 8 Oct 90 05:50:04 -0400
  The message by Ed Luke (who is, incidentally, the SysOp of the MARS
BBS discussed in it) is, indeed, a hoax.

  For more information about it, see the article entitled "MARS BBS
Sting a Prank" in Issue #2.06 of the Computer Underground Digest
(available in alt.society.cu-digest for those of you who read news and
whose feed includes that newsgroup).  The article does a good job
discussing the risks made clear by this "joke".

  The article claims that the prank was "not malicious" and "not
intended to be deceptive".  Unfortunately, in the real world, there is
often a gap between what is intended and what actually occurs.  Many
people *were* deceived by his story, and I'm sure that it caused some
people quite a bit of worry about the possibility that Operation
Sun-Devil might be coming after them next.

  I do not think Mr. Luke used very good judgment at all when he wrote
his "prank".

    Jonathan Kamens,    MIT Project Athena


Loving Little Egypt - phone freaks

Dick Karpinski <dick@ccnext.ucsf.edu>
Fri, 5 Oct 90 15:34:11 PDT
In Loving Little Egypt (ISBN 0 14 00.9331 1), the protagonist is a weak sighted
boy who discovers vulnerabilities in the in-band signalling of the early dial
telephone network.  This delightful tale includes episodes of interaction with
Bell, Edison, Tesla and others in a quest to improve the security of the phone
system.  Comparisons with Morris come readily to mind.  The interactions among
the blind phone freaks also invite comparison with the Whole Earth Review
article on the facts and people involved by the Secret Service in Operation Sun
Devil.  This book uses science and technology as major plot elements, which
seems to be a major problem for folks like the operatives in Sun Devil.  The
risks involved here range from technical vulnerabilities to serious loss of
freedoms due to heavy handed tactics by uncomprehending agents of law
enforcement organizations.
                                                  Dick


CERT Advisory Update - NeXT Systems (See RISKS-10.47.)

<cert-advisory-request@cert.sei.cmu.edu>
Fri, 5 Oct 90 11:52:48 -0400
This message is an update of the October 2, 1990 CERT Advisory (CA-90:06)
"NeXT's System Software".  There is one correction and an update that you
should be aware of.

For Problem #2 SOLUTION, the following line has been added:

  # /etc/chmod 440 /usr/lib/NextPrinter/npd.old

This will disable the old printer program.

NeXT is also making the new printer program, npd, available electronically
via anonymous ftp for Internet sites.  The archives sites are:

        nova.cc.purdue.edu
        umd5.umd.edu
        cs.orst.edu

In addition, NeXT has asked the CERT to announce that if anyone cannot get
it from the archives, NeXT Technical Support can provide it. Requests should
go to:

        ask_next@NeXT.COM [...!next!ask_next]

Ed DeHart, Computer Emergency Response Team

Please report problems with the web pages to the maintainer

Top