Subject: RISKS DIGEST 14.47 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Wednesday 7 April 1993 Volume 14 : Issue 47 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Another Mystery for the San Francisco Muni Metro (PGN) Columbia and Discovery shuttle problems (PGN, Jim DePorter, Ken Hollis via Paul Robichaux) ``Organized Crime Gets into Phone Fraud'' (PGN) An interesting bug for users of "at" (Dave Parnas) RISKS of Complacency (DOS 6.0) (A. Padgett Peterson) Using your company's E-mail for private purposes (Omer Zak) Re: Personal letters (Paul Robinson) Re: Hayes Sequence Triggered (Ron Dippold) Groupware (non)security query (Rob Slade) Legal Net Monthly Newsletter (Paul Ferguson) Injured Using a Computer Pointing Device?: Read This (Pete W. Johnson) FTCS-23 ADVANCE PROGRAM (Mohamed Kaaniche) 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. REQUESTS please to RISKS-Request@CSL.SRI.COM. 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. For information regarding delivery of RISKS by FAX, phone 310-455-9300 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.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: Wed, 6 Apr 93 08:46:58 PDT From: "Peter G. Neumann" Subject: Another Mystery for the San Francisco Muni Metro Just after 1 p.m. on Sunday afternoon, April 6, a San Francisco Municipal Railway car (1228) was headed for the car barns when it crashed into the rear of another car (1304) that had stalled in the Twin Peaks Tunnel. 15 people wound up in the hospital. It took all night to clear the wreckage, and full service began again only on Monday morning. The causes of the stall and of the crash were still unknown. The signal system and the safety controls are as follows: * An `automatic' speed-control system has three speeds, 10, 27, and 50 mph. [Apparently ZERO is not considered a speed.] * A cab-signalling system informs the operator of the maximum permissible speed, red for 10, yellow for 27, green for 50. The controls were thought to be `foolproof', because the car automatically slows or stops if the operator exceeds the maximum indicated speed. There are also impedance bonds in the tracks that are supposed to determine whether the track ahead is clear. The operator of car 1228 is named Johnny Wong. Three possible scenarios were suggested: 1. Wong or someone else had disconnected the cab-signalling system, which would bypass the speed controls. [This is allegedly not easy to do, and has various voice protocols associated with it.] 2. There might have been a failure of the track-signal system, which would have made car 1304 invisible to the control systems. 3. Human failure was also mentioned, although in the absence of the first two scenarios, that does not seem to make much sense. [Source: An article by Carl Nolte in the San Francisco Chronicle, 6 Apr 1993, pA1, following up on the previous day's reportage.] Well, the next day's report begins with this paragraph: The crash ``... was the result of the operator deliberately disabling the safety system so that he could speed up his train, sources close to the investigation said''. The investigation continues. Stay tuned for any further revelations. [Source: article by Phillip Matier and Andrew Ross, SanFranChron, 7 Apr 1993, p. A1] [By the way, the "Another" in the subject line is because I was reminded of the Ghost trains that plagued the Muni Metro repeatedly beginning about ten years ago. PGN] ------------------------------ Date: Wed, 7 Apr 93 08:57:49 PDT From: "Peter G. Neumann" Subject: Columbia and Discovery shuttle problems On 22 March, Columbia's main engines were shut down three seconds before lift-off, because of a leaky valve. On 5 April, Discovery's launch (STS-56) was aborted eleven seconds before lift-off. Early indications pointed to a valve in the main propulsion system. In this case, the engines had not yet been ignited. (There had been an earlier one-hour delay at nine minutes before launch, due to high winds and a temperature sensor problem.) [Source: San Francisco Chronicle, 6 Apr 1993, p.A2] A computer glitch is now being blamed for the 5 April delay. Computer data had indicated that the valve had not closed. ``However, engineers believe that the valve closed properly and a bad circuit might be to blame.`` That is, the computer was in error in reporting the valve status. [Source: AP item in the San Francisco Chronicle, 7 Apr 1993, p.A3] ------------------------------ Date: Wed, 7 Apr 1993 01:38:34 GMT From: jimd@SSD.intel.com (Jim DePorter) Subject: Shuttle launch aborted by computer error... [...] The real reason for sending this is that the reporter said "since it is a bug in the computer software it will be easy to fix and the shuttle will be able to launch in the next 24 hours". Seems the expectations of fixing something as 'simple' as software are set way to high. I understand the idea behind the statement: If the problem was in the valve the shuttle could be delayed for more then 24 hours, while all you need to do to fix software is fix the code and reload the 'application' (possibly by floppy disk (-8 ). The risk has to do with people having a little knowledge. Not to long ago software was a big and nebulous idea to most reporters. Now everyone has certain ideas about how software actually works, which in most cases is actually wrong (heck I know people who still have trouble understanding the difference between ram space and disk space). ------------------------------ Date: Wed, 7 Apr 93 08:43:58 CDT From: robichau@lambda.msfc.nasa.gov (Paul Robichaux, NTI Mission SW Dev Div) Subject: STS-56 abort << this was originally posted on sci.space.shuttle by Ken Hollis of the Kennedy Space Center >> [...] STS-56 abort at T-20 seconds (or thereabouts, maybe 16 seconds per my GLS DD?) was called today because of the GLS (Ground Launch Sequencer). It detected that the MPS (Main Propulsion System) High Point Bleed valve (PV22) closed indicator did not come on as expected. PV22 is a monostable, normally closed, helium pneumatically actuated valve on a line attached to the LH2 17" manifold. This 17" manifold is the line that goes between the ET (External Tank) and the main engines to supply LH2 to the engines. The high point bleed line is situated in the Orbiter at the "high Point" of that manifold. The LH2 manifold between the ET and the Orbiter looks like an inverted "U". One end of this manifold goes down to the bottom of the LH2 section of the ET (as opposed to the LO2 section at the top of the tank), the other end goes down towards the engines. Since LH2 is very cold, just about any temperature rise will tend to let it gas off. The high point bleed allows any gasses / bi-phase liquid that may accumulate at the top of this U to be siphoned off overboard, where it is sent to the flare stack & burned. It only takes a couple of seconds for this valve to be closed before a gas pocket forms in this section of line, so the valve must be open as close to lighting the engines as possible so that the engines don't ingest a hydrogen bubble. Believe it or not, this still simplifies the operation of the LH2 system with the engines & loading the tank. The lines in the aft for the MPS / SSME system are commonly referred to as "a plumbers nightmare". During the "terminal count" at about T-20 seconds, the open command is removed. Since this is a "monostable" valve, if there is no helium supply or no power to the solenoid that lets helium to the valve, the valve will close. GLS then verified at about 16 seconds (per my last DD) it is closed and everything is fine. Today the Open indicator went from ON to OFF (indicating it cycled) but the Closed indicator never went from OFF to ON (indicating it did indeed close) thus causing the abort. A downstream temperature transducer went from cold to very warm also indicating that the valve closed, but GLS does not check that temp ducer. A 48 hour scrub-turnaround has been called contingent on relying on the temp ducer rather than the Close indicator. Last I saw the indicator was not still working. It would be easy to say the it is a microswitch failure on the valve, but it could be quite a few things wrong (as always on the Orbiter) and further troubleshooting will have to be performed in the aft to figure out exactly what the problem is. Any problems after T-31 seconds is an abort for the day. No more holds are available. Ken Hollis INTERNET: HOLLIS@TITAN.KSC.NASA.GOV SPAN/HEPnet: KSCP00::HOLLIS ------------------------------ Date: Wed, 7 Apr 93 8:59:44 PDT From: "Peter G. Neumann" Subject: ``Organized Crime Gets into Phone Fraud'' A new survey by John Haugh's Telecommunications Advisors, Inc., claims that technically sophisticated organized-crime rings are annually defrauding U.S. businesses and telephone companies of $4 billion in long-distance calls. 70.3 percent of the almost 700 companies surveyed reported they had been hit by toll fraud at least once in the past five years, with an average loss of $125,000 [inferentially, I conclude, per company rather than per hit]. Haugh predicted that 35,000 companies will be victimized this year. [That multiplies out to $4.375 billion for the year if the past average holds true.] [Source: An article by John Eckhouse, San Francisco Chronicle, 7 Apr 1993, p. D1] ------------------------------ Date: 03 Apr 1993 19:13:18 -0500 (EST) From: parnas@triose.eng.McMaster.CA (Dave Parnas) Subject: An interesting bug for users of "at" If you look in the manual for "at" you will see that one of the recommended ways of using it is to have each at job schedule a new one a day or a week or a month later. Some find this easier than editing the /cron file or they may not have authority to do that. I regularly use this trick to schedule a daily backup of my files onto a tape that I always leave in my tape unit. Last year in April it stopped working. I thought perhaps there had been some kind of outage or bug and simply restarted it. This year I noticed that when it ran (early this morning) and try to schedule tomorrow morning's backup, at gave the message "too late". I thought it might have been some problem caused by a series of power outages we had yesterday but then I noticed it was also happening on two other machines. I did some experimenting and found that at would not schedule any jobs from 0200 to 0259. A few hours later I understood. Tomorrow morning there is no 0202 (the time that schedule my backup) because of the switch to EDT. We will go directly from 0159 to 0300. I read the manual and there is no indication in the manual that any such check is made. It says you can use any time between 0000 and 2359. This is clearly a case of incomplete documentation. Is it a case of the author of at being too clever, or me being too stupid? I think it a nice example of how subtle can be the error that leads to a failure. It never occurred to me that they would be checking for that missing hour. They probably never thought of someone having a regularly scheduled call for 0202. However, there is something even nicer. If it skips the run in the spring, shouldn't it run it twice in the Fall? I checked my records and it doesn't do that. Even though the clock is going to drop back it schedules the run for the next day. Now, is that a bug? If so whose? A question of documentation! Dave ------------------------------ Date: Thu, 1 Apr 93 21:09:21 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: RISKS of Complacency (DOS 6.0) Yesterday I went down to the local Babbages for a copy of DOS 6.0 with expectation of a similar experience as when 5.0 was purchased. Well the box was the same size but that was about it. (What do you expect for US50.00 anyway). It seems that MS-DOS now comes much like an automobile or cable television: the base price doesn't include the options. Inside the two-inch-thick box was a slim volume (321 pages vs 668 pages in the DOS 5.0 manual) mostly on the new "features" (as in "that's not a bug, its a feature" 8*) and three high density disks (and a coupon for low density - one of many coupons). Well, I can say this much, its not really for monochrome laptops, its not really for XTs, the commands are not consistent, and it has its share of bugs, but seems ok otherwise. Towards the end of the book you find a set of coupons: the first asks you to send in US24.95 + US5.00 for shipping + tax. This gets you the "Microsoft MS-DOS 6.0 Resource Kit" which includes the "MS-DOS 6.0 Technical Reference", and a set of "supplemental disks" which include things like COMP, EDLIN, EXE2BIN, and LCD.CPI which were left out of 6.0 (everyone in Redmond must like to wait on EDIT and has an active matrix laptop in their Porche). If you are using STACKER, for US5.00 you can get a conversion utility for DBLSPACE & possibly repeat my experience (on my venerable but 100% compatible XT clone, WD controller, & ST-225, attempting to use DBLSPACE resulted in a "Divide Overflow" half-way through the conversion & left the machine unbootable even from floppy - had to reboot with a lesser DOS version and clean off all of the DBLSPACE files to recover - happened more than once so no fluke). Speaking of DBLSPACE, when formatting a 360k floppy with /S, you now get three hidden files and have only 180k free: seems DOS 6.0 grew a bit and now puts 50+k of hidden DBLSPACE.BIN on the floppies too. There is an anti-virus tool from Central Point but by now every virus-writer in the world knows how to turn it off with a high function of Int 10, 16, or 21h (haven't tried it but was told by a reputable source). Even so there is yet another coupon at the end of the book requesting another US19.90 for two updates, one "now" (they knew it was obsolete already ?) and one in 3-4 months. Actually cheap compared to the (pounds)29.90 they expect from UK residents (includes VAT). What really got me is the lack of a simple environmental variable to turn of the color in the utilities for a monochrome display. I told SETUP to use monochrome but this ended when SETUP (which also informed me that an "incompatible disk compression" was present - nope) was done. For EDIT, /B is the switch and /NOHI helps. DEFRAG wants /BW, MSAV allows /BW but /MONO works better (you can go out for lunch while the memory scan runs on an XT). Now there are alternatives to cubic money. You can download the supplemental file (DOS6SUPP.EXE) from the MS BBS in Washington (206.936.6735), all 480+k of it & the BBS does support 9600 baud but do not confuse it with v42, v42bis, or MNP. 33 bad blocks (a record) during the download but my trusty Supra, 16550 chips, and Procomm+/Zmodem (plugs) handled it ok. The Anti-Virus update can be downloaded from 503.531.8100 - not on the coupon but on page 277 - probably Central Point. In short, the product has the feel of "not ready for prime time" but it did appear in the first quarter '93 (last day actually - well Egghead had it the day before). A final note: I did try to call Microsoft tech support about things encountered (90 days "free" support is available starting with the first call). I got through to the lady who took serial numbers (and started the 90 day timer) quickly enough only to be informed after that I was 86th in line & could expect a 90+ minute wait. Not an 800 call. From Florida to Washington. No thank you. (At least they told me 8*). Padgett ------------------------------ Date: Wed, 07 Apr 93 01:40:22 +0300 From: Omer Zak Subject: Using your company's E-mail for private purposes At present, companies have the right to require their employees to use company computers, including E-mail access, only for company business. Employees who participate in the Internet discussion groups may violate this restriction. Then they incur the risk of harassment if they ever fall out of favor and/or hold unconventional political beliefs. The remedy? Next time you accept a job, negotiate (along with your salary and fringe benefits) the right to use your company's E-mail also for private purposes, subject to reasonable limits (which are based ONLY upon quantity of mail send and received) and the understanding that the time you spend on private E-mail is your time, not company time. Companies have the right to control the use of computers which belong to them. On the other hand, they are required to compensate you for your work in their behalf (in the form of salary etc.). So considering E-mail access to be another fringe benefit will solve the problem. --- Omer ------------------------------ Date: Wed, 7 Apr 1993 03:03:09 -0400 (EDT) From: Paul Robinson Subject: Re: Personal letters On < Mon, 29 Mar 1993 13:24:37 (PST) > In Comp Privacy 2-11, Steven Hodas > If I send a personal letter to someone do they have the right to > disclose it to others without my consent? No. The Copyright act of 1978 and later amendments gave statutory protection at the federal level for the first time to unpublished works. > Does this vary state by state? No. Prior to the 1978 law, an unpublished work was subject to the protection of the common law of the state in question. The new law expressly excludes states from having any jurisdiction over unpublished works and voids any "common law copyright" which might have existed. All works are automatically protected under federal law. > If it's prohibited, is it a civil or a criminal issue? Civil. > If it is permitted doesn't that suggest that we have greater privacy > protection for electronic communciation because the ECPA would prohibit > that kind of disclosure? I think you are confusing things. The ECPA gives to Electronic mail the same protections which are available for telephone conversations - the protection against interception by third parties or the use of intercepted E-Mail by law enforcement personnel without a warrant, i.e. what the laws against wiretapping and recording of telephone calls, the ECPA provides to the same extent to E-Mail. The ECPA does not apply to the sender or recipient of the message. It only applies to anyone who may see a message prior to its delivery to the designated mailbox or delivery point. It applies to the E-Mail providers who carry the message and to anyone who delivers it. I am also posting this to the Risks Digest for a reason which has to do with another issue which almost no one has noticed. As of April 1, 1988, the United States became a member of the Berne Union for the Protection of Literary Works. This treaty is most famous as the reason companies would simultaneously publish a book in Canada in order to obtain protection under the Berne Convention. As of four years ago, that process was no longer necessary because the U.S. is now a member of the Berne Union. The most significant issue under Berne (I refer to this as "It Berne's me up") is that there are no formalities or requirements of notification in order for a work to obtain copyright protection. What this means is that copyright notices became totally optional after April 1, 1988 for all works first published on or after that date. In theory, if you obtained a computer program from someone which simply had his name and address on it, and wanted to use it, you would have to find out if the person who wrote it wanted anything to license it. You can be sued, and lose, and the other party can collect damages, even though the work has no indication of copyright notice. I live just outside of Washington, DC and the Copyright office is just a 20 minute train ride away. A frightening fact is that despite the treaty having been around for more than four years, the Copyright office still does not have copies of the text of the treaty. They have copies of the Phonolog Convention (for protection of sound recordings) and they have copies of the Universal Copyright Convention (which instituted the C in a circle copyright notice.) But Berne is conspicuously absent. It makes me wonder what things are stated in this treaty that are so bad that nobody wants people to know what it says. (The last time I tried to get a copy was about a year ago, but that still was 3 years after implementation and the Copyright Office STILL did not have copies of the text of the treaty. It makes me wonder why. Just remember this little piece of information. A treaty, once ratified by the Senate, has the force and effect of an amendment to the Constitution of the United States and can override its provisions. Think about that some time. Paul Robinson -- TDARCOS@MCIMAIL.COM ------------------------------ Date: Tue, 6 Apr 1993 20:43:37 GMT From: rdippold@qualcomm.com (Ron "Asbestos" Dippold) Subject: Re: Hayes Sequence Triggered (Peterson, RISKS-14.46) risks@csl.sri.com writes: >ps Turning off the "in band" sequence & using DTR I can understand, but > 128 (80h) is just as likely as "+" (2Bh) in a binary file unless the > Motorola firmware interprets it as "none". In general, most modems treat anything above 127 as ignore. Having been bitten by the triple plus sequence even with the Hayes guard time (back when I used rn, for instance, and was '+'ing through articles...) I learned to turn this off very early. ------------------------------ Date: 6 Apr 93 18:41 -0600 From: "Rob Slade, DECrypt Editor, 604-984-4067" Subject: Groupware (non)security query I am looking for experiences, anecdotes and comments relating to security, or the lack thereof, in "groupware" applications and systems. This material will become part of an article to be published later this spring. Any replies that I wish to quote I will contact the author first. For those replying from the newsgroups, I would appreciate copies to roberts@decus.ca and rslade@sfu.ca for backup. Vancouver Institute for Research into User Security Canada V7K 2G6 ROBERTS@decus.ca Robert_Slade@sfu.ca rslade@cue.bc.ca p1@CyberStore.ca ------------------------------ Date: Wed, 31 Mar 93 16:31:09 EST From: fergp@sytex.com (Paul Ferguson) Subject: Legal Net Monthly Newsletter Opinion, editorial and news worthy submissions are currently being (sought and) accepted for a new start-up electronic news journal. This monthly compilation will be called 'The Legal Net Monthly Newsletter' and will focus on the legal and ethical aspects of computer networking. Legal Net Monthly will be a non-biased, open forum electronic newsletter keeping in step with the networking environment of the '90's and will be availble by E-Mail subscription. Legal Net Monthly is aiming to release it's first issue on May 1st, 1993. Articles on the following topics are especially welcome: o Defining "Criminal Mischief" on the Nets o Authoring/Distributing Computer Viruses: Legal Implications o Legislative news around the world Send all submissions, subscription requests and correspondence to: fergp@sytex.com Paul Ferguson, Network Integration Consultant, Centreville, Virginia USA fergp@sytex.com sytex.com!fergp 1:109/229 (FidoNet) ------------------------------ Date: 5 Apr 1993 06:45:52 GMT From: petej@garnet.berkeley.edu (Pete W. Johnson) Subject: *** Injured Using a Computer Pointing Device?: Read This *** This is a pointer to a basenote and discussion pertaining to computer pointing device injuries (mouse, trackballs, puck, stylus, etc.) in sci.med.occupational. For convenence I have included a copy of the basenote below. To follow net etiquette, please direct all responses to the basenote below in sci.med.occupational notesgroup ONLY. (Copy of Basenote) This note (which is being posted monthly) is for anyone that has been injured using a computer pointing device (mouse, trackball, puck, tablet, etc.). I have been assisting computer operators who have been injured using pointing devices for the past 4 years. I am now presently doing research at the University of California's (San Francisco and Berkeley's) Ergonomics Lab on the design of computer pointing devices with the goal of reducing injuries associated with their use. In order to do this, I need to collect information on pointing device design characteristics (button design, button force, device size, device shape, etc.) that are important in minimizing and/or reducing the physical stresses operators are subjected to. Some of this information will be collected through my laboratory research, but a major and important source of information has to come from operators like yourself. I need to collect all the information I can from computer operators that have been injured as a result of pointing device use. In order to do this, I need your help. If you have been injured using a pointing device, I would appreciate it if you would send me a note with information pertaining to your injury. I would like the information e-mailed directly to me (petej@garnet.berkeley.edu). The format I would like the information sent to me is as follows, fill in as much as you can: 1) NAME: (optional) 2) COMPANY: (optional) 3) PHONE #: (optional) 4) NUMBER OF HOURS SPENT IN FRONT OF THE COMPUTER PER DAY: 5) PERCENTAGE OF TIME SPENT USING A POINTING DEVICE: 6) MANUFACTURER OF COMPUTER AND MODEL NUMBER: 7) POINTING DEVICE USED AT TIME OF INJURY: (Please be specific) a) MANUFACTURER b) MODEL OR PART NUMBER c) DESCRIPTION OF DEVICE 8) PRIMARY SOFTWARE APPLICATION USED AT THE TIME OF YOUR INJURY 9) TYPE OF INJURY 10) WHAT YOU THINK CAUSED YOUR INJURY 11) IF INJURY IS RESOLVED OR YOUR CONDITIONS HAVE IMPROVED, WHAT CHANGES WERE MADE (This is probably the most beneficial information) My intent is to enter this information into a database in order to gather information and look for trends. Each month I will share relevant information by posting a monthly summary in sci.med.occupational similar to what has been done with keyboard information. If you are presently experiencing problems, feel free to call me (510/231-9405) and I will share with you what I know. I am also open for suggestions, please post responses to this basenote or e-mail me if you have any further suggestions or input. If your company has internal bulletin boards, please post this note or provide a pointer telling your co-workers about this basenote in the sci.med.occupational newsgroup. I will be also be posting a pointer to this basenote in comp.risks, comp.human-factors, and sci.med as well. Finally, if you have any opinions or inputs on a particular pointing device or pointing device design in general, send me a note or call me. Our lab is assisting some of the major pointing device manufacturers with the design of their pointing devices. If you have some inputs for a particular company, I will be happy to direct them to the appropriate person. Thanks for your help. Peter W. Johnson (End of Basenote) ------------------------------ Date: Wed, 31 Mar 93 19:53:31 +0200 From: kaaniche@tsf.laas.fr Subject: FTCS-23 ADVANCE PROGRAM FTCS-23:The 23rd Annual International Symposium on Fault-Tolerant Computing Diagora, Centre de Congres de Labege, Toulouse, France, June, 22-24, 1993 To receive a hardcopy of FTCS-23 Advance program [or a complete version of the on-line announcement, which was much too large for RISKS], please contact Mohamed Kaaniche: LAAS-CNRS,7 avenue Colonel Roche, 31077 Toulouse, France Tel: +(33) 61 33 64 05, Fax: +(33) 61 33 64 11 Email: Mohamed.kaaniche@laas.fr [The full announcement is also in the CRVAX.SRI.COM RISKS archives CD RISKS: with the file name RISKS-14.FTC . PGN] FTCS is the world's most important forum for the presentation and discussion of state of the art developments in dependable computing systems. This year's program features 60 regular papers, 5 practical experience reports, 6 software demonstrations and one panel. This program is the result of a very stringent selection process carried out by the international Program Committee on more than 300 submissions. The regular paper sessions cover a breadth of topics from concurrent error detection to software-implemented and application-based fault-tolerance, from theoretical issues in modeling to field measurement of fault- tolerant system dependability, from testing to fault injection. The opening plenary session will be devoted to practical experience reports on two safety-critical, software intensive systems currently in operation: the digital fly-by-wire systems of the Airbus family of airliners, and the speed control system of the Paris subway. The panel will discuss the limits in dependability, and the software demonstrations will encompass tools for hardware and software dependability evaluation. Exhibitors from both industrial and academic communities will present commercially available products, advanced prototypes and tools relating to the conference theme. An exhitors' forum will offer technical presentations relating to the exhibited products, prototypes and tools. The symposium participants will be given the opportunity to attend a pre-symposium review of the research conducted at LAAS-CNRS, as well as joining post-symposium technical visits of Aerospatiale, CNES and Matra Marconi Space. On Monday June 21, a welcome reception will be organized at Hotel Capoul. On Tuesday June 22, the Mayor of Toulouse will give a reception in the famous "Salle des Illustres", followed by a concert at the Jacobins Cloister. On Wednesday June 23, the traditional excursion will be to Albi, home town of the famous painter Toulouse-Lautrec, followed by a banquet. ------------------------------ End of RISKS-FORUM Digest 14.47 ************************