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…
On 6 Aug 1997, at a time estimated from radar data and cockpit voice recorder (CVR) timing as 01.42:30, Korean Air Flight 801, a Boeing 747-300 crashed into a hillside very near the Nimitz navigation beacon on approach to the airport at Agana, Guam. Although the accident has little obvious relation to computer failures (except for the failure noted by Steve Bellovin in RISKS-19.29), the procedure that the aircraft was supposed to be following has error-detection properties which it may be interesting to discuss using such vocabulary. Virtually nothing specific can be said at the moment about causes. The media carried stories that the glide-slope transmitter (GS) was out of service at Agana; also that a radar system called the Minimum Safe Altitude Warning (MSAW) system was discovered to have a software bug, which prevented it from warning the Agana Tower controller, with whom the plane was in radio contact, that the aircraft was too low to make the approach safely. The MSAW system is integrated into the software running the Agana tower controller's radar screen, but the system itself is located at Andersen AFB, some 10nm (nautical miles, about 11.5 statute miles) beyond the end of Runway 6L at Agana. Two facts are salient. First, the GS is not a part of the approach procedure that the aircraft was cleared to fly (the `localiser-only ILS'). The pilot was required to know before leaving Korea, and evidence in the cockpit corroborated that he knew, that he would not be using the procedure which requires the GS (the `full ILS'). Second, the procedure flown does not rely on any local radar at all being available, let alone MSAW. Thus concentrating on these two features would miss the point of an accident explanation, which is to clarify how the aircraft failed to fly according to a procedure which is designed to be safe to fly, and to all current understanding is so, for all suitably-equipped aircraft, including not only the B747 but many small four-seat Cessnas and Pipers. The equipment required to complete the approach safely has been the basis of flight radio navigation for the second half of the 20th century. A brief introduction to this radio navigation may be found in my article `Traditional Aviation Radio Navigation: An Introduction' at http://www.rvs.uni-bielefeld.de/abstracts.html#navigation The aircraft impacted the hillside well below the altitude of the top of the radio beacon sitting on this hill, 724ft. The aircraft was required to be at 1,440ft altitude at this point. One big question is: why was the aircraft over 700ft lower than it should have been? Maybe the pilot thought he was higher than he in fact was (this apparently happened with the Aeroperu accident - Ladkin, RISKS-18.59). However, the pilot had received the correct barometric data for the barometric altimeters (the so-called `altimeter setting'); the altimeters were recovered after the crash and were stuck at an altitude-indication roughly consistent with the altitude of impact. Furthermore, the aircraft was equipped with a recent model Ground Proximity Warning System (GPWS), an AlliedSignal Mark 7, which measures altitude by bouncing a radio signal vertically off the terrain below the aircraft. According to the CVR, this provided voice-synthesised altitude callouts of 1,000ft, 500ft and 100ft from terrain, as well as warnings of `sink rate, sink rate' and `minimums, minimums'. The crew was said by the NTSB to have been relatively quiet on the CVR, which is not what one would expect if they had recognised and were attempting to deal with an unusual flight condition (one would expect at least an announcement from the pilot flying of a change in status or intention). Weather conditions are being looked at, with a view to determining if there were unusual conditions such as windshear. There were reported to be some moderate-intensity rain showers on the approach path. Moderate-intensity showers are usually not indicative of potential windshear conditions, which are usually associated with thunderstorms, and a witness on the hillside very near to the crash said it was not raining on that hill at that time. Windshear did not seem to be a prime suspect during the early stages of the investigation. The particular positions (`fixes') on the ground that the aircraft on the localiser-only ILS 6L approach is required to identify are three: the Final Approach Fix (FAF), which is 1.6nm before the VOR, which the aircraft must pass at 2,000ft altitude and then descend to 1,440ft; the VOR itself, which the aircraft must pass at 1,440ft and then descend to 560ft, and the Missed Approach Point (MAP), at which the aircraft must `go around' (make an immediate climb to altitude and turn to fly back to a specific `fix') if the runway or surrounding lights are not clearly in sight. All these three fixes at Agana are redundantly indicated by the equipment aboard an aircraft, were this equipment to be used in a standard manner, so the procedure in effect incorporates error-detection of one navigation instrument failure (see ILS-article reference below). Since the procedure requires a go-around on detection of any instrument anomaly, it is therefore fail-safe providing it is followed rigorously and there aren't correlated multiple navigation-instrument or -signal failures. One would expect the investigation to try to answer the question whether these conditions were met. Had the aircraft passed the FAF at the required indicated altitude (on the altimeters), and had the indicated altitude been approximately correct, the aircraft would have had to have flown a descent gradient (`glide path') of over 7.7 degrees to arrive at the impact point. Such an angle of descent would be dangerously steep (this is between two and three times the expected glide-path angle), and the rate of descent at typical approach speeds would have been between 1,800 and 2,200 feet per minute, which would be dangerously high at this point in an approach. In conclusion, the localiser-only ILS procedure assumes correct barometric altimetry, and provides one-failure error-detection along with a safe go-around manoeuver should this situation arise. It does not require GS or MSAW. The GPWS provides some detection of incorrect barometric altimetry when this errs in the unsafe direction (when the aircraft is lower than pilots think - higher is of course safe, although equally incorrect). Pilots were provided with altitude callouts from the GPWS which were consistent with their actual situation and inconsistent with flying the approach according to procedure (the 500ft callout should normally happen well *after* the VOR, as depicted on the approach chart that the pilot had selected in the cockpit). However, earlier-model GPWS's were subject to false positives, and Nimitz Hill has a reputation for generating GPWS false-positives also. It is far too early in the investigation to speculate on what caused the crash. A number of `working hypotheses' (to put it *very* politely) have been advanced both in public and in private. So far, I have not seen one which is more-or-less consistent with the facts that are public so far. This itself is reason for caution - either some of the `facts' are misleading, or the accident will be very hard to explain. Readers interested in the details of the approach procedure may find them in an introductory article I wrote entitled `Flying an ILS or Localiser Approach -- An Example' <http://www.rvs.uni-bielefeld.de/abstracts.html#approaches>. The NTSB said early on that the crash has `all the earmarks of' controlled flight into terrain (CFIT). This is a description of an accident type, rather than an explanation of how it happened, but there are nevertheless often commonalities to accidents of a certain type. Over half of all deaths in commercial jet aircraft accidents in the late 80's/early-to-mid 90's were CFIT. The risk of CFIT on non-precision approaches such as the localiser-only ILS 6L into Agana has been estimated by research by the Dutch NLR (National Aerospace Lab), published by the Flight Safety Foundation, to be of the order of five times as great as the risk with precision approaches (such as the `full ILS'). The NTSB said that CFIT accidents usually involve some form of human error. Reducing the number of CFIT accidents has been a priority for aviation safety organisations in the 1990's. Readers interested in more background on CFIT, as well as why the Agana crash is a strong candidate as a CFIT accident, may be interested in my article `Controlled Flight Into Terrain: What Is Being Done?' <http://www.rvs.uni-bielefeld.de/abstracts.html#CFIT>, as well as the Flight Safety Digest 15(4/5), April-May 1996, which contains the Dutch report, at http://www.flightsafety.org/FSD1996.html Peter Ladkin, Universitaet Bielefeld, Postfach 10 01 31, D-33501 Bielefeld, Germany ladkin@rvs.uni-bielefeld.de +49 (0)521 106-5326/5325/2952
An article in this morning's _Globe and Mail_ in Canada reports on an unexpected side-effect of the craze for electronic pets [e.g., Tamagotchi, RISKS-19.20]. > Teachers seek humane gag as virtual pets enter classrooms > BY KIM HONEY, *Globe and Mail* > As thousands of children return to school with virtual pets in their > pockets, teachers are wondering how to silence the electronic lambs > without being held responsible for their deaths. It seems that many children develop strong attachments to their e-pets and can be seriously upset when their "babies" "die" due to lack of attention. Neglected e-pets also cause a problem in class by beeping incessantly until they "die." Teachers at some schools are warning parents that e-pets are inappropriate toys for children to bring to school. Such toys "have already been banned from some classrooms in China, Hong Kong, Thailand, Taiwan, Singapore, the Philippines and Britain." [Comment by MK: Some parents and others argue that taking care of e-pets is good training for life and teaches good values. If playing with this particular class of electronic game influences children's values, what then might we expect from children's exposure to hours a day of the pervasive violence and crudity of video games and television programming?] M. E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com
Re: people being called by loos, banks, vending machines... For reasons such as this, here in the US, it is illegal to autodial a number more than N times (I can't recall the value of N, but it is fairly small, on the order of 5 or 6 times) without some sort of human behavior to restart the process. Apparently, the phone company here in California takes this illegal-ness rather seriously: About 5 years ago, my phone here at work was the target of phones calls on the order of one every two minutes. There was enough clicking on the line to cause my voicemail to actually record 5 minutes of nothing for each such call, and it overflowed after 64 entries (nice small limit, that :-) ). Needless to say, I wasn't very happy about this, nor were my coworkers (who heard this ringing for 2 hours before I got in from the weekend). It took a while to get a trace, but once it was done, the offending line was found to be an ATM machine. I couldn't ever get the name of the bank, but the PacBell employee did inform me that they contacted said bank informing them of the problem. After two days went by with no action (ie, I was still getting phone calls, no return calls by the bank to PacBell, denying that the problem was theirs, etc) PacBell cut ALL phone lines to and from this bank (some 50 odd lines). The employee said "we figure they'll respond pretty quickly now." The Risk: if you do autodialing, better know the law! Tom Dowdy, Apple Computer MS:302-3KS, 1 Infinite Loop, Cupertino, CA 95014 dowdy@apple.COM
The nearest spelling checker at hand, ClarisWorks, offers "simper," "temper," "swampier," and "semipro" for "semper," and "fiddles" and "Fidel is" for "fidelis". (No kidding, capitalized and with the internal space.) If I deliberately misspell it as "fideles" then "fiddles" is the only suggestion... Daniel P. B. Smith dpbsmith@world.std.com [I had tacitly assumed that the incorrect "fideles" had been corrected to "fiddles" (a single-letter substitution), rather than the farther-away but correct "fidelis". PGN]
The federal statute can certainly be construed as covering the victim's expenditures — it speaks of "causes loss or damage to one or more other persons of value aggregating $1,000 or more". (Note also that the threshhold appears to be $1,000, not $5,000.) Some state laws are are clearer — California's computer crime statute make an explicit distinction between direct losses and reasonable expenses to assess the damage and repair it. A more interesting question is how valid the calculations are in this (or any) case. There's a long history of bogus numbers, such as the famous E911 case, where an improbably high figure was attached to the value of the purportedly stolen document. It was later discovered that it was for sale for about $13. [E911: Steve is referring to the Craig Neidorf case, RISKS-10.65,11.39,11.62,13.86. PGN]
This argument comes up a lot in the spam wars. Yes, if you read that part of the statute literally, the definition of a fax would include many computers, and the FCC has ruled that a computer with a fax modem is a fax for the purposes of the law. But it's extremely unlikely that a court would hold the existing statute to cover junk e-mail, much though we wish they would, because the intent of the Congress was quite clear, to regulate faxes, not to regulate e-mail. That sort of literalism is not popular in legal circles because it leads to silly results, e.g., "if your computer has a printer and/or scanner, sorry, we sent you this spam by mistake." The law also requires that all faxes contain the sender's phone number, which means that if e-mail is a fax, 99% of all e-mail is illegal due to lack of phone number. I have heard rumors that there may be a court in Washington State that was willing to stretch 47 USC 227 to cover e-mail, but I've been unable to pin down details, and in any event, until a case like that is appealed it has little precedent value for other courts. The Congress certainly could regulate e-mail similarly to faxes, which is what bill H.R. 1728 does. It's supported by many organizations including ISP/C, CAUCE, and Experian (the credit bureau formerly part of TRW). Visit http://www.cauce.org for more info. The risk here: although the law has a certain amount in common with software since both try to express algorithms, we propeller-heads shouldn't make the mistake of expecting the parallels to go too far. John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869 johnl@iecc.com, Village Trustee and Sewer Commissioner, http://iecc.com/johnl,
If it's true that an e-mail message counts as a fax under USC 47:227, then almost all e-mail is illegal, not just the junk, since the law also requires that the telephone number of the sending fax machine be included on *all* faxes (other things are required as well, some of which would seem to be impossible to do in e-mail). Phaedrus discussed the issue in RISKS-18.62 (http://catless.ncl.ac.uk/Risks/18.62.html#subj13). Keith C. Ivey, Washington, DC <kcivey@cpcug.org> http://cpcug.org/user/kcivey/
I thought RISKS readers, especially those involved in the development of secure electronic payment systems, would be interested in a paper entitled "Weaving a Web of Trust" by Adam Rifkin and Rohit Khare. IMO, it does a superb job of outlining the risks involved with not managing trust issues up front in the design and implementation of software systems being deployed on public networks. http://www.cs.caltech.edu/~adam/local/trust.html Mark Baker, Ottawa Ontario CANADA Java, CORBA, Agents, Beans distobj@acm.org mbaker@nortel.ca http://www.iosphere.net/~markb [The paper is in the World Wide Web Journal, an issue subtitled Web Security: A Matter of Trust, Summer 1997, vol 2, no 3. The entire issue is full of interesting contributions (including a published version of the report of the 11 cryptographers and computer scientists noted in RISKS-19.17,19). PGN]
In RISKS-19.34, MaxStern@aol.com reports the anti-junk-e-mail tactic of including e-mail addresses at the Federal Communications Commission and USPS in your .sig. The idea is that spammers who use lists of e-mail addresses compiled by sifting Usenet News articles will find themselves spamming these organizations. Max Stern pointed out that if this works it will be adding to junk mail, and will cause harassment of the individuals whose e-mail addresses you add to your .sig. Another possibility is that it won't work because of the current capabilities of spam tools. Two of the software tools currently on sale for automatically collecting e-mail from the net are designed not to collect any addresses that end .edu or .gov. All the addresses suggested in Max Stern's posting end .gov. Another tool on sale for the same purpose is designed not to collect any addresses whose username is postmaster, webmaster, abuse, or root. The risk of these capabilities in spam tools is that the people who have most influence on spam-related policy decisions will receive much less spam than the rest of us. Miranda Mowbray, Hewlett Packard Laboratories Bristol
Wait a minute. Is there any *actual evidence* that a cell-phone was responsible? The fact that there were several cell-phones in operation seems irrelevant. For example, last time a bulb blew in my house, there was a car driving past my house. I have heard of similar occurrences. Conclusion: Driving a car past a house creates a risk of a light bulb blowing!! As another post pointed out, if cell-phones are so dangerous to in-flight computers, how come I have never had a problem in an office with 20-30 computers of all types and at least a dozen cell-phones?? Are in-flight computers less resilient than Intel/MS boxes!!!!!!! Unless someone can demonstrate a causal link, there is a very serious RISK of give-the-dog-a-bad-name and automatically blaming cell-phones (or laptops, etc) for other really serious problems which don't get properly investigated. Given my experiences so far in life, I would be much more ready to blame a computer failure on the computer hardware/software than the poor, maligned cell-phone. Does anyone know of any studies that show evidence that cell-phones can do what they are acussed of. Has anyone actually done such a study? Ian Cargill CEng MIEE Soliton Software Ltd.
There are a couple of issues here, the first reason not to use cell phones in flight is that the 8/900 Mhz signals quite close to the frequency ranges used by DME (Distance Measuring Equipment) that forms part of the navigation system. The presence of a 3W transmitter close to the receiver may swamp the front end of the receiver and prevent or degrade signal reception. The second reason is that a cell phone used is flight is seen by cells for many miles and ties up frequency space on every cell that can see it (line of sight is a long way from 30,000 feet). FM radios are not allowed because they tend to re-radiate at a frequency equal to the tuned frequency plus the local oscillator which happens to come out in the 115 to 125 mhz region used for aircraft navigation and communication. Again a stray signal may block say an instrument landing system from being received. Computers have a different problem - the RF shielding is never as good as it could be once the machine leaves the factory, since they are full of square wave signals which include every odd harmonic (to infinity in a perfect case) they tend to radiate mush of a wide range of unpredictable frequencies. Are these risks high? probably not but given the current trend towards flying into mountains do you want to chance it? John Pettitt EVP & CTO CyberSource Corporation jpp@cybersource.com
I believe solar storms are a stream of charged particles, not electromagnetic radiation. They don't travel at the speed of light, so it's quite possible for a radio signal to get here ahead of them. The damage is done by the radiation that these particles emit when they arrive. Since light takes about 5 seconds to travel a million miles, and the system is purported to give us an hour (3600 seconds) warning, I'm guessing that the particles are traveling at about 1/700 light speed. What I was curious about when I heard the story is: what are we supposed to do during that hour? Given a couple of days warning before a hurricane you can tape your windows and/or evacuate. How do we protect against a solar storm, and can those protections be put up in an hour? Barry Margolin, barmar@bbnplanet.com BBN Corporation, Cambridge, MA [We received more mail on this point than ever before in the 12-year history of RISKS. Thanks to all who responded, much faster than the solar flares could reach us. PGN]
| I read an article today about a solar study satellite launched into | a gravi-stationary orbit around the Earth at the point where Earth | gravitation and Sun gravitation are equalized ... Not even close to equal, actually: the Sun's gravity at that position, called L1, is about 40 times the Earth's. If the Earth was not present, an object in the satellite's orbit would go around the Sun once every 51 weeks or so. The significance of the L1 point is that the Earth contributes *just enough* of a pull to slow down that period to exactly 1 year, creating a fixed relationship of Earth, Sun, and satellite. | The satellite is to study solar winds, flares, and particle streams. | The article proclaimed the satellite would "give us a one hour warning of | solar storms that would otherwise not be available ..." [But how is this | possible if the solar radiation, like the radio from the satellite, | travels at the speed of light?] Because it doesn't. The radiation of concern in this case is not electromagnetic, but streams of charged particles. A moving charge generates a magnetic field, and the powerful effects of a solar storm can lead to large distortions in the Earth's feeble magnetic field. The streams do indeed travel at nearly 1,000,000 mph, but this is only 1/700 of the speed of light; so the one-hour warning is quite right. Kathy A. Svitil wrote a 1-page article on this in the June "Discover", p.36. Mark Brader, msb@sq.com
> years 00-38 are treated as 2000-2038 instead of 1900-1938). The problem applies *only* to people who decide to *input* two-digit years (such as 2 Sep 97). This isn't a Y2K problem per se because it can happen at any time, and has been going on for years in Tcl and many other systems -- witness the many stories of 105-year olds being sent info on kindergarten). Tcl/Tk is no worse (or better) than other code in this respect. AFAIK, all dates converted in this way (or any other) are stored internally as Unix integers. Of course, they're subject to the well-known Y2038 problem when Unix passes 2**31 seconds since Jan 1, 1970 (but that's a different story). Prof. Ethan L. Miller, U of Maryland Baltimore County, CSEE Dept, 1000 Hilltop Circle, Baltimore, MD 21250 +1 410 455-3972 elm@umbc.edu
> Lloyd> "There are also a few other minor incompatibilities in Tcl 8.0 > Lloyd> and Tk 8.0: [..] 2.2-digit years are now parsed differently by (that's Point Two: 2-digit years, before anyone with 2.4 children gets any funny ideas.) [2.2 spaced out!? PGN] > The problem applies *only* to people who decide to *input* dates with > two-digit years (such as 2 Sep 97). In other words, all users. (Users do the darnedest things.) > This isn't a Y2K problem per se because it can happen at any time, as do Y2K problems; note previously-reported problems with future expiry dates. Variable product lifetimes mean that a Y2K problem will occur at any time. > and has been going on for years in > Tcl and many other systems - witness the many stories of 105 year olds > being sent info on kindergarten). so _that's_ why they call it 'second childhood'! > Tcl/Tk is no worse (or better) than > other code in this respect. Changing expected behaviour and going against user assumptions that have been built upon prior experience is an even bigger risk than Y2K, IMO. Handling the input unexpectedly before it gets to the script is dangerous - compare with the previously-discussed Javascript tendency to treat numbers with leading zeroes as octal, for instance. (Incidentally, the Javascript Date object has its own problems - e.g. in 1.0 'You cannot currently work with dates prior to 1/1/70' and this legacy problem will eventually catch someone.) <L.Wood@surrey.ac.uk>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641
Because most of the Unix world still uses 32-bit timestamps in the range 1970-2038, this is perhaps much less of a RISK than it seems at first. The real RISK is that not much will be done about that until at least 2035. Furthermore, Solaris 2.5.1 defines time_t as a C "long" which is currently 4 bytes. When 64-bit operating systems finally catch on there will be a lot of code to change when "long" becomes 8 bytes, while the data on disk is still only 4. On another note, Java seems to be limited to the Unix date range (1970-2038) even though it is a new language defined near the end of the century. Jeffrey Anderson-Lee System Manager, Digital Library Project, University of California, Berkeley
Please report problems with the web pages to the maintainer