University of Bielefeld -  Faculty of technology
Networks and distributed Systems
Research group of Prof. Peter B. Ladkin, Ph.D.
Back to Abstracts of References and Incidents Back to Root
This page was copied from:

Previous Issue Index Next Issue Info Searching Submit Article

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 15, Issue 30

Weds 1 December 1993


o Risks of automated betting
Russ Corfman
o Computer Changeover May Cost $16M
Lin Zucconi
o Mercury passwords can be compromised
Keith Lockstone
o Computerized Pornography
Brian Randell
o Picking from Trash (Re: Charge cards from mail-order houses)
Li Gong
o GRE goes "adaptive"
Cris Pedregal Martin
o More news on the Lufthansa A320 accident in Warsaw
Peter B Ladkin
o Memory error corrupts file
James Michael Chacon
o New Moderator for the Computer Privacy Digest
Dennis G. Rears
o Re: Safety-critical software
Pete Mellor
o Re: Ada Usage
Tucker Taft
Mathew Lodge

Risks of automated betting

Russ Corfman < corfmanr%gtephx@[] >
Sun, 28 Nov 93 16:58:38 MST
     The following article about problems with automated gambling at a dog track
     was taken from the sports page of the 28 Nov 1993 Arizona Republic:
          Computer Glitch costs bettor shot at $17,000
     The bettor had the right numbers and plenty of time at the window but lost a
     chance at $17,000 when the computer wouldn't take his wager at the Palm Beach
     (Fla.) Kennel Club.  "I've been betting for 35 years with horses and dogs, and
     this is the toughest part to take," said the man, who did not want his name
     used.  He and his wife tried to enter six combinations, including the winning
     one, four minutes before post time Friday.  But the computer refused to take
     the numbers fed by the clerk and her supervisor. They called the track trying
     to get the race delayed, but no one answered.  
     "Unfortunately, there are mistakes that are made," track spokeswoman Theresa
     Hume said. "We can't pay him anything unless he has the winning tickets."  The
     man shrugged off his bad luck, saying, "I'm a gambler.  I'm a bettor. That's
     what I do."
     Russell Corfman, AG Communication Systems; Phoenix, AZ
     UUCP: ...!{ncar!noao!enuucp | att}!gtephx!corfmanr    (602) 581-4403

Computer Changeover May Cost $16M

"Lin Zucconi" < >
29 Nov 1993 15:45:15 U
     Article in Saturday (Nov. 27, 1993) issues of the Valley Times says that "bugs
     in a new computerized hospital billing system could cost Los Angeles County up
     to $16 million." The county signed a $65M deal in 1990 for the computer system
     to keep track of billing and clinical treatment at county facilities. System
     was to be installed Jan. 1994 but that date is now Sept. 1994. The nine-month
     delay will cost the county $4M to extend its countract with the company
     currently handling hospital billing. The system could also have up to $2M "in
     extra programming and miscellaneous costs." "We thought the system was hard to
     work, it wasn't user friendly," said Asst. Auditor-General Mike Galindo.

Mercury passwords can be compromised

Keith Lockstone < >
Wed, 24 Nov 93 13:38 GMT0
     In the UK, one of the ways of accessing the Mercury phone system is to dial
     131 on the British Telecom system, dial the 10 digit Mercury password and then
     dial the required phone number.
     When making private calls from my workplace, I thought it best to use my
     Mercury account and pick up the cost myself.
     Originally, the company exchange used pulse dialing.  So, in order to make a
     call, I would dial 131 and then use a tome beeper to dial in the password and
     phone number.  Thus the exchange only logged 131 as the call destination.
     However, when a new company exchange was installed, the whole system went to
     dual standard, i.e., pulse and tone dialing.  Some weeks later, I realised the
     implications and asked to see the exchange log.  There, of course, was my
     Mercury password included in the call destination field.  I hastily had my
     Mercury password changed and have never used it this way since!
     British Telecom regularly uses call loggers for traffic analysis purposes.  As
     they do not record conversation, they do not need a warrant from the Home
     Secretary.  The were used without a warrant in the 'Prince Philip Mailbox
     Hack' case (Regina v. Gold and Schifreen) to establish patterns of
     interconnections between individuals and on-line computer systems.  Their
     misuse by unscrupulous BT employees could lead to a black market in Mercury
     Keith Lockstone

