The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 13 Issue 05

Wednesday 22 January 1992


o Another A-320 crash in France
o California Judge recommends NO on CALLER ID
o Re: Gulf war virus?
Andrew Klossner
o Chicken Little and the Computer
A. Padgett Peterson
o CPAs leary of electronic filing
Paul Schmidt
o Re: AT&T machines and dates
Chris Traynor
Daniel J Yurman
o A Tale of Risk Avoidance
Kai-Mikael J\d\d-Aro
o A little knowledge can lead to understanding the universe
Armando P. Stettner
o Risk of computer-generated overhead foils
Jonathan Bowen
o MacNeil/Lehrer Report on Phone System Risks
Randall C Gellens
o Re: Automated bill collectors, privacy, ...
Marc Shannon
o Re: Ohio justices fight over computer snooping
Bob Frankston
o IEEE Software Safety
Tony Zawilski
o IEEE Oakland Security and Privacy Symposium Preliminary Program
John McLean
o Info on RISKS (comp.risks)

Another A-320 crash in France

Tue, 21 Jan 1992 10:00:56 -0500 (EST)
By Michela Wrong (REUTERS 21 Jan 1992)

   PARIS, Jan 21, Reuters - The Airbus A320, a model of which crashed in France
on Monday night killing 87 people, has been dogged by controversy since before
its 1987 launch, with critics arguing that its computerised controls are too
sophisticated.  A French Air Inter A320 on a domestic flight ploughed into a
mountainside in snow and fog shortly before it had been due to land at
Strasbourg, giving no distress signal.  Only nine of the 96 people on board
survived.  The narrow-bodied 150-seater became the world's fastest selling
plane even before its 1987 maiden flight, notching up over 200 orders.  It is
central to Europe's challenge to U.S. planemakers for dominance of the world
civil aviation market.
   But Airbus Industrie, a consortium of French, German, British and Spanish
firms, has fought to win acceptance for the advanced avionics first put to
civilian use in the A320.  "Each time (one crashes) the crew is blamed whereas
the responsibility is really shared in the hiatus between man and machine,"
said Romain Kroes, secretary-general of the SPAC civil aviation pilots' union.
   In a technique previously used only in combat aircraft, commands are sent
electronically rather than hydraulically.
   Pilots say the system restricts what they can do in a crisis by setting
built-in limits on the plane's movements.  They objected to a cut in the number
of cabin crew on the A320 from three to two.
   Airbus insists that "fly-by-wire" is safer in an emergency, allowing pilots
to know how far they can push the plane without causing a disaster.
   Kroes said the latest crash, which followed accidents in France and India,
proved that pilots' fears were well-founded.  "There are numerous faults in the
way man-machine communication and the cockpit have been designed on the A320...
since the Habsheim and Bangalore crashes it has been clear to us that the crews
were caught out by cockpit layout," he said in a radio interview.
   In June 1988, one of the first models sold to Air France crashed during a
demonstration flight in eastern France.  The plane cruised into a thicket of
trees, killing three aboard.
   A commission of inquiry accused pilot Michel Asseline of "cowboy-like
behaviour" for flying too low and concluded that there was nothing wrong with
the aircraft.  But Asseline, who survived, insisted that the plane's equipment
had failed to alert him to the loss of altitude.
   A report commissioned by the victims' families found that standard
procedures with flight recorders following a crash had been flouted.  The main
French pilots' union, SNPL, was convicted of libel for accusing the authorities
of tampering with the recorders to absolve the plane and protect Airbus sales.
   The controversy resurfaced in February 1990 when an Indian Airlines plane
crashed at Bangalore Airport, killing 90.  Indian authorities grounded all
Airbuses after the Indian Commercial Pilots Association blamed a systems
   But a judicial inquiry concluded that the pilots were to blame for putting
the engines on the wrong setting, which made the plane fly too slowly.
   Airbus, which sent four experts to the scene of Monday's crash, declined to
speculate on the cause, saying it would await the results of an official
   But company sources said there was no reason to think that fly-by-wire had
played a role.  Bad weather and the mountainous terrain were more likely
factors, they said.
   Created in 1970 as a European challenge to U.S. giants Boeing Co. and
