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 Swedish Accident Investigation Board's preliminary report on the Gripen crash on Aug 8 is presented in the air force's magazine FlygvapenNytt 3/93. Summarily, the conclusions are: - The only equipment malfunction before the crash was the electronic map which had nothing to do with the crash - The flight control system, the engine and all other systems worked as specified until the aircraft impacted - No external cause is suspected - The pilot was properly trained and equipped - The limits for minimum altitude and maximum angle of attack were exceeded insignificantly and did not have anything to do with the crash - The manufacturer and customer knew that large and rapid stick movements could cause divergent Pilot Induced Oscillations, but considered the likelyhood of it actually happening insignificant, so all pilots weren't informed - The red warning light was too late in telling the pilot that the control system was saturated, for him to do anything about it - The low altitude of 270 m made it impossible for the pilot to try to regain control The crash sequence started with a low speed 360 deg left turn at 280 m. The afterburner was lit, speed 285 km/h, load 2 G, bank angle 65 deg and angle of attack 21 deg. After finishing the turn, the control stick was moved to the right almost to the endpoint and slightly forward. The left wing's rear control surface rapidly went to the bottom position. The aircraft to bank to the right 20 deg past horizontal, angle of attack decreased to less than 10 deg. In order to fast regain a horizontal wing attitude, the pilot rapidly pulled the stick almost all the way to the left and continued to keep it slightly forward. This caused the control surfaces to move with their maximum deflection speed, and as the flight control system then had little or no control surface movement on its own to work with, the stability margin was reduced. At the same time the alert system informed the pilot of this, and he no longer recognized the aircraft's behaviour. The aircraft started to roll to the left and pitch up. In response to this the control stick was moved almost to the right endpoint and some forward. The result was a roll to the right to 35 deg bank and a lowering of the nose to 7 deg below the horizon, whereupon the stick was pulled forcefully back and to the left. At the same time, the artificial stability system tried to raise the nose, which in combination with the pilot's command caused a powerful pitch up. By this time, the control stick was fully forward, but the aircraft was already unflyable. >From exit of the turn until ejection the sequence took 6.2 s. The time from when the pilot didn't recognize the flying characteristics until stall took 2.7 s, but the control system warning wasn't shown until 1.2 s before the stall. The cause of the crash was the misjudgements that PIO was so unlikely and that the warning light would tell about any problems early enough for no mention of this in the pilot's manual was necessary. My own comments: The first crash was caused by the artificial control system having too much authority, sometimes leading to a slight response delay to the pilot's commands, causing PIO during a landing in gusting sidewinds. It has been reported from other sources that the main change made to the control laws a few weeks before the crash was to increase the pilot's authority a tiny bit. Some doubt has also been cast on the statement that the flight control computer worked as specified, as its log only goes a few seconds back and thus only showed data since the pilot left the aircraft. The crash report doesn't go into this in detail, but it is clear they had its error log to work with, in addition to data from the "black box". This report also clears up some things I didn't understand from earlier this year, when it was said that maximum angle of attack was 26 deg, and at 35 deg the rear airbrakes come out and the canard gives a full pitch down command automatically. Obviously fly-by-wire does not have to mean you impose hard limits on the aircraft's performance, in the Gripen case the pilot is trusted not to exceed them. Urban Fredriksson urf@icl.se
According to Flight International, 10 NOVEMBER 1993, "an automatic engine-control function in the McDonnell Douglas MD-81, of which the operating airline was unaware, was a major factor in the Scandinavian Airlines System (SAS) accident near Stockholm, Sweden, in December 1991, says the official report into the accident" In summary, it seems that the airline failed to detect clear ice on the wings before takeoff. The ice broke free and entered the engines damaging the fan stages. This caused the right engine to surge. The pilots retarded the right throttle. The automatic thrust-restoration system ATR caused both throttles to advance without the pilots noticing, making the surging worse in the right engine and starting surging in the left. The surges destroyed the engines. It seems that SAS were unaware of the ATR, which was documented but in a section of the production flight-procedure manual dealing with noise abatement. SAS VP Johan Juhlin is reported as saying "We did not order it. It was hidden in the computer. The only way to disconnect the ATR was to disconnect the whole autothrottle system." McDonnell Douglas say that they made SAS aware of the full capabilities of the MD-80 when it was delivered. The documentation has since been improved, and SAS have changed their procedures and training to emphasise the ATR and correct anti-surging procedures. The ATR was designed to improve safety where an engine fails after take off and noise abatement procedures have caused the engines to be throttled back. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk Fax: +44-225-465205
I forwarded the RISKS note about people receiving gun permit renewal notes accidentally in Massachusetts to David Lewis, who heads the Registry of Motor Vehicle's information technology group. (His official title is Deputy Registrar.) You may remember the message: >Date: Fri, 5 Nov 93 13:26:43 EST >Subject: Mass. state police confuse car owners with gun carriers >My wife received a letter yesterday from the Massachusetts state police, >informing her that it was time to renew her "License to Carry Firearms". >It included a renewal form that she was to take to her local licensing >authority, the police station in our case. This is what David Lewis had to say about it: "It wasn't actually a tape of vehicle owners. They got stickers confused with people who were supposed to get food stamps. So the people [who were supposed to get] the food stamp books got the gun permits, and the people who were supposed to get gun permits got food stamps. But it wasn't the Registry this time." Just setting the record straight.
[This was submitted by a reliable RISKS contributor who wishes to remain anonymous. PGN] It was noted in RISKS-15.25 that industry needs to be sold on the usage of Ada. As far as I know, industry likes Ada well enough. What they do not like is the EXCLUSIVE use of Ada. Industry has the problem of maintaining millions of lines of working code, code that is rather well debugged, and reasonably well documented, code that was written in what was once a DoD standard - FORTRAN or COBOL, for example. If the government really believes in capitalism, and if the government believes that private industry is in business to make money, then the government should be willing to allow industry to transition to Ada as that makes economic good sense. And not sooner. What such a policy shift might discover is that there are real problems for which Ada is not the best language. There is a very significant difference between a policy of "Ada exclusively" and a policy of "any assembly language you choose." Limiting government sponsored software to a list of government approved languages is a good place to start; investing some r&D money (little "r" and big "D" since most of the "research" is done) in software engineering "tools" for some "legacy languages" (FORTRAN, COBOL, BASIC) would improve the codes written in those older languages, and avoid the impact of a massive mandated change. Indeed, some of these "tools" exist; "DAVE" for FORTRAN, for instance.
Was there anything significant in your running the expression of faith in ADA just before the article about Groundhog day? There are still people who seem to believe in the latter too. Dave
> From the Ottawa Citizen Sunday Edition November 7, 1993 > by Brad Evenson, Citizen consumer writer > ... > "After having practised the emergency stopping manoeuvres with anti- > lock brakes, drivers drove faster, had higher accelerations around a curve > and stopped harder," a summary of the study said. > "If drivers choose to drive faster because they know they have greater > control, and if they choose to follow other vehicles more closely under > slippery road conditions, then the safety benefit from anti-lock brakes > might be reduced or lost completely." Okay, if this study is not misleading, then anti-lock brakes are a device which allows faster driving and closer following in slippery road conditions, without increasing the accident rate. This is bad? Mark Brader, SoftQuad Inc., Toronto utzoo!sq!msb, msb@sq.com
By the general secretary of the Chaos Computer Club France (CCCF), the French translation of "The Little Black Book of Computer Viruses" will soon be published by Addison-Wesley France (fax: +33 1 48 87 97 99). Naassance d'un Virus (dec 1993, 237 pages, circa 98 FF). Jean-Bernard Condat, PO Box 155, 93404 St-Ouen Cedex, France Phone: +33 1 47874083, fax: +33 1 47874919, email: cccf@altern.com
On pseudospoofing, there is an interesting SF-based discussion of the potential political consequences, to be found in Orson Scott Card's _Speaker_for_the_Dead_ (if I recall correctly, the two other sections of the [so far] trilogy also contain some elements: _Ender's_Game and _Xenocide_). In these books, Card describes a situation in which the political commons (not unlike internet) is invaded by two extremely bright pseudospoofers, who, seemingly opposed, debate each other in such a way as to manipulate the public into going along with their schemes. There are better writers than Card, and the concept has probably been around for a while, but it's an interesting execution. Andrew Marchant-Shapiro Depts of Sociology and Political Science USmail: Union College, Schenectady NY 12308 AT&T: (518) 388-6225 INTERNET: marchana@gar.union.edu BITNET: marchana@union.bitnet (no fooling!) [AM-S among others reminded me that my rend(er)ing of Tom Lehrer was not as on the records. "Don't write naughty words on walls IF you can't spell." I knew that, but (mis?)remembered a live version from the early 50s... PGN]
I'd like to assure the readers of RISKS that I am in fact a unique person, distinct from the other names L. Detweiler listed. Of the people on his list I know from personal contact, all are distinct people in Real Life(tm). Well before his post to RISKS, L. Detweiler was provided means of personally verifying that many of the names he listed are distinct True Names (eg phone numbers he can call), but it doesn't seem to help. Nick Szabo szabo@netcom.com
To everybody who is worried about the service anon.penet.fi: If you mail to an address such as an####@anon.penet.fi, you will be assigned an id. If you mail to na####@anon.penet.fi, your message will be passed along and you will NOT be assigned an id. an == anonymous na == not anonymous It's that simple. I mention this because it seems every other week somebody is discovering the "risks" of this service while how to avoid the problem altogether is never discussed.
In RISKS-15.25, Robert L Ullmann points out that one may be able to be
identified when using an anonymous mailer through stylistic analysis
techniques. ( This is what radio intercept operators in WWII called the
senders fist. ), There is a section that I was told about on the Comparative
Literature GRE that starts _None of the following paragraphs were written by
any of the authors listed, but the correct answer is the name of the author
whose style the paragraph was written in._ The problem with this technique is
that many people may use similar enough techniques that attempting to assign a
message to an individual may be very difficult.
Recently JPL opened an anonymous newsgroup for internal gripes. My boss's
boss came to me and said that he had noticed that I was active in that group.
( It is good to know that management is reading the group. :-)) I asked him
how he came to that conclusion and he told me that he recognized my style of
writing. The only problem was I had not heard of that newsgroup till he told
me about it.
Seth
Neither Jones, nor Mellor, nor Parnas (see RISKS-15.22) was arguing in favour of exhaustive testing in the quote picked upon by Schroeppel. Jones was trying to explain the complexity of software to non-programmers. He did this by trying to give the listeners a "feel" for the number of possible cases that would have to be considered. I pointed out that even though the complexity, as described, seemed daunting, it was understated. There is neither theoretical, nor practical basis for focusing on control state and neglecting data state. The thought attributed to Daimler by Schroeppel is irrelevant because carburetors don't have to be tested on all mixtures, just the ones that they will encounter, and that can be controlled. Moreover, continuity, and known upperbounds on the derivatives of the functions describing carburetors, limit the amount of testing that need be done. It's this lack of continuity that makes testing of software so difficult.
Richard Schroeppel <rcs@cs.arizona.edu> has taken exception to my essay on "Networking on the Network" in Risks 15.12, stating "I do not choose my friends based on their potential usefulness to my professional advancement. Even a little bit." As my essay repeatedly made clear, I am not advising anybody on the choice of their friends, only on the development of their professional relationships. These are different concepts. Heretofore, practical knowledge about how the world works has been restricted to elites, who are so embarrassed about this knowledge that they only pass it along in private, leaving others exposed to the Risks of untutored navigation in the professional world, permanently wondering why they can't seem to get anything done. If we write down the world's unwritten rules and circulate them on the Internet, maybe we can level the playing field a bit — or even change the rules. Phil Agre, UCSD
I've just remembered an old episode of the "Space Patrol" TV series in which the good guys spaceship was fired on by Earth spaceport defenses, which had been set to fire on any metals not originating on Earth. Unfortunately in a classic design glitch, the system designers had forgotten that many of the Space Patrol's ships had been built on Pluto, and were made of - ahem... Plutonium. The RISKS are obvious. Whatever they are. Steve Taylor smt@xedoc.com.au Xedoc Software Development
> First there was writing in the palm of the hand, then the crib sheet (or back > of the tie or sole of the shoe or etc.), next came the programmable > calculator, now coming to a store near you, the Newton generation. There was an alleged incident at Reading University (England) where a student used a laptop computer in an exam. The exam in question was "open book" but the rules did not forbid it's use in any exam. After this, the rules were tightened up and each calculator had to be "certified", as either - "non programmable" or "programmable and memory cleared". Certificates had to be displayed on desks, and invigilators could request that the memory be cleared at the start of the exam. Any device with alphanumeric memory was prohibited. Any calculator (even a simple 4 function credit card calculator) could be confiscated until the end of the exam unless a certificate was displayed on the desk. I can't vouch for the accuracy of the incident, but I was very aware of the rules being tightened up to the point that I had to go and buy a simple scientific calculator to use instead of my HP-28S. And switching from RPN to grungy-old-horrible-notation was a total pain! Highlighting the flaws in a set of rules isn't always a good idea - it usually gets the rules tightened too far. AndyC the WB (aka Andy Cunningham) Logica Industry / Ford Motor Company Phone: +44 277 253765 Fax: +44 277 253582 Net:andyc@cappsdv2.fob.ford.com
(from the CPSR Alert 2.05)
In response to a CPSR Freedom of Information Act lawsuit, the FBI this week
released 185 pages of documents concerning the Bureau's Digital Telephony
Initiative, code-named Operation "Root Canal." The newly disclosed material
raises serious doubts as to the accuracy of the FBI's claim that advances in
telecommunications technology have hampered law enforcement efforts to execute
court-authorized wiretaps.
The FBI documents reveal that the Bureau initiated a well-orchestrated public
relations campaign in support of "proposed legislation to compel
telecommunications industry cooperation in assuring our digital telephony
intercept requirements are met." A May 26, 1992, memorandum from the Director
of the FBI to the Attorney General lays out a "strategy ... for gaining
support for the bill once it reaches Congress," including the following:
"Each FBI Special Agent in Charge's contacting key law
enforcement and prosecutorial officials in his/her territory
to stress the urgency of Congress's being sensitized to this
critical issue;
Field Office media representatives educating their contacts
by explaining and documenting, in both local and national
dimensions, the crisis facing law enforcement and the need
for legislation; and
Gaining the support of the professional associations
representing law enforcement and prosecutors."
However, despite efforts to obtain documentation from the field in support of
Bureau claims of a "crisis facing law enforcement," the response from FBI
Field Offices was that they experienced *no* difficulty in conducting
electronic surveillance. For example, a December 3, 1992, memorandum from
Newark reported the following:
The Newark office of the Drug Enforcement Administration
"advised that as of this date, the DEA has not had any
technical problems with advanced telephone technology."
The New Jersey Attorney General's Office "has not experienced
any problems with the telephone company since the last contact."
An agent from the Newark office of the Internal Revenue
Service "advised that since the last time he was contacted,
his unit has not had any problems with advanced telephony matters."
An official of the New Jersey State Police "advised that
as of this date he has had no problems with the present
technology hindering his investigations."
Likewise, a memorandum from the Philadelphia Field Office reported that the
local offices of the IRS, Customs Service and the Secret Service were
contacted and "experienced no difficulties with new technologies." Indeed,
the newly-released documents contain no reports of *any* technical problems in
the field.
The documents also reveal the FBI's critical role in the development of the
Digital Signature Standard (DSS), a cryptographic means of authenticating
electronic communications that the National Institute of Standards and
Technology was expected to develop. The DSS was proposed in August 1991 by
the National Institute of Standards and Technology. NIST later acknowledged
that the National Security Agency developed the standard. The newly disclosed
documents appear to confirm speculation that the FBI and the NSA worked to
undermine the legal authority of the NIST to develop standards for the
nation's communications infrastructure.
CPSR intends to pursue further FOIA litigation to establish the extent
of the FBI involvement in the development of the DSS and also to obtain
a "cost-benefit" study discussed in one of the FBI Director's memos and
other documents the Bureau continues to withhold.
----
To subscribe to the Alert, send the message:
"subscribe cpsr
Please report problems with the web pages to the maintainer
x
Top