Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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
Please report problems with the web pages to the maintainer