Computerized Pornography

< >
Fri, 26 Nov 1993 12:07:54 GMT
     The attached article is reprinted in its entirety from today's (26 Nov 1993)
     edition of The Independent.
     The issue of pornography and portrayals of violence in computer game
     cartridges and disks is very high profile here at the moment - particularly
     this week with the ending of a much-publicised and very harrowing trial which
     resulted in two 11-year old boys being convicted of the brutal murder of a
     two-year old child, who they had enticed away from his mother in a shopping
     mall. In delivering the "guilty" verdict (on the youngest defendants ever to
     be found guilty of murder in the UK) the judge said that exposure to such
     material might have influenced them - the police however have disagreed.  (A
     day or so before the trial verdict there was a lengthy documentary on TV - I
     didn't note the details - whose main point was that parents who in general
     exercise some judgement and control over the films and videos that their
     children watch are almost invariably unaware of, and would be horrified by,
     some of the material their children are exposed to via computer game
     cartridges and disks.)
     The present government statement is not being portrayed as a response to the
     judge's comments, and indeed is more concerned with pornography than violence.
     However the atmosphere in which it has been received is for the moment at any
     rate very much influenced by this particular trial verdict.  Brian Randell
         - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        Howard to Tackle Computerised Porn, by TERRY KIRBY, Crime Correspondent
     ACTION to tackle pornographers who plan to create and trade in
     computer-simulated paedophile material was announced yesterday by Michael
     Howard, the Home Secretary.
     The move is designed to plug a loophole in the law, which currently only
     covers indecent photographs, film and video recordings of children under the
     age of 16. It will be included in the forthcoming Criminal Justice Bill, which
     already contains measures to toughen existing legislation covering child
     There has been mounting concern among senior police officers and the Home
     Office following the discovery that pornographic images of women had been
     scanned onto computer discs, modified to appear more childlike and then had
     images of children's heads superimposed to create pornography of high
     photographic quality.
     Although the equipment required costs several thousand pounds, officials
     are concerned that "cottage industries" could be set up to produce computer
     images of child pornography for the black market.
     Ministers emphasised yesterday that, although only isolated examples of the
     trend had been identified and a case had not been brought to court, it was
     necessary to act swiftly because it was possible that such
     computer-simulated pornography could be outside existing laws, and delay
     could allow the pornographers to thrive.
     Mr Howard said: "New technology continually presents new challenges to the
     law. I am determined the law should keep pace with them and I will not
     hesitate to act whenever those who degrade children find new means of
     peddling this material."
     The proposals give police powers to arrest, without warrant, traffickers in
     child pornography and other obscene material, increase police powers of
     search and seizure, and improve the powers of trading standards officers.
     Courts will be given powers to impose sentences of up to three months
     and/or a (pounds) 5,000 fine for possessing paedophile material; traders
     can face a maximum of three years.
     Dept. of Computing Science, University of Newcastle, Newcastle upon Tyne,
     NE1 7RU, UK   PHONE = +44 91 222 7923

Picking from Trash (Re: Charge cards ..., Wobber, RISKS-15.29)

Li Gong < >
Wed, 24 Nov 93 11:04:52 -0800
     I've noticed that the phone companies in several states and at least one long
     distance carrier use (or used) the same algorithm to assign a PIN to a calling
     card, based solely on information about the person.  Thus if you throw your
     old card into the trash in Massachusetts and move to California, one who picks
     the trash can reliably charge all his/her calls to your new California
     account.  [I guess one can ask for a different PIN from the phone company.]
     Li Gong, SRI International, Computer Science Lab, Menlo Park, California

GRE goes "adaptive"

