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…
I enjoyed very much the interesting report by Lindsay F. Marshall (RISKS
DIGEST 4.48) that shows four near-miss incidents in the UK. The reasons
for the incidents are: (1) An Aberdeen radar controller, (2) The Iranian
crew, (3) The controller who handled 14 aircraft simultaneously and had
forgotten the 737's existence, and (4) a trainee controller who had
forgotten the presence of the military jet.
I find this important report to be misplaced. It must belong to another
RISKS-FORUM Digest, one that is not a "FORUM ON RISKS TO THE PUBLIC IN
COMPUTER SYSTEMS" like ours, but to the "FORUM ON RISKS TO THE PUBLIC IN
MANUAL SYSTEMS".
I do not find it fair that we include their stories in our bulletin.
By the way, I guess that they had a field day with the train accident,
the one in the East that none of us managed to blame computers for.
Danny.
[I HAVE INFORMALLY BEEN WORKING UNDER THE CRITERION THAT RISKS is
a forum on risks to the public in COMPUTER-RELATED TECHNOLOGIES.
If the computers in a computerized system are not used to proper
advantage to prevent something that is caused by PEOPLE, that is
relevant. If there are no computers in an environment that is
critical (and especially if it is difficult to control), then that
also is relevant. In the former case, the existence of computers
often leads people to rely on the computer systems rather than
remember that they (the people) are critical elements in the overall
system. In the latter case, the absence of computers is itself an
issue. Besides, it was a slow week otherwise. But, I left out the
trains anyway... PGN]
This is starting to become ridiculous. In RISKS-4.48 there were only 2
articles concerning computers; all the rest were about aviation, cars and
telephones - nice horror stories, but all referring explicitly to human
error (not while using/programming computers) and faulty hardware (not
computer hardware). I thought the purpose of having this group moderated was
to prevent such articles from filtering through! (Yes, I know, some of them
are mine, I admit).
Amos Shapir, National Semiconductor (Israel)
In RISKS Vol 4 Issue 48 Lindsay Marshall reproduces a recent news article from The Observer, which is a quality newspaper: > London Air Traffic Control Centre ... suffered a total loss of main > power as the morning rush of flights began. > A standby generator also failed ... Now, even allowing for paraphrasing and journalistic licence, it would seem to be relevant to ask what happened to the secondary and tertiary main (grid) power feeds, the secondary and tertiary generators, the secondary battery system, and why the battery system was apparently only designed to last for 30 minutes. Phone switches have better backups! At least Bell Systems' ones do — I can't speak for British Telecom. Of course these systems may have been the result of Government cost savings... Jonathan Clark
Here's a story about how a little innocent disk-space cleanup led to a student doing an exam, and being told he'd passed, when he shouldn't have been allowed to take it at all. All law students in Ontario must pass the Bar Admission Course before they become lawyers. One course in the BAC is on Accounting in a Law Office. This course is taught by CAI, and the exam is on-line. Every student gets a different exam; the random seed is the student's (internal, numerical) user-ID on our UNIX system, so that we can easily reproduce any student's exam if need be. Students who fail the exam on the first crack are allowed to do it again as a supplementary. They are supposed to get a new account installed for them and use the new account. With the new account, they get a different user-ID and therefore a different exam. If they try to use their original account to do the exam again, once they've already done it, the system stops them. A student took the exam on a Tuesday afternoon and failed (scored 44%). He didn't contact us to get a new account set up, merely came in on Wednesday morning and took the exam again. Taking EXACTLY THE SAME EXAM, he scored 50% and was told he'd passed. We discovered this when our weekly statistics run told us that out of 538 students who had taken the exam, 536 had passed and 3 had failed! (The Bar Admission Course's overall pass rate is very close to 100%. You have to be pretty bad to get 50% your second time round on the SAME exam!) Normally the system would have prevented him from taking the exam again. However, in an effort to free up some disk space that Tuesday night, I combined all students' result files into one compendium. (There was a one-line file for each student account, and disk blocks were used much more efficiently by combining them all together.) I had forgotten that the way the system stopped a student from taking the exam twice was by detecting the existence of a result file! (This has been fixed.) Also, the message to the student indicating that he had failed, but could retake the exam as a supplementary, did not indicate that he'd have to get a new account to do so. (Now it does.) What we decided to do was contact the student and tell him that the allowing of him to retake the same exam was a mistake and he must do it again. Fortunately, he didn't object, took it again (different exam) and passed. If he had objected, I don't know what we would have done. How do you fail someone after he's taken an exam and passed? David Sherman (dave@lsuc.UUCP), The Law Society of Upper Canada, Toronto
On February 4 a restaurant near Rochester, NY caught fire. The owner dialed 911, which connected him to the county-funded, city-run emergency services network. Apparently he told the operator that the fire was at "321 Linden Ave." The Automatic Location Indicator, a system which uses a computer file maintained by Rochester Telephone to identify the address from which incoming calls originate, displayed "321 Linden Ave. Brighton" [a suburb of Rochester]. Fire trucks were immediately dispatched to that address. Unfortunately, the restaurant is located at 321 Linden Ave. in East Rochester, another suburb several miles east. Fortunately, about two minutes later the fire was called in by someone else who did specify the proper location; the additional damage suffered because of this delay does not appear to have been major. Operators for 911 are instructed to seek locations from callers, and to rely on the ALI only when the caller is unable to give that information. In this case, however, it seems clear that in the absence of the ALI the operator would have attempted, almost certainly successfully, to ascertain the town involved orally. Thus the faulty data in the ALI file was the cause of the dispatching delay. It appears that such errors, while not common, are not extremely rare either. (Incidentally, the county Commissioner of Public Safety took this occasion to complain about duplicate street names within the county, apparently a continuing sore point here. It strikes me that the system (computers and procedures) should be robust enough to handle this; after all, if one eliminated the duplicates one would still have the sound-alikes, numbers east versus numbers west, and so forth.)
At a recent aviation safety conference, Jack Eggspuler told a story similar
to that of the student with the extra $25,000 credited to his account
[Steve Thompson, RISKS-4.46]:
He had banked for years at a small-town bank. One day, a large banking
conglomerate bought up the small bank. After this, Jack noticed that his
deposits weren't being listed.
A similar thing happened to me through the Massachusetts Baybanks
chain. Although it is it statewide bank it's actually split into
smaller regional banks. I had/have an account Baybank/Middlesex.
Unfortunately someone else had an account with Baybank/Harvard with
the same individual account number (although the bank codes were different).
Every few months she would make a deposit or (more often) a withdrawal
at a Baybank/Middlesex branch and the teller wouldn't notice that the
bank number was different. Bingo, money out of my account. After
three such errors (including one that resulted in an overdraft), and a
number of fights to insure that I got back all charges and interest, Baybanks
finally agreed that something should be done about it - namely having me
change my account number.
This is one instance where I'd far rather trust my account to a computer
that reads ALL of the information off my banking card.
-nazgul
[See my comment after Danny Cohen's message above, especially if
you don't think this should be relevant to the RISKS Forum! PGN]
<> The killer (pun intended) is the electronic four-wheel steering. There is <> no mechanical connection whatsoever between the steering wheel and the <> steering gearboxes! Two 24 volt battery-powered electric motors are <> responsible for turning the front and rear wheels. ... I don't see why just using electronic steering is dangerous. Especially in today's litigious society. I am sure that the car makers will think of this when they put the electronic control in. Side note: Isn't the F-16 a fly-by-wire plane? If electronic steering is safe, and reliable enough for combat jets, why wouldn't it be safe enough for everyday car?
> ...leaving even my elderly parents wondering: if the microburst was
> so severe as to be unflyable (according to NCAR's McCarthy), and if
> its potential presence was not reported by the only people who could
> have known about it, how could it be the pilots' fault? ...
They flew into/under what they clearly saw to be a violent thunderstorm.
There are few worse sins in flying. Their only excuse was the the planes
ahead of them had gotten away with it — an attitude that has been loudly
criticized in other contexts, e.g. the Challenger disaster.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
If you are going to use RJ parts for terminals, you should make the center wires (red and green) be ground, and tie them together in your RJ to DB25 box. If you plug this cable into a phone system it looks like a phone which is off the hook. This is, of course, only true for single-line service, but that is probably the vast majority. Properly wired RJ terminal cables solve just about all of the problems with RS232. You want to plug your terminal into your modem? Great, just use a standard male-male cable. PC into terminal? Same. PC into printer? Modem into printer? Terminal to terminal? Same. Solve the wiring problem ONCE for each device that comes in the door, and you never have to do any work to connect any two devices. If you'd like further info on how to wire like this, send mail. This scheme (the one I'm familiar with, superior to all others I've seen) was developed (I believe) by Dave Butterfield at UCLA, and is used there. The parts are much smaller, cheaper, and easier to use than DB25s.
Please report problems with the web pages to the maintainer