iwm@doc.imperial.ac.uk (06/01/90)
This is a summary of an article in the Guardian for 1st June:
`Computer hitch stalls GP budgets', any inaccuracies are mine.
At the moment UK family doctors are funded according to the size of their
practice and various overheads. As part of changes to the National Health
Service, doctors may be required to maintain their own budgets and buy
treatment from local hospitals. To do this doctors will require specialist
software to interface with hospital databases as well as doing their own
accounting. The first stage of the scheme involving several hundred doctors was
to start next April. The changes are unpopular and doctors are dropping
out, software firms working in the area claim that developing
the software is not worthwhile given the number of sales to those doctors
participating. It was stated that even if the government funded the development
there is not enough time to produce and test the software in time.
Although it is not stated in the article, I believe that one problem may
be that different hospitals run different (and incompatible) accounting
software.
Ian W Moor
ARPA: iwm@doc.ic.ac.uk
JANET: iwm@uk.ac.ic.doc
Department of Computing, (The skin is mightier than the banana)
Imperial College.
180 Queensgate
London SW7 UK.
2-Jun-90 16:15:13-GMT,34082;000000000004
Received: from csl.sri.com by hercules.csl.sri.com at Sat, 2 Jun 90 09:14:57 -0700.
(5.61.14/XIDA-1.2.8.35) id AA18589 for risks via SMTP
Received: from nsfnet-relay.ac.uk by csla.csl.sri.com at Sat, 2 Jun 90 09:14:30 -0700.
(5.61.14/XIDA-1.2.8.27) id AA04097 for risks@hercules.csl.sri.com via SMTP
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa11645; 2 Jun 90 17:00 BST
From: Pete Mellor <pm@cs.city.ac.uk>
Date: Sat, 2 Jun 90 17:08:14 PDT
Message-Id: <24133.9006030008@csrsun2.cs.city.ac.uk>
To: RISKS@csl.sri.com, aeronautics@rascal.ics.utexas.edu
Subject: Article on A320 in Aeronautique, April 1990
Cc: philw@cssun10.cs.city.AC.UK, pm@cs.city.ac.uk
Dear Robert and Peter,
I was given this article by some colleagues who bought the magazine while
visiting France for a research project meeting. Having had a quick look at
it, I decided that it was *very* interesting. It contains chapter and verse
on a couple of hair-raising incidents on board the A320, and the author
obviously had access to the dossier of OEB's, from which he draws some
fascinating conclusions regarding the general state of readiness of the A320
on entry into service and the possible causes of the Habsheim accident. He
also includes an excellent summary of the legal wrangle surrounding the
investigation into Habsheim. So, because of:
a) the technical quality of the article,
b) the fact that it presents a French (and therefore not negatively biased?)
view, and
c) the fact that it is not readily accessible to the majority of UK and US
readers,
I decided, at *enormous* cost in time and effort :-), to make a careful
translation of the whole article, and send it complete to RISKS and to
Aeronautics Digest.
Now, I know that it is *large* (32Kbytes) and so not easy to include as a
whole on the digests. However, since you are moderators and catch this stuff
before it hits the ethers :-), I leave it to you to decide how to handle it.
Robert suggested posting a summary and leaving the whole article on the
Aeronautics archive server. Unfortunately, I have not hade time to prepare a
decent resumee. (Sorry, I've gotten used to reading French recently :-)
Anyway, here goes. If it doesn't work first time, I'll split it up and send it
in pieces, so be prepared for some garbled messages. :-)
-------------------------------------------------------------------------------
LES CRISES DE NERFS DE L'A320
Translation of article by Bertrand Bonneau: Aeronautique, April 1990, pp. 94-101
[Translator's comments and additions are in square brackets.]
-------------------------------------------------------------------------------
THE A320'S ATTACKS OF NERVES
- The first aircraft in the history of the world to be totally "managed" by
- computer; has the A320 been put into service before it is ready?
- The excessive number of incidents during its first year of use can only make
- one think so. How could the willingness to declare the pilots responsible for
- major accidents, even before the judges have returned their verdict, appear
- other than suspect? Even so, as everyone wished, the verdict whitewashed the
- aircraft.
At the start of 1988, the French authorities and Airbus Industrie congratulated
themselves on the certification of the A320 only one year after the first flight
of the prototype. In less than one year, the manufacturer had demonstrated the
reliability of this new generation aircraft to the authorities of four of the
States of the European Community.
However, controversy surrounding the aircraft would not be slow to surface at
the time of the inaugural flight of the Air France A320, on 28th March 1988
over Paris, with the Prime Minister of the time on board. This flight was
marked by a series of technical incidents, notably by the untimely setting off
of alarms. New controversies were to arise when an aircraft was destroyed in
the forest of Habsheim in Alsace (26th June 1988), and when an Indian Airlines
A320 crashed before reaching the runway in Bangalore last February. In both of
the last two cases, the aircraft was whitewashed as far as public opinion was
concerned before the slightest preliminary accident report was published...
Although what have come to be called the "Chirac flight" and the "Habsheim
affair" are the two facts most known to the public, the first year of operation
of the A320 has been marked by numerous incidents which have directly called
into question certain systems on the aeroplane. Often badly received by the
first crews qualified on this aircraft, and sometimes vigorously denied by the
technical directors of the launching companies, these incidents lead one to ask if the manufacturers and the certification authorities have not proceeded a
little too quickly.
*Twelve times more incidents than were foreseen.* In his statement on the first
year of operation of the A320 in the Air France fleet, a statement addressed to
the general department of civil aviation (Direction Generale de l'Aviation
Civile - DGAC) on the 11th July 1989, the technical sub-director of operations
management of the national company remarks that the first exercise has been
marked by "a greatly increased number of technical incidents altogether"
(page 12). Whereas the target set was one incident per thousand hours of flight,
the year 1988 ended with an incident rate of twelve per thousand hours of
flight. For comparison, this rate was 5/1 000 at the time of the first year of
operation of the Airbus A300.
The frequency of these incidents which have marked the A320 going into service
within Air France, Air Inter and British Airways has forced the manufacturer to
publish no fewer than 52 provisional flight notices (OEB, Operations Engineering
Bulletin) between April 1988 and April 1989. The launch of a new aircraft
requires on average four times fewer. OEB's are temporary notices sent out by
the manufacturer to the users. They form a list of anomalies or simply
functional features of the aircraft, which do not appear in the users' manual
for the equipment (FCOM, Flight Crew Operation Manual): they are only revealed
in the course of operation. In the case of Air France, these provisional
records are provided to the crews in the form of a volume of supplementary
technical information notices (Renseignements Complementaires Techniques
- RCT's).
For the A320, the number of OEB's alone gives an account of the problems of
putting the aircraft into service. At the technical level, around twenty of the
fifty main computers of the first A320's coming off the production lines in
Toulouse have had to undergo modifications. For the A320 is the first aircraft
in the world to be completely computerised. Computers control the function of
all the systems of the aeroplane (motors, ailerons, but also the cabin
lighting, etc); it [sic] processes raw data, converts them, and
transmits them to the pilot. Now, the application of numerous modifications
defined by the manufacturer in order to correct defects in the systems or to
enhance them, has been the origin of new breakdowns. These new problems have
obliged the manufacturer to publish new OEB's before drawing up final
modifications.
During service, companies have had to modify once or several times certain
procedures for operating their aircraft. Also, with the exception of Air Inter,
which reported only good results, the increased number of incidents was the
origin of poor availability and bad technical readiness of the first A320's
delivered. "Of 7 334 stop-overs [landing + take-off's (?)] carried
out up to April 1989," states the report of the technical sub-director of
Air-France, "one lists on technical grounds [i.e. something went wrong (?)]:
4 accelerations-stops on take-off, 36 about-turns on the ground,
10 about-turns in the air, 1 emergency descent procedure, the cabin altitude
being on the increase (without violent decompression), 1 engine stop in flight."
[If you think this lot is confusing, you should see the original French!
I think an about-turn on the ground is an aborted take-off, and an about-turn
in the air is a return to the departure port. I'm not sure what the difference
is between an about-turn on the ground and an acceleration-stop. Presumably
the latter means the engines raced or cut-out during approach to take-off.
'Cabin *altitude* being on the increase' is a literal translation: I think it
means the cabin atmosphere was below pressure, since they came *down*.
Anyone with access to a dictionary of French avionic terms, or who knows the
correct English avionic terms is welcome to correct me!]
It is advisable to add to these outcomes the grounding of aircraft due to
suspect behaviour, and 74 cancellations of flight before even starting up the
engines.
*Reliability in question*. For the aviation companies, the most serious problem
would seem to have been that of the reliability of the information given to the
crew by the various systems of the A320. The operating assessment by the
technical sub-director of Air France is edifying on this subject. One discovers
there, for example, that: "certain inconsistencies of piloting information
have led to certain confused and very distracting situations, where the
information presented to the pilots on the control screens, during flight, was
in contradiction to the physical reality of the equipment, not always
verifiable in flight", (report already cited, page 18).
[Presumably this means: "The instruments were lying, but the pilots couldn't
get out and walk around to check this at 30 000 feet!" Nice to know that
French technical officialese is as obscure as British or American! ;-}]
Without a doubt, Captain Claude Dalloz and First Officer Patrick Vacquand share
the views of the technical sub-director of Air France. On the 25th August 1988,
while taking off from Roissy on a flight to Amsterdam (flight AF 914), they had
the disagreeable surprise of seeing the message "Man pitch trim only" appear in
red on their control screens. In plain terms, this message informed the pilots
that the controls activating the pitch control mechanism were no longer in a
functional state. In this case, the only means of ensuring the longitudinal
stability of the aircraft is to manually move the trimmable horizontal
stabiliser by means of the pitch trim wheels.
Meanwhile, the copilot who was at the controls felt not the slightest difficulty
in controlling the aircraft. Then the crew witnessed a display of imaginary
alarms ("fire in the toilets", for example), and noticed new signalling
anomalies on the screens concerning the flight control systems, the position of
the landing gear, and also the situation of the automatic pilot.
It was therefore decided to return, but, during the approach, the gear at first
refused to come down normally. Given the uncertainty, three passes at low
altitude were made in front of the control tower to ascertain the real position
of the gear after having carried out safety manoeuvres. As the information
provided to the crew ("gear partially down") did not correspond to the
observations of the controllers at Roissy (gear down), the passenger cabin was
prepared for an eventual crash, which did not, very fortunately, occur. The
same incident recurred on another plane on 29th November 1988. It finally
required nine months of operation before a new, more reliable, version of the
Flight Warning Computer (FWC) called into question by these two cases was made
available to users.
*A temperamental altimeter*. A good many problems due to the design of
certain systems have revealed themselves since the start of operation. The
most spectacular, for the passengers, would have been the vagaries of the
integrated cabin communication system (CIDS), which modified explanations or
illuminating announcements in an eccentric fashion. More seriously, the crews
discovered that the temperature regulation of the passenger cabin could
interfere with the functioning of the engine power control computers (FADEC),
generating breakdowns and alarms. To avoid these interferences, crews were
asked not to "reinitialise" the cabin temperature regulation system while the
engines were running.
However, the most worrying phenomenon for the crews has been the untimely
alterations to the setting of the altimeters during flight. Having reached
a certain altitude, the pilots set their altimeters in a standard way,
calculated in relation to the theoretical atmospheric pressure at sea level
(1 013 hPa), in order that all aircraft using the airspace should have the same
reference for altitude (QNH base). Relative to this base, the altimeter
indicates a pressure altitude, which is a "QNE" altitude. While the aircraft
is descending, at a predetermined height the crew must set their altimeters
in relation to the altitude of the destination airport (QFE base). Apart from
some very rare landing strips situated below sea-level, airports are above this
[sea-] level. Since pressure diminishes with altitude, the value of QFE is
generally less than 1 013 hPa. The sudden alteration of the altimeter setting
by the flight programming computer (FCU, Flight Control Unit) sometimes occurs
in uncomfortable conditions. So, in July 1988, during an approach to Roissy,
the untimely alteration of the altimetric setting, which conveyed itself as
a reversal of the altimeter reading, provoked an automatic delivery of fuel in
order to compensate for the false deviation in altitude generated by the
defaulting computer and detected automatically by the safety systems of the
aircraft. This delivery of fuel occurred while the aircraft was being flown
manually on its descent. The rapid intervention of the pilot could not avoid
the aircraft going into overdrive for several seconds.
Untimely alterations of altimetric settings showed up on at least the first
three planes delivered to Air France, among them the aircraft which crashed at
Habsheim. The commission of enquiry has revealed in its final report that such
an incident had taken place on the plane several hours before its crash,
concluding immediately that this anomaly due to a design error had played no
part at all in the accident. Moreover, the flight report (CRM, compte-rendu
materiel) of a crew, concerning a third aircraft of Air France, made mention of
vagaries of the altimeter.
It is therefore surprising that the report of the technical sub-director of
Air France limits this type of incident to a single A320 of his fleet (the
aircraft registered F-GFKB), when it has also occurred on at least two other
planes (registered F-GFKA and F-GFKC). But the most amazing thing remains that
this functional anomaly should cease without anyone being able to identify its
origin!
*Recording of parameters*. In an indirect manner, these two types of incidents
have revealed another potential source of problems in the level of the
recording of parameters by the "black box recorder" (DFDR, Digital Flight Data
Recorder). In effect, each piece of information given to the pilot is handled
by a cascade of computers. Now, this "black box" records the majority of its
information on the intermediate computers and not at the start
or end of the processing chain. When examining this data, therefore, there
is nothing that allows one to know precisely what the pilots had for
information, since there is no recording at the output of the symbol generator
[DMC] for their screens.
The problems posed by the flight data recording system can be illustrated by
referring to the two incidents mentioned. If the Paris/Amsterdam flight
recalled above had ended in a crash, the "black box recorder", which captures
a large part of its information from the flight warning computer (FWC), would
have revealed that the crew no longer had pitch control available. In fact,
all the flight controls were functioning, but the flight warning computer,
which is one of the principal sources of information of the "black box
recorder", had failed (diagram, p.98).
Equally, if the untimely alterations of the altimeter readings had ended in
a crash, the "black box recorder" would have revealed no malfunction of the
altimeter assembly, since the recording of pressure altitudes (QNE), which was
correct, is effected by equipment located upstream of the failing computer.
This computer (FCU) incorrectly processed the information which had been sent
to it, and an erroneous indication of altitude was sent to the control screens
(diagram above, p. 99).
*Modification Campaigns*. Before the A320's went into service, the launch
companies' instructors - who cannot be accused of bias since
they were all volunteers - complained of having had no contact with the
test pilots of Airbus Industrie. The report of the technical subdirector of
Air France, for its part, confirms this worry by revealing that it had at last
been possible to establish a "frank relationship" (page 17) after six
months. The adaptation of failing systems has been progressively integrated
in the course of several modification campaigns begun at the start and
middle of 1989 as problems were found and listed. It was necessary
to wait until the end of last year to obtain the definitive version of certain
pieces of equipment, that is to say, eighteen months after the certification
and entry into commercial service of the A320.
At the end of last year, the dossier of supplementary technical notices (RCT's)
distributed to A320 crews already comprised eleven pages, whereas the RCT's of
other aircraft in the Air France fleet rarely got beyond three pages.
Contrary to the fears expressed many times in the course of these last years,
not only by certain pilots' unions, but also by the American certification
authorities (FAA, Federal Aviation Authority), the electrical flight controls
and the electronic engine control system, which constitute the two great
technological innovations of the A320, would never be the direct cause
of any significant incident, notably in stormy conditions. During test
just as in service, the A320 was struck by lightning several times without the
least influence on the flight controls.
The majority of the teething troubles and design faults of the A320
therefore concern more classical systems. The report of the technical
sub-director of Air France is once again definitive: "Pressurisation,
management of cabin communications (CIDS), pneumatic generation, auxiliary
power units (APU)... have been for a long time of an unacceptable reliability.
Everything is still not under control to this day (NDLR: 11th July 1989)."
(Report already cited, page 17).
*Industrial secret*. It could therefore be thought that the certificator has
turned his attention above all to the innovative elements (flight controls,
FADEC, etc.) of the A320. However, this explanation, although not completely
without foundation, does not take into account the fact that the systems called
classical are also subject to major innovations, since they practically all
require computer automation.
Without invoking the young demons of computing, the embedding of numerous
pieces of software on board aircraft of the new generation (A320, but also
McDonnell-Douglas MD 11, Boeing 747-400, among others) can pose problems for
the official agencies. Up until then, the certificators were confronted by
much more simple systems (cabling, for example) and by perfectly mastered
technologies (electricity, for example). With the A320, the certificator
found himself before a gigantic interactive data processing system, made up
of "boxes" which consisted of inputs and outputs. No-one having foreseen
such a rapid installation of computers on board service aircraft, it was not
possible to find, in the international regulations, standards directly
applicable to this domain.
Furthermore, the certificator came up against protection of embedded software
by industrial secret. The official agencies were finally forced sometimes to
give their agreement to a piece of equipment, on a simple demonstration of the
required result, without being able to know precisely the organisation of the
system which allowed it to be reached. In such a context, only a more thorough
programme of tests would have permitted the major design faults of certain
systems to be revealed with certainty and would have avoided certain launch
companies having to proceed with the modification of nearly half of the main
computers of their first A320's.
The protection of software by industrial secret constitutes a source of
problems also for the users' maintenance services, who must leave it to the
manufacturer to understand the reasons for its failure. For the time being,
the best equipped companies are provided with certain software test sets, but
eventually the users will have to be able to test their systems directly on
the battery of test sets of the manufacturer through data transmission networks.
*The dead-ends of certification*. It is interesting to note that use has
revealed several loopholes in certification. A provisional information bulletin
dating from the month of May 1988 (OEB no. 06/2) reveals for example that the
single information source for the pilot's and copilot's altimeters on the A320,
is not compatible with certification standards [i.e. it makes a single point
failure possible?].
Another provisional information bulletin sent out in August 1988 (OEB no. 33/1)
indicates that the safety lighting system of the floor of the passenger cabin
does not conform to certification standards. This system would not
automatically illuminate when one of the emergency evacuation devices of the
aircraft was activated, in the case of the loss of the normal electricity
supply. Now, this lighting system provides an illuminated pathway in the
central aisle of the cabin, which must allow passengers to find the safety
exits or doors during an evacuation in the dark or in smoke. This design
defect was underlined by the final report of the commission of enquiry into
the Habsheim accident.
"To be the launch client of a new aircraft is sometimes a painful task,"
one of the directors of Air France confided last year, before adding that "the
A320 would attain the level of reliability of the fleet (of Air France) by the
start of 1990." This would be practically two years after the certification of
the aircraft. A last example: it has been necessary to wait until the month of
July 1989 for it to be noticed, in the course of a test flight, that the
landing gear could, in certain cases, not retract fully in case of a shut-down
of engine no. 1 during take-off (OEB no. 62/1). (1)
The totality of these elements, then, could allow one to believe that speed and
haste had been confused.
Bertrand Bonneau
---------------
[Footnote:]
(1) The OEB's are intended to be temporary. As a consequence, the anomalies
with which they are concerned when they are sent out, have normally been
corrected.
-------------------
[End of main article. Text in boxes accompanying illustrations follows:]
-------------------
[Box on p. 95, below photograph of cockpit:]
*Up to the customer to complete the tests.* The standards and certification
procedures of civil aircraft are not adapted to the A320, an aircraft which,
for the first time in the history of civil aviation, is massively equipped
with data processing systems. For example, the software in the flight warning
computer [FWC] included a fault which a good computer scientist could have
repaired without a doubt. But this software is protected by industrial secret,
and as luck would have it the fault did not show itself at the time of the
certification campaign. Result: an aircraft has been sold with a certain
number of latent defects, which the first customers have discovered bit by bit.
-------------------
[Box on p. 97, accompanying photographs of instrument panels in cockpits of
(1) A320, (2) A310, (3) A300:]
THE TECHNOLOGICAL LEAPS OF THE AIRBUS
The A320 (1) is the first aircraft whose cockpit panel is entirely equipped
with cathode tube screens [CRT's]. Only three traditional instruments are still
found there, in case of failure of the former [i.e. CRT's]. The new screens
display more synthetic and more complete information to the crew. So, the whole
navigation of the flight is directly visible to one of them, and the image
evolves in real time along with the movement of the aircraft, whereas on
traditional aircraft, this tracking is effected by the pilot on a piece of
paper on which he reports the successive positions given by the on-board
equipment (radiobeacon receiver, radiocompass, inertial platform [IRS?], etc.).
But these screens can also, unfortunately, deliver erroneous information if
one of the systems that supplies them is failing; and the irony is that often
this information cannot be verified by the pilots in flight (see diagrams,
p.98). An aircraft of the preceding generation, the A310 (2), was already
equipped with some screens, whereas the A300 (3), which was developed at the
start of the 70's, is only equipped with classical electromechanical
instruments.
-------------------
[Box on pp. 98-99, illustrating two incidents described in the main
text, labelled case A and case B in the boxed text to allow cross-reference
between that and the two accompanying diagrams, which show by numbered labels
the placing, and communication between, the following:]
1. PFD. Piloting screen. It is this which displayed "manual pitch trim only"
in case A in the text, and the erroneous QFE altitude in case B.
2. ECAM. Screen which gives information about the aircraft systems (motors,
lighting, etc.).
3. PA. Automatic Pilot.
4. Side-stick.
5. FCU. Flight Control Unit.
6. DMC. Symbol generator for screen displays [Display Management Computer].
7. SEC-ELAC-FAC. Computer [sic] for flight controls (ailerons, pitch control
surface, flaps, spoilers, etc.).
8. ADIRU. Air Data Inertial Reference Unit
9. SDAC. System Data Acquisition Concentrator, which translates into data
processing language the data received from systems upstream of it (sensors,
controls, etc.).
10. FDIU. [Flight Data Interface Unit] Computer for the flight data
recording system, which manages the "black box recorder" [DFDR].
11. Hydraulic servo-mechanism for pitch control surface.
12. Trimmable Horizontal Stabiliser [THS] and pitch control surface.
13. DFDR. "Black box recorder" [Digital Flight Data Recorder].
14. Switch for display of QFE pressure [on FCU]
BREAKDOWNS AND DANGERS INVENTED BY THE COMPUTER
*A. Alarmist computers.* This simplified diagram [p. 98] of the A320 systems
(which takes no account of the actual location of the computers) shows how the
crew of flight AF 914 of 25th August 1988 found themselves confronted by
nonsensical information generated by the flight warning computer (FWC). This
sent the erroneous message "manual pitch trim only" to the piloting screen
(PFD) and to the "black box recorder" (DFDR), a message informing of a loss of
control of the pitch control surfaces (red arrows). [Sorry. Colour diagrams are
difficult over e-mail ;-)] Put simply, the pilot can no longer control the
climb or descent of his aircraft with the stick (but only by means of a manual
back-up control). In fact (green arrows), this control [i.e. the electronic one]
was functioning perfectly.
*B. Imaginary altitude.* The second diagram [p. 99] shows how the pilots had
on their screens an untimely alteration to their altimetric setting, generated
by the flight control unit (FCU), whereas the altitude data in the air data
inertial reference unit (ADIRU) was correct. The FCU prompted an inversion
between the pressure altitude (QNE) and the altitude of the destination landing
strip (QFE). As the QFE was giving an altitude below the QNE altitude (which
would allow one to believe that the aircraft was flying dangerously lower than
it was in reality), the safety systems of the aircraft demanded an automatic
delivery of fuel to regain height.
-------------------
[Box on pp. 100-101:]
HABSHEIM ACCIDENT: CFMI ASSESSES CFMI
On the 26th June 1988, the air show organised by the little flying club of
Habsheim, in the Haut-Rhin, turned to drama when an Air France A320 crashed
with 130 passengers in the forest which bordered the landing field, in the
course of its display flight. In a few minutes, the aircraft was almost
completely burned. Toll: 3 dead, 34 injured, the other 93 occupants unhurt.
Nearly 18 months after the accident, the Commission of enquiry delivered its
report. Contrary to what it had been possible to affirm, this document (called
the "Bechet report" after the name of the president of that commission) does
not establish any responsibility, but limits itself to stating the facts and
suggesting some measures. After all, only judges are entitled to decide blame
and responsibility. Now, this decision has not taken place. The investigating
magistrate has even requested recently the reopening of the inquiry for
supplementary information.
No-one knows, then, what the Mulhouse magistrate thinks, but the context in
which the enquiry into this accident was begun could be marked by certain
irregularities. Indeed, on the evening of the drama, the director general of
Civil Aviation was filmed by a television crew as he took charge of the
transport of the two "black boxes" (CVR and DFDR). Now these two recorders
are the essential elements for the enquiry. The presence of the director
general of civil Aviation at the scene of the accident and the particularly
active role that he played that evening seem hardly compatible with the
ministerial directive of the 3rd January 1953 relating to the coordination
of the judicial inquiry and the technical investigation and with
directive no. 300 IGAC/SA of the 3rd June 1957 concerning the steps to be
taken in case of irregularity, incident or accident in aviation. The General
Directorate of Civil Aviation having had the responsibility of certifying the
aircraft and having authorised the holding of the meeting, it is legitimate
to ask oneself if its director is not simultaneously judge and party to the
case. Moreover, the authority designated by the regulations as being competent
in the matter of enquiries is not the DGAC but the General Inspectorate of
Civil Aviation (IGAC), placed under the direct authority of the Minister of
Transport.
A second factor, which follows from the first, could leave one to suspect
that the concern of the only technical enquiry had overridden that of
the judicial enquiry. First, it was necessary to wait two days for an
investigating judge to be appointed, whereas that is generally done in half a
day for major accidents; and this is one of them [i.e. major], with, moreover,
a considerable amount at stake. Furthermore, the two black boxes were left for
nine days without any judicial control, since the placing under seal was only
done on the 5th July (let us recall that the accident took place on 26th June).
In the meantime, parts of the recording of the conversations held in the cockpit
during the flight were published in the press, in defiance of the secrecy
required by the directive [i.e. no. 300 IGAC/SA of 3rd June 1957(?)].
Reading of the Bechet report (page 41) reveals that the assessment of the
damaged aircraft engines was entrusted to their own manufacturer (CFMI), on the
SNECMA premises at Melun-Villaroche. Without casting doubt on the quality of
the assessment achieved by the manufacturer on the premises of one of his
partners with the participation of the Commission of Enquiry, it seems
astonishing that the manufacturer should have had control over a procedure
which concerned him so directly. As one knows, in the case of an enquiry
relating to an accident, an assessment is always likely to have judicial
consequences.
That is all the more surprising since the engines had been directly implicated
by the statements of the crew immediately after the accident. One can therefore
ask oneself why the assessment of the two CFM56-5A1's was not entrusted to the
experts of the Propeller Test Centre of Saclay, which comes under the Flight
Test Centre. Indeed, this centre does not have any judicial, industrial or
commercial links with the equipment in question.
Even if the conclusions of the commission of enquiry, based on that assessment
and on the recording of the "black box recorder" [DFDR], categorically
rule out the two engines, that will not cut short some of the objections which
some of the lawyers would have been able to try to set out before the judges
of Mulhouse. Such would not have been the case if that investigation had been
entrusted to an organisation which was not also an interested party.
If the defects of acceleration of the CFM56-5A1 engines of the Air France A320,
noticed sometimes in certain cases of low altitude flight, did not exhibit
themselves at the time of the accident, why, then, was a provisional information
bulletin (OEB 19/1) sent out in May 1988, modified in the following August
(OEB 19/2)? Moreover, the adjustment of the stator blades (counterbalancing [?]
of the jacks which modify their pitch [?]) of these engines, which has a direct
link with their efficiency at low speed and at low altitude, was also modified
a short time after the accident. There again, why?
-------------
DISCLAIMER:
1. The opinions expressed in this article are not necessarily the opinions
of City University, of the Centre for Software Reliability, or of the
translator.
2. Misprints in the original are the responsibility of the publisher.
3. Factual errors in the original are the responsibility of the author.
4. Errors in translation are the responsibility of my O-level French mistress.
5. I am not responsible for ANYTHING! ;-}
Peter Mellor
-------------------------------------------------------------------------------
2-Jun-90 21:52:18-GMT,1206;000000000005
Received: from csl.sri.com by hercules.csl.sri.com at Sat, 2 Jun 90 14:52:09 -0700.
(5.61.14/XIDA-1.2.8.35) id AA21147 for risks via SMTP
Received: from nsfnet-relay.ac.uk by csla.csl.sri.com at Sat, 2 Jun 90 14:52:03 -0700.
(5.61.14/XIDA-1.2.8.27) id AA04400 for risks@hercules.csl.sri.com via SMTP
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa21037; 2 Jun 90 22:37 BST
From: Pete Mellor <pm@cs.city.ac.uk>
Date: Sat, 2 Jun 90 18:53:19 PDT
Message-Id: <24420.9006030153@csrsun2.cs.city.ac.uk>
To: RISKS@csl.sri.com
Subject: Re: Airline Booking Cancellation (Risks 9.91)
Cc: barnes@xylogics.com, ellswort@cs.unc.edu, pm@cs.city.ac.uk
I have been asked for the full reference to the paper I referred to in the
above article. It is:
Adam R: "A licence to steal? The growth and development of airline information
systems"
Journal of Information Science 16 (1990), pp. 77-91,
0165-5515/90/$3.50, Elsevier Science Publishers B.V.
Apologies to anyone who had difficulty tracking it down. I will snail
photocopies if requested.
Peter Mellor
-------------------------------------------------------------------------------
2-Jun-90 21:52:48-GMT,8557;000000000000
Received: from csl.sri.com by hercules.csl.sri.com at Sat, 2 Jun 90 14:52:17 -0700.
(5.61.14/XIDA-1.2.8.35) id AA21156 for risks via SMTP
Received: from nsfnet-relay.ac.uk by csla.csl.sri.com at Sat, 2 Jun 90 14:52:09 -0700.
(5.61.14/XIDA-1.2.8.27) id AA04404 for risks@hercules.csl.sri.com via SMTP
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa21045; 2 Jun 90 22:37 BST
From: Pete Mellor <pm@cs.city.ac.uk>
Date: Sat, 2 Jun 90 21:41:40 PDT
Message-Id: <24825.9006030441@csrsun2.cs.city.ac.uk>
To: RISKS@csl.sri.com
Subject: Hacking, Viruses, and UK Law
Cc: nigel@cs.city.ac.uk, pm@cs.city.ac.uk
Recent raids on suspected hackers and the likelihood of anti-virus legislation
in the US (RISKS 9.95) should not make us forget what is happening in the UK.
The story so far:
In September 1988, the English Law Commission (ELC) issued a consultative
document, "Computer Misuse".
In April '89, Emma Nicholson, MP, proposed a private member's bill to make
various hacking activities illegal. This was generally thought to be poorly
researched, and too hastily drafted. It was roundly attacked in the Guardian
by, among others, Peter Sommer (aka Hugo Cornwall, author of "The Hacker's
Handbook). The bill failed for lack of time. (A frequent fate of private
members' bills.) [1]
In October 1989, the ELC published its final report on "Computer Misuse" [2].
This suggested three new offences. I quote from a summary by Peter Casey
of the DTI [3]:
- a basic offence which will apply to anyone who seeks to enter a computer
system knowing that the entry is unauthorised. This would be punishable by
up to three months imprisonment.
- a more serious offence of unauthorised entry into a computer system with
intent to commit or assist the commission of a serious crime. This would
be punishable by up to five years imprisonment.
- a further offence of intentionally and without authority altering computer
held data or programs, punishable with up to five years imprisonment.
Because of the international nature of computer misuse the Commission also
proposes reform of the jurisdiction rules to remedy a gap in the current law
whereby an offender initiating or furthering a crime completed abroad may
escape prosecution in any country. [End of quote.]
Another private member's bill implementing these proposals was introduced by
Michael Colvin, MP, and received its 2nd reading in the Commons on May 4th 1990.
Called the "Computer Misuse Bill", it has been amended to allow powers of search
and entry of suspected hackers' premises by police armed with a magistrate's
warrant. It passed its second reading with the amendment, but without stronger
amendments proposed by Emma Nicholson "to give magistrates powers to sign
warrants that extended that extended the police powers of search and seizure,
and for judges to sign warrants that allowed the police to intercept computer
communications....She pressed for an amendment that would oblige British
Telecom and Mercury, on the instructions of a magistrate, to begin surveillance
of designated communications traffic."[4]
The bill was attacked by Harry Cohen, MP. "The first major problem raised by
Cohen was that the bill doesn't define the term 'computer'. He also questioned
how the offence of 'unauthorised access' would be applied in practice. Cohen
pointed out that the lack of a definition raises the spectre of unauthorised
access to the microchip computers found in 'domestic appliances such as a
sewing machine with a programmable pattern, or a washing machine, video
recorder or compact disc player that can be programmed'. Even fax machines or
photocopiers would lead to some 'farcical prosecutions', he asserted.
However, other anomalies would arise if a defintion of 'computer' were
included. For example, if a computer were described in precise and exacting
terms, would the next technological development produce a computer that
was not a computer as defined by the Computer Misuse Bill?...In the end, it
was decided not to include a definition of computer in the bill, as this
would let the courts decide in each case." [4]
Cohen's second attack was more interesting. "...Cohen drafted three amendments
to ensure that the security procedures adopted by a computer owner could be
examined by the courts....if computer owners did not have security procedures
that sufficiently protected their computers from unauthorised access, the
hacker could get off. [From the basic charge of unauthorised access.]
Cohen's other two attempts were variants aimed at extending the Data Protection
Act to all computer operations. The MP argued that any individual who suffered
damage because computers, software or data were insecure or unreliable, should
be able to seek compensation from the owner via the courts or the data
protection registrar. The owners would have one main defence: to show that they
'had taken such care in all circumstances as was reasonably required' to
maintain the reliability and security of the computer, data or program in
question."[4]
(His amendments failed.)
The main arguments can be summarised as:
Cohen (quoting Francis Aldhouse, deputy data protection registrar) [4] :
"You've only yourself to blame if your neighbour's cattle get into your
unfenced field.", and:
"Logic dictates that computer owners should be legally responsible for the
security of their computers just as gun owners are responsible for their guns."
Nicholson [4]: "If a madman with a knife attacks another person in the street,
would the victim be responsible for not taking reasonable care to prevent the
attack?"
Sommer (arguing against Nicholson) [1]: "In fact, most of the computer-related
activities most people would think ought to be criminally sactioned already
are."
It will come as no surprise to UK readers to learn that Colvin and Nicholson
are Conservative, and Cohen is Labour, and that the government are being
supportive in such little matters as parliamentary time.
Interestingly, Colvin seems to favour some of Cohen's arguments. Speaking at
a contingency planning and disaster recovery seminar, he said: "If companies
do not invest in their own computer security strategy, then they cannot expect
the sympathy of the courts when people are charged under the provisions
proposed in my Bill." [5]
Also, Nicholson "plans to introduce a Computer Usage Bill in the autumn, which
will lay down rules for the use of computers covering maintenance, support and
upgrades." [5]
The truth of Sommer's argument is illustrated by the case of one Nicholas
Whiteley, appearing before Southwark Crown Court last week on seven charges
of criminal damage arising from hacks carried out during six months in 1988.
He admits the hacks, but claims he did no damage. (My private information is
that he overwrote files with joke messages, and the amount of damage was
estimated as &25 000. I also believe he was convicted, but haven't seen a
report of his sentence.) He hacked ICL series 39 machines at Queen Mary College,
Hull University, and Glasgow University. He told the court: "My messages weren't
a threat, they were just a wind-up." [6]
The Computer Misuse Bill, in the meantime, goes on to committee and then to the
Lords, then back to the Commons. If it succeeds, we should start worrying
about just how 'authorised' we are around September.
References:
[1] Hugo Cornwall: "Wrong ways on hacking", Guardian, 13th April 1989.
[2] The Law Commission report, Command 819, Criminal Law, Computer Misuse,
(Law Com. 186), HMSO, &5.60
[3] Peter Casey: "Proposals to curb computer misuse", JFIT News, Issue 8,
Nov. 1989, Pub. DTI/SERC
[4] Chris Robbins: "Hacking through both the Houses", Computing, 24th May 1990
[5] Lindsay Nicolle: "No sympathy for security slackers",
Computer Weekly, 24th May 1990
[6] Tony Collins: "Hacker exposes security of university systems",
Computer Weekly, 24th May 1990
============================================================================
Peter Mellor, |
Centre for Software Reliability, |
City University, |
Northampton Square, |
London EC1V 0HB |
|
Tel.: +44 (0)71-253-4399 Ext. 4162/3/1 |
Fax.: +44 (0)71-253-3861 |
E-mail: p.mellor@uk.ac.city (JANET) |
============================================================================
1-Jun-90 20:37:28-GMT,1933;000000000001
Received: from decpa.pa.dec.com by hercules.csl.sri.com at Fri, 1 Jun 90 13:37:24 -0700.
(5.61.14/XIDA-1.2.8.35) id AA12033 for risks via SMTP
Received: by decpa.pa.dec.com; id AA16880; Fri, 1 Jun 90 13:37:16 -0700
Received: by jumbo.pa.dec.com; id AA13895; Fri, 1 Jun 90 13:37:08 -0700
From: horning@src.dec.com (Jim Horning)
Message-Id: <9006012037.AA13895@jumbo.pa.dec.com>
Date: 1 Jun 1990 1336-PDT (Friday)
To: risks@csl.sri.com
Cc: horning@src.dec.com
X-Folder-Carbon: 90-Sent2
Subject: Re: RISKS DIGEST 10.01 ATM range-checking
In-Reply-To: Message of Fri, 1 Jun 1990 9:38:08 PDT from risks
It's pretty clear that different banks have different practices, as
well as diverse equipment. My bank (Wells Fargo) advertises that
they will credit you with an extra $10 if the ATM makes any mistake
on a deposit (and, indeed, I've never detected one). They also do
some range-checking. I haven't conducted extensive experiments, but
I recently deposited a check for an order of magnitude more than my
usual deposit, and was asked to confirm an extra time before the
transaction was completed. I thought that this was a very sensible
precaution.
In a related vein: When I first got my ATM card it was limited to
$200/day of cash withdrawal, which is not unreasonable. However,
after a decade of modest inflation, there were times (like just before
trips) when a larger sum would have been convenient. One day it
occurred to me to try to withdraw more, and what do you know? It
disbursed $300 without complaint. So my trips to the ATM became less
frequent. Some time later, I noticed that years of carrying the card
in my wallet had cracked it, right across the magnetic stripe. So
I asked for a new one. Now I'm limited to $200/day again. I infer
that it was a fault on the stripe that let me withdraw more. I would
have hoped that the limit was enforced by something less subject to
decay and/or tampering.
Jim H.
1-Jun-90 18:38:00-GMT,2087;000000000005
Received: from ucbvax.Berkeley.EDU by hercules.csl.sri.com at Fri, 1 Jun 90 11:37:54 -0700.
(5.61.14/XIDA-1.2.8.35) id AA10730 for risks via SMTP
Received: from apple.com by ucbvax.Berkeley.EDU (5.63/1.41)
id AA01089; Fri, 1 Jun 90 11:37:06 -0700
Received: by apple.com (5.61/25-eef)
id AA23116; Fri, 1 Jun 90 11:37:38 -0700
for comp-risks@ucbvax.berkeley.edu
To: comp-risks@ucbvax.Berkeley.EDU
Path: apple!chuq
From: chuq@Apple.COM (That's MR. Idiot to you)
Newsgroups: comp.risks
Subject: Re: Debate on SJG raid in comp.risks
Message-Id: <41534@apple.Apple.COM>
Date: 1 Jun 90 18:37:35 GMT
References: <CMM.0.88.644258310.risks@hercules.csl.sri.com>
Organization: Fictional Reality. We can write it for you wholesale
Lines: 29
Just to clarify one thing:
>>If you're running a BBS that's supporting a group of system crackers, you are,
>>at least, contributory to felony crimes...
>The problem was that SJG *was* clean, as far as I know -- the Secret
>Service just went overboard in their search for "contamination". I
>believe guilt-by-association is not a tenable legal theory in the US.
A couple of people have taken my comment above as implying I think
that SJG was running a cracker board. Not true. From everything I've
heard they are definitely in the "innocent bystander" category. Why
haven't they got their stuff back? Very good question. All I"m hearing
on my side is variations of "it ain't over until it's over" -- which to
me sounds silly based on what I know.
I am definitely NOT trying to justify the impounding of SJG stuff, nor
attempting to imply guilt or anything else at them. I was simply pointing
out that the situation was more complex than some were making it out to be.
The Secret Service seems to have good cause to talk to SJG about this stuff?
Yes? Did they need to go in and grab all the gear? From what I know, no --
but I don't know all the details of the case. The details I do know indicate
they over-reacted, however.
--
Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking]
It isn't easy being green. -- Kermit
1-Jun-90 17:30:53-GMT,1535;000000000015
Received: from BU.EDU by hercules.csl.sri.com at Fri, 1 Jun 90 10:30:03 -0700.
(5.61.14/XIDA-1.2.8.35) id AA09759 for risks via SMTP
Received: by BU.EDU (1.98) Fri, 1 Jun 90 13:29:53 EDT
Received: by alphalpha.com ( 5.52 (84)/test)
id AA08770; Fri, 1 Jun 90 10:51:56 EDT
From: nazgul@alphalpha.com (Kee Hinckley)
Message-Id: <9006011451.AA08770@alphalpha.com>
Date: Fri, 1 Jun 90 10:51:55 EDT
Subject: Re: 2600 article
To: RISKS@csl.sri.com
Please someone correct me if I'm wrong, but I think there's a Catch 22 here.
The evidence suggests that I can be arrested based on the contents/usage
of my BBS, even when I'm unaware of that usage. (It remains to be seen
whether I can be convicted, but frankly, if my equipment gets confiscated
for a couple years, I hardly care.)
However, it seems to me that the Electronic Privacy Act prevents me from
taking any actions which would let me prevent the misuse of my board.
Namely, I can't read people's mail/files to see if they are doing something
illegal.
Is this really the case?
-kee
+-----------------------------------------------------------------------------+
| Alphalpha Software, Inc. | Voice/Fax: 617/646-7703 | Home: 617/641-3805 |
| 148 Scituate St. | Smart fax, dial number. | |
| Arlington, MA 02174 | Dumb fax, dial number, | BBS: 617/641-3722 |
| nazgul@alphalpha.com | wait for ring, press 3. | 300/1200/2400 baud |
+-----------------------------------------------------------------------------+
-------
1-Jun-90 18:56:45-GMT,2144;000000000001
Received: from uunet.UU.NET by hercules.csl.sri.com at Fri, 1 Jun 90 11:56:40 -0700.
(5.61.14/XIDA-1.2.8.35) id AA11043 for risks via SMTP
Received: from ladcgw.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA12233; Fri, 1 Jun 90 14:55:47 -0400
Received: from l66a by ladc.bull.com (4.0/SMI-4.0)
id AB11989; Fri, 1 Jun 90 11:52:05 PDT
Date: Fri, 01 Jun 90 11:17 PDT
From: ZENITH <ZENITH@l66a.ladc.bull.com>
Reply-To: Zenith/A_Birner <Zenith/A_Birner@l66a.ladc.bull.com>
To: Risks@csl.sri.com
Really-To: Risks@csl.sri.com
Subject: Re: Steve Jackson Games and A.B. 3280 (Von Rospach, 9.97)
Message-Id: <900601.11502381.073361@L66A.CP6>
Chuq Von Rospach (chuq@apples.com) writes:
If you're running a BBS that's supporting a group of system crackers, you
are, at least, contributory to felony crimes.
By law? Why? We don't hold a package delivery service like UPS liable
if they happen to deliver burglary tools; why is the owner/operator of a
BBS treated differently for what seems to me an equivalent offense?
Von Rospach goes on to say:
A BBS that's on the up-and-up should have no worries, though.
That seems to be the central issue; it shouldn't be tossed off so casually.
The Bill of Rights is predicated on the assumption that the innocent have a
legitimate reason to worry about the effects of actions taken by their
government; governments to that point (and since) had not been terribly
worried about who got chewed up by the wheels of justice, so long as some
"guilty" party was convicted. Human nature has not changed much in the
intervening years--there are still those who hold to the creed of "Kill 'em
all; let God sort them out". We the innocent still need protection from
those who would elevate expedience over justice; if ease of implementation
and administration becomes the primary criterion by which we judge our laws,
we are in deep trouble.
I have noticed a disturbing trend in society, towards a belief that it is
better that 100 innocents should suffer than one guilty critter should go
free; it is difficult to reconcile this notion with that of "innocent until
proven guilty".
- Andy -
1-Jun-90 18:58:35-GMT,1334;000000000001
Received: from hp-sde.sde.hp.com by hercules.csl.sri.com at Fri, 1 Jun 90 11:58:19 -0700.
(5.61.14/XIDA-1.2.8.35) id AA11055 for risks via SMTP
Received: from hpcvxnkm.cv.hp.com by hp-sde.sde.hp.com with SMTP
(16.2A/15.5+IOS 3.13) id AA10029; Fri, 1 Jun 90 11:34:33 -0700
Received: by hpcvxnkm.cv.hp.com; Fri, 1 Jun 90 12:01:46 pdt
Date: Fri, 1 Jun 90 12:01:46 pdt
From: Nathan K. Meyers <nathanm@hpcvxnkm.cv.hp.com>
Message-Id: <9006011901.AA13609@hpcvxnkm.cv.hp.com>
To: RISKS@csl.sri.com
Subject: Risks of moderated newsgroups and COWABUNGA
Subject: Risks of moderated newsgroups and COWABUNGA
By now, most readers of moderated newsgroups on the internet have had
the pleasure of reading the semi-literate ramblings of "THE BIFFSTER".
As best I can tell, the following has been shown by this exercise:
1) Moderated newsgroups are not particularly secure (did anyone think
otherwise?).
2) You can make something foolproof, but you can't make it damn
foolproof.
3) The perpetrator may have reached a new world record in the irr/eff
ratio (irr = number of people irritated, eff = effort expended).
4) Gone forever are the days when breakins were conducted by individuals
with above-average intelligence and sense of humor (remember
moskvax!kremvax!chernenko many Aprils ago?).
Nathan Meyers
nathanm@cv.hp.com
1-Jun-90 20:23:24-GMT,2866;000000000001
Received: from bull.com by hercules.csl.sri.com at Fri, 1 Jun 90 13:23:19 -0700.
(5.61.14/XIDA-1.2.8.35) id AA11895 for risks via SMTP
Received: by sunshine.pws.bull.com from memora (sitting.pws.bull.com) (vers 4.1)
for RISKS@csl.sri.com (from wex@pws.bull.com (Warren Lavallee))
id <AA12745@sunshine.pws.bull.com>; Fri, 1 Jun 90 16:22:05 EST
Reply-To: <wex@pws.bull.com>
Received: by memora (14.5/client 11-8-89)
(for RISKS@csl.sri.com) id AA22392; Fri, 1 Jun 90 16:22:10 edt
Date: Fri, 1 Jun 90 16:22:10 edt
From: wex@pws.bull.com
Message-Id: <9006012022.AA22392@memora>
To: RISKS@csl.sri.com
Subject: Computer to track down drivers without insurance
The following is excerpted from a UPI newswire story:
BOSTON (UPI) -- Tens of thousands of illegally uninsured drivers in
Massachusetts will be tracked down and hunted when the Registry of Motor
Vehicles implements a new computer-based system beginning Friday [6/1/90].
The new system, which allows insurance companies to electronically
send the Registry's computer a list of uninsured motorists whose
policies have been revoked for nonpayment, aims at cracking down on the
estimated 300,000 Massachusetts drivers who take to the roads without
insurance.
``Hopefully with automation, deadbeats who don't have the money or
those who try to beat they system won't be on the road,'' said Robert
Hutchinson, Massachusetts registrar of motor vehicles.
Police will pursue those individuals who fail to obtain insurance
after being discovered.
[Generic filler about the costs of uninsured motorists - sky-high -
and the hope that the computer will do what the people are unable to do:
keep up with the workload.]
The significance of this is that there is a new law in MA: get caught
driving without insurance and the cops can take away your license plates on
the spot. You then get to call a tow truck, since you can't drive without
plates. Get caught driving without plates and you get to call a cab, since
the cops can have your car towed on the spot.
The problem is that insurance companies in this state are notoriously slow
in processing paperwork. That's a major reason why so many uninsured
motorists get away with it; the paperwork just hasn't caught up with them.
The companies take this long with *all* their paperwork. My company took
four months to send me a reinstatement notice after they (erroneously)
suspended my insurance for not having the car inspected (though they
continued to bill me every month). I shudder to think what would have
happened had I been stopped during those four months...
--Alan Wexelblat
Bull Worldwide Information Systems internet: wex@pws.bull.com
phone: (508) 671-7485 Usenet: spdcc.com!know!wex
The taxes of every American west of the Mississippi are used to pay off
the interest on the national debt.
1-Jun-90 20:41:58-GMT,1950;000000000001
Received: from SCFD.NWC.NAVY.MIL by hercules.csl.sri.com at Fri, 1 Jun 90 13:41:50 -0700.
(5.61.14/XIDA-1.2.8.35) id AA12117 for risks via SMTP
Message-Id: <9006012041.AA12117@hercules.csl.sri.com>
Date: 1 Jun 90 13:34:00 PDT
From: "FIDLER::ESTELL" <estell%fidler.decnet@scfd.nwc.navy.mil>
Subject: Local solution to caller ID .vs. Privacy problem
To: "risks" <risks@csl.sri.com>
The following is by definition going into the Public Domain. (If RISKS
posts it.) If that costs me any chance to make a fortune from AT&T,
maybe it also raises the possibility that the solution will come sooner.
Problem: Some of us want to know "who is calling."
BUT some of us don't want others to know when WE call.
Solution: Put the smarts for "who are you?" and "none of your business"
[or, "I'm 555-1234"] in the handsets, at each end,
NOT in the switch [or switches, for long distance calls].
Old handsets would automatically neither request caller ID, nor give it.
Folks who want to know would buy new handsets; when they get calls from
old handsets, the reply to the "who are you?" query would be, "service
not available" [as opposed to "none of your business"]. Yes, a smart
switch would have to provide that, probably after a time-out of sorts;
and yes, that could be spoofed. Nothing is perfect.
(But wait. Could even an old handset, touchtone or rotary, reply manually
to a ring, while the line was open? That is, I call you, and you want to
know who I am; your query is forwarded to my old handset as a ring; to send
you my number, I dial it; the intermediate switch aborts the call, with an
appropriate message to you, if it detects my attempt to falsify my ID.)
It is then up to the callee to accept or decline the incoming call; and,
it is up to the caller to risk losing the connection. That effectively
takes the decisions out of the hands of big brother, and puts them back
with us, where they belong.
Bob
1-Jun-90 23:39:19-GMT,3226;000000000001
Received: from fernwood!ames!harvard!spdcc!esegue.UUCP by hercules.csl.sri.com at Fri, 1 Jun 90 16:39:12 -0700.
(5.61.14/XIDA-1.2.8.35) id AA14577 for risks via UUCP
Received: from ames.UUCP by fernwood.mpk.ca.us at Fri, 1 Jun 90 15:54:54 -0700.
(5.61.14/XIDA-1.2.8.34) id AA02462 for risks via UUCP
Received: from harvard.harvard.edu by ames.arc.nasa.gov (5.61/1.2); Fri, 1 Jun 90 15:53:03 -0700
Received: by harvard.harvard.edu (5.54/a0.25)
(for fernwood!hercules!risks) id AA29983; Fri, 1 Jun 90 18:53:00 EDT
Received: by esegue.segue.boston.ma.us (smail2.5+)
id AA07773; 1 Jun 90 18:33:46 EDT (Fri)
To: marc@csl.sri.com
Subject: Re: Denial of service due to switch misconfiguration
Organization: Segue Software, Cambridge MA
Bad-Cc:
Date: 1 Jun 90 18:33:46 EDT (Fri)
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Message-Id: <9006011833.AA07773@esegue.segue.boston.ma.us>
In every PBX I have ever dealt with, there have been foulups of some sort when
dealing with new telephone prefixes and area codes. In one memorable case, I
was trying to straighten out a problem with my mortgage, and the person at the
bank never, ever, returned my calls. I was about ready to call in the bank
regulators. After leaving quite a few tartly worded messages, I finally
managed to get her on the phone, and discovered that every time she called me,
she'd gotten an error recording of some sort and had assumed that the number
she had was wrong or my phone was out of order. In fact, I had just started
to work at a job with a new PBX with a new set of DID numbers in a new prefix,
and the PBX at the bank hadn't heard about my prefix yet. I told her to dial
9-0 and ask the telco operator to place the call in the future.
Even PBXes with class of service restrictions frequently get it wrong. At one
place where I consult they forbid international dialing for most lines except
for some speed dial codes programmed into the PBX. At least, they think they
do. If I dial 011-code-number, I get a fast busy from the PBX. If I dial
01-code-number and make it person to person, it works. If I dial
10288-011-code-number or 10222-011-code number or 10333-code-number, it works.
(If only I had some friends in foreign countries to call.)
The local telco has a newsletter that they send out to advise PBX customers of
new prefixes, upgrades to CO equipment (which always cause some problems since
if nothing else, call progress sounds and the timing of calls change.) There
are a lot of changes. As far as I can tell, every PBX that does least cost
routing needs to know all of the prefixes in its local area code, and in most
cases the updates are typed in by hand using some decidedly user hostile
interfaces. If anything, I'm surprised that they get them right as often as
they do. In many cases, I suspect that the PBX manager only updates the
prefix table when somebody complains.
Telephone calls are routed by what is in effect a tremendous distributed data
base that maps numbers to trunks and routes. At least near the fringes, the
data base is usually updated by methods that to me at least seem laughably
obsolete.
Regards,
John Levine, johnl@esegue.segue.boston.ma.us, {spdcc|ima|lotus}!esegue!johnl
2-Jun-90 6:26:11-GMT,3759;000000000001
Received: from karazm.math.uh.edu by hercules.csl.sri.com at Fri, 1 Jun 90 23:26:07 -0700.
(5.61.14/XIDA-1.2.8.35) id AA17063 for risks via SMTP
Message-Id: <9006020626.AA17063@hercules.csl.sri.com>
Received: by karazm.math.uh.edu id <AA21443@karazm.math.uh.edu>; Sat, 2 Jun 90 01:25:37 CDT
From: J. Eric Townsend <jet@karazm.math.uh.edu>
Subject: What the SJG Cyberpunk Manual Tells You to Do
To: risks@csl.sri.com
Date: Sat, 2 Jun 90 1:25:34 CDT
X-Mailer: ELM [version 2.2 PL13]
Well, I rushed out and bought GURPS Cyberpunk, in the hopes that my
money will help SJG with legal fees. (Plus, I collect game stuff.)
On the front cover, in the SJG Illuminatus logo, it says:
"The book that was seized by the U.S. Secret Service! (see p. 4)"
Anyway...
(Assuming I know *nothing* about cracking/phreaking. I won't comment
on my real knowledge.) The following is a summary of text from the
GURPS Cyberpunk supplement, with a few direct quotes.
How Much Hacking Can I Do Based on the C-word manual:
(From the section entitled "Netrunning".)
0. People use handles to hide their real identity (p62).
1. You can uses sensitive devices to listen in on the signals being
sent to a computer monitor, and redisplay the image on your own screen
(p62).
2. General info on ISDN. (p64-64)
3. Computer accounts can come in various levels, from specialty logins
(uucp) to "superuser" who has access to everything. Some programs can
give you a higher level of access, equivalent to a "better" account (p68).
4. General info on back doors (p69).
5. General info on chat systems (p69).
6. A list of network names from around the world. No clues as to which
are real. For the US, the following are listed:
WUT, UDTS 2, Datel I & II, Telenet, Tymnet, ARPAnet, Infomaster, GraphNet,
TRT, FTCC, UniNet, Autonet, CompuServer, GENIE, AlaskaNet, JANET, Internet
(p 71).
7. Passwords can be really obvious, or hard to remember random text strings
(p 72.)
8. A program could possibly cause physical damage (p 72.)
9. General Phreaking Info:
- Diverters: go through a bunch of systems so that tracing takes
a long time;
- Junction Boxing: Just go down to the local junction box and tie in
(p 76).
10. Lots of networks use different protocols that are sometimes
incompatible (p 77).
11. Ma Bell stuff:
- Existence of CN/A, and that Ma Bell can look you up in any way;
- Line Routing: "With access to the main phone switch computer,
a hacker can control everything about a specific phone line.";
- Monitoring: a person could monitor calls with the right access;
- After Billing: A person could change bills;
(p 82).
12. Trashing: Go through somebody's trash to find out all sorts
of interesting info about their computing equipment (p 86,87).
(13 and 14 are from the section "Attack and Defense Programs". The
programs are obviously s-f software, but...):
13. Promote: "This program is executed from a normal user account on a
system. If successful, the account is 'upgraded' to a superuser account."
14. Webster: "This is the standard icebreaker for use against Password
programs (see p 93.). It acts as an extremely fast 'brute-force' hacker."
(p 92).
15. Credcard Crime: A false balance could be entered in an account.
A device could be used to access somebody else's card without having
the correct password to get into the credcard (p 105). [note: a credcard
is a self-contained debit card that can have anything from a pasword to
retina scan protection.]
And, um, that's about it. Now that you've read that, you know how to break
into computer systems and do phone phreaking... 1/2 :-)
--
J. Eric Townsend -- University of Houston Dept. of Mathematics (713) 749-2120
Internet: jet@uh.edu
Bitnet: jet@UHOU
Skate UNIX(r)
2-Jun-90 22:01:18-GMT,1998;000000000001
Received: from uunet.UU.NET by hercules.csl.sri.com at Sat, 2 Jun 90 15:01:13 -0700.
(5.61.14/XIDA-1.2.8.35) id AA21223 for risks via SMTP
Received: from talos.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA26062; Sat, 2 Jun 90 18:01:06 -0400
Date: Sat, 2 Jun 90 17:59:33 EDT
From: kjones@talos.pm.com (Kyle Jones)
Message-Id: <9006022159.AA19604@talos.pm.com>
To: RISKS@csl.sri.com
Subject: Re: Word Perfect Software Upgrade Crashes Utah Phone System
m1wmk00@fed.UUCP writes:
> From an Infoworld article on Word Perfect ("Leader of the Pack,"
> pp. 45-6, May 23, 1990):
>
> "When [Word Perfect] 5.0 shipped in May 1988, the company underestimated
> the demand for telephone support. Although it bought additional phone
> lines, traffic was so heavy that calls to the support department brought
> down the toll-free systems for the state of Utah, including phone systems
> for American Express, Delta Airlines, and the Latter Day Saints Church."
This reminds me of something that happened in my own neck of the
woods.
One night I was watching a program on channel 35 when a message
flashed on the screen. The message said that the Xth caller
would win concert tickets or some such. Since the phone was
right beside me, I decided what the hey, and picked up the phone
to call. I didn't get a dial tone for the long time. Odd.
Finally I heard the tone and dialed the number. I waited. And
waited. And waited. No connection, no ringing, no click,
nothing.
Thinking I'd misdialed somehow, I depressed the switchhook to try
again. I waited for the dial tone. And waited. And waited.
And waited! Suddenly it occurred to me, the number began with
358-... my exchange, augh. Apparently the massive influx of
calls to the TV station completely hosed whatever gateway there
was for my exchange, so I couldn't get a call in edgewise. (Does
this sound right to you folks who know something about the phone
system?)
Whatever the reason, I'm glad the house wasn't on fire. :-/