Subject: RISKS DIGEST 10.48 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 9 October 1990 Volume 10 : Issue 48 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Global warming or bad hardware? (Bob Campbell) Equinox on A320 (Pete Mellor) Ada and multitasking (Erling Kristiansen) Re: Arbitration Myths (Bernie Cosell) California DMV and Italian publicity (Jon) Government routinely ignores Privacy Act (Clifford Johnson) Computer sound editors are appropriate technology, not deceipt (David A. Honig) Operation Sun Devil invades the InterNet? (Jonathan I. Kamens) Loving Little Egypt - phone freaks (Dick Karpinski) CERT Advisory Update - NeXT Systems (Ed DeHart) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. TO FTP VOL i ISSUE j: ftp CRVAX.sri.comlogin anonymousAnyNonNullPW cd sys$user2:[risks]GET RISKS-i.j ; j is TWO digits. Vol summaries in risks-i.00 (j=0); "dir risks-*.*" gives directory; bye logs out. ALL CONTRIBUTIONS ARE CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. The most relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Tue, 9 Oct 90 15:12:54 mdt From: Bob Campbell Subject: Global warming or bad hardware? 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 ------------------------------ Date: Sat, 6 Oct 90 21:22:55 PDT From: Pete Mellor Subject: Equinox on A320 (UK Channel 4, Sun., 30th Sep) 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] ------------------------------ Date: Mon, 08 Oct 90 10:28:12 CET From: EKRISTIA@ESTEC.BITNET Subject: Ada and multitasking 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. ------------------------------ Date: Fri, 5 Oct 90 12:27:25 EDT From: cosell@BBN.COM Subject: Re: Arbitration Myths (Peter Denning, RISKS-10.42) }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\ ------------------------------ Date: Sat, 06 Oct 90 15:39:06 PDT From: jon@pacbell.UUCP (A Product of Society) Subject: California DMV and Italian publicity 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 ------------------------------ Date: Tue, 9 Oct 90 15:01:14 PDT From: "Clifford Johnson" Subject: Government routinely ignores Privacy Act 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] ------------------------------ Date: Mon, 08 Oct 90 16:43:44 -0700 From: "David A. Honig" Subject: computer sound editors are appropriate technology, not deceipt In RISKS-10.47, Ed Hall 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)... ------------------------------ Date: Mon, 8 Oct 90 05:50:04 -0400 From: "Jonathan I. Kamens" Subject: Operation Sun Devil invades the InterNet? 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 ------------------------------ Date: Fri, 5 Oct 90 15:34:11 PDT From: dick@ccnext.ucsf.edu (Dick Karpinski) Subject: Loving Little Egypt - phone freaks 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 ------------------------------ Date: Fri, 5 Oct 90 11:52:48 -0400 From: cert-advisory-request@cert.sei.cmu.edu Subject: CERT Advisory Update - NeXT Systems (See RISKS-10.47.) 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 ------------------------------ End of RISKS-FORUM Digest 10.48 ************************