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…
UUPC/extended is a mail system for personal computers running MS-DOS. (The
name is a pun on UUCP.) On Leap Day, Saturday, 29 February 1992, UUPC's UUPOLL
program, which polls a remote system for mail at regular intervals,
consistently hung the PC on which it was running. One workaround was to set
the system clock ahead a day to 1 March.
Drew Derbyshire, the author of UUPC, traced the problem to a bug in the
mktime() library function in Borland C++ 2.0, which converts a time to calendar
format. Drew demonstrated that mktime() will hang a PC on Leap Day, and
reported the problem to Borland. As distributed, UUPC is compiled with Borland
C++ 2.0, though source code is available for do-it-yourselfers. Apparently,
Borland has issued a corrected version of the library function (I haven't
verified this).
Drew tried to warn UUPC users by mail after discovering the problem on
Saturday. Ironically, many did not get the message until Sunday or Monday,
when they found their PCs hung in UUPOLL.
Roger H. Goun, Digital Equipment Corporation, goun@ddif.enet.dec.com or
goun%ddif.enet@decwrl.dec.com, {pacbell,pyramid,uunet}!decwrl!ddif.enet!goun
From the N.Y. Times News Service, 3 March 1992 (I saw it in the SanFranChron): Intel Corp. said Monday it had stopped shipping a computer network software program because some units were found to be infected with the ``Michelangelo'' virus, a program that infects IBM and compatible personal computers and can potentially destroy data. A division of Intel in Hillsboro, Ore., said it had shipped more than 800 copies of the program, called LANSpool 3.01, which inadvertently contained the virus. The virus is designed to activate on March 6, Michelangelo's birthday, and can erase data and programs if it is not detected with antiviral software. The company said it had checked its software with a virus-scanning program before shipping it, but that it had failed to detect the virus. A number of computer makers and software publishers have issued similar alerts about the Michelangelo program and a variety of companies are now offering free software to check for the virus. There are more than 1,000 known software viruses that can copy themselves from computer to computer by attaching to programs and files.
>Sigh... Sorry, but this is FALSE! The Michelangelo virus attacks any IBM PC
>compatible computers. There is no need that they are MS-DOS machines. You can
>get a 80386 and install only Xenix on it, without any MS-DOS partitions.
That's a pretty amazing feat, since to do this, it would have to a) be a UNIX
(or XENIX) binary, not a DOS binary, b) somehow get root access on the machine,
c) figure out which device is actually the disk, and then d) munge it (d is, of
course, the easiest part). Even if you run it under a DOS emulator, it is
usually configured such that a DOS program cannot access any random device, or
open up a disk drive (e.g.., it provides a pseudo-disk, for programs that like
to just open up the disk under DOS themselves... but it cannot open up, say,
/dev/root unless /dev/root available via normal permissions to the person who
started the program).
I think you are seriously confused about things, and I will continue to
believe that until I see proof otherwise.
Sean Eric Fagan
| Sigh... Sorry, but this is FALSE! The Michelangelo virus attacks any IBM PC | compatible computers. There is no need that they are MS-DOS machines. You can Incorrect. The virus CAN affect machines that run Xenix or UNIX, but ONLY if they are booted from MS-DOS with an infected floppy disk. UNIX filesystem and program mechanisms, even on UNIXes that support "mounting" of MS-DOS floppies, will not permit the Michaelangelo virus to install itself under UNIX or Xenix. The worst that can possibly happen is that a VP/ix or DOS-Merge partition will be infected, but *if it is only used under VP/ix or DOS-Merge then the primary boot track will not be affected because VP/ix and DOS-Merge will not allow it to be accessed*. Misinformation about viruses is yet another RISK that must be considered. I've encountered an article on Usenet from someone who thought (erroneously) that ALL computers would be affected (perhaps due to the events detailed in the original RISKS submission?). This further claim that the virus can somehow install itself on computers that are never booted into MS-DOS is just as incorrect. Brandon S. Allbery, KF8NH [44.70.4.88] allbery@NCoast.ORG Senior Programmer, Telotech, Inc. (if I may call myself that...)
Lawyerspeak from hell. Two questions:
<> b. The Program is to be used only in connection with a single computer.
Isn't this kind of stupid in the license of a program which is
fundamentally most useful in a networking environment? Or, since
licenses are free, should I get a few licenses for myself, in case I
happen to want to run it on multiple machines?
<> d. You may not translate the Program into any other computer language.
Including RTL, or assembler? Darn. Can't compile it, then.
RISKS of boilerplate legalese?
Marc
Good points. We'd happy to receive comments on the legal agreement, since there aren't many things like RSAREF to compare against. We were aware of the "lawyerspeak" on the number of copies; it's pretty conventional, and we don't intend to keep anyone from storing more than one personal copy for personal in a network environment. But we wanted to start with conservative language. On the issue of translating into another language, your observation "Can't compile it" is a good one ... But of course you can compile it. Let's see if we can work out some better language. I invite you to join the RSAREF user's group <rsaref-users@rsa.com>, which will discuss issues such as the license and help us improve things. To join, send email to <rsaref-users-request@rsa.com>. -- Burt Kaliski, RSA Laboratories
Chris Hibbert (xanadu!hibbert@uunet.uu.net) is correct that I misinterpreted
the AVI spec in one important way. The spec no longer calls for a VIN to
be transmitted (the term VIN no longer appears in the spec) but rather the
transponder's unique 32-bit code (see section 1705.5(e)(1). (I was misled by
the retention of the term "AVI".) This is a significant improvement PROVIDED
that transponder id's are not indexed against VIN's (or SSN's etc) when the
transponders are sold or installed. The transponder is still to be fixed to
the front bumper (1705.3, 1705.8), as opposed to being bought at 7-11 and kept
in one's glove compartment. Whoever does the installing or collects payments
will probably have enough information to register the transponder by VIN or
license number. And this doesn't even count future uses of the transponders
(e.g., 1702.1); future Transaction Record Formats could contain the VIN or
just about anything else. Thus it is true that "The new draft doesn't leave
room for an identifier of the vehicle or the driver in the communication
packets", but it is also misleading.
I was unclear with regard to the issue of extensibility. Earlier versions
did mention the possibility of extension, but the latest is much more explicit
on the subject. It is also more careful about separating out AVI-specific
features from the underlying generic device.
A number of people have corresponded with me about how one might implement
toll collection without requiring every car to carry a transponder. My real
complaint had to do with the whole notion of a "spec". Chris says that "The
spec doesn't talk about [the broader process of toll collection] because it's
not part of the technology being designed." But this is only true on the
narrowest possible definition of "the technology being designed". More
socially relevant definitions are possible.
The folks proposing the Privacy Act reprinted in recent Risks issues are aware
of these issues and seem sincere in their desire to protect privacy. But I am
horrified by Chris' report that:
Some [Caltrans folks and vendors] are willing to say that they expect
"other forces" (maybe DEA or INS?) to try to make this kind of equipment
usable for tracing people's movements. There may have been attempts to
make this be standard equipment on new cars.
The atrocious record of the DMV and the reputed attitude of Caltrans provide
little comfort, and it would take a small twitch of California politics to put
all the Senator Lockyers on the street in a few years. If personal tracking
technologies cannot be made inherently resistant to civil liberties abuse then
they should be banned.
Phil Agre, UCSD
It sounds like you are the victim of two human errors and one piece of
odd coincidence. First, your mail carrier incorrectly decided to place that
mailpiece in a change-of-address bin. Then, the change-of-address mail
was passed Computer Forwarding System (CFS) where the seven digits
you described were typed in. By coincidence, there was someone on your
carrier's route (or the wrong carrier route was typed in) with certain address
similarities who had recently moved (I believe information is maintained for
1.5 years). Finally, the person who applies the yellow label is supposed
to check the name and apparently didn't.
Seven digits are usually sufficient because mail typically doesn't get to the
CFS unless the mail carrier is aware of an address change. Quality control at
the final step was probably lacking for the typical reasons (working too fast,
fatigue, boredom, etc.).
Craig
> The risk is not so much that the logs are made, but more that the service
> is presented as "anonymous", leading people to believe that it actually is.
By his tone and statements William Rucklidge shows himself knowledgeable
about various logging techniques, both administrative and security-oriented,
as found on many networked hosts, So, what bothers me? Two things...
First: Network application protocols have evolved over 15 years and more.
FTP has ALWAYS been a man-in-the-loop protocol. The FTP-user must use a
(different on each, we pray) valid ID/PW combination on each of the SOURCE
and TARGET hosts; i.e., must be able to log on or in to each host to migrate
any file from SOURCE to TARGET. Various host administrations realized it
would be of value for a given SOURCE host to make certain files/directories
widely available, without having to register huge numbers of users. Result:
ANONYMOUS FTP, in which the valid ID/PW combination on the SOURCE host only,
and for a limited file or directory set, reduces to an advertised pair such
as "anonymous" and "guest", or "anonymous" and "any-non-null-string", etc.
The meaning of 'anonymous' here is NOT that no one logs such a transaction;
rather, that the user can obtain files without being a registered user of
the SOURCE host. 'Anonymous' here equates to convenient, not unidentifiable.
Second: William Rucklidge implies, maybe even states, that a widely-known
Internet host permitted itself to be an anonymous FTP TARGET. I hope not!
However, even if the MBDF-A virus was migrated TO a TARGET host by someone
using a registered ID/PW combination, that indicates a breakdown of trust
at some point. Perhaps the (SOURCE or) TARGET host administrator did not
know his user. Perhaps the user shared his ID/PW combination. Perhaps
someone or two stole an ID/PW combo. I don't know, and my speculations are
ignorant and dangerous. My point: host and network use is built upon and
dependent upon trust. Trust is a fragile thing, the substrate of cooperation.
William Rucklidge, writing from a host apparently at the site where the two
people alleged to have spread the virus were arrested, seems to imply that
'anonymous' ought to mean unidentifiable. I hope I misinterpreted what he
wrote. In any society built and dependent on trust, such as our Internet,
a user should NOT want anonymity, not even as a matter of FTP convenience;
surely, NEVER as a mechanism for evasion.
Mike Pabrinkis, Naval Surface Warfare Center, Dahlgren, VA 22448
(703)663-7743 (AV)249-7743 <mpabrin@relay.nswc.navy.mil>
If the rate of descent was really 3,300 feet per minute, as reports suggest, then 200 ft gives 3.636 seconds before impact, assuming flat terrain. I do not have information about the terrain. Allowing two seconds to react, is this enough time to go around? I believe that go-arounds can be executed from a few feet, *if they are expected*, and if the engines have not spooled down. I wonder what the tolerance on the 200 feet is, and what the allowable delay in generating the message is? The slant angle of the beam will affect the actual height at which 200 ft is measured, unless this is corrected for. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk
It's wrong to assume this is really a crash-alert system, like a GPWS. It's designed for use with an airliner flying a normal approach. Confused? Allow me explain! In a normal airplane, duties are divided between pilot flying and pilot-not- flying. Pilot flying flies the approach: manipulates the control column, throttle, autopilot, etc. Pilot not flying handles radios, checklists, navigation, systems, etc. During the last few minutes of the approach, he makes call-outs: decision height (when one has to go around if the runway's not in sight), and a variety of standard altitudes (1000', 500', 200', 100', 50', etc). All "above ground," as opposed to regular altimeter readouts, which are usually "above mean sea level." (exception being the radio altimeter, which always displays distance above the ground immediately underneath the sensor). I can really digress on this point, if pressured. :-) The call-out practice is intended to enhance the situational awareness of the pilot flying the airplane, as well as the crew as a whole. The exact call-outs are normally subject to airline policy and the approach being flown: some are very superficial, while others have call-outs at practically every 20 feet. During these call-outs, it is assumed the airplane would be in the "safe" GPWS envelope, since it's flying a normal flight path, presumably over level terrain at this point, and bumping into a sloping mountain isn't much of an issue. GPWS doesn't know the difference between an airport boundary and a cornfield, and it would be irritating to have a major warning every time the airplane simply passes a threshold altitude. On the A320, of COURSE, the call-outs are automated, freeing the F/O to do other things. The system makes all call-outs, including one just before touchdown, reminding the pilots to activate the thrust reversers, by yelling "RETARD!" You can bet this improves the self-esteem of the pilots. :-) So, again, this is all pretty irrelevant to the Strasbourg crash. The system isn't a warning or caution; it's just advisory. Whether we want the system to be *automated* is another question entirely, though. As stated, the practice is designed to improve crew communication. The whole idea behind call-outs is to verify that pilot A flying the airplane is thinking the same thing as pilot B, who is making the call-outs. All automated call-outs accomplish is to verify that Pilots A & B both *independently* agree that the computer knows what it's doing; they may then grow to rely upon its accuracy, and on the other pilot to cross-check his own instruments. Automated call-outs are yet another interesting new dimension on the functional social atmosphere and professionalism of the cockpit environment. Another practical consideration is that, considering the human factors problems of tape-style instruments, which provide the altitude and airspeed indications on the A320, I think it would be a good idea to keep the PNF calling out the altitudes, rather than rely on the radio altimeter computer. Especially when one considers all the approaches that DON'T have a nice, smooth field for miles around the airport, but rather are on mountains, near cliffs, etc., and will cause the radio altimeter to think it's much higher than it actually is. A human pilot could cross-check with the barometric altimeter; the computer is designed to work with the radio altimeter. As for the three seconds they may have had on the Air Inter, and what they might have done with them: who knows? If they were in a cloud, they'd be inclined to believe their instruments and continue flying the airplane, checking secondary sources for confirmatory information. And there goes the three seconds. On an airplane which is prone to spurious warnings, they'd probably ignore it, especially if they think they're at 8,000', 3000' above their target altitude, which, in turn, is a couple thousand feet above the maximum terrain elevation for the sector. And then there's the good possibility they had much less than three seconds, since, even though they were descending at 3000 fpm, they were also going forward at 180 knots or so. Pete's comment of 1 second tends to support this idea. As an aside, good pilots do not yank back on the controls and perform dramatic maneuvers every time a light goes off: more accidents have been caused by that sort of behavior than otherwise. There's an old story of an astronaut — Gus Grissom, I believe — who was suddenly presented with a rather dramatic array of warnings while on the pad. Rather than start flipping switches instantly, as training required, he took a second or two to get his bearings, and study the situation. In that period, the systems reset, and the warning lights went out. He's commented that if he HAD started doing things instinctively, he could have REALLY got himself into a lot of trouble. I suppose there's a moral there for systems that perform automated tasks on the basis of immediate data--and don't give the pilot the final authority to correct those mistakes, when spurious data corrects itself or is identified. GIGO rules. Just my $0.02. Robert Dorsett Internet: rdd@cactus.org UUCP: ...cs.utexas.edu!cactus.org!rdd
Just a comment on the function of callouts. In any airplane, automated or not, callouts on the final approach do more than ensure that both crew members share a notion of what is going on. Flying an approach is a visually intensive task for the pilot flying regardless of the weather conditions. An auditory callout by the PNF provides the pilot flying with important information in a sense modality that is not already heavily loaded. United Airlines, for example, mandates a callout at 500' above touchdown that includes the radio altitude, the descent rate, and an indication of speed relative to the target approach speed. For example, "five hundred feet, seven down, plus four" would mean seven hundred feet per minute descent rate, and four knots above target approach speed. When you are trying to pick up the approach lights in broken clouds and would like to transition from instruments to outside references, it is real nice to learn (without having to look) that you are on path, with an appropriate descent rate and a have few knots of speed over the target. If any of you find that the first recommendation of the commission report translated by Peter Mellor smells suspiciously like a commitment to a cause for this accident, you might be interested to know that Northwest Airlines began a program to develop new crew procedures for the use of flight path angle and vertical speed modes in their A320's before the latest accident happened. I think the problems have been known to airlines operating the A320 for some time. Even if it turns out that the accident was not caused by a confusion of these modes, the report acknowledges that it is an issue that ought to be addressed. Edwin Hutchins, Department of Cognitive Science, U.C. San Diego La Jolla, CA 92093-0515 ehutchin@ucsd.edu
The following is a translation of the relevant paragraphs of the interim report: The point of impact was situated at an altitude of around 800 metres on the south-west slope of "la Bloss" mountain, which rises to 823m (see map in annex 1). At this place, the ground slopes upwards. The amount of slope varies between 8 and 17%. A forest of pines about 25 metres tall covers the entire area. The distance over which trees had been damaged was about 120 metres. Measurements taken of the damaged trees allowed a rough estimate that the aircraft entered the trees at an angle of descent of about 12 degrees, with a roll inclination of the order of 18 degrees. ---End of extract The map in annex 1 is large scale, and shows very little. Obviously "slopes upwards" means upwards in the direction in which the aircraft was travelling. The flight data from the QAR approximately confirms the above estimates. The QAR was burned, and in particular the last 25 seconds worth of tape prior to impact was damaged, and had to be read by special means. The last frame that has been read so far is at impact -4 seconds. This final reading shows: Barometric altitude = 2750 ft Radio altitude = 600 ft Vertical speed = -4000 ft/min (and seems to have been increasing) Airspeed = 186 kt Bearing (cap) = 68 deg To calculate time to impact from the point at which the radiosonde reported 200ft (which it would have measured relative to the tree-tops), we must take into account the upward slope of the ground, as well as the horizontal and vertical speeds of the aircraft. The airspeed would need to be corrected for wind velocity to get ground speed. The meteorological report for the area of the crash site gives wind between 1000 and 2000 metres as north-east or east-north-east 25 to 35 kt irregular, gusting to 40 kt. Since it is nearly 7 pm, and I have a pint waiting for me in the Sekforde Arms, I will leave this calculation to somebody more dedicated, but bear in mind that the ground was uneven, so that any estimate is bound to be rough. My own finger-in-the-air guess at the time to impact is "not very long". After they heard that "Two hundred feet" announcement, the pilots wouldn't even have had time to say "Merde!", never mind do a go-around. Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk
Robert Dorsett writes: As with most crashes, the Air Inter crash was likely the result of a complex number of factors; no single protection could have "saved" the airplane. I think you mean to say that any one of a number of factors WOULD have saved the airplane. It's the COMBINATION of the factors that caused the crash. I certainly don't want to fly on anything so screwed up that it's going to crash for a whole bunch of reasons!
Please report problems with the web pages to the maintainer