Cris Pedregal Martin < >
Mon, 15 Nov 1993 21:26:39 -0500 (EST)
     Canada-US-academia readers may skip this background paragraph.  The GRE is a
     standardized (multiple-choice, fill-in-machine-readable- form) test used by
     most universities as (sometimes very important) element in deciding on an
     applicant's admission.  There's a general test, and specialized tests for a
     number of subjects, such as Computer Science, Math, etc.
     The New York Times, 15 Nov 1993, p. A1) carries a story on using computers
     to give the GRE. It is written by Michael Winerip and entitled:
       "No. 2 Pencil Fades As Graduate Exam Moves to Computer"
     I'll sidestep the discussion on how seriously one should take standardized
     exams; the fact is that they make or break many an applicant. I want to focus
     on the way in which the computer is used. It is not just as a clever way to
     record the answers to a test in the usual format. The new format is
     "adaptive."  To quote from the blurb:
       ... The computer randomly selects a first question of medium
       difficulty. If the test taker answers the question correctly,
       the computer poses a more difficult question. Once the test
       taker gives an incorrect answer, he or she is given a question
       at the next easiest level.  Test takers are graded based on
       the level of difficulty they master.
     This is very attractive to ETS (the company that administers these tests) for
     various reasons; one is that the processing of the test is trivial --as a
     matter of fact, it reports the result to the student as soon as she answers
     the last question.  But more interestingly: there are many more different
     tests to make out of the same set of questions (they claim that in a test
     trial with 1200 people there were no two equal tests; the readers of RISKS are
     familiar with combinatorics).  So there's a strong economic incentive here.
     The RISKS?  The usual with erroneous results coming from faulty software, and
     the faith most people have in computers. And more: current GRE reports scores
     and percentiles. The latter, but also the former, are normally taken in the
     context of a population.  But now there will be no such thing anymore.  Of
     course, the "testing experts" will normalize things away by assigning "values"
     to the questions; as any experienced teacher knows, it is quite hard to rank
     all questions by difficulty...  as the faculty in the CS Dept used to say in
     the comprehensive exams here:
       The number next to each question indicates its value, but
       budget your time carefully as we make no claim as to the
       relative difficulty of the questions.
     There's other risks and problems; I am sure other readers will contribute to
     the discussion.  The overall risk is to make decisions that significantly
     affect the functioning of the system (i.e., the choice of incoming students)
     based on models of reality whose validity is hard ascertain.
     Cris Pedregal Martin            
     Computer Science Department              UMass / Amherst, MA 01003

More news on the Lufthansa A320 accident in Warsaw

