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 45
Monday, 2 February 1987
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
- Info on RISKS (comp.risks)
DATE-86, or The Ghost of Tinkles Past
Rob Austein <SRA@XX.LCS.MIT.EDU>
Fri, 30 Jan 1987 00:48 EST
Extracted from the Arpanet-BBoards archives. --sra [NOTE DATES...] Date: Wednesday, 11 December 1985 09:55-EST From: Dan Hoey <hoey@nrl-aic.ARPA> 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
Computerised Discrimination (an update)
Brian Randell <brian%kelpie.newcastle.ac.uk@Cs.Ucl.AC.UK>
Fri, 30 Jan 87 09:57:00 gmt
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 : <UK>!ukc!cheviot!brian
JANET : brian@uk.ac.newcastle.cheviot
Another non-malfunctioning alarm
Jeffrey Thomas <Ad.JDThomas@CU20B.COLUMBIA.EDU>
Mon 26 Jan 87 17:56:45-EST
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.
Re: Engineering models applied to systems, RISKS-4.42
Joseph S. D. Yao <hadron!jsdy@seismo.CSS.GOV>
31 Jan 87 02:42:57 GMT
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)
Re: A scary tale--Sperry avionics module testing bites the dust?
D. W. James <vnend@ukecc.uky.csnet>
28 Jan 87 00:47:42 GMT
>From: Nancy Leveson <nancy@ICSD.UCI.EDU>
> 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
Report problems with the web pages to the maintainer