| 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: http://catless.ncl.ac.uk/Risks/15.30.html | |
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Risks of automated betting
Computer Changeover May Cost $16M
Mercury passwords can be compromised
Computerized Pornography
Picking from Trash (Re: Charge cards from mail-order houses)
GRE goes "adaptive"
More news on the Lufthansa A320 accident in Warsaw
Memory error corrupts file
New Moderator for the Computer Privacy Digest
Re: Safety-critical software
Re: Ada Usage
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 corfmanr@agcs.com
UUCP: ...!{ncar!noao!enuucp | att}!gtephx!corfmanr (602) 581-4403
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.
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
passwords.
Keith Lockstone
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
pornography.
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 Brian.Randell@newcastle.ac.uk PHONE = +44 91 222 7923
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
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 pedregal@cs.umass.edu
Computer Science Department UMass / Amherst, MA 01003
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
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
0x8488.
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)
James
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:
Submissions: comp-priv@uwm.edu
Administrivia: comp-priv-request@uwm.edu
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 ftp.pica.army.mil and at ftp.cs.uwm.edu.
I wish Professor Levine good luck in his new role. I plan to assume a role
as Official Lurker.
dennis
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]
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,
On 15 Nov 1993, erwin@twracs.fp.trw.com (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)
environment.
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
design.
> 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 stt@inmet.com
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 ftp.nyu.edu 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
"everything".
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
lodge@ferndown.ate.slb.com
| This page was copied from: | http://catless.ncl.ac.uk/Risks/15.30.html |
| COPY! | |
| COPY! | |
|
by Michael Blume |