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 International Herald Tribune for Monday Oct 2, p1, has a report on a DC10, NorthWest Flight 52, on its way to Frankfurt from Detroit. They landed in Brussels, much to everyone's surprise except for the passengers, cabin crew and air traffic control.
A controller in Shannon changed the destination in the en-route computers for some reason no-one has fathomed. So everyone after that sent NW52 merrily on the way to Brussels. The cabin crew and passengers noticed, because the cabin flight-path display was showing them going to Brussels rather than to Frankfurt (the cities are 200miles=325km away from each other). The flight crew first noticed when they broke out under the clouds on approach to Brussels, and noticed that the layout of the airport was not similar to Frankfurt. Sensibly, they decided to continue the landing. And will remain landed until the investigation figures everything out. A spokesman for NorthWest pointed out that the crew *should* have known where they were.......
That reminds me of the time I was flying Chicago to SFO and following the ground on my WAC (World Aeronautical Chart). The routing went south of the Colorado/Wyoming boundary, past Aspen, and then over the Green river canyon, which is some 250km past Aspen. Just then, the captain announced "We're just passing Aspen, Colorado, out of the left window." But we got there OK. Even United pilots can recognise the Mina and Coaldale transitions to the Modesto arrival when it hits them ;-)
Peter Ladkin.I have a fax that I have received from the Systems Engineering Society. In the footer, it says "Internet: SESociety508-420-0210ol.com" Since I know that the address is @aol.com, it seems that something has substituted the outgoing fax number for the "@a".
The root cause appears to be that the formerly rare character "@" has become more frequently used, making it no longer appropriate as an escape sequence.
Henry Troup - hwt@bnr.ca (Canada) - BNR is not committed to anything I sayThe following is taken from a report in the Independent (a UK quality paper) for Tuesday 3 October 95. The headline is `Court computers in countdown to chaos'.
Programming work is underway to prevent thousands of court cases being called for 31 Dec 99.
`The Lord Chancellor's department is implementing the scheme to prevent
legal chaos caused because aging court computers cannot speak Latin or understand the concept of eternity.'
The problem is that many cases are adjourned `sine die' (literally `without date') when they need to be disposed of without reaching any sort of verdict. The intention is that they are never seen again. The computers used for scheduling court hearings can't cope with this so clerks in some courts have been entering the latest date that the machine knows about---31 Dec 1999. This means that on 30 December these systems will print a huge list of all these cases, for hearing the next day. The article suggests that up to 25,000 cases may be involved in some inner city courts. The exact size of the problem is unclear as other clerks in other courts may have used other tricks to get round the problem. A computer `expert' is quoted:
`When the first systems were introduced 25 years ago, the last day of 1999
was still a long way off and it did not matter if these cases were adjourned until that date. It is only just over four years away and we have got to do something about it. Fortunately, computer software has advanced and the courts will not have to record
false dates under the new system.'
My comments: the concept of `sine die' has been around for hundreds of years, it really should have been in the original specification for the system. Also, if 31 Dec 99 is the latest date the system can cope with, it has bigger problems than just dealing with `sine die' cases. It won't be able to adjourn any cases to known, fixed, dates in 2000 and beyond.
Peter Ilieve peter@aldie.co.uk[Also noted by Keith Bennett <keith.bennett@durham.ac.uk>. PGN]
It seems the phone monopoly, KPN, had some problems restyling the phone directory of Utrecht. The restyling involved adding a 'yellow pages' kind of index to the alphabetical section, and the possibility of advertisements in the alphabetical section of the directory. The Utrecht directory was recalled because of a lot of errors; it seems that about 10% of entries was corrupted one way or the other. Newspapers reported at the time the cause was 'computer error' while merging the list of subscribers with the list of advertisers.
Now, nearly a year later, KPN/PTT still does not have its data right. No directories have been published since. For Amsterdam, where I live, this means the directory will be published in January of February 1996 instead of the original may 1995. Other cities will have approximately the same delays.
While the subscriber database is correct, the advertisers database is not, it seems. The subsidiary of KPN responsible for the directories, Telemedia, told me this:
The being unavailable of directories causes quite some problems. Phone numbers tend to change quickly here, as it is often not possible to keep your number even when moving to another part of the city. And even government or business numbers are quickly given to private subscribers who will then probably not be happy.
The RISK here is having a lot of calls arrive at the wrong destination. Having a monopoly run the phone system is probably the biggest cause here, followed by trusting your (computer) systems and procedures.
Thomas ToninoHere is a great report about someone getting involved.
911 phone line crossed
RICHMOND, Va. (AP) — When Rosa H. Dickson answered her telephone, the caller requested an ambulance. It took only a moment to figure out that the caller had dialed 911 and got Dickson instead. "When I realized what happened, I dialed 911 and couldn't get 911," she said Monday.
[This lasted for half an hour, beginning at 5 a.m. Dickson then alerted the police of the problem, and kept passing info on to police, two calls for rescue crews and one for police. One caller gave the wrong number, and then called in again later when nothing happened. Bell Atlantic apparently messed up on maintenance following a system upgrade. PGN]
For those who are not familiar with this part of the world, Delhi Electric Supply Undertaking (DESU) is the name of a company that supplies electricity to the city of Delhi, the capital of a country called India. The company has been using a computer to make the electric bills of its customers for quite some time now (the trouble starts!). One fine morning about a year back, the computer decided to print wrong customer codes on the monthly bills it produced for some privileged persons like me. Since the code is long (18 alphanumeric characters!), nobody noticed the mistake.
With good faith, I paid the bill. As you might expect, next month I saw an arrear amount on my bill. When I took it to DESU's office, they had several theories on how the error might have occurred. They did an ad hoc correction on the bill (hardcopy). The same game continued for an year till, another fine morning, I got a notice for disconnection, the ultimate punitive action from DESU for non-payment of bills!
A number of panic-calls to the top-brass of the company later, I came to know the reason. The mystery of the misbehaviour of the computer is still unknown — it could probably be a software bug! More stunning was the fact that while some of the dealing clerks knew about the problem, they pleaded helplessness and seemed to be at the mercy of the computer. The matter becomes worse as the responsibilities of the preparation of the bills, receipt of payments and the issue of the notices rest with different departments, with the computer gracefully occupying the centre- stage.
Though my immediate problem (disconnection threat) has been taken care of, DESU cannot assure me that I shall get a correct bill next month or that I shall not get yet another funny disconnection notice. As this moment, I remain under the threat of the monster computer that is probably churning out yet another wrong bill, either for me or for somebody else.
Though this story is a pretty low-tech one than those usually discussed at the RISKS forum, the moral remains the same: Computers (for the matter, technology in any form) should never become the boss!
Hiranmay Ghosh, Centre for Development of Telematics, Akbar Bhawan,I am currently setting up my own Web site, through MASSInternet (a subsidiary of PSInet). I wanted to call this site espen.com, and to have my email address be self@espen.com, which I thought had a nice OO ring to it. Registering the domain name takes about 6 weeks, so in the meantime PSI gave me the email address self@usa1.com (rather grand, but it works fine).
You can probably guess the rest: A number of email systems have a feature called copy_to_self, and apparently some users think the CC: field is where to turn this feature on. A transitory problem, to be sure, and so far the email copies I have received have not been really interesting....
Espen Andersen <self@usa1.com, soon to be self@espen.com>[Via "Will Tracz" <tracz@lfs.loral.com>, editor, ACM Software Eng. Notes]
NOTE::: I believe that professionals involved in hardware components of flight control systems are required to be identifiable and accept responsibility for the quality of the work they sign off on.
THE FACT THAT SOME COMPONENTS OF SUCH SYSTEMS NOW CONSIST OF COMPUTER SOFTWARE SHOULD HAVE no EFFECT ON THE ACCOUNTABILITY RULES - but, I do not remember this being enforced adequately!
>Numb : 274 of 294 Date : 09/21/95 11:13am
>Conf : 1975 - alt.politics.datahighway
>From: HDUN11A@prodigy.com (Charles Smith)
>Subject: AIRLINER CRASHES
[...] Two final notes on the crash of CAL-140: Japan's 23 major insurance companies will pay a total of $78 million to the families of those killed in the crash of CAL-140. In addition, the Japanese National Police are investigating the crash of CAL-140 under the heading of "MURDER".
Aviation Week and Space Technology
Charles R. Smith hdun11a@prodigy.comIn regards to the `success' story about the STRATUS system, where a room full of computers survived baking in 120oF heat for 3-4 days with only 2 disk drives failing, this story is remarkable in that it completely overlooks the inevitable degradation of the electronic equipment at that site that did NOT fail immediately during the overheating episode. Excessive temperatures degrade electronic components and reduce their life expectancy considerably. For 3-4 days the hardware baked itself in 120oF conditions without notifying anyone of the underlying problem. Over the weeks and months to come after this episode, the owners can expect a higher-than-normal failure rate of the equipment so exposed.
Had the STRATUS system included a temperature alarm to a central office, something on the order of, "Hey, guys, my A/C is out and it's over 100 in here - HELP!" STRATUS might have not only saved the drives that immediately failed due to the heat but also the other equipment that will inevitably fail early as well.
In a sense, this reveals another RISK of modern computers/electronic equipment; the inability to always diagnose and report to the operators what is REALLY wrong with the system, even if you have designed a sophisticated diagnostic/reporting capability into the system.
***
This reminds me of a story told by my faculty advisor back in college. In his graduate school days he worked on one of the original UNIVAC mainframes in the country. That machine comprised dozens of racks of vacuum tube-technology logic boards stacked in banks up to the ceiling in their computer room. Each board controlled a different function in the computer and he said that after a while he could tell from the error returned in a malfunction not only which board had failed but also the most likely vacuum tube that had gone out. Usually the failure was blamed on excessive heat, because even with the room's central A/C going full blast the heat from the tubes kept it nice and toasty in there, especially around the ceiling.
His EE department was always complaining about the high tube failure rate due to excessive heat so finally the school ordered a newer, bigger A/C for them. Unfortunately, when they came to install it, the electricians forgot to tell anyone that they were shutting off the A/C power at the breaker box. So the computer kept running...
...the first anyone knew what was happening was when they heard explosions
from the computer room, as boards blew up starting from the top racks and then down to the bottom racks, one bank at a time. My advisor said it took them 3 months to rebuild the system and when they finished, they welded the A/C panel box shut.
The RISKS of the right hand not knowing what the left had is doing are obvious.
> If you do this on a Macintosh (Excel v5.0a on a PowerMac 8100/110) you get a
> result of 1.40737488355328 = 1.28, proving that the Macintosh is 6 times (as
> powerful as a PC) ...
Interestingly enough., Excel v5.0a on a Mac IIsi also yields .64; however, if you paste the original number as text and then perform a math operation, Excell yields the correct result.
What I find interesting (and disturbing) is not that some number that most people will never use behaves oddly, but that the program behaves oddly. I'm working on a project that will use digital controls for power plant applications, and as part of that we need to verify that the system responds as expected during operations and transients. I wonder how we will be able to test for obscure bugs such as this (since if one number does this, what other features haven't we yet encountered). More importantly, we need to design the system to tolerate such undiscovered flaws and not go nuts when it does (a daunting task).
Jim[I have heard some reports that this flaw is actually an intentional feature intended to detect copyright ripoffs. Music publishers and dictionary editors have been doing similar things for years. PGN]
In Risks v17 no36 Ross Anderson reported a proposal from the Council of Europe to ban strong encryption within Europe, and to introduce a 'Euro-Clipper'. I have to say that I think the article he
reports jumps
the gun somewhat. The actual proposal reads (in the relevant section)
"V. Use of Encryption
14. Measures should be considered to minimise the negative effects of the use of cryptography on the investigation of criminal offenses, without affecting its legitimate use more than is strictly necessary."
The UK already allows a Police Constable to obtain a warrant requiring a suspect to produce all information on his computer 'in legible format' ie de-crypted, and I suspect this is all that will be required to meet the proposal.
This is not of course to say that there are not people about contemplating doing just what Ross relates. They are usually sat on a fat surveillance budget, and wondering how they will justify it next year.
David Swarbrick, Swarbrick & Co, Solicitors, 22 Bradford Road BrighousePlease report problems with the web pages to the maintainer