Text File

Subject: RISKS DIGEST 13.70 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Thursday 6 August 1992 Volume 13 : Issue 70

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Software problems plague new Canadian air traffic control system (Mark Bartelt) Fun with high pressure (Michael Stern) Mr. C. Baggage, who was neither a Mister nor a Baggage at all (Geoff Kuenning) Unreliable call-return phone feature... (Rex Black) GTE's Personal Secretary (Chuck Ham) Police files (Nigel Allen) Re: User interface studies: oh, what's the use? (Steve Summit) Sweet Old Things and User Interfaces (Ed Ravin) Re: Computer scoring glitch at Olympics (Stanley Chow, Joe Konstan, David Wittenberg) 1993 Symposium on Research in Security and Privacy (Dick Kemmerer)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, 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.COM<CR>login anonymous<CR>AnyNonNullPW<CR> CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 13, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". <CR>=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: Tue, 4 Aug 92 06:49:37 EDT From: Mark Bartelt <sysmark@mouse.cita.utoronto.ca> Subject: Software problems plague new Canadian air traffic control system

Glitches stalling updated airport radar Bugs mar new air control system Toronto Star, 3 August 1992 By Bruce Campion-Smith

An $810 million program to install updated radar systems at Canada's major airports has been stalled by a series of stubborn software bugs. The sophisticated system has crashed in tests and in actual use, freezing radar screens, displaying false information and even showing jets flying backwards, sources say. In at least one case, air traffic controllers in Montreal were left without radar for 15 minutes when the system suffered a "catastrophic failure," according to federal documents. Controllers restricted flights and later that March night resorted to the old radar system, according to a memo obtained by The Star under the Access to Information Act. At no time were passengers at risk, says a letter accompanying the memo. "It's incredible. It's a multi-million-dollar operation. We're up to version four and it's still not operational," said Paul Gauthier. Gauthier is vice-president, technical, with the Canadian Air Traffic Control Association, the union representing the country's controllers. "Government seems to be able to get themselves in the situation where they are paying through the nose and not getting the goods," he said. The system has been in use at Calgary International Airport since June 6 and so far the system is working well, said Roger Westmore, Transport Canada's project manager. "There is a back-up, but we think it's unlikely it would be required," Westmore said. That back-up is provided by controllers in Edmonton, and a switchover in the event of a major failure of the system would take five to 10 minutes, Gauthier said. "I couldn't believe it, but that's what they are doing," he said. "It's not certified or commissioned, but they are running live tests with live people." The massive program is known as the radar modernization project (RAMP) and is touted as one answer to easing congestion -- and reducing delays -- in the skies above congested airports, like Person International. The new radar replaces vacuum-tube technology with a better picture of what's happening in the skies. That would allow them to space aircraft closer together and, in the end, get more flights in and out of busy Pearson. Transport Canada officials say they are close to clearing "the last hurdle" and are optimistic that the system will be up and running at Pearson early next year -- 2 1/2 years after originally expected. The system should be fully operational across Canada within the next six months, Westmore said. But controllers and airline representatives are less hopeful. "That's the story we've been getting for the last three years. It's always just around the corner," said John Redmond, president of the controllers' association. "It's crashed in Montreal. It's crashed in Moncton. It's crashed in Toronto," Redmond said. "The problem is primarily with the software not being able to handle the amount of data that runs through the system, and it keeps crashing," Redmond said. Controllers who have experienced an unnerving system crash say they never know how long they'll be without radar when it happens. That's why the new system is losing the trust of the very people who will have to use it, Gauthier said. The system screw-ups in testing include: -- Switching the data tags between two aircraft when the planes are close together on the radar screen. The tags are vital, identifying the green blips on the screens. -- Backing up targets on the screen, in essence showing jets flying backwards. Developing a software package that would work in Toronto Centre -- the busiest airspace in Canada -- has remained the big hurdle, sources say. One stumbling block has been the system's inability to handle heavy traffic. Just when designers think they have one glitch cured, another pops up, sources say. The curious problems struck as recently as last month, when the latest package of software was tested in Moncton and failed, they say. Westmore denies the system failed and instead says it needed "additional improvements." With a project of this magnitude, it's normal to expect some problems, he said. The contract for the system was awarded to Raytheon Canada Ltd. in 1985.

------------------------------

Date: 4 Aug 92 03:43:17 GMT From: stern6@husc10.harvard.edu (Michael Stern) Subject: Fun with high pressure

Beware of high pressure without passive safety devices! The following account of a near accident at a research university is constructed from conversations with a friend of mine who will remain nameless, as will his university.