McDonnell Douglas Corp., Airbus has received a total of 661 orders for the
A320, with 251 already delivered.  The consortium of British Aerospace PLC,
France's Aerospatiale, the Deutsche Airbus subsidiary of Germany's Daimler-Benz
AG and Spain's CASA has 26 per cent of the world market.
   The fly-by-wire technology used in the A320 is due to be adopted in a new
four-engine A340 wide-body Airbus, which is being flight tested, and may also
be used in a 600-seater that is in the planning stage.

     [The 22 Jan 1992 San Fran Chron, p.A7, notes Agence France-Presse,
     citing informed sources, said that the aircraft made an abrupt 2,000-foot
     drop on its approach to the Strasbourg-Entzheim airport.  PGN]

California Judge recommends NO on CALLER ID

"Peter G. Neumann" <>
Wed, 22 Jan 92 10:59:29 PST
California administrative law judge John Lemke has declared that Caller ID
would be an unwarranted privacy invasion in an opinion that now goes to the
state Public Utility Commission, which is expected to issue a final decision in
the next two months.  He recommended approval of other proposed services, Call
Trace, Call Block, Call Return, Repeat Dialing, Priority Ringing, Select Call
Forwarding, Special Call Waiting, and Special Call Acceptance, which he said
could provide the benefits of Caller ID without the detriments.  (Caller ID has
been approved in 20 U.S. states, Washington D.C., and Canada.)  [San Fran
Chronicle, front page 22 Jan 1992]

Re: Gulf war virus?

Andrew Klossner <>
Tue, 21 Jan 92 14:21:33 PST
    "How could a "printer" infect a computer with a "virus"?"

One technically straightforward approach would be to plant the agent in a
printer that will be connected directly to a network.  For example, Macintosh
printers are typically connected to an Appletalk network, where they enjoy full
peer privileges.  There is nothing to prevent such a printer from snooping
around the network attempting to find and compromise other servers.

[My employer, a printer manufacturer, doesn't do this sort of thing.]

Andrew Klossner (, uunet!tektronix!frip.WV.TEK!andrew)

Chicken Little and the Computer

A. Padgett Peterson <>
Tue, 21 Jan 92 10:03:40 -0500
   "and so the brave little printers destroyed all of the Evil Empire's
computers and they lived happily ever after." - Some of the items seen in the
last year bear a remarkable resemblance to the works of Hans Christian Anderson
but then it just goes to prove P. T. Barnum's axiom.

     The simple fact is that the public will believe anything the public wants
to believe, particularly when it deals with "magic".  As a result we have
printer viruses, modem viruses, CMOS viruses, and on, and on, ad nauseum.
(Actually I like Aryeh Groetsky's story of a virus that infects floppy disk
drives and toasters that causes both to eject their contents at lethal

     This is not to say that there hasn't been a printer virus (actually a
trojan - it scrambled the password in Postscript printers rendering them
inaccessible), rather that information does not flow both ways (not that it
can't, both zero slot LANs such as Lantastic-Z (R I'm sure) and a nifty program
by Diacom (plug) that comes with a cable to connect my car's computer to a
laptop and lets me find out what is going on inside utilize bidirectional
communications through the parallel port) without help from a program inside
the computer (I am told that Dan Jenkins, one of my favorite authors, dislikes
parenthetical statements immensely).

     This was the underlying problem with that Army RFP about radio transmitted
viruses (understand that there were two grants made for phase one @ $50k each):
Building a virus is easy (too easy), transmitting the virus via radio is easy,
the hard part is getting the other guy's computer to retrieve & execute it.  Of
course, if you can design the listener into the other guy's computer, you've
got it made - see the French Novel "SoftWars" (not the current paperback of the
same name, this one was earlier) for a description of one method. As I recall,
the basis was a weather computer tied to Soviet defense systems and the program
was designed so that if St.  Kitts reported some impossible temperature...

     Of course, the problem is that to understand what can and what cannot be
done you must understand the architecture and that actually takes some research
on the subject (shudder) - something abhorrent to the public and, while not
unusual for a journalist, is really not what most get paid for (no-one is more
ignorant than an expert speaking out of their field). Besides phone calls are
more fun.

     So what happens ? - a rumor starts, often innocently - like the April
Fool's "InfoWorld" parody (incidentally one of the three best weekly PC
magazines). However, for a parody to work it has to be just a bit off center,
something obvious to experts but close enough to reality to be possible,
especially when quoted out of context. In fact, as I recall, there were two
similar stories at that time with the other in PC-Week).

     So the rumor starts and the first thing that happens is journalists start
