2-Feb-87 20:02:17-PST,8915;000000000000 Mail-From: NEUMANN created at 2-Feb-87 20:00:29 Date: Mon 2 Feb 87 20:00:29-PST From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 4.45 Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest Monday, 2 February 1987 Volume 4 : Issue 45 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: DATE-86, or The Ghost of Tinkles Past (Rob Austein) Computerised Discrimination (an update) (Brian Randell) Another non-malfunctioning alarm (Jeffrey Thomas) Re: Engineering models applied to systems, RISKS-4.42 (Joseph S. D. Yao) Re: A scary tale--Sperry avionics module testing bites the dust? (D.W. James) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM) (Back issues Vol i Issue j available in CSL.SRI.COM:RISKS-i.j. MAXj: Summary Contents Vol 1: RISKS-1.46; Vol 2: RISKS-2.57; Vol 3: RISKS-3.92.) ---------------------------------------------------------------------- Date: Fri, 30 Jan 1987 00:48 EST From: Rob Austein To: Risks@CSL.SRI.COM Subject: DATE-86, or The Ghost of Tinkles Past Extracted from the Arpanet-BBoards archives. --sra [NOTE DATES...] Date: Wednesday, 11 December 1985 09:55-EST From: Dan Hoey To: ARPANET-BBOARDS@MIT-MC.ARPA Re: Software alert: DATE-86 ReSent-date: 14 Dec 1985 03:05:52 EST ReSent-from: Arpanet-BBoards-Request@MIT-MC.ARPA Early this year a message appeared on ARPANET-BBOARDS commemorating the ten-year anniversary of DATE-75. A somewhat more ominous anniversary will occur in four weeks, on 9 January 1986. Users of the TOPS-10 operating system should beware of software failures beginning on that date. DATE-75 is the name of a set of program modifications applied to the TOPS-10 operating system, running on DEC PDP-10 computers. Before the modifications, the TOPS-10 system could only represent dates between 1 January 1964 and 4 January 1975. The DATE-75 modifications added three more bits to the representation of dates, so that dates up to 1 February 2052 could be represented. To maximize compatibility with existing software, the three extra bits were taken from several unused positions in existing data structures. The change was announced in mid-1974, and several tens of person-years went into updating software to recognize the new dates. Unfortunately, reassembling these bits into an integer representing the date was somewhat tricky. Also, some programs had already used the spare bits for other purposes. There were a large number of bugs that surfaced on 5 January 1975, the first day whose representation required the DATE-75 modification. Many programs ignored or cleared the new bits, and thought that the date was 1 January 1964. Other programs interpreted the new bits incorrectly, and reported dates in 1986 or later. Date-related program bugs were frequent well into the Spring of 1975. On 9 January 1986, the second bit of the DATE-75 extension will come into use. Users of software developed in the 60's and early 70's on the TOPS-10 operating system should beware of problems with testing and manipulation of dates. Beware especially of programs that were patched after manifesting bugs in 1975, for in the rush to fix the bugs it is possible that some programs were modified to assume that the date was between 1975 and 1986. Any date that is off by a multiple of eleven years and four days is probably caused by this type of bug. Dan Hoey ------------------------------ From: Brian Randell Date: Fri, 30 Jan 87 09:57:00 gmt To: RISKS@csl.sri.com Subject: Computerised Discrimination (an update) Since my original posting on this I've received enquiries as to whether there has been any follow up in the UK press. I hadn't seen any until today's Guardian, which carried the following (excerpted) article: MEDICAL SCHOOL FACES RACE INVESTIGATION By Andrew Veitch, Medical Correspondent The Commission on Racial Equality is to launch an investigation into discrimination against blacks at one of Britain's leading medical schools, it was disclosed yesterday. Sir Peter Newsam, the CRE Chairman, is invoking its rarely used legal powers under the Race Relations Act to investigate the way in which St George's in south London selects its students. This means that CRE officers have satisfied the commission that there is prima facie evidence that the Act has been breached. [...] The inquiry follows the Guardian's disclosure last month that the school was using a computer programme which deliberately downgraded non-white applicants. Two of its consultants, Dr. Aggrey Burke and Dr Jo Collier, ran applications through the computer and found that being a non-Caucasian female lowered the applicant's ranking by up to 20 points - probably enough to reject a candidate who would have been accepted on academic performance alone. The programme was designed to mimic the decisions of the selection committee, which it replaced. The academic board scrapped the programme after being given details of the consultants' investigation. ... Brian Randell - Computing Laboratory, University of Newcastle upon Tyne UUCP : !ukc!cheviot!brian JANET : brian@uk.ac.newcastle.cheviot ------------------------------ Date: Mon 26 Jan 87 17:56:45-EST From: Jeffrey Thomas Subject: Another non-malfunctioning alarm To: neumann@CSL.SRI.COM ReSent-To: RISKS@CSL.SRI.COM Garnered from a report just now heard on NPR's All Things Considered: BBC reporter speaking of the investigation of the crash of the airliner carrying Mozambique President Samora Machel: Based on official transcripts of the cockpit conversation before the crash, when a ground proximity alarm sounded, the (soviet) pilot ignored the alarm, believing it to be malfunctioning. The investigation also noted evidence that some of the instruments appeared to have been tampered with after the crash, fueling speculation by the soviets that the plane had been lured to the site by a false navigational beacon. ------------------------------ From: hadron!jsdy@seismo.CSS.GOV (Joseph S. D. Yao) Date: 31 Jan 87 02:42:57 GMT To: seismo!mod-risks@seismo.CSS.GOV Subject: Re: Engineering models applied to systems, RISKS-4.42 Summary: Loose coupling applies to software. I think that the concept of loosely-coupled systems can be very well applied to software engineering, although perhaps not in the way Wexelblat quotes Meldman as saying. There, the model seems to be that computer systems as a whole don't communicate well, and therefore prevent massive "data rot," as it were. That's as may be, and I may be reading it wrong anyway. But I see this as a very good model for the kinds of things we do in modularisation of software, information hiding, defensive programming, and the like. We try to make sure that errors in one part of a system don't propagate to other parts, by building bridgeheads against them (testing for bad data), not tightly coupling data values (controlling import and export), et alii. Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised) ------------------------------ Return-Path: Date: 28 Jan 87 00:47:42 GMT From: The News System To: ukecc!ukma!cbosgd!mod-risks@seismo.CSS.GOV From: vnend@ukecc.uky.csnet (D. W. James) Subject: Re: A scary tale--Sperry avionics module testing bites the dust? >From: Nancy Leveson > According to my FAA source, the FAA is not >thoroughly comfortable with this, but the autopilot is only flight-crucial >on this aircraft during about 45 seconds of the landing. Also, their tests >have found that pilots can successfully recover from an autopilot failure >during this period (by performing a go-around) about 80% of the time. While not a direct computer risk, is anyone else troubled that the FAA considers a 1 in 5 chance that the pilot WON'T recover acceptable? Or is it just that they believe a failure during these crutial 45 seconds to be of acceptably low probability? UUCP:cbosgd!ukma!ukecc!vnend; or vnend@engr.uky.csnet; orcn0001dj@ukcc.BITNET ------------------------------ End of RISKS-FORUM Digest ************************ -------