Subject: RISKS DIGEST 14.83 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 16 August 1993 Volume 14 : Issue 83 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Dorney Park Hercules roller coaster injures 14 (Steve Walker) About 'Terminal Compression' (Paul Robinson) Ghost in the machine (Mich Kabay) Clusters and electromagnetism (Phil Agre) Re: SKIPJACK Review (Brandon S. Allbery) Clipper & French key escrow (Richard Schroeppel) Privacy Digests --- reminder (PGN) PDCS2: Predictably Dependable Computing Systems, Open Workshop (Louise Heery) The RISKS Forum is a moderated digest discussing risks; comp.risks is its USENET counterpart. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. PLEASE SEND REQUESTS FOR SUBSCRIPTIONS, archive problems, and other information to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS". Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 14, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. If you are interested in receiving RISKS via fax, please send E-mail to risks-fax@vortex.com, phone +1 (310) 455-9300, or fax +1 (310) 455-2364 for information regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; instead, as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Mon, 16 Aug 93 18:48:54 PDT From: "Steve Walker via Peter G. Neumann" Subject: Dorney Park Hercules roller coaster injures 14 On July 18 at Maryland's Dorney Park, an occupied train on the Hercules roller coaster ran into an empty train outside the loading platform, injuring 14 passengers. The trains operate with no brakes for the 1 minute and 50 second ride; once they leave the station are free-wheeling when not being towed uphill. A faulty sensor was blamed, which was supposed to detect the train leaving the station, which in turn would enable the computer system to release the restraints on the empty train so that it could move into the loading area. Three new safety measures will be added. * A backup sensor will be added where the first one failed. (Strangely, the present sensor is the only one that did not have a backup.) * The control panel will be modified to display all trains on the track. * A manual brake will be added. The temporary fix is to operate only one train on the track. [From an article by Chuck Ayers, *The Morning Call*, July 28, 1993, p. B5, sent to RISKS by Steve Walker.] This accident sounds remarkably similar to the accident on the Timber Wolf roller coaster at Worlds of Fun in Kansas City, on March 31, 1990. The nature of the accident and the fixes were essentially the same! See RISKS-9.96. ------------------------------ Date: Sun, 15 Aug 1993 03:29:55 -0400 (EDT) From: "Tansin A. Darcos & Company" <0005066432@MCIMAIL.COM> Subject: About 'Terminal Compression' A company (Inter Pact) has run a number of advertisements on the Internet regarding their book 'Terminal Compression' which has been subsequently released in text form which can be downloaded via FTP, with the idea that if you read it you will send them a shareware donation. I probably would never have read the book if it hadn't been made available that way. The copyright slugs on the text indicate publication years of 1991-1993, seemingly indicating a recently issued book. (One of the items in the book is the mention of the new E-Mail address for the White House, which was only created this year.) The book has a number of holes in it which I could see through and I decided to comment. A shorter version of this message has gone to the Telecom Digest. The book deals with the combined issues of some of the dangers of technology and the threats to the privacy of individuals, I have therefore posted this review to both the Risks List and the Privacy List. I will mention one hole which is so obviously inaccurate as to be ridiculous: A government agency gets a court order telling the newspaper in the story, "The New York City Times" (note: not 'The New York Times' but the article makes clear that the paper on Sunday is '34 pounds') to not print any articles dealing with the ability to read CNG emissions (this is the leakage off a computer or monitor which can be read like a radio transmitter from a distance by electronic equipment.) A reporter writes an article from research, and an agency gets a prohibition not just against that article - which is a dubious issue to get a prior restraint order against in the absence of use of government material, anyway - but that this court order is not to stop a particular article, but to completely prohibit any articles regarding that particular *subject*! I've never heard of a judge that would even consider issuing that type of order, (an appeals court would tear him to shreds) and this assumes the paper wouldn't (1) print the article anyway and risk a contempt citation (2) print a _blank_ article and a copy of the court order. Apparently this order was never publicized; any time a government agency tries to suppress publication of something in a newspaper it usually makes _national_ headlines; the press takes threats to the 1st Amendment *very* seriously. CNN's use of the Noriega Tapes comes to mind, and, of course, the Pentagon Papers and the A-Bomb schematics cases. Without intending to spoil the story, I wanted to point out that it mentions only AT&T as the national long distance carrier; a deafening silence exists about MCI and Sprint. Yet later in the book it mentions 'FTS-2000' the private network for government telephone calls that MCI has unsuccessfully been fighting ever since 1/2 went to AT&T and 1/2 went to Sprint, from the time of its creation. At a point in the book, it mentions that the National Security Agency (NSA) uses its massive computer arrays to monitor - in real time - every telephone call connection made in the U.S., e.g. every dial call from and to any point and the call being forwarded, and to where. This seems to forget that despite there being some 200+ service points (called LATAs in the trade) in the U.S. where every call has to go into or out of, not to mention the private cellular carriers, plus local call forwarding setups and call forwarding through PBXs. Plus private cellular companies, trunked mobile radiotelephone companies, ham radio patches... Even in the book it mentions that one of the calls made by some of the criminal elements in the book went to 'a Canadian Cellular Exchange'. I find it hard to believe that a Canadian telephone company is going to let a U.S. government agency inquire into its phone system without a court order issued by a Canadian judge. Is Pacific Bell going to allow someone from the Canadian Department of Revenue or Scotland Yard have the list of who owns what non-listed number without a U.S. Court Order? I think not. (I'll skip over the possibility of bribery for now.) I find it a bit far fetched to believe that it is possible to put a 'pen register' on every telephone call made in the United States. If I call into General Electric's PBX in New York, or Northrop's in Los Angeles, is a call transferred out of it (one of perhaps 100 that go out at any minute) mine or someone else's? Also, in the story it notes that voice, fax or data transmissions are detected and that encrypted ones are 'red flagged'. This is a crock. Bits are bits; there is no way to tell based on the bit stream going through a data call whether the Zmodem Binary transfer I make is a ZIP archive, an EXE file, a binary data file, a Word Perfect file, or a binary file which has been processed with PGP or RIPEM. Bits are Bits; there is no means to differentiate between a compressed, encrypted transmission (such as a file processed with PGP) and a binary data file. It could be possible due to echo cancellers to tell if someone is using a data transmission device; whether a fax or modem detection is possible is another thing. And it also assumes someone doesn't switch to a non-standard method of data transmission such as combined voice and data on a compressed transmission channel. Or local calls to non-telephone networks such as Compuserve. Or private long distance companies that don't use Feature Group service, but simply buy commercial inward lines in some cities and lease dedicated trunk space. The virus issues are a little ridiculous too. Now a couple of years ago a man named William Harrison, I think, wrote a book called 'virus'. With the same basic idea: a series of rogue computer programs can be used to allow someone to commit crimes. Harrison's book was much better: I've had more than 12 years of computer experience as well as extensive use of MSDOS and there wasn't *a single* technical mistake in Harrison's book. The virus issues are rather silly. For one thing, unless someone is careless on large machines, you can't create viruses for VMS or IBM mainframes; they have fully operational supervisor state protection against runaway programs. It might be possible to damage some data in some files if you contaminated them, but in general the kind of virus problems that are reported on PCs because every program that runs on a PC runs with unlimited privilege. One of the viruses is mentioned that it fries the printer port and "causes smoke, then while the user checks that, damages the disk drive". Now, I know it's possible on very old Hercules cards to program them wrong and damage them, and some IDE drive cards have errors in them and miscommanding them could damage the card or the disk (due to errors in the design.) This one, however, is a little hard to believe. I have said it many times: the only reason that viruses can even exist is because the operating system does not use the memory and task protection hardware built into every Intel x86 processor higher than the 80186. A criminally negligent practice, I would say. A person I know claims there are bugs in the 80286 task protection hardware, which I find hard to believe. In any case, 80386 hardware contains working task protection capability. If viruses became so serious that it was necessary to worry about them, it would be not too difficult to release the equivalent of the IBM VM/370 operating system for PCs: at the 80386 level, everything runs in user-mode protection and does not have of I have said it many times: the only reason that viruses can even exist is because the operating system does not use the memory segmentation and task protection hardware built into every Intel x86 processor higher than the 80186. A person I know claims there are bugs in the 80286 task protection hardware, which I find hard to believe. In any case, 80386 hardware contains working task protection capability. If viruses became so serious that it was necessary to worry about them, it would be not too difficult to release the equivalent of the IBM VM/370 operating system for PCs: at the 80386 level, everything runs in user-mode protection and does not have kernel privileges. It can refuse all disk I/O except from the ROM BIOS, any attempt to access any I/O ports is refused. Without that access - which requires privilege - a program cannot do damage and can't get access to the system. A user could well trust a program and allow it access to the screen ports. And the protection program could either allow certain access directly or trap access and emulate it. So there would be no means to get access to the disk drive hardware and no means to attach to other files. The hardware doesn't permit access without permission. If you don't want the story spoiled, do not read this paragraph. At the end of the story, a character responsible for some of the problem meets with the Director of the NSA and we find out that the attacks were intentional with the knowledge of the NSA Director, to cause the country to increase security on its computers. Then, after the director speaks to the person, he has him arrested. Now, it's one thing to 'burn' one of your own people, but nobody is stupid enough to put someone involved with a covert agency in a public trial where he can - as a legitimate defense - expose an agency's dirty laundry. The argument of 'National Security' won't wash in a criminal case; if the defense has evidence that will exonerate it, it is entitled to present it, and if the government requires it to be suppressed, the court will dismiss the criminal complaint. If the man was tried in a secret trial or a military court where it could be hushed up, that's one thing: but a public trial in open court in these type of circumstances is hard to believe. My sister is of the opinion that people don't notice technical errors in books, movies and TV shows. I do and I'm certain other people do, too. Paul Robinson - TDARCOS@MCIMAIL.COM ------------------------------ Date: 16 Aug 93 11:53:34 EDT From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: Ghost in the machine "Phone malfunction sends out 911 call." Associated Press: Syracuse, NY. Globe & Mail / Canada / 14 Aug 93, p. A7 [Summarized by MK] The owner of a cordless phone was rudely awakened by police after his phone sent out a 911 call all by itself. AT&T spokesperson Steven Emery explained that older (> 5 years) cordless phones can accidentally pick up random frequencies and generate dial tones as a result. In this case, the tones happened to be 9, 1 and 1. The emergency response centre recorded the call and traced the address through the phone company. Michel E. Kabay, Ph.D., Director of Education, National Computer Security Assn ------------------------------ Date: Thu, 10 Jun 1993 17:56:17 -0700 From: pagre@weber.ucsd.edu (Phil Agre) Subject: clusters and electromagnetism An article by Kenneth R. Foster in RISKS-14.70 surveys some literature on clusters of illness that have been associated with VDT use. Without wishing to question the author's integrity or methods, it might be useful to consider the point of view of the people who actually find themselves becoming statistics in a similar way. Paul Brodeur's article "The Cancer at Slater School" in the New Yorker (12.7.92, pages 86-119) is a very long and detailed account of the travails suffered by a group of elementary school employees who found themselves dying of cancer at a frightening rate. They suspected that the high-tension power lines running along the school playground might have something to do with it, and they called in the power company to help them investigate. The story concerns the astonishing lengths to which the power company, principally through the agency of fully accredited scientists, went to stonewall, delay, obfuscate, and declare "inconclusive" the study of these poor people. Granted that many in the relevant industries revile Mr. Brodeur, nonetheless if his tale is even faintly representative of the studies surveyed by Dr. Foster then I despair for the health both of science and of everyone else. Phil Agre, UCSD ------------------------------ Date: Wed, 11 Aug 93 12:28 EDT From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: SKIPJACK Review >... Such devices would provide high quality cryptographic security >without preserving the law enforcement access capability that distinguishes >this cryptographic initiative. ... Which, even to a non-crypto expert like myself and given that SKIPJACK is not the only foreseeable "high quality cryptographic security" algorithm, will only have the intended effect if all other cryptographic systems are banned; while you would lose the ability to talk to SKIPJACK-equipped devices, you could still communicate *without* using SKIPJACK and allow some other device or software program to perform the encryption/decryption. Considering the current Congressional review revealing misuse of the NCIC database (mentioned in the following digest article by Peter Wayner), I see some other problems as well. The proposed key escrow system involves encrypting the escrowed keys in such a way that they can only be decrypted by LEAF devices, and therefore the escrow agencies will require access to LEAF devices to examine their own escrowed key lists. I see two problems with this: (1) How are *these* keys encrypted? If the encryption algorithm is subject to exhaustive or "shortcut" searches, the keys may as well be in plaintext. If they are encrypted using SKIPJACK, we have either a chicken-and-egg situation or a back door to avoid the need to obtain keys from the key escrow agencies (just feed a LEAF device the conversation *as an encrypted key* and see what it comes back with). (2) The only protection against the escrow agency decrypting its escrowed key list is to keep the agency from obtaining a LEAF device. I dare say there are ways around this, such as the one (also mentioned in Wayner's submission) of a less-than-honest policeman obtaining a LEAF device and "loaning it out". This is somewhat mitigated by the fact that the escrowed key is only useful when combined with the corresponding key from the other escrow agency, but is still a potential source of problems. Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org ------------------------------ Date: Wed, 11 Aug 1993 11:30:57 MST From: "Richard Schroeppel" Subject: Clipper & French key escrow Peter Wayner's report on the Clipper system included the bone-jarring sentence: > We know that the government of France is widely suspected > of using its key escrow system to eavesdrop on US manufacturers in France. I was under the (obviously naive) impression that the Clipper system was the first seriously proposed use of key escrow. Now I discover that France is using key escrow, right now, today. The French experience might be relevant to our own discussion. Could someone provide more information? Rich Schroeppel rcs@cs.arizona.edu ------------------------------ Date: Mon, 16 Aug 93 18:49:15 PDT From: "Peter G. Neumann" Subject: Privacy Digests Periodically I remind you of TWO useful digests related to privacy, both of which are siphoning off some of the material that would otherwise appear in RISKS, but which should be read by those of you vitally interested in privacy problems. RISKS will continue to carry higher-level discussions in which risks to privacy are a concern. * The PRIVACY Forum Digest (PFD) is run by Lauren Weinstein. He manages it as a rather selectively moderated digest, somewhat akin to RISKS; it spans the full range of both technological and non-technological privacy-related issues (with an emphasis on the former). For information regarding the PRIVACY Forum, please send the exact line: information privacy as the BODY of a message to "privacy-request@vortex.com"; you will receive a response from an automated listserv system. To submit contributions, send to "privacy@vortex.com". * The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is run by Dennis G. Rears. It is gatewayed to the USENET newsgroup comp.society.privacy. It is a relatively open (i.e., less tightly moderated) forum, and was established to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. Submissions should go to comp-privacy@pica.army.mil and administrative requests to comp-privacy-request@pica.army.mil. There is clearly much potential for overlap between the two digests, although contributions tend not to appear in both places. If you are very short of time and can scan only one, you might want to try the former. If you are interested in ongoing detailed discussions, try the latter. Otherwise, it may well be appropriate for you to read both, depending on the strength of your interests and time available. PGN ------------------------------ Date: Mon, 16 Aug 1993 10:17:56 GMT From: l.m.heery@newcastle.ac.uk (Louise Heery) Subject: PDCS2 Open Workshop [Apologies to those of you who have already seen this.] Please find below the programme for the PDCS2 September Open Workshop, being held at LAAS-CNRS, Toulouse, 21 - 23 Sept. '93, together with a registration form. All attendees are subject to the registration fee unless specifically told otherwise. Additional information such as hotels and maps of LAAS will be forwarded upon receipt of completed registration forms, which should be returned to me NO LATER THAN 10 September '93. However, as individuals are responsible for making their own hotel reservations, I would advise you to reply sooner so that I will then be able to send you a list of recommended hotels. Please also note that the number of places available at the workshop are limited and that I will, therefore, be working on a first-come-first-served basis with regard to receipt of registrations. Regards, Louise Heery | PDCS2 Administrative Co-ordinator | | Dept. of Computing Science, | | Claremont Tower, | | University of Newcastle upon Tyne, NE1 7RU | | Tel: +44/091-222-7948 Fax: +44/091-222-8232 | | E-mail: l.m.heery@newcastle.ac.uk | PDCS2, as its acronym implies, aims to build on, and take significantly further the work of ESPRIT Basic research Action 3092, Predictably Dependable Computing Systems (PDCS), on the problems of making the process of designing and constructing adequately dependable computing systems much more predictable and cost-effective than at present. In particular it will address the problems of producing dependable distributed real-time systems and especially those where the dependability requirements centre on issues of safety and/or security. The planned programme of research concerns a number of carefully selected topics in fault prevention, fault tolerance, fault removal and fault forecasting. The work to be done ranges in nature from theoretical to experimental; in a number of cases it involves the acquisition or implementation, in prototype form, of software tools, and their experimental interconnection. OPEN WORKSHOP TIMETABLE - TUE. 21 - THUR. 23 SEPT. '93. Tuesday 21 Sept. 8.30-9.30: REGISTRATION AND COFFEE 9.30-10.30: Welcome: Alain Costes (10 mins) PDCS OVERVIEW AND WORKSHOP Introduction: Brian Randell (50 mins) COFFEE 11.00-12.30: REAL TIME FAULT TOLERANCE Moderator: Alan Burns (University of York, York, UK). Speakers: (1) Johannes Reisinger, "Real-time Interprocess Communications in MARS" (Technische Universitat, Vienna, Austria); (2) Andrea Bondavalli, "Adaptable Fault Tolerance for Real-Time Systems" (CNR, Pisa, Italy). LUNCH 14.00-15.30: OBJECT-ORIENTED FAULT TOLERANCE Moderator: Lorenzo Strigini (CNR, Pisa, Italy). Speakers: (1) Jean-Charles Fabre, "Fault and Intrusion Tolerance in Object-oriented Applications by Fragmentation-Redundancy-Scattering" ( LAAS-CNRS, Toulouse, France in conjunction with University of Newcastle, UK); (2) Robert Stroud, "Object-oriented Techniques for Realising Fault Tolerance in Software" (University of Newcastle upon Tyne, Newcastle upon Tyne, UK). COFFEE 16.00-17.30: DEMONSTRATIONS Room 1 Room 2 Room 3 Demo A Demo C Demo D Demo B Demo C Demo D Wednesday 22 Sept. 9.00-10.30: INDUSTRIAL INVITED SPEAKERS: Moderator: Alain Costes Speakers: (a) Marc Guillemont (Chorus Systemes) (b) Malcolm Mills (Software Sciences Limited) (c) Peter Knezu (ALCATEL Austria) COFFEE 11.00-12.30: SECURITY ASSESSMENT Moderator: Yves Deswarte ( LAAS-CNRS, Toulouse, France). Speakers: (1) Bev Littlewood & Tomas Olovsson, "A Pilot Experiment in the Modelling of Operational Security" (CSR, City University, London, UK and Chalmers University of Technology, Goteborg, Sweden); (2) John McDermid, "Developing Secure Systems in a Modular Way" (University of York, York, UK). LUNCH 14.00-15.30: FAULT INJECTION Moderator: Hermann Kopetz Speakers: (1) Eric Jenn, "Fault-injection into VHDL Models: The MEFISTO Tool" (LAAS-CNRS, Toulouse/Chalmers University of Technology, Goteborg); (2) Johan Karlsson, "Validation of the MARS System by Physical Fault Injection," (Chalmers University of Technology, Goteborg). COFFEE 16.00-17.30: DEMONSTRATIONS Room 1 Room 2 Room 3 Demo A Demo B Demo C Demo A Demo B Demo D Thursday 23 Sept. 9.00-9.30: TESTING Moderator: Tom Anderson (University of Newcastle upon Tyne, Newcastle upon Tyne, UK) Speakers: (1) Pascale Thevenod, "Functional Testing of Critical Software: Formal and Statistical Approaches; A Case Study" (LAAS-CNRS, Toulouse and LRI-Universite de Paris-Sud, France); (2) Werner Schuetz, "A Statistical Approach for Testing the Execution Time of Program Units" (LAAS-CNRS, Toulouse, France and Technische Universitat, Vienna, Austria). COFFEE 11.00-12.30: SOFTWARE RELIABILITY EVALUATION Moderator: Karama Kanoun (LAAS-CNRS, Toulouse, France). Speakers: (1) Mohamed Kaaniche, "Discrete-time Software Reliability Modelling and Evaluation" (LAAS-CNRS, Toulouse, France); (2) Sarah Brocklehurst & David Wright,"General Methods for the Improvement of Software Reliability Predictions" (City University, London, UK). LUNCH 14.00-15.30: ACADEMIC INVITED SPEAKERS AND CONCLUSION Moderator: Jean-Claude Laprie Speakers: (a) Jack Stankovic (University of Massachusetts) (b) John Meyer (University of Michigan) Closing Address: Jean-Claude Laprie (20 mins) ================ END OF TIMETABLE ================ DEMONSTRATIONS A> "Object Oriented Fragmentation/Redundancy/Scattering" (University of Newcastle upon Tyne, Newcastle upon Tyne, UK and (LAAS-CNRS, Toulouse, France). A distributed Electronic Diary system which has been designed using Eiffel design tools and implemented on top of the DELTA-4 Support Environment will be demonstrated. The system uses fragmentation-redundancy-scattering to provide means of achieving high reliability and security by tolerating both accidental faults and intentional intrusions. B> R. Schlatterbeck, "Tool Integration by CDL" (Technische Universitat, Vienna, Austria); In the first phase we will explain the purpose, the structure and the operation of CDL using a set of pictures. In the second phase we will demonstrate the prototype implementation of our CDL tools. C> "Analysis of Predictive Accuracy and Recalibration of Reliability Growth Predictions" (City University, London, UK); Some real software failure data will be analysed using reliability growth models, an analysis of the accuracy of the resulting reliability predictions, and their recalibration, will be conducted. D.G. Leber, "Single Board Computer with High Error Coverage" (Technische Universitat, Vienna, Austria); Presentation of a single board computer with high error detection coverage: We will explain the special mechanisms within the hardware and the operating system of the new MARS nodes which are responsible for realizing both the fail-silence property and a predictable timing behaviour REGISTRATION FORM: Fee 1800 FF (inclusive of VAT) Last Name:___________________________________________ First Name:__________________________________________ Title: Prof/Dr/Mr/Ms/Mrs/Miss/Other:_________________ Address:_____________________________________________ _____________________________________________ _____________________________________________ Tel:________________ Fax:________________ E-mail:___________________ Delete as applicable: Please reserve a place for me at the Open Workshop YES/NO Date of arrival:____/09/93 Please add my name to the PDCS2 Technical Report mailing list YES/NO I will attend the banquet dinner: Yes/No I am vegetarian: Yes/No Please indicate preferred method of payment (delete all methods EXCEPT the method of payment chosen): Fee 1800 FF (inclusive of VAT) Bank Transfer: (I will send out the details necessary for this upon receipt of registration) OR French Bank cheque to the order of ADERMIP OR Order form for invoice OR Credit Card: Visa/Mastercard/ EuroCard OR On site payment by cash/credit card Return form, to arrive no later than 10 September 1993, to: Louise Heery, PDCS2 Administrative Co-ordinator, Department of Computing Science, University of Newcastle upon Tyne, Newcastle upon Tyne, NE1 7RU, UK. Fax: +44/091-222-8232; e-mail: l.m.heery@newcastle.ac.uk ------------------------------ End of RISKS-FORUM Digest 14.83 ************************