calling up "experts" and asking "could this happen ?"  with the predictable
responses: "Uhhh", "If the SendMail buffer overflowed into the command
queue...", "If the muffler bearings spun the transmission backwards..."  and
other techno-babble. Point is, it takes a lot of confidence to stand up and say
"It can't happen." - besides, the journalist will then call up someone else who
will say "It could" & guess which gets printed tomorrow ?

     And so the headline comes out: "Army infects Iraqi computers with virus
shipped in printers from Jordan". One comment made by a neighbor (remember, my
house is only a half mile from Universal Studios) during televised coverage of
the Gulf War sticks in my mind: "Universal could have done it better" & the
"printer virus" is a natural. - You will, Oscar, you will.

CPAs leary of electronic filing

Paul Schmidt <tijc02!pjs269@uunet.UU.NET>
Tue, 21 Jan 92 09:28:59 EST
Several CPAs in town are not using the electronic filing offered by the I.R.S.
Why?  Because the I.R.S. initiates the phone call to the CPA's office to
retrieve the form.  This means that the I.R.S. would be accessing computers
remotely.  Tax preparers are worried that the I.R.S. could get more than a
person's tax information by accessing all of the data on the computer.

The solution that some tax preparer's are using is to have a separate,
dedicated computer for filing electronically.  They put only the tax forms onto
this computer.  This is an easy solution since they could probably get by with
just a floppy drive.

Another threat is that someone else could call the tax preparers computer and
get the information.
                                           Paul Schmidt

Re: AT&T machines and dates (Thomson Kuhn, RISKS-13.04)

Tue, 21 Jan 1992 11:44:36 -0500
    The posting made in RISKS-13.04 concerning AT&T machines seems to have
been a little over-inflated and wrongly put by the writer.  If he had indeed
spoken to the VAR he would have been told that the date problem existed SOLELY
on AT&T 6300 models - these were made around 83 and have 8088 CPUs.  The
company did not expect these machines - in their current configuration to last
as long as they have (one point for us).  It is a simple matter to upgrade the
bios or use the date patch [Let us note that this warning is made clear to
users if they ever read manuals].
    I thought this list existed for the purpose of discussing risks, not
for editing of the truth to make a story YOUR OWN...

Chris Traynor, AT&T Bell Labs

Re: AT&T machines and dates (Thomson Kuhn, RISKS-13.04)

Daniel J Yurman <>
Tue, 21 Jan 92 7:28:02 MST
In RISKS-13.04 Thomson Kuhn notes that AT&T PCs cannot set the date to 1992.
The reader may be referring to and old, and well known "feature" of the XT
class AT&T 6300.  This MS-DOS machine, based on the Intel 8086, had a clock
chip which ran out of gas at the end of 1990.  Many PC user groups have since
circulated several software patches to this problem which effectively add five
years to the clock chip date.  These programs typically are loaded in the
config.sys file and the user may merrily compute with the '6300 until the
device falls apart from age.

The application to RISKS is that users, especially small businesses and home
users, do not care about double declining depreciation schedules nor the
technology refreshment rate of Intel-based personal computing.  Once they've
bought a machine this class of users has every intention of running it into the
ground until it is no longer functioning, or, passing it on to their children.
The manufacturer of the AT&T 6300, which as the Italian firm Oliveti, built the
'6300 like a tank and mine, built in early 1986, is still surviving the
assaults of four teenagers and one freelance writer.  The only thing it objects
to is temperatures below 65 F.  Obviously, the engineers who designed the
system thought any user worth his salt would give the '6300 the old heave ho
within five years and so limited the clock chip accordingly.

Dan Yurman, Idaho National Engineering Lab., PO Box 1625  MS 3900
Idaho Falls, ID 83415            Phone: (208) 526-8591    Fax: (208) 526-6902

A Tale of Risk Avoidance

"Kai-Mikael J\d\d-Aro" <>
Tue, 14 Jan 92 14:06:04 MET DST
[Disclaimer: I'm not trying to sell anything (in fact, none of the stuff I
mention can be bought anyway), I just had a fascinating experience I'd like to
share with you.]

I had been toying around with vtalk (an Ethernet-telephone for
SPARC-stations from Oki Elektric Industry, Co.) and tried to add some bells
and whistles to it.

