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…
>From the Washington Post, Dec. 26, 1993: >From "1993: The year of the weird" (page C3) The Syracuse Herald-Journal reported in January that its telephone hotline, featuring excerpts of the presidential debates last fall, was succeesful except for one glitch: Ross Perot's voice sometimes hit a pitch that mimicked a certain telephone tone that automatically shut down the whole system. Professor Lance J. Hoffman, Department of EECS, The George Washington University, Washington, D. C. 20052 (202) 994-4955 hoffman@seas.gwu.edu
I wonder if there are any protocols in place or even proposed for "quarantining" signals detected by SETI programs against the possibility of viral infections in software? If Turing machines are a universal feature of mathematics, might not a malicious or possibly just careless civilization be transmitting open or disguised programs that could conceivably wreak havoc among our delicate infosystems? Has anyone thought of this possibility and its implications? Or has this subject been done to death already and I've missed it? If so any pointers to the info at any archive site gratefully appreciated. If not, surely it merits some serious discussion? After all, we were so afraid of biological contamination the first few Apollo crews were in isolation for days until we determined that there was no danger. We should have the same concern for informational "contamination" today, since so much of our civilization depends on Turing machines..... ["Just careless" would seem unlikely if they were an advanced civilization. There is always a possibility that an unanticipated signal might do something strange to a system. There are lots of cases of electromagnetic interference in the RISKS archives, for example. But if everything in SETI is interpreted properly as pure DATA, you don't need to worry. BTW, if we had tapes long enough for the Turing machines, they might be able to reach to distant planets. PGN]
Flight International, 22/12/93-4/1/94 p11 contains an article on the report of
the commission of inquiry into the Jan 1992 Strasbourg A320 crash. Details and
comments on the preliminary findings have appeared in RISKS before. E.g. see
RISKS-14.01 (Mellor) on a rumor of a possible transient fault in the FMGS.
The crew set up an unusually high rate of descent (3,300 ft/min) instead of
the usual 800 ft/min (the final approach fix is only at 1,500 ft above ground
level). FI's report focuses on the crew training and the interface problems
highlighted by the report.
"The commission concluded that the crew's "below-average" performance
contributed to the accident and that the low combined time on type of the two
pilots (162h captain/61h co-pilot) caused a lack of familiarity with the
equipment on the A320's flightdeck, which has "...increased the risk factor".
[...]
From the moment of descent until impact, says the report, the
aircraft's high descent rate was adopted and maintained. The commission
observed that the "vertical navigation" was left entirely to the automatic
systems and the crew appeared to ignore all the clues available to them about
their abnormally high descent rate.
The commission says that the reason for the crew's descent mode
selection is not proved beyond all doubt, but that the most probable
explanations are a confusion as to which descent mode - vertical-speed (VS) or
flight-path-angle (FPA) - was set, having either forgotten to set it or having
set it incorrectly.
The ergonomic design of the descent-more selector is criticised for
being too easy to misread or mis-set. Airbus states that a design improvement
[..] has already been certificated and incorporated into all new A320s since
November 1993. A retrofit package will be available for fitting from January
1994.
The many recommendations in the report concentrate heavily on the need
for regulation to ensure pilot training and procedures improvements, together
with a need to monitor and standardise symbology development in modern
flightdeck displays."
Peter Ladkin
Flight International, 22/12/93-4/1/94, p11.
"Dangerous overheating in an Airbus Industrie A320 engine-starter unit led to
complete in-flight engine-control failure [..].
The starboard [engine ....] suddenly wound down to idle power at
4,000ft (1,200m) in the climb from London Heathrow on 13 December, 1992.
Reversion to manual control had no effect because the circuit breakers
for the full-authority digital engine control (FADEC) and engine-interface
unti had tripped and would not reset. THe aircraft returned safely to
Heathrow. [...] Temperatures reached 400\degC inside the engine cowl,
damaging the FADEC wiring. The AAIB says that the engine wind-down was
probably caused by short-circuiting, which gave false signals about
thrust-reverser position.
In October 1989 a similar [..] event led to the issue of the 1991
Service Bulletin. A Bulletin issued after the incident was not applied to the
[aircraft in this report]. The AAIB recommends making it mandatory."
Peter Ladkin
To: Bob Frankston "Robert M. Frankston / MCI ID: 100-7411" From: Mark Eppley / MCI ID: 296-7039 @ mci Date: 12-23-93 01:55:00 EST (12-23-93 02:19:57 EST) Subject: RE: From Risks Digest It is called LapLink Wireless. Uses FM phase lock loop radio transceivers we developed and licensed to National Semiconductor. He is way off base. 2 levels of security exist as well as compression/encryption of packets flying through the air.
Of course, another take on this situation (and equally applicable to the computer world) is that the security culture mainly benefits its vendors and overseeing bureaucracy: that the slipshod techniques are merely there to reassure a naive public that the airlines and their government are doing something with respect to an issue that gravely concerns many: but evidence had repeatedly shown--even at the peak of "red scares"--that these measures tend not to deter the high-risk attackers (or even catch very many of the low-risk attackers, as the estimated ~30,000 security violations/year testifies). EVEN when conducted according to specification. Metal detectors are manned by poorly trained, low-cost personnel, and provide a single point of entry that is easily subverted. Similarly, badges are ineffective, and door combination locks are easily compromised. But they do show the public that "something is being done." So when hijackings to Cuba became embarrassing, checkpoints appeared; when bombings occur, the call for outrageously expensive explosives detectors goes up; when an airline employee kills the flight crew of an airplane, the employees are treated like criminals (every airline pilot in the United States must pass through the same security checkpoints as the passengers, for instance: in Russia, they ARM their pilots :-)). This is all visible to the public, and may provide (as with computer security) some level of deterrence for *honest* individuals, but overall, the results are mixed, at best. Countries that do security right (such as Israel) do it very slowly, and very expensively; countries that want their cake and be able to eat it too (profitable security; the closest analog may be network security), resort to symbolic measures, largely ineffective--but which help sell a notion that "something is being done." So, as with computer security, perhaps the real question to ask is whether the symbolism--for all its faults--is really worth it. I don't particularly relish the prospects of living in a police state, myself. Actually, I *did* live in one, for over ten years. Sure, you can go to sleep with the front door wide open, but such societies take their toll in much more profound, disturbing ways than petty violence. Robert Dorsett rdd@cactus.org ...cs.utexas.edu!cactus.org!rdd
I have had a keen interest in this problem since my portable was stolen from my car. This is what I have since learnt: Re-Chipping is a misnomer. All modern cellphones can have *soft* Electronic Serial Numbers (ESNs) and phone numbers. On my NEC P3, these can be changed without even removing the cover. The real thief is the airtime company. They leave me with two choices: 1) Pay UKP137.00 to get out of my airtime contract. (3 months line rental, plus UKP50.00 disconnection +tax) 2) Buy a new phone. They have a whole department to sell theft-replacement phones. The prices for phones sold without a new airtime contract are *much* higher than those sold with a contract. The reality is that people generally only upgrade their phones when they get stolen, so it is in the interest of the airtime providers to sell phones with a high "black" value. The entire trade in stolen phones could be stopped by the simple expedient of using *hard* ESNs and dipping the circuitry in epoxy. Andrew
The rechipping is a service provided even by the Taiwan government, at about NT$4000 (about US$160) a pop. Lots of people who are legally registered and paying customers buy cell phones from the US and rechip them to use in Taiwan. The reason is quite legitimate — the cost of buying a cell phone in Taiwan is exceedingly high. Presumably, by providing this service, the Taiwan government gets fees that would have gone into phone dealers' pockets. Li Gong, SRI International
I was a little surprised my comment got posted, since I was basically interested in the moderator's opinion on why software typically had so many problems. BMDSTP project was unusual in being successful, and I was looking for some comparably successful projects. Lauren Wiener asks some sharp questions: 1. What was the purpose of the software? This was the Site Defense Program, which was to build software for the ballistic missile defense system that followed Safeguard. It was also the testbed for Modern Programming Practices, and Barry Boehm was involved. ALTHOUGH the management was good, it was not particularly better than management I've worked with since. The BMDSTP managers did take a proactive stance, trying not to be blindsided by problems, and they were always willing to listen to their engineers. This program was redirected in midstream in response to the ABM pact, and instead went to Kwajalein as a tracking and data collection tool for the phased array radar out there. It ran on a pair of CYBER 7000 machines. It worked, and it worked well. 2. Was the product actually used in real-world situations, as opposed to testing? Hard to answer. It ended up a component of a test system, but it was not under test there. It certainly met its requirements. 3. Were the acceptance tests specified in advance? Were they available to the developers to use as they developed the software? Yes, we were very careful to get the required performance envelope and functional requirements defined in detail, and we ran off-nominal stress tests against those requirements. The real-time operating system was specified top-down, with performance requirements as well as functional requirements, and we built an automatic testing system that validated the RTOS and DMS for each delivery. I've not seen anything since like the way that process was managed. Most programs address performance and reliability late, if ever, and we addressed it from the beginning. As Tom Bell puts it: "Pay me now or pay me later. It'll cost more later." We paid up front. I'm very interested in why this one program worked so well. I've been observing the FAA Advanced Automation Program for the last three years and trying to understand the difference between my experience on the BMDSTP and their current experience. My impression is that there is a non-linear relationship between the effectiveness of technical management and the success or failure of a software project. If the software is just slightly too hard for the management team, they fall behind and spend their time playing catch-up and responding to surprises. If they are able to get their arms around the system early, on the other hand, they can keep ahead of the problems and control things much more effectively. There's not that much of a difference between most managers and engineers that I can identify, so I suspect it's the nature of the software development problem to be like that. Does that help? Harry Erwin Internet: herwin@cs.gmu.edu or erwin@trwacs.fp.trw.com [Yes, Thanks. PGN]
Please report problems with the web pages to the maintainer