Dr Peter B Ladkin < >
1 Dec 93 21:31:32 GMT (Wed)
     The story so far is that the spoilers, brakes and reverse thrust were disabled
     for up to 9 seconds after landing in a storm on a waterlogged runway, and the
     airplane ran off the end of the runway and into a conveniently placed earth
     bank, with resulting injuries and loss of life. (First report of actuation
     delay in Flight International, 13-19/10/93.)  Subsequent enquiry led various
     people including myself to speculate that there was some sort of logic or
     system error, which was subsequently narrowed down to a problem with the
     arming logic for the spoilers-brakes-reverse-thrust combination (let's call
     this the braking logic for short).
     On 10 Nov, Frankfurter Allgemein reported that Lufthansa had concluded there
     was a problem with the logic, and was requiring their pilots to land in a
     different configuration and a different manner in such weather and runway
     conditions, to `fool' the logic. This decision was supported by the
     Luftfahrtbundesamt, the German equivalent of the FAA (US) or CAA (GB). Der
     Spiegel, in issue 47 (22/11/93) reported on the `deadly logic' of the A320
     braking systems. Der Spiegel this week (issue 48, 29/11/93) reported that
     Lufthansa was talking with Airbus on a change in the braking logic to reduce
     the weight-on-wheels load criterion from 12 metric tons to 2 metric tons, and
     claimed that this was the first time that Airbus had to `convert their
     machines' because of an accident (`ihre Maschinen nach einem Unglueck
     umruesten muessen').
     I talked this afternoon to David Learmount, the Operations and Safety Editor
     of Flight International, concerning progress on the A320 crash in Warsaw and
     the consequences. He holds an ATP (Airline Transport Pilot) or equivalent
     rating.  I asked David what was afoot, since Flight International has been
     relatively quiet since 13/10.  He said that Lufthansa, the Luftfahrtbundesamt,
     and Airbus are all still in conference.  Firstly, the airplane is not
     certificated for what Lufthansa want to do.  So, they are all trying to figure
     out what *can* be done.  The certification authority (JAA, see below) may be
     involved in these discussions.  Everyone, including David, is aware that
     although the solution may be implemented in software, this doesn't necessarily
     mean the software itself was at fault (i.e. the software may correctly
     implement the braking logic, but this latter may be inappropriate).
     Some other information. David said that normally one carries 5-15kts for
     gusts. Carrying 20kts, as in Warsaw, is unusual. Secondly (confirming
     speculation that some pilot actions may have been contributory), the pilot
     tried to grease it on, rather than dumping it on. (`Dumping it on' means
     landing relatively hard, which is acceptable to all but the passengers, is
     likely to have compressed the squat switches, and also more likely to get the
     wheels gripping and spinning.)  Thirdly, the landing was well inside the
     certification envelope, which is somewhere in the region of 200kts.
     Additionally, there is no information to suggest that the pilot had any
     indication that the weather report was old.  David also confirmed the 12
     metric ton figure for the squat switch trigger.
     The Joint Airworthiness Authority certifies (or certificates, as they say)
     airplanes for EU countries. Theoretically, all members of the EU are members
     of the JAA, but in practice only the French (DGAC), British (CAA), Germans
     (LBA) and Dutch (???) are active rule-makers. 
     Many thanks to David and Flight International for this information.
     Peter Ladkin

Memory error corrupts file

James Michael Chacon < >
Sun, 28 Nov 93 05:40:18 CST
     I had an interesting thing happen to me the other morning while working.
     According to syslog, I got a parity error somewhere in memory:
       Nov 26 01:17:26 vmunix: Parity error reported at 0x8488, actual address is 
       Nov 26 01:17:26 vmunix: Parity Error, ctx = 0x2, virt addr = 0x8488
       Nov 26 01:17:26 vmunix: pme = 820013b0, phys addr = 13b0488
       Nov 26 01:17:26 vmunix: Parity Error Register 94<ERROR,CHECK,ERR08>
       Nov 26 01:17:26 vmunix:  bad module/chip at: U590
       Nov 26 01:17:26 vmunix: parity error at 13b0488 is transient.
       Nov 26 01:17:26 vmunix: page 13b0000 back in service.
       Nov 26 01:17:26 vmunix: System operation can continue
     From the looks of it, it was a transient error that fixed itself without a
     problem. However, right after this the load on the machine started climbing
     rapidly and would not come down no matter what I tried. So, I figured it was
     time for a reboot anyways and rebooted.
     When everything came back up, I could log in ok as my shell just execs X 
     windows on the console, but could not get a local window. Traced it down by
     the last modified time on my shell. Seems /usr/local/bin/bash (which is my
     current shell) had last been modified on Mov 26 at 1:17......
     Now this is bad, I get a parity error, which corrupts a supposedly
     non-writable text segment page, which then gets marked as dirty so the OS
     flushed it back onto the disk. What's next, writing data pages back out as
     text pages?  (This is on a Sun IPC running 4.1.3)

New Moderator for the Computer Privacy Digest

"Dennis G. Rears" < drears@Pica.Army.Mil >
Wed, 1 Dec 93 8:28:14 EST
         I will relinquish moderator duties of the Computer Privacy Digest today.
     Prof. L. P. Levine will take over as the new moderator of the Computer Privacy
     Digest (comp.society.privacy) effective midnight tonight.  The new relevant
     addresses are:
     	Complaints:	/dev/null
       The primary reason I am leaving the group is time.  In the last few months I
     have not had the time to adequately perform the duties of being a moderator.
       I would like to thank all the people who have contributed to the digest and
     those people who have provided me with pointers on making the digest better.
     I have for the most part enjoyed moderating the group.  I will miss the
     off-line discussions I have had with many of you.
       The CPD had it origins in the telecom-privacy mail list which I set up in
     August of 1990.  Telecom-priv started out to address concerns of Caller Id.
     It was an outgrowth of a discussion that was started on the Telecom digest.
     The telecom privacy maillist was merged into the Computer Privacy Digest on 27
     April 1992.  According to the October USENET readership report
     comp.society.privacy is read by about 44,000 people, 73% of USENET sites
     receive this and is ranked at 683.  I have about 500 subscribers/exploder
     lists.  I think we have come a long way since the first issue was published in
     April 1992.  FTP access to the archives of the Computer Privacy Digest & the
     Telecom Privacy list are available at and at
       I wish Professor Levine good luck in his new role.  I plan to assume a role
     as Official Lurker.
     P.S.  I will remain as the keeper of the government (MIL & GOV) portion of
     the RISKS list.  The BARFmail is still at a tolerable level.
        [And once again, many thanks to Dennis for his past and future help in 
        his nonMILitant keeping of the RISKS sublists.  PGN]

Re: Safety-critical software (Parnas, RISKS-15.22)

Pete Mellor < >
Tue, 23 Nov 93 19:40:07 GMT
     Dave Parnas <parnas@qusunt.eng.McMaster.CA> writes:- 
     > Even if we did test
     > every possible path, we have not done exhaustive testing.  We should 
     > not ever imply that such a test would be an exhaustive test.
     I totally agree, and Cliff Jones would probably agree as well. In my summary
     of the programme, I was trying to give a fair account of what was actually
     said, without interposing my own views or comments. (Since I did not have a
     recording or transcript to hand when I was writing, however, the summary was
     dependent on my highly unreliable memory.) Cliff Jones was also constrained by
     broadcasting time, and the need to address a non-technical audience.
     Peter Mellor, Centre for Software Reliability, City University, Northampton 
     Square, London EC1V 0HB Tel: +44 (71) 477-8422, Fax.: +44 (71) 477-8585, 

Re: Ada Usage (Erwin, RISKS-15.28)

Tucker Taft < >
Fri, 19 Nov 93 13:56:15 EST
     On 15 Nov 1993, (Harry Erwin) wrote:
     > There are real problems for which Ada is not the best language.
     I would rephrase this to say that at a given time in a given environment, one
     language may be more productive than another.  However, this more often has to
     do with the experience of the development team, the availability of existing
     software components and tools, etc., than the inherent features of the
     language.  It is quite possible over time to shift the balance toward a
     different language, through training and experience, the development of
     reusable software components, and the development of appropriate tools.
     Below I have more detailed comments on your claims that Ada is inadequate on
     the basis of its inherent features.  Although I don't agree with your
     comments, I would certainly agree that in a given software development
     environment, things might be set up much more productively for development in
     one of these areas in some other language.
     However, when it comes to the DoD, they need to worry about not just the
     start-up costs of using a given language, but also the reliability, the
     quality, the maintainability, and the "transferability" of the result
     produced.  By "transferability" I mean the ability to take the code and
     documentation for a system and move it to a new development (or maintenance)
     Transferability is a bigger concern to the DoD than most typical software
     developers, because the DoD generally contracts out software development, and
     is then generally required by law to be able to re-compete maintenance
     contracts on a periodic basis, unless the product is a commercial
     off-the-shelf product.  In other words, doing the initial custom development
     of a DoD system is not a guarantee of life-long employment ;-).
     One of the main goals of having a single (or just a few) common high-order
     language(s) for the DoD was to address the requirement for transferability.
     Of course the DoD would like to use commercial off-the-shelf products if they
     can solve the problem, but for some reason they haven't found many COTS
     submarine-based missile launch control systems (or whatever ;-).
     In my detailed comments below, please remember that I don't disagree with your
     basic premise -- when restricted to a particular environment, any given
     language might not be the most productive.
     However, I don't think you have a real case in the following complaints with
     respect to the DoD concerns.  There are already DoD contractors (and others)
     for which Ada is already the most productive language in some or all of the
     areas you mention below.  Of course, this is because they have made the
     investment in Ada training, components, and tools to reach that point.  If
     they had made the same investment in Lisp training, Lisp components, and Lisp
     tools they might find Lisp is the most productive for them.
     So perhaps a more fundamental question is, given two different contractors,
     each of which is fully trained up and ready to go in Ada or Lisp or (fill in
     the blank) language, which one should DoD select on a given contract.  The
     excellent transferability of Ada, and the many inherent reliability features
     of Ada, makes it a good choice from the DoD perspective.  And even if the two
     languages are similar from these perspectives, there are advantages for the
     DoD to stick with just one language, so that the DoD itself can build up its
     own expertise, components, and tools in that "common" DoD language.
     > 1. Simulation--due to the lack of support for coroutines, Simula-style
     >    semaphores, condition queues, call by name, and event lists,
     Ada supports "coroutines" in the sense that it supports full tasking in the
     language, and two tasks can hand control back and forth should they so choose.
     Did you have something else in mind?  Semaphores, condition queues, and event
     lists are also easily implementable in Ada.  Could you explain why
     call-by-name is relevant to simulation?  Is it the ability to pass subprograms
     as parameters?  This is provided in Ada 83 via generics, and in Ada 9X also
     via access-to-subprogram types.  Generics can also be used to pass an object
     "by name" (formal IN OUT objects).
     > 2. Test generation--for similar reasons,
     Same issues.
     > 3. Multi-threaded applications with external inputs, where the usual
     >    tasking libraries run into problems. ...
     The "tasking library" comes with the compiler in Ada, and is required to be
     "carefully integrated" with the operating system if it is to conform to the
     definition of the language.
     > 4. Object-oriented programming in the full sense,
     Ada 9X supports object-oriented programming in the full sense.  Ada 83
     supports abstraction, modularity, information hiding, and compile-time
     polymorphism (generics), which are already enough to support object-oriented
     > 5. Completion routines for inter-device protocols, and
     Can you elaborate on what is a "completion routine"?  Is it an event handler?
     This is provided via generics in Ada 83, and also via access-to-subprogram and
     dispatching operations in Ada 9X.  Is it an interrupt/signal handler?  These
     are supported in both Ada 83 and Ada 9X.
     > 6. Anything that needs to run close to the bare metal.
     Ada 83 provides excellent support for data representation control.  Ada 9X
     goes further.
     As mentioned above, I agree with your basic premise that in a given
     environment, one language will be more productive than another.  But I know
     there are software developers who are very productive in Ada in all of the
     areas you mention above.  But of course, there are others who are more
     productive in some other language in these same areas (presumably do to
     different training, experience, components, or tools).
     S. Tucker Taft   Intermetrics, Inc.  Cambridge, MA  02138

re: Ada Usage (Erwin, RISKS-15.28)

< >
Wed, 24 Nov 93 10:39:49 GMT
     While not wishing to drag RISKS into a language debate, Ada gets so much
     undeserved bad press that I feel I should comment on Harry's assertions:
     > 3. Multi-threaded applications with external inputs, where the usual
     >    tasking libraries run into problems. ...
     This isn't a problem with Ada per-se -- just one particular implementation.
     Ada run time systems today are very well integrated with the OS on UNIX
     platforms, for example. There are several Ada RTSes that implement tasking
     on top of POSIX threads for excellent task and I/O handling.
     You get even better implementation on "bare targets" with no OS, since the
     RTS doesn't have to work around the OS to get the real time performance
     some users require.
     > 4. Object-oriented programming in the full sense,
     True, there's no inheritance or polymorphism, but then both of these are
     largely incompatible with real-time software (one of Ada's target
     application areas). Dispatching routines for objects introduce variable
      run-time overheads that most real time people would rather do without.
     Having said that, Ada 9X *does* provide full OO programming (get the latest
     pre-release version of GNU-Ada 9x from if you're interested).
     > 6. Anything that needs to run close to the bare metal.
     I've written Ada that runs very efficiently on "bare metal" Transputer
     networks.  I think that qualifies as a counter example to the blanket
     Ada is certainly no panacea for RISKy programming problems. Then again,
     a colleague has just spent the last six hours tracking down a bug in a C
     program that turned out to be caused by an array index out of range --
     something that an Ada program would have pointed out immediately.
     Mathew Lodge   Schlumberger Technologies,  ATE division, Ferndown, UK

Previous Issue Index Next Issue Info Searching Submit Article

Report problems with the web pages to
This page was copied from:
Last modification on 1999-06-15
by Michael Blume