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 talked with Alan Pollock at the National Transportation Safety Board in Washington DC on March 4. The investigation is being conducted by Dominican Republic with `full participation' of the US NTSB. The Dominican Republic civil aviation authorities asked the NTSB to make available some information after a preliminary review of the Cockpit Voice Recorder (CVR) and Flight Data Recorder (FDR) information.
[Summary of official information]
The CVR and FDR were taken to the NTSB on February 28th. A preliminary review was conducted on February 29th. The quality of the data was good. The crew discussed airspeed indications early during the takeoff roll and after takeoff. While climbing through 7300ft, the stick shaker sound was heard, the aircraft started to descend and the stick shaker sound continued for about 84 seconds until the end of recorded data. Recorded airspeed at stick shaker activation was 335kts. Ground-based radar and other FDR data indicated a much lower airspeed. The data are consistent with proper functioning of flight controls, engines and thrust reversers. There is no evidence of any unusual weather event or external forces on the aircraft. Investigation is continuing.
[end of summary]
The `stick shaker' is a device which `shakes' the control stick when lift begins to degrade to let the pilots know of an impending aerodynamic stall. It really gets your attention, quickly, not to speak of raising the adrenaline level.
Courtesy of Robert Dorsett, I understand there are three independent airspeed indication systems in the B757: two electronic and one mechanical backup. It's unlikely in the extreme that all three were faulty. Pilots are trained to deal with faulty information (I've had an airspeed indicator fail, I had only one system, I'm not a professional pilot). Since controls were functioning normally and there was no indication of outside disturbance, I would think it's likely that there was no relevant airfoil contamination or misfunction. One could further conclude from this that the recorded 335 knots is likely not the actual airspeed at time of stick shaker activation.
This raises two issues which will presumably be addressed by further inquiry. First, why did airspeed drop: is it because the pilots appeared to be following faulty airspeed information; if so, why were they doing so? Second, was recovery initiated by the pilots at stick-shaker activation: if not, why not; if so, was 7300ft altitude sufficient to recover in the actual situation, or did other factors inhibit recovery? Answers to these questions will probably lead to other questions.
The full text of the February 7 FAA press release and the March 1 Dominican Republic Factual Information from the NTSB is contained in my compendium `Computer-Related Incidents and Accidents with Commercial Airplanes' at
http://www.techfak.uni-bielefeld.de/~ladkin/
(The name of the compendium changed since the scope is broadening somewhat.)
I have made the claim that the nature of Internet opens it to various forms of deliberate damage and also to inevitable processes of decay and stale information. These latter two issues are important because anything that increases the amount of bad, stale data in the system tends to provide incentives for more robotic programs and automated mechanisms for use in screening. These devices have their own problems, in particular their ability to generate large volumes of traffic which then become loads on the system and problems for human operators to sort out. When ill-intentioned people are added to the mixture, it is possible to have really unpleasant things happen. PGN's lead item in RISKS-17.83 is a case in point.
The value of access to a data channel is partly a function of the signal to noise ratio of the data channel. As the S/N falls there are incentives to use more sophisticated filters to extract signal from noise. In analog systems these noise filters have well defined, if often undesirable, characteristics. In the digital realm, the behavior is more difficult to characterize, especially when the filter design is closely matched to expected nature of the signal being filtered.
The growing use of these filters necessarily marks the Internet as a thermodynamically inefficient process: it is always less efficient to filter after the fact than it is to clean the signal before. (The problem, of course, is that those who bear the cost of filtering at the tail end are not those who would bear the cost of producing a really clean signal at the front end!)
Of course, the net has been successful to date largely because the information placed there has been of known quality and those involved with the network have been restrained by storage limits, the originating group's culture, etc. In this way there has been a historically high S/N, which makes searches and conversations relatively low effort and high yield.
The English economist Gresham's name is attached to a "law" of monetary systems that says "Bad money pushes good money out of circulation." Bad money refers to paper currency, which is easily debased by printing more. Good money refers to coin minted from precious metals, the value of which remains relatively constant. When paper currency is debased, people tend to hoard their coin and the paper circulates, hence the law.
I modestly propose Cook's law (named after my Mother) which is "Bad data drives good data out of circulation." Here the bad data is the easily collected, easily stored, largely meaningless collections of characters that we see in so many areas (e.g. medical records) that are making the value of effortful contributions (e.g. thoughtful summaries of the relevant details of a patient's clinical history and current state) hard to find. I claim that they are hard to find in part because the other things in the chart constitute a form of noise that makes extracting the signal hard, and in part because the value (and incentive) for creating them is largely lost in the blizzard of other material. Interestingly, the electronic medical record has been accompanied, in many places, by an underground paper system that isolates relevant information from the electronic data in ways that make it easy to generate and retreive, at least in the context of daily activity. We see this especially in the ICU and operating room where informal records are made on slips of paper, pieces of adhesive tape, etc.
As the electronic medical record accumulates more data there will be a major effort to raise the S/N level via information filters not unlike the robotic devices now being developed to cope with the falling signal and rising noise levels of the Internet. Humans will attempt to isolate high signal-low noise areas by using manual paper methods and hoarding the paper and by constructing within the electronic environment, vaults with access that is economically or organizationally restricted to those with incentives to maintain high S/N.
Richard I. Cook, MD ............. Cognitive Technologies LaboratoryAs a Macintosh user and Netscape user, I've been waiting anxiously for an implementation of Java for the Mac. Netscape finally released their beta 1 version of their browser with Java implementation about ten days ago, and like all fans of bleeding-edge technology, I downloaded my copy the moment I heard about it. There are many problems that can be attributed to such an early version of the program, I noticed one particularly grievous oversight: the lack of a provision to turn Java downloading off.
Volunteer Beta testers have to be willing to deal with many problems, but being unable to evade such a well-documented and easily avoidable security risk shouldn't be one of them. I hope this is a problem that Netscape fixes in their next beta release.
AjD adelano@frymulti.com http://www.frymulti.com/~adelano/Netscape and possibly other (future?) Java-enabled browsers do not allow for system-wide defaults. They should allow for System Administrators to not only set defaults for users, but to also override user preferences. This would allow the Administrator for a system to disable (for example) Java or JavaScript system wide.
The risks in not having such an option?
Assuming Java is bullet-proof.
Java is the type of program that has potential security holes in it as it allows someone to run programs on a machine they do not necessarily have any real access to. It is well designed to reduce the risks, but like any new program, there are bound to be bugs.
Patches are nice, but there is no way to insure that everyone would be running the new version. If the browser allowed preferences based on version number, one could disable Java for buggy versions, but allow it for patched versions.
Topic: Java Implementations Can Allow Connections to an Arbitrary Host
The CERT Coordination Center has received reports of a vulnerability in implementations of the Java Applet Security Manager. This vulnerability is present in the Netscape Navigator 2.0 Java implementation and in Release 1.0 of the Java Developer's Kit from Sun Microsystems, Inc. These implementations do not correctly implement the policy that an applet may connect only to the host from which the applet was loaded.
The CERT Coordination Center recommends installing patches from the vendors, and using the workaround described in Section III until patches can be installed.
As we receive additional information relating to this advisory, we will place it in
ftp://info.cert.org/pub/cert_advisories/CA-96.05.README
We encourage you to check our README files regularly for updates on advisories that relate to your site.
I. Description
There is a serious security problem with the Netscape Navigator 2.0 Java implementation. The vulnerability is also present in the Java Developer's Kit 1.0 from Sun Microsystems, Inc. The restriction allowing an applet to connect only to the host from which it was loaded is not properly enforced. This vulnerability, combined with the subversion of the DNS system, allows an applet to open a connection to an arbitrary host on the Internet.
In these Java implementations, the Applet Security Manager allows an applet to connect to any of the IP addresses associated with the name of the computer from which it came. This is a weaker policy than the stated policy and leads to the vulnerability described herein. [...]
If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). [...]
CONTACT cert@cert.org +1 412-268-7090 (24-hour hotline)
Location of CERT PGP key: ftp://info.cert.org/pub/CERT_PGP.key
CERT personnel answer 8:30-5:00 p.m. EST (GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax +1 412-268-6989
CERT Coordination Center, Software Engineering Institute
Carnegie Mellon University, Pittsburgh PA 15213-3890 USA
To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request@cert.org
CERT publications, information about FIRST representatives, and other security-related information are available for anonymous FTP from ftp://info.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce
Copyright 1996 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included.
CERT is a service mark of Carnegie Mellon University.
[See full CERT bulletin for further details. PGN]
Following the suicide bombing in Tel-Aviv, Israel yesterday, the local telephone exchange was reported to have "collapsed" due to overload. In the report I heard, "collapse" was not defined.
To better understand this, it is helpful to know that Israelis are acutely aware of goings-on. Israelis are major users of cellular telephones; terrorist attacks are reported nation-wide literally within minutes.
I was in Jerusalem last week, very near 2 terrorist attacks. After the first, friends and relatives called from out of town, recognizing that I was nearby, to inquire if all was well. The following day, I went into town, boarding the bus exactly when another terrorist attack occured at a nearby intersection. As usual, it was reported on the radio within minutes, while I was still on the bus. I got off two stops later and used a public pay phone to call my home-base, to notify them that I was OK.
I'm not a telephony expert, but with such `social conventions', it is conceivable that a major telephone exchange can collapse by overloading.
Jake Livni jakel@eos.bony.com> Excel version 5.0 on the PC does work for 2/29
This is true. And Excel version 5.0 knows that the year 2000 is indeed a leap year (see RISKS-17.83). It is very clever. Actually, it also "knows" that the year 1900 was a leap year. But it wasn't...
The program also doesn't appear to handle dates that are not in the 1900's or 2000's, so I couldn't check 2/29/1800 or 2/29/2100 or 2/29/2400. Of course,
we'll all be using stardates by the time the year 2400 comes around.
In each version of Excel that I've examined, the 60th day of the calendar is 29 Feb 1900. Set a cell's format to "date" and type in 60 to see for yourself. This means, of course, that computations such as "number of days between x and y" where one or the other date is in early 1900 will be wrong. Fixing the bug is also RISKy because that would change the date interpretation of all ordinal dates greater than 59, in turn making every existing spreadsheet involving a date compute or display something unintended. Thought experiment: would YOU fix this bug if Excel were your product? How?
-- Carl HauserA similar situation happened to me. A heavily time-dependent system I wrote and maintain utilizes a code-file library to translate between Universal Time and the user's local time, in this case, Eastern Australia Summer Time. A problem reported by my customer originated in the code-file library. The person who supports the code-file library diagnosed a bug that is triggered by the switch from Summer (Daylight Savings) time to standard time.
"But that switch isn't supposed to happen until the end of March!" True, but *last* year, it happened at the *beginning* of March, and the code-file library had not been bounced since the new parameter file, containing this year's switch date was put into place, so it still thought the switch was on 3rd March.
I suspect a similar situation is what caused Steve's glitch. The risk, it seems to me, is in allowing local governments to futz around with the switch dates on a whim, rather than setting a firm rule for when to switch. On the other hand, the risk may be that users expect computers (or software, or programmers) to be able to predict with any accuracy, what various governing bodies' decisions will be, long before those bodies even consider the question.
Following my previous post on the Sydney WIN95 daylight saving fault, I today attended PC 96 (a large trade exhibition). Microsofts stand had many linked PCs running WIN95 & NT. And guess what... all running 1 hour late!
I tried to get some idea of a fix for the faulty data but all I was offered was "change the clock", "The state government changed the law after the release" and "were looking into it"!
The risks here are that even the suppliers didn't seem to know there was a problem! or if they did they didn't tell themselves!
Who supplied the data for the release? Didn't they notice when the law changed?
What about future changes?
The parameterization data sits in the WIN95 Registry as a hex string, it seems to me that the least Microsoft should do is document the structure of this string.
Steve Elliott, NORESE Pty. Ltd. 4, Glassop St., Balmain, NSW 2041 Australia +61 (41) 12 608 12 selliott@world.net Fax: +61 (2) 555 7911["David Moss, Application Development Centre, +61-2-561-6532, DTN< 730-6532 <moss@aussie.ENET.dec.com> responded to Steve Elliot's earlier posting, observing that ``the legislation relevant to Daylight Saving Time in Australia has evolved faster than computer system manufacturers have been able to (or maybe bothered to?) implement the new rules.'']
As an Australian living in the US I can relate to Windows 95's woes. I have an Australian calendar sent to me each year so I can keep track of local holidays and events such as these.
My calendar said that the changeover would be at March 3. When I last phoned home, I checked and found that the calendar was wrong. The calendar happens to be the Australian printing of the Far Side Desk Calendar.
This raises one RISK and one amusing possibility:
Risk: The information used was incorrect in the first place and is relied upon by numerous sources. The validation was done and performed correctly on this wrong information. (GIGO).
Amusing Possibility: Microsoft uses a Far Side calendar for their research.
I also hope that the Australian product support for Microsoft realised what the problem was early enough to help people. But from the sounds of it the detection was not early enough to provide a patch.
David Morgan, Interactive Software Engineering, 270 Storke Rd, Suite 7, Goleta CA 93117 USA +1 (805) 685-1006 davidm@eiffel.com http://www.eiffel.com> The Orion flaw was discussed by Intel on 29 Feb 1969.
A premonition?? Or has the discussion on leap years gotten out of hand??
[TNX. I am delighted people read RISKS so diligently. I received quite a few jokes on that slip-up. I fixed it in the ftp.sri.com archive copy, for future generations. PGN]
About 25 years ago, I found a remarkable bug in the "midnight routine" of a program designed to run continuously 24 hours a day, 7 days a week.
In the New Year's night of any leap year, this routine stored the value 29 for February in the table of month lengths (located in the main memory). The bug: this variable was calculated two months before it was actually used; if the program would have to be restarted (for any reason) within January or February of a leap year, the length of February would have been reset to its initial value, viz. 28, and the program would have produced garbage, on 29th February.
Fortunately, this particular bug did not go into the production version of the program; otherwise it could have remained undetected for several years.
The RISKs?
/* Peter, many apologies. I left *not*s in where I shouldn't.
Long held beliefs overriding new-found knowledge and fingers.
*/
[Ah, yes, the (k)nots unravel. To make a short story much shorter than
the mass of messages I received on this one, Dale's message was really
ambiguous to me and I probably added to the problems by not insisting
that he clarify everything before running the item, and worse yet, trying
to figure out what he *really* meant. Digital of course had it right.
But the IBM system User International (Issue 19, Nov. 95), reference
does seem to have it wrong! PGN]
I few years ago I wrote some code (for a database reporting tool) that tried to understand time in various ways. My conclusion was that time is a pain in [***] to deal with in computer programs---it is always a special case.
[Omitted discussion duplicating some of RISKS-17.83, but based on year = 365.2422 days.]A 365 day year comes out .2422 days short. Every four years, this is 4(.2422) = .9688 days short, so an extra day is added. However, that means
<> [...] the length of the tropical year is 365.24219 days. ...
I suggest:
> I hope someone decides well in advance, to permit the programmers to get
> ready.
Seems unlikely to me.
JanYou forgot to credit *the* authoritative source for the leap year rules - Kernighan and Ritchie's "The C Programming Language", section 2.5, which even gives us a code fragment. Woe be unto programmers who can't cut and paste a couple lines off paper. (Porting to Cobol is left as an exercise to the reader.)
Gary Koerzendorfer, Systems Technology Division, Hewlett-Packard Co., 19447 Pruneridge Ave., Cupertino Calif 95014 garyk@cup.hp.com (408) 447-4783In C, rendering of the formula is:
leap_year = (year % 4 == 0 && !(year % 100 == 0 && !(year % 400 == 0)));
For posterity, here is (correct!) C code to compute whether "y" is a leap year or not. As PGN notes, this will have to change sometime probably in the next 10,000 years to account for the 3 day/10,000 year discrepancy. I don't have a reference for this, but I did do copious literature checking a few years ago when I was frothing at the mouth about this subject. I suppose you could count me as an expert because, (a) I'm an astronomer, and (b) I worked at a Planetarium and this was one of the relatively common questions asked, that our staff needed to know the correct answer to.
The more understandable version of the code comes first. Note that it is easiest to start with the *longest* periodicity, i.e., the 400 year one, and then move down to the smaller period cases. This ensures the longest period ones don't get lost in the "if it's mod 4" case.
typedef unsigned char Boolean;
enum _boolEnum { false=0, true=1};
Boolean IsLeapYear(int y)
{
if(y % 400 == 0) return true;
if(y % 100 == 0) return false;
if(y % 4 == 0) return true;
return false;}The more compact macro version is:
#define ISLEAPYEAR(y) ((y) % 400 == 0 || ((y) % 100 != 0 && (y) % 4 == 0))Finally, note that if you are really lazy and willing to put off your buggy software for another 100 years, since 2000 is a leap year, then you can use
#define CHEAP_LEAP(y) ((y) % 4 == 0) /* fix before 29 Feb, 2100 */between 1 Jan 1901 and 31 Dec 2099.
[Actually, because 2100 is *NOT* a leap year, it better be fixed before the end of 28 Feb 2100. The above code is correct; the comment is misleading. Note added in archive copy, inspired by a message from Wayne, 15 Jul 1997. PGN.]
You may have heard enough on this topic, but the Explanatory Supplement to the Astronomical Almanac (ed P. Kenneth Seidelmann, US Naval Observatory, 1992) [...] notes the problem raised by PGN in RISKS-17.83 — that eventually adjustments will be needed — and states that although various such adjustments have been proposed, none has been instituted. It also raises the interesting point (in section 12.13) that the U.S. legal code specifies no official national calendar. Our use of the Gregorian calendar stems from a 1751 Act of Parliament of the U.K.
Steve Thorsett Physics Dept Princeton UniversityPlease report problems with the web pages to the maintainer