Now, in the line of my studies came the exhortation "Be formal!". I have been a
bit dubious of formal methods, they have seemed as a lot of sweat for obvious
results.  But anyway, I thought it could be nice to at least draw a little
automaton so that I could have a pretty picture of all signals going back and
forth between the processes of the parties.

I had Anneli Avatare, a coworker from SICS, over and we both worked for perhaps
an hour drawing up an automaton on the wyteboard and trying to account for all
signals. This wasn't a very large design, so after having both gone over it we
were satisfied that it seemed sound.

Now Anneli suggested that we test the design in the Graphical Concurrency
Workbench, GCW, on which she had worked.  I had used the Concurrency Workbench
before and disliked it, but the GCW was a new acquaintance.  I got in to SICS
the next morning, where Anneli had already drawn most of the automaton.

A little background is in order: CWB, the Concurrency Workbench is a tool
developed by the Swedish Institute of Computer Science and the University of
Edinburgh which allows the user to enter definitions of concurrent
communicating processes and validate them, check for deadlocks, minimise the
state space and so on.

As the name suggests, GCW is a graphical front-end to CWB and is implemented as
an application on top of LOGGIE, a meta-tool for generating language-oriented
graphical editors.

We finished up the automaton and toyed around a bit, fascinated by the
(relative) ease with which we could neaten up the graph, redoing nodes and

Then we got to testing the design.  We created a pair of the automata and
connected them to each other as the two parties.

We could then simulate the design by "sending signals" to the processes and see
how little pucks moved from one state to another.  To our surprise we soon
managed to run the processes into a deadlock.  We stared at the trace and
realised we had forgotten to handle the reply signal from a sequence of
hangings up and callings up.  It was obvious what the fix was, and we could
just add the missing vertex to the graph.

Now we tried automatic deadlock finding and watched as GCW ran through the
state space moving the pucks along and found two more potential deadlock
situations, both in which the fix was as trivial as in the first case.

Now, the moral of this story is perhaps not so much How Formal Methods Carried
The Day And Saved My Program, but something more on the psychological side: I
had been exposed to formal methods all through my professional education, but I
had never realised the point of them and generally regarded them as a nuisance.
Now, suddenly there was a way for me to work out the definition of a process
*interactively*, easily amending any problems in the process, the graphic
display giving me a clear picture of *why* my ideas were faulty, showing me
*how* I got in the mess I was in and suggesting ways to get out of there.
Perhaps the moral can be stated as: When Formal Methods Are Fun And Simplify
Your Work, Then You Will Also Want To Use Them.

Kai-Mikael J{{-Aro, IPLab, NADA, KTH, S-100 44 Stockholm SWEDEN +46 8 790 91 05

A little knowledge can lead to understanding the universe

Armando P. Stettner <>
Mon, 13 Jan 92 01:03:21 -0500
While purchasing some pre-recorded cassette tapes for my mother for Christmas,
the clerk placed all 15 of them down on one of those pads that have a big sign
reading "Don't place credit cards or ATM cards on or near this device!"

I asked "if this thing can cause damage to the magnetic info on cards, is it
safe for other things magnetically encoded to be placed on it?"  After
conferring with another clerk (while the tapes continued to sit on the pad),
the first clerk said it is better to be safe than sorry and started to move

Upon hearing this short discussion, a third, more pompous clerk came over and
said that these pre-recorded tapes can't be damaged by this device.  She went
on to say "there is this little plastic tab" on the back edge of the cassette,
which, when punched out, "prevents *any* inadvertent erasure or recording!"

I did not know where to begin....  But clearly an example of a little knowledge
can be dangerous.

Risk of computer-generated overhead foils

Tue, 14 Jan 92 01:01:35 +0100
A mildly amusing incident happened during the opening talk by O J Dahl today at
a workshop on Software Construction here at Schloss Dagstuhl in Germany. He
started his talk and a few minutes in, whilst fumbling with his foils, he
suddenly realised that they had all been printed the wrong way round on the
attached paper side rather than the transparency side. Always check your
computer-generated slides before your talk! The replacement talk used good old
hand written foils and thus avoided this (50%?!) "risk". :-)

Jonathan Bowen, Oxford University Computing Laboratory

MacNeil/Lehrer Report on Phone System Risks

Randall C Gellens <>
Tue, 21 Jan 92 08:46 GMT
   [Forwarded from the Telecomm Digest by <>]
    TELECOM Digest     Tue, 21 Jan 92 19:31:53 CST    Volume 12 : Issue 68

The MacNeil/Lehrer News Hour for Monday, January 20 contains a report (about
twenty minutes or so in length) on the risks of the phone system ten years
after the breakup.  It includes the fire at the Chicago POP of all three
carriers, the power failure in New York, the spate of software-induced outages,
and lots more.  Interviewed are executives from AT&T, MCI, and Sprint (the
Sprint and MCI execs say how scared they were when the New York power failure
hit, because if it could happen to AT&T it could happen to them), workers
talking about staff cutbacks, FCC officials, Congressmen, phone users, and
others.  It includes footage of hearings, shots of a 4ESS, fiber trenching, and
horrendous amounts of cable inside a switching center.

If you missed it live, you can order a transcript or a videotape.  I forget the
address for transcripts ($4), but the videotape number is (800ed) 328-PBS-1 (no
price mentioned).  (I have no connection with PBS or MacNeil/Lehrer).

Re: Automated bill collectors, privacy, ... (MacKinnon, RISKS-13.03)

Marc Shannon <R602MS5U@VB.CC.CMU.EDU>
Sun, 12 Jan 1992 14:05 EST
I have had a similar call to Bryan's (an automatic credit dunning system).
When I received the message saying "if you are John Doe, press <1>", I pressed
<1>.  The system then informed me that listening to this message was an
invasion of privacy and if I really wasn't John Doe, I'd be in serious trouble.

How can this be so?  *They* called *me*!  Don't I have the choice of what I
want to do with a call that is placed to my number?

My intention in finding out that poor Mr. Doe had a credit problem was simply
to find the number of the company that originated that message and inform them
of the error in their database, which I did do.  The woman with whom I spoke
about the problem was very sympathetic to my concerns of receiving unwarranted
phone calls and assured me that their database would be corrected.  It must
have been fixed as I have not received any more calls from them since.

The bottom line: I *HATE* these computer generated phone calls.  If someone is
calling with personal information, it had better be a person so that such
errors can be detected (and apologized for) before the personal information is
given out to someone it shouldn't be.  At least, to the benefit of this
company, they did give me a contact number.  I have, in the past, received such
calls telling me that I (no name given in that message) was in trouble with
company X and I should send in payment immediately.  They didn't leave a number
to discuss it with a human.

Sigh...are we starting to rely on computers a bit much?

--Marc Shannon

Re: Ohio justices fight over computer snooping (Harding, RISKS-13.04)

Tue 21 Jan 1992 16:58 -0500
Snooping is not new.  What is, perhaps, new, is naivete about the accessibility
of information.  Back in the old days of Multics, security was viewed as a key
system facility.  This wasn't just because of ARPA funding, but also because
the computer utility had to embody social conventions beyond those needed in a
calculator.  The default access to a user's information was no access.  This
was in keeping with the convention that one doesn't paw through another's desk.
While one can argue that locking desks is not the norm, the ability to
surreptitiously browse from another terminal requires something beyond simple

Unfortunately, many newer systems in a misguided attempt to be friendly
either ignore access control entirely or default the systems to give the
world, or at least, colleagues read access.

The moderator and other readers can provide more details of the evolution of
these conventions.  And I'm sure newspaper staffers can tell about the
entertainment of reading others' drafts.

IEEE Software Safety

Tony Zawilski <>
Wednesday, 22 Jan 1992 10:44:29 EST
I am writing as Vice Chair of the IEEE P1228 Working Group on Software Safety.
We have been working since October of '89 on a standard for Software Safety
Plans.  The SSWG has some 150 members, and we are now very close to submitting
final draft to the IEEE standards hierarchy for balloting.  We will be mailing
out this last draft to our SSWG membership for review and comment this week.
All comments would be due back at the end of February, and then the final
version would be completed at our March 6 meeting.  We would like to assure a
broad base of comments, so if any of the readers of RISK would like to be
included on the mailing list to receive this draft, please have them email
their mailing address, email address, and telephone number to:
Their names will be added to the mailing list for future mailings.
Thank you for your courtesy.
Tony Zawilski

Oakland Preliminary Program

John McLean <>
Tue, 21 Jan 92 17:55:27 EST

8:45--9:00: Welcoming Remarks: Deborah Cooper, John McLean

9:00--10:30:    DISTRIBUTED SYSTEMS: John Rushby, Session Chair
  9:00-- 9:30:  On Inter-Realm Authentication in Large Distributed Systems
            Virgil Gligor, Shyh-Wei Luan, Joseph Pato
  9:30--10:00:  Integrating Security in a Group Oriented Distributed System
            Michael Reiter, Kenneth Birman, Li Gong
 10:00--10:30:  Authorization in Distributed Systems:  A Formal Approach
            Thomas Woo, Simon Lam

10:30---11:00:  BREAK

11:00--12:00:   COVERT CHANNELS:  Tom Berson, Session Chair
  11:00--11:30: Lattice Scheduling and Covert Channels
            Wei-Ming Hu
  11:30--12:00: The Influence of Delay Upon an Idealized Channel's Bandwidth
            Ira Moskowitz, Allen Miller

12:00--2:00:    LUNCH

2:00--3:00: INVITED SPEAKER: John McLean, Session Chair

3:00--3:30: BREAK

3:30--5:00: CRYPTOGRAPHIC PROTOCOLS: Dan Nessett, Session Chair
  3:30--4:00:   Encrypted Key Exchange:  Password-Based Protocols Secure
        Against Dictionary Attacks
            Steven Bellovin, Michael Merritt
  4:00--4:30    On Message Integrity in Cryptographic Protocols
            Stuart Stubblebine, Virgil Gligor
  4:30--5:00:   Roles in Cryptographic Protocols
            Einar Snekkenes



9:00--10:30:    SECURITY MODELS: George Dinolt, Session Chair
   9:00-- 9:30: The Typed Access Matrix Model
            Ravi Sandhu
   9:30--10:00: A Resource Allocation Model for Denial of Service
            Jonathan Millen
  10:00--10:30: Non-Monotonic Transformation of Access Rights
            Ravi Sandhu, Gurpreet Suri

10:30--11:00:   BREAK

11:00--12:00:   INFORMATION FLOW: Dale Johnson, Session Chair
  11:00--11:30  A Logical Approach to Multilevel Security of Probabilistic
            James Gray, Paul Syverson
  11:30--12:00  Using Traces of Procedure Calls to Reason About Composability
            Catherine Meadows

12:00--2:00:    LUNCH

2:00--3:00: INTEGRITY: Richard Kemmerer, Session Chair
  2:00--3:00    PANEL: Report of an Integrity Working Group
            Panelists: Marshall Abrams, Edward Amoroso,
            Leonard LaPadula, Teresa Lunt, James Williams

3:00--3:30: BREAK

3:30--5:00: CONCURRENCY CONTROL: Tom Haigh, Session Chair
  3:30--4:00:   A Multilevel Transaction Problem for Multilevel Secure
        Database Systems and Its Solution for the Replicated
            Oliver Costich, John McDermott
  4:00--4:30:   A Two Snapshot Algorithm for Concurrency Control Algorithm
        in Secure Multi-Level Databases
            Paul Ammann, Frank Jaeckle, Sushil Jajodia
  4:30--5:00:   Alternative Correctness Criteria for Concurrent
        Execution of Transactions in Multilevel Secure Database
            Sushil Jajodia, Vijayalakshmi Atluri

5:00:   TC MEETING



9:00--10:30:    SYSTEMS: Tanya Korelsky, Session Chair
   9:00-- 9:30: Evolution of a Trusted B3 Window System Prototype
            Jeremy Epstein, John McHugh, Rita Pascale,
            Charles Martin, Douglas Rothnie, Hilarie Orman,
            Ann Marmor-Squires, Martha Brandstad, Bonnie Danner
   9:30--10:00: A Neural Network Component For An Intrusion Detection System
            Herve Debar, Monique Becker, Didier Siboni
  10:00--10:30: An Optimal Solution to the Secure Reader Writer Problem
            Glenn Benson

10:30--11:00:  BREAK

11:00--12:00:   DATABASE SECURITY: John Dobson, Session Chair
  11:00--11:30: Security for Object-Oriented Database Systems
            Jonathan Millen, Teresa Lunt
  11:30---12:00 A Natural Decomposition of Multi-level Relations
            Frederic Cuppens, Kioumars Yazdanian

12:00--12:15:   AWARDS

Please report problems with the web pages to the maintainer