Researchers were attempting to measure directly the permeability for melt transport through a matrix of partially molten rocks. This required the use of a digitally controlled high-pressure pump (a 25,000 psi Single-Cylinder Positive Displacement Pump manufactured by Ruska Instruments of Houston, TX.)

The pump was controlled by a ZEOS 386 clone via a serial line. On the day in question, the computer froze while the pump was compressing the system at full speed. Before dying, it sent enough garbage across the serial line to confuse the pump's keyboard, so that researchers lost all software control of the pump, which merrily continued to compress past the software pressure limit which had been set (corresponding to the maximum pressure for the tranducers in the system, 2000 psi). It got to 4000 psi, the threshold for permanent damage to the transducers, before they managed to switch the power to the pump's motor off. This is particularly scary because the pump will go to 25,000 psi, but the plumbing was rated only for 20,000 psi so it would probably have been an explosive failure.

They had had problems with the clone in the past; most of which were believed related to the Extended Memory Manager.

It should be noted that the following safety precautions would eliminate this type of danger: use of _hardware_ travel limit switch as well as software pressure limit. Also, any system with pressure-sensitive parts should always have at least one safety head equipped with a suitable rupture disk.

Michael Stern

------------------------------

Date: Tue, 4 Aug 92 23:43:36 PDT From: desint!geoff@uunet.UU.NET (Geoff Kuenning) Subject: Mr. C. Baggage, who was neither a Mister nor a Baggage at all

Some years ago, a cellist acquaintance landed a job on the opposite coast. Like all serious cellists, she bought a second ticket for her valuable instrument rather than subject it to the vagaries of airline baggage handling.

As it happened, someone near the destination later offered her the use of another fine cello so that she wouldn't have to bring her own. Stuck with an extra ticket, she successfully advertised it for sale. The only catch was that the purchaser had to identify himself as Mr. C. (for Cabin) Baggage when he boarded the flight.

It seems that the ticket-reservation system doesn't have a provision for tickets issued to non-persons. A blank field is an error, and there is no override. I've heard of some pretty creative names invented by cellists to identify their instruments on flights.

Geoff Kuenning geoff@ITcorp.com uunet!desint!geoff

[She could buy a ticket for the 'cello case in the name of Justin Case -- just in case she needed the extra seat. Further confusions arise ticketing a baseball pitcher named Viola or someone associated with ClariNet. (Playing first bass/base is clearly ambiguous orally/aurally/AuraLee.) There are also rigorous orchestras with Horn Clauses in their contracts. PGN]

------------------------------

Date: Tue, 4 Aug 92 09:33:02 CDT From: rex@iqsc.com (Rex Black) Subject: Unreliable call-return phone feature...

I know that caller ID has generated a number of discussions about privacy and risks to individuals. I'd like to pass on a personal experience I had with a related technology, call return.

I was using my modem and computer to telecommute on Sunday afternoon. Shortly after hanging up, my phone rang. The caller asked with whom she was speaking. I responded by asking who she was trying to reach. It turned out that she had just been the victim of a harassing phone call. Southwestern Bell has a phone feature (call return) that allows a person to press a star-sequence (i.e., *1) to call back the last caller. According to the phone salesman who (aggressively) marketted it to me when I had my phone connected three months ago, it uses the same logic as caller ID. (He mentioned that Southwest Bell would offer caller ID in the fall.) He promoted call return as a "great way to deal with obscene or harassing callers." My experience Sunday afternoon points out a serious risk associated with such technology. Clearly, the system has a bug. That bug lead someone to believe that I was harassing them. Depending on what was said, the system identified me as a misdemeanant or a felon.

On Monday, I called Southwestern Bell and explained my concern. While the person I spoke with understood my concern, he did not help. He repeated the standard disclaimer about "no phone system is perfect, the phone company can not guarantee accuracy, blah, blah, CYA, CSWBA..." I did manage to get from him some further information: First, this was hardly the first time this happened. He mentioned that incidents like mine occur frequently. Second, the phone company's policy requires that, before turning a case over to the police, someone must repeatedly call and harass someone. One instance does not suffice.

I then called the P.U.C. I spoke with a woman there who, when she realized I was calling to voice concerns about caller ID and call return, adopted a very tired tone of voice. She gave me a docket number and said that I should send in my comments to the P.U.C. I asked about groups who may have joined fight against such technology. She said that SWB had just submitted the caller ID request, but she expected that a number of people would get involved in the ensuing discussion. She did not sound pleased at the prospect. Rex

------------------------------

Date: Tue, 04 Aug 92 08:20:27 EDT From: CMHAM01@UKCC.uky.edu (Chuck Ham) Subject: GTE's Personal Secretary

General Telephone is just now offering the "Personal Secretary" voice message service to the public here. In recent newspaper ads GTE touts that the service takes messages, reminds you of important dates, has a wake up service, and can be programmed up to a year in advance. Sounds like I can throw away my answer- ing machine, my date book, my alarm clock and my computer, all for the low price of $5.95 a month with the first 30 days free!

Customers, however, are not made aware of some of the risks involved. A friend was recently made a victim of the service WITHOUT subscribing.

She noticed her home phone (which she always used to receive client calls) was not ringing and no messages were being left on her answering machine. Several times when she tried to dial out a strange tone came over the receiver. This went on for several days until her business associate complained of the same problems.

After discussing this with GTE my friend discovered that a church-friend that works for GTE signed up SEVERAL people without their knowledge. (She thought it was a "nice" thing to do.)

My friends problems with the "Personal Secretary" were caused by the way the system is set up. First, it answers on the first ring, therefore it wouldn't activate the answering machine or allow a person to answer. Second, without the proper code number you cannot retrieve your messages (the tone she heard was alerting her to the messages she had waiting... but of course she had no idea what it was for). Needless to say my friend was not impressed!

How could the phone company employee sign someone up without their knowledge or signature? Doesn't GTE have some legal obligation to notify a customer before tapping a service onto their line? Can they just do it without any proper authorization?

Chuck Ham chuck.ham@ukwang.uky.edu Radio/TV Information Specialist University of Kentucky

------------------------------

Date: Fri, 31 Jul 1992 20:00:00 -0400 From: Nigel Allen <nigel.allen@canrem.com> Subject: Police files

New York Awarded Funds to Improve Criminal History Records To: State and City Desks Contact: Stu Smith of the Office of Justice Programs, U.S. Department of Justice, 202-307-0784 or 301-983-9354 (after hours)

WASHINGTON, July 30 /U.S. Newswire/ -- The U.S. Department of Justice has awarded the state of New York $381,512 to continue its program of improving the quality of the state's criminal history recordkeeping, the Bureau of Justice Statistics (BJS) announced today. The project, administered by BJS in the Office of Justice Programs (OJP), is part of a three-year, $27 million program established by the Attorney General to help states upgrade current systems used to maintain records of arrests, prosecutions, convictions and sentences. The Bureau of Justice Assistance is providing the funding through the Edward Byrne Memorial State and Local Law Enforcement Assistance Program. "The major objective of this cooperative agreement is to improve the overall quality of the state's criminal history record information by improving disposition reporting, " said BJS Director Steven D. Dillingham. "This administration is making every effort to assure the highest standards of accuracy and timeliness in criminal history record information across the country. It is critical that law enforcement officers, prosecutors, judges and corrections officials have access to complete and accurate information on each individual within the purview of the criminal justice system," Dillingham commented. The New York Division of Criminal Justice Services will use the assistance to correct database problems identified during the first phase of the program and complete a study to determine if problems related to disposition collection can be systematically resolved. "The program emphasizes the recording of arrest, conviction and sentencing information in a form that will make felony history information more reliable and complete," Dillingham commented. "This is a crucial component of the overall objective of insuring that state criminal history records are up-to-date and available to all criminal justice agencies." Additional information about this program is available from BJS. Publications and statistical and research data may be obtained from the National Criminal Justice Reference Service, Box 6000, Rockville, Md. 20850. The telephone number is 301-251-5500. The toll-free number is 800-732-3277.

Canada Remote Systems - Toronto, Ontario/Detroit, MI World's Largest PCBOARD System - 416-629-7000/629-7044

------------------------------

Date: Tue, 4 Aug 92 15:09:55 -0400 From: scs@adam.mit.edu (Steve Summit) Subject: Re: User interface studies: oh, what's the use? (Slade, RISKS-13.69)

Robert Slade writes: > Couple... at next ticket machine looking very > worried...: "How do you work this?" Point out large legend at top... Point > out large A by map, B by buttons, etc. Couple goes back to worrying in > front of next ticket machine.

There's a fundamental problem here which we might as well lump together with computer literacy (or lack thereof). Many people have an instinctive, gut-level response to anything that "looks technical": "Oh, this is too complicated. I can never figure these things out." No amount of (impersonal) hand-holding in the form of allegedly idiot-proof instruction will help; these people's minds are firmly made up. ("The lady doth protest too much, methinks" applies -- if a technical system, for use by the masses, seems to need "idiot-proof" instructions, it's probably too late. Don Norman's POET discusses this phenomenon well, and at length.)

The instinctive response ("I can't figure this out") is irrational, because there are many allegedly idiot-proof technical systems out there which are truly inspired in the techniques they employ to achieve alleged idiot-proofness, techniques which render the interfaces accessible to just about anyone *if they try*. But remember, humans are basically irrational creatures (which only makes irrational responses harder to understand for those of us who occasionally try to be rational).

A lode that newspaper columnists have been gleefully mining lately is disgust (theirs and their readers') over voice mail systems ("push 1 if you would like to..."). These systems, when implemented well, can be much more efficient than waiting on infinite hold for harried, human operators. But the people doing the complaining want to talk to a person, they don't want to push buttons.

I think it will take a couple of generations before there is any kind of widespread approval and appreciation of these and other similarly technical systems. Steve Summit scs@adam.mit.edu

------------------------------

Date: Tue, 4 Aug 1992 14:42:13 GMT From: elr%trintex@uunet.UU.NET (Unix Guru-in-Training) Subject: Sweet Old Things and User Interfaces (Slade, Re: RISKS-13.69)

Robert Slade, in RISKS 13.69, describes the scene in front of various automatic teller machines and ticket machines and sees that in spite of clear and instructive diagrams (to him) people (especially older people) are still having trouble using automatic machines.

Although it's a little hard to read Robert's prose, he appears to be saying that no matter how smart the computer is, some people are still too stupid to use it. I'm a bit worried by that -- the readers of RISKS are all fairly sophisticated computer users who can handle the various commands of Unix, VMS and fourteen million different mail-readers. Have we forgotten that not everyone else in the world uses computers the way we do? That operating a machine, be it a soda vending machine, vacuum cleaner, bank machine, or Sun workstation, is not a skill human beings are born with?

If the user interface is too difficult for most users to figure out, it's not the user's fault. It may not even be the machine's fault -- it may just be the job the machine is trying to do is too complicated for the average person. The problem is that is was designed by "computer geeks" like us, who don't have a problem learning a difficult interface.

Perhaps as the older generation passes, replaced by a generation born using Nintendos, remote controls, digital watches, and other accoutrements of the digitized era, the minimum ability of the average person to use a machine interface will increase. But until then, we shouldn't fall into the trap of blaming the victim for the inadequate user interface.

Ed Ravin elr@trintex.uucp elr%trintex@uunet.uu.net +1-914-993-4737

------------------------------

Date: 4 Aug 92 10:07:00 EDT From: Stanley (S.T.H.) Chow <SCHOW@BNR.CA> Subject: re: Computer scoring glitch at Olympics (Carr, RISKS-13.69)

This is a good illustration of a problem that is often blamed on copmuter systems, particularly when cutting in a new system.

People forget that it is a different game.

The rules were changed (I presume at the insistance of the Americans as a result of the Soul Olympics), why should one expect the same result from the new rules as the old obsolete rules? The fact that a computer system was used to keep score under the new rules is neither here nor there (unless there has been a real computer glitch).

One can conjure up many different possible reaons why the new rules give a result different from the old rules, one can also argue endlessly as to which set of rules are better, but rules are rules.

To bring this back to RISKS: using a new computer system to implement a new set of rules can bring about surprising result, having people in the loop adds a degree of self-correction.

Stanley Chow (613) 763-2831

BNR, PO Box 3511 Stn C, Ottawa, Ontario, Canada K1Y 4H7 BitNet: schow@BNR.CA schow%BNR.CA.bitnet@relay.cs.net ..!uunet!bnrgate!bcarh185!schow

------------------------------

Date: Mon, 3 Aug 92 19:02:55 PDT From: konstan@elmer-fudd.cs.berkeley.edu (Joe Konstan) Subject: Re: Computer scoring glitch at Olympics

In RISKS-13.69, John Carr presents a _Boston Globe_ except about a "computer glitch" that eliminated US boxer Eric Griffin. As someone who watched the fight (tape delayed) on TV, and has been following the controversy, I'd like to add a few points that are missing from the article.

There are two main human reasons why the computer system, which most commentators thought functioned properly, would record such a score. First is the "Nintendo effect"--boxing judges don't tend to have particularly good reaction times, and therefore may miss the one-second cutoff. Second is a particularly bad judge, who recorded only 13 punches total while the others averaged 29.5. This judge had just returned from a two day suspension for poor performance.

To understand the system, it is somewhat useful to understand the layout of the ring judges. This picture is approximate:

X ---------- | | X | | X | | ---------- X X

Under the new scoring system, the main score is based on a majority of judges recognizing any punch. Since at least one, and often two will have obscured views, a single bad judge really can throw off the system WITHOUT ANY COMPUTER MALFUNCTION.

Finally, this particular match, while extremely shocking, is not that unusual. Throughout these olympics, a large number of clear punches, particularly to the body, have not been scored.

As we see again and again, a computer cannot take a poor system and make it better--but it can provide a focus for blame. Joe Konstan

------------------------------

Date: Wed, 5 Aug 92 19:08:41 -0700 From: dkw@cs.brandeis.edu (David Wittenberg) Subject: Re: computer scoring at olympics (RISKS-13.69)

If you don't know how to do something, you don't know how to do it with a computer.

The real problem is that boxing has not decided what they mean by "landing a blow". Note that the individual scores vary by more than a factor of 3. If the judges differ by a factor of three, how can they expect that software will mediate this difference? I suspect that the software did exactly what it was specified to do.

According to the commemtators, the new scoring system has changed the style of boxing. Computers cannot decide what the rules should be, but they can, and perhaps should, be used to see what results different rules give, and one can they chose the rule that most closely correlates with the judges' impressions.

--David Wittenberg

------------------------------

Date: Thu, 06 Aug 92 15:05:45 PDT From: kemm%cs@hub.ucsb.edu Subject: 1993 Symposium on Research in Security and Privacy

CALL FOR PAPERS 1993 IEEE Symposium on Research in Security and Privacy Oakland, California, May 24-26, 1993

sponsored by IEEE Computer Society Technical Committee on Security and Privacy in cooperation with The International Association for Cryptologic Research (IACR)

The purpose of this symposium is to bring together researchers and developers who work on secure computer systems. The symposium will address advances in the theory, design, implementation, evaluation, and application of secure computer systems. Papers and panel session proposals are solicited in the following areas:

Secure Systems Privacy Issues Information Flow Network Security Formal Models Viruses and Worms Database Security Access Controls Security Verification Authentication Data Integrity Auditing and Intrusion Detection

INSTRUCTIONS TO AUTHORS:

Send six copies of your paper and/or panel session proposal to Richard Kemmerer, Program Co-Chair, at the address given below. Put names and affiliations of authors on a separate cover page only, as a ``blind'' refereeing process is used. Abstracts, electronic submissions, late submissions, and papers that cannot be published in the proceedings will not be accepted.

Papers must be received by November 15, 1992 and must not exceed 7500 words; papers that exceed this length will be rejected without review. Authors will be required to certify prior to December 25, 1992 that any and all necessary clearances for publication have been obtained. Authors will be notified of acceptance by February 1, 1993. Camera-ready copies are due not later than March 15, 1993.

The Symposium will also include informal poster sessions. Send one copy of your poster session paper to Teresa Lunt, at the address given below, by January 31, 1993. Electronic submission of the latex source for poster session papers is strongly encouraged. Poster session authors must send a certification with their submittal that any and all necessary clearances for publication have been obtained.

PROGRAM COMMITTEE Tom Berson Paul Karger Jon Millen Anagram Laboratories OSF MITRE Deborah Cooper Tanya Korelsky Jeff Picciotto Paramax Systems Corporation ORA MITRE George Dinolt Sue Landauer Phillip Porras Loral Labs TIS Aerospace Virgil Gligor Teresa Lunt Ravi Sandhu University of Maryland SRI George Mason Univ. Deborah Hamilton Doug McIlroy Marv Schaefer Hewlett-Packard Laboratories AT\&T Bell Labs CTA Jeremy Jacob John McLean Brian Snow Oxford University NRL NSA Sushil Jajodia Catherine Meadows Yacov Yacobi George Mason University NRL Bellcore

For further information concerning the symposium, contact:

Teresa Lunt, General Chair Cristi E. Garvey, Vice Chair SRI International, EL245 TRW, MS R2-2104 333 Ravenswood Avenue One Space Park Menlo Park, CA 94025 Redondo Beach, CA 90278 Tel: (415)859-6106 Tel: (310)812-0566 FAX: (415)859-2844 FAX: (310)812-7147 lunt@csl.sri.com

Richard Kemmerer, Program Co-Chair John Rushby, Program Co-Chair Computer Science Department SRI International, EL254 University of California 333 Ravenswood Avenue Santa Barbara, CA 93106 Menlo Park, CA 94025 Tel: (805)893-4232 Tel: (415)859-5456 FAX: (805)893-8553 FAX: (415)859-2844 kemm@cs.ucsb.edu rushby@csl.sri.com

Jeremy Jacob, European Contact Oxford Univ. Computing Laboratory 11 Keble Road Oxford, England OX1 3QD Tel: +44 865 272562 FAX: +44 865 273839 jeremy.jacob@prg.oxford.ac.uk

------------------------------

End of RISKS-FORUM Digest 13.70 ************************