2-May-94 21:51:36-GMT,29924;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01545; Mon, 2 May 94 17:51:35 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29934; Mon, 2 May 94 17:51:25 EDT Received: by chiron.csl.sri.com id AA00697 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Mon, 2 May 94 14:40:29 -0700 From: RISKS Forum Sender: RISKS Forum Date: Mon, 2 May 94 14:40:26 PDT Subject: RISKS DIGEST 16.01 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Monday 2 May 1994 Volume 15 : Issue 01 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Vandalism disrupts service at UK University (Peter Ladkin) Subjectively, it's eerie (Phil Agre) Miniature cameras on Sacramento-area alarm systems (Dan Zerkle) DIA delays due to programmers, mayor implies (Bear Giles [2]) Re: DMV Computer upgrade goes awry... (Shel Kaphan) Re: Unusual Newspaper Error (Stewart Rowe, David Wittenberg, Daniel B. Dobkin) Re: MIT student arrested for BBS ... ( Fredrick B. Cohen) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Sat, 30 Apr 1994 11:35:23 +0200 From: Peter Ladkin Subject: Vandalism disrupts service at UK University Early on Monday 18th April, a vandal exploiting a not-unknown security hole started disrupting services and corrupting files at Stirling University in the UK. Stirling University is a SuperJanet site, with a microwave link to Edinburgh. The entire site was affected. I was working intensively with a colleague in Stirling at the time. My experience was that the site was unreachable by Internet services for over 24 hours, and that telnet and ftp services were seriously degraded for 3-5 days. Email service was unavailable for 2-3 days. It would be conservative to estimate that at least 6 person-weeks of expert time were required to discover and repair the damage. I cannot assess the amount of disruption, not only in terms of work time lost but in terms of reorganising one's planned work time, to users of the systems. It must be considerable, if my experience is any guide. Someone believed to be the vandal, and a member of the University, was identified I believe on Tuesday 19th. I understand he is no longer on University premises, and the University authorities are considering what further action is required. Because of possible legal proceedings, I'll identify my sources of information and exactly what they said in an Appendix. In a separate submission, I'll offer a few comments of my own on this incident. I had been a member of the Stirling Department of Computer Science and Mathematics for 18 months up until April 94. Knowing that it was an `inside job', I queried a colleague as to whether more than one member of the department knew the suspect. The answer was yes. >From this information alone, I was able to identify my own suspect X, and ask whether X was any longer around, or whether anyone expected to see him back. The answer confirms to me with high probability that X is the suspect. (I note that nothing has been proved concerning X.) If X did it, the process by which he came to it would be interesting, both for psychologists and for those who wish to secure their systems against corruption. [I'll drop the conditional and use the indicative, for stylistic not semantic reasons. Readers should reinsert it, since nothing has been proven against X.] And it provides a cautionary tale that shows how vulnerable we all are. After the fact, I can guess who X is with a bare minimum of hints. However, before the act, only X's therapist, if he had one, is likely to suspect that anything may happen. And of course, in any case if he had been able to communicate his feelings to anyone sympathetic or understanding - but otherwise uninvolved - the chances are that the incident would not have happened. It's a very self-destructive act. Playing with computers is an important part of X's life, and indications are that he was good at it and liked it. Now, no one but no one is likely to offer him a job doing it. A major part of his life is in ruins. Despite all else, I can feel some sympathy for what must be his current plight. It isn't even zero-sum. Everyone has lost in a big way. [And it must be far, far worse for him if he's not the culprit!] Peter Ladkin Appendix: Sources of Information. I talked to the Senior Computer Officer of the Department of Computing Science and Mathematics by phone on Tuesday 19th. He confirmed that the Stirling site was off the Internet on Monday, that disruption started early Monday morning, luckily just after Computer Science had made backups of their subnetwork of systems. He confirmed an estimate of at least 3 person-weeks of the DCSM staff, and suggested at least an equal number for Computing Services staff, to identify damage and effect some repair. He said that the disruption was caused by someone exploiting a not-unknown system weakness, and that a suspect who was a member of the University had been identified and removed from the site. He identified the gender of the suspect by his choice of pronoun. He gave no further information, citing administrative and legal responsibility. I talked to one member of the Department of Computing Science and Mathematics, who confirmed that a suspect was known to more than one member of the Department, and that he (male) was identified through a piece of `luck'. Peter Ladkin, CRIN-CNRS & INRIA Lorraine BP 239 54506 VANDOEUVRE-LES-NANCY FRANCE (+33) 83 59 20 14 (Msgs 20 00) Peter.Ladkin@loria.fr ------------------------------ Date: Sun, 1 May 1994 13:05:12 -0700 From: Phil Agre Subject: Subjectively, it's eerie ,In the 5/1/94 Sunday New York Times, the Business section includes one of those nice experiential articles about new technology, in this case a Ford with DSP circuitry in it that makes the inside of the car sound like a cathedral (concert hall, night club, opera house, stadium, etc). The full reference is: Hans Fantel, A recital hall on wheels, New York Times, 1 May 1994, Business section page 7. Here is a brief quotation: "Subjectively it's eerie. Sitting inside this hologram, I felt bathed in music, virtually forgetting where I was. Engine and traffic noises faded from awareness. The car somehow seemed like a space capsule. I was gliding along, swathed in Puccini, while outside the harried scenes of Manhattan rolled by like a silent movie." On the same page is another article about plans by the US government and Rockwell International for "intelligent vehicle highway systems". Phil Agre, UCSD ------------------------------ Date: Sun, 1 May 94 00:35:54 PDT From: zerkle@cs.ucdavis.edu (Dan Zerkle) Subject: Miniature cameras on Sacramento-area alarm systems The April 24 edition of the Sacramento Bee (page B5, staff writer) publishes a story about a miniature camera that will "revolutionize" the Sacramento area security alarm industry. Some important points of the article: A miniature "camera on a chip," about the size of a postage stamp, is attached to an alarm system. When the alarm is tripped, the camera sends four pictures back to the the alarm monitoring service. Presumably, the pictures are digitally encoded and sent through some sort of modem. The first picture arrives twenty seconds after the alarm is tripped. Police are particularly excited about this because it will let them use the pictures to detect false alarms. The system is intended to be used in a wide variety of businesses, and also residencies. The photographs will be usable as evidence in court against robbers and burglars. The camera is so small that it can be easily hidden anywhere. It is also inexpensive -- one third to one half the cost of a closed-circuit video camera. "The pictures come out pretty clear," according to a police communications supervisor. The device was developed by Automated Security Holdings in England, licensed to TVX Inc. of Broomfield, Colorado, and test-marketed by Roseville Telephone (near Sacramento). ..... The risks? Many. Here are a few: It only takes four pictures, which are presumably freeze-frames. A burglar may trip the alarm yet not be photographed (perhaps going by the camera between pictures). The alarm agency or police may see that the pictures don't show anything, and thus believe that it is a false alarm. They may then decline to respond or may respond inappropriately. This is a perfect spy device, and will be easily available at a price less than a simple video camera. The potential abuses of such a device are many, but employee monitoring is one. Your boss could point one at your work area to watch you, and you'd never know. A hidden security camera is really a spy camera, equivalent to an audio bug. In fact, the article mentions that it could be used against internal thefts. If someone says the pictures are "pretty" clear, that means that they aren't entirely clear. If police trust pictures too much, the potential is there for police to misidentify a suspect (based on a picture), but firmly believe that they are right. This is especially likely if the pictures are monochrome. As the first picture arrives in twenty seconds, they are certainly low resolution (consider connection time for the modems). A camera in my residence? What if it starts sending pictures back to the alarm company at random? What if some voyeur at the alarm company figures out how to get pictures whenever he wants? Most people who have these alarm systems will not know how they work, so they won't be aware of these risks. A remote digital camera would be useful in some situations. For instance, it could send pictures of a bank robber holding a gun, so that the police could more easily identify a suspect. The main risk here is (again) too much trust in the technology. Also, there's not a great need to hide a security camera. You generally want potential crooks to know they're being monitored. Dan Zerkle zerkle@cs.ucdavis.edu ------------------------------ Date: Sat, 30 Apr 1994 11:21:16 -0600 From: Bear Giles Subject: DIA delays due to programmers, mayor implies The Saturday, 30 April 1994 issue of the _Rocky Mountain News_ (and probably every other paper within 500 miles) had a massive front page story on the utter failure of the luggage system during tests at Pena International. (IMHO these design failures have reached the point where the current Secretary of Transportation needs to answer some questions.) Apparently, Mayor Webb is considering an *indefinite* delay, at the request of the hub airlines United and Continental. Of interest to comp.risks readers are the following paragraphs from the article: Webb, who has regretted setting -- and missing -- other airport deadlines during his three years in office, said other one isn't a good idea. Although deadlines motivate some people, they don't work well for computer programmers who must fix what is wrong at DIA, he said. Strictly speaking, this is probably true. The incredible design flaws (e.g., designing the airport to use an untested luggage transportation system with *no* fallback capability) and construction snafus (e.g., the "messy" power system despite contractual agreements to provide a "clean" power feed, leading to significant delays while BAE scrambled to find power filtering equipment) leave software as the only practical way of getting out of this mess. And very few experienced programmers would tolerate the same people who have screwed up things to this extent trying to impose an unrealistic deadline on them now... ... but Joan Q Public will undoubtably read this as yet another example of computer software screwing up the system. It's the 90's -- your dog didn't eat your homework; the software garbled it! It's almost enough for me to move 30 miles so I can vote against Webb in the next election. :-) Bear Giles bear@cs.colorado.edu/fsl.noaa.gov ------------------------------ Date: Sat, 30 Apr 1994 15:33:11 -0600 From: Bear Giles Subject: More on DIA fiasco Reading later articles (there were several pages of DIA coverage today, not just Mayor Webb's flamebait), it appears the scapegoat du jour for the DIA delay is the "buggy software" that reads the bar codes in the luggage and determines where to send the cart. A fascinating (for the wrong reasons) newspaper article included such interesting factoids as: Software -- essentially the brains of a computer system -- is so complex that a misplaced comma or an omitted semicolon can crash entire computer systems. Even the smallest error can cause a ripple effect that turns into a tidal wave of the kind that swamped AT&T's main switching system several years ago and shut down nearly 90% of the phone company's domestic long-distance operations for hours. Strange how us computer types have never figured out how to check for syntax errors like this. (Compilers can't catch all such errors, but that's why we set up human checks like coding standards and code walkthroughs.) The BAE system employs laser scanners that read bar-coded labels placed on baggage. Experts say that means the BAE computer system probably employs real-time, numerical-control software. Hmm... doesn't "numerical control" refer to machining equipment? At Louisville-based Storage Technology Corp., such software is a key feature of the company's robotic tape library storage systems. "What they are probably seeing, and I saw it many times, is that you fix one problem and you're just peeling back a layer of the onion," said Mark Hopkins, an engineering manager for StorageTek. Which explains why Iceberg has been such a successful product. Strangely absent from the article is the reason Denver (or BAE) decided to build a system which reads tags on luggage (which can be oriented in an arbitrary direction) instead of reading permanent tags on the cart itself. The latter case would require keeping track of what luggage is in which cart, but eliminates all of the headaches of reading the tags on the luggage itself. (Hmm, the wording of a newspaper graphic implies that a copy of the luggage tag may be placed on the cart as well, but its alignment may not be perfect.) Even stranger was an item in another article which identified "gaps" in the tracks as a biggest problem right now (the software being a bigger long-term problem). It seems the wheels on the cart are falling into gaps between sections of track, causing jams or derailments. (Failing luggage is a serious construction worker hazard.) This is truly bizarre since the luggage system is in a protected environment, located in underground tunnels. For the tracks to be damaged by "vibration" caused by a couple limited tests implies that this infrastructure was *seriously* underdesigned. Bear Giles bear@cs.colorado.edu/fsl.noaa.gov [Various articles also noted by greg@imsl.com (Greg Holling), who also contributed similar analyses. Greg, thanks. PGN] ------------------------------ Date: Fri, 29 Apr 1994 21:11:15 -0700 From: sjk@netcom.com (Shel Kaphan) Subject: Re: DMV Computer upgrade goes awry... SACRAMENTO - The California Department of Motor Vehicles has informed a flabbergasted legislative committee that it has spent $44.3 million on a computer modernization program that will never work. ... Note that this amount of money is approximately equal to the $50M per year in highway funding that the federal government has been withholding from California because we have not yet instituted the rule that anyone caught in possession of any amount of any illegal drugs or prescription drugs without a prescription will have their driver's license suspended for six months. That's whether you're driving at the time or not. According to the SJ Mercury News a week or two ago, the CA state legislature is most unlikely to put off adoption of this rule any longer, presumably at least in part because of the effect of recent disasters on highway construction budget requirements. Even without the DMV debacle the state might have decided to do this, but perhaps one can hold them partially responsible for the declining quality of legislation these days. Shel Kaphan sjk@netcom.com ------------------------------ Date: Thu, 28 Apr 1994 13:47:28 -0400 From: "Stewart Rowe" Subject: Re: Unusual Newspaper Error In Risks 15.79 I asked: >Perhaps one of your readers can explain how the Midwest edition of *The New >York Times* today had a photo on the front page with the caption. "Joseph P. >Kennedy Jr. being arrested at the White House yesterday", with no further >explanation or story anywhere in the paper? Several respondents have reported that, in the Metro edition, the explanation was found in three paragraphs at the end of the adjacent story about Haitian refugees. Apparently these paragraphs were cut by the person who made up the continuation page in the Midwest edition, leaving Joe Jr. hanging there on page 1. (Yes, I checked back and they are not there in my copy). Stewart Rowe usr2210a@tso.uc.edu ------------------------------ Date: Wed, 27 Apr 1994 10:31:19 -0500 (EDT) From: David Wittenberg Subject: Re: Kennedy arrest According to the "Boston Globe", Congressman Kennedy and several other colleagues (7 or 8?) were arrested for demonstrating in protest of the US government's policy on Haiti. The arrests were made by the Park Service police. My guess is that the congressmen had every intention of getting arrested as a way of increasing publicity. The error was in a correct, but misleading caption. We usually assume that when a politician is arrested it is unintentional. --David Wittenberg dkw@cs.brandeis.edu ------------------------------ Date: Thu, 28 Apr 94 16:51:23 EDT From: "Daniel B. Dobkin" Subject: Re: Unusual Paper Error (Rowe, RISKS 15.79) For what it's worth, my wife asked the same question, and she was looking at the New York Metro/Suburban edition. While I can't speak with any real authority about the Midwest (national) edition, I will say that in my experience the first page doesn't change much; the big difference is in the metro section: the national editions don't carry the local stories. The picture with the caption ("Joseph P. Kennedy Jr. being arrested at the White House yesterday") accompanied the story about the Administration's policy on Haiti. While there was no mention of Rep. Kennedy anywhere in the story, it did state that (quoting from memory) "four members of the House of Representatives were arrested during a protest at the White House." To my eye, this is sloppy copy editing, not a bona fide technology blunder.... The technology does seem to encourage such sloppiness, though, a fact to which our moderator (and the RISKS archives) will bear witness. \dbd ------------------------------ Date: Tue, 26 Apr 94 16:16:01 PDT From: Fredrick B. Cohen Subject: Re: MIT student arrested for BBS ... (Cohen, RISKS-15.76) Sorry - I was mistaken when I claimed that LaMacchia was arrested. The correction noted by Tim Shepard and Douglas Rand in RISKS-15.79 was accurate. As to the issue of his intent to pirate software, that was not the charge against him. It was wire fraud! I have read the copy of the indictment and commentary and I find this awfully strange. Furthermore, I find little if any substantive evidence of intent to pirate software in my reading of the quotes from the indictment. If you assume he is innocent and ask yourself if these comments could have been innocently made by a person of that age in that environment, you may find that the assertion of guilt is not warranted. FC ------------------------------ Date: Mon, 02 May 1994 12:50:25 -0600 (MDT) From: "Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067" Subject: "The Streetwise Guide to PCs" by Jerome/Taylor BKSTRTPC.RVW 940118 Addison-Wesley Publishing Company Heather Rignanesi, Marketing, x340, 73171.657@Compuserve.com P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario, M3C 2T8 CANADA telephone 416-447-5101, fax: 416-443-0948 or Tiffany Moore, Publicity tiffanym@aw.com Bob Donegon bobd@aw.com John Wait, Editor, Corporate and Professional Publishing johnw@aw.com Tom Stone, Editor, Higher Education Division tomsto@aw.com Philip Sutherland, Schulman Series 74640.2405@compuserve.com 1 Jacob Way, Reading, MA 01867-9984 800-822-6339 or 617-944-3700, Fax: (617) 944-7273 5851 Guion Road, Indianapolis, IN 46254, 800-447-2226 "The Streetwise Guide to PCs", Jerome/Taylor, 1993, 0-201-60839-1, U$14.95 Those of us who have been around the computer world for any length of time have seen a great many "How to Buy a PC" seminars, articles and user group meeting talks. They generally offer a lot of helpful advice and useful information for the novice. I have, however, often noted personal bias being delivered with the same force and weight as known and tested fact. The neophyte generally comes away with a much better knowledge of the computer market--but also with a number of unsubstantiated prejudices. Here, then, is a book on the same topic. Containing far more material than any one-hour talk or magazine article, it nevertheless has some of the same tone. Those wise in the ways of computer purchasing will many times breathe an "Amen!" to much of what is here. There are also, however, personal biases and blind spots that the newcomer will have difficulty recognising. Chapter one is a general diatribe against the industry as a whole. As vitriolic as it may sound to the newcomer, the authors may, in fact, be *under*stating the case. Chapter two states that software is central to the whole process, and gives tips for evaluating the major applications. The remaining eight chapters are devoted to hardware. There are some easily identifiable oddities. The statement that Windows' management of resources makes things easier obviously comes from someone who has never had to check the five completely different print menus under Windows to find out why nothing is coming off the printer. Some items seem to be subject to time lag, as with the insistence that 386 and 486 CPUs are maker- independent. (This might have been true earlier, but the 486 market is now an utter shambles.) The authors still cling to their claim that all surge protectors are created equal. I found the section on virus protection to be fairly reasonable--except that they still get the Stoned message wrong, think all scanners are equally effective, and don't know about shareware scanners. In fact, shareware doesn't get much of a shake in spite of the railing against overpricing and software bloat. In addition, some of the recommendations for protection may give a false sense of security. The authors frequently repeat the refrain that one should never by anything with cash or cheque: put it on a credit card so that you will have some fallback. The use of a credit card, however, does *not* necessarily protect you. Once you sign the charge slip, you are committed to honour that debt. The credit card company *may* choose to reverse the charge and not pay the merchant, but that is at *their* discretion, and they are not automatically on your side. (The credit card company may take several months even to decide whether or not to reverse the charge: the representatives I talked to, at the credit card service office, the local bank, the head office complaint department and the head office PR office refused to give any upper bound or time limit for a decision. The PR department initially stated that paying by card was the same as paying by cash, but refused to answer when asked to comment specifically about the case of defective equipment.) You really are alone out there: I recently checked up on the Better Business Bureau, and found that while the technology the BBB is using for phone access to reports is impressive, the reports themselves are less so. A company which has had several disputes in the past, and has a current dispute outstanding, is listed as being in "satisfactory" standing, and the BBB had "received no complaints" during its existence. The BBB also had a chance to respond to this and indicated that it was because of their "standard reporting language" imposed from head office. (BBB is a franchise.) Complaints are not entered into the automated system until proven, beyond doubt, to be "valid": the consumer is not allowed an opportunity to respond to the final offer from the merchant. Decisions on validity are made by the BBB. The BBB is paid by the vendor. The conclusion is left as an exercise to the reader. (The General Manager of the local BBB stated that more detailed information is available from the counselors, although this is not made at all clear from the automated system. I checked this out later, and it turns out not to be the case. She also stated that most people deal with the counsellors rather than the automated system, which doesn't surprise me in the least.) In the absence of any better, though, this book is to be recommended for beginners *before* they buy a computer. One of the particularly nice features is a sample advertisement introducing every chapter and dissected for "lies". Get some street smarts before you go buy a PC. And never buy anything on the spot. copyright Robert M. Slade, 1994 BKSTRTPC.RVW 940118 DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 DECUS Symposium '95, Toronto, ON, February 13-17, 1995, contact: rulag@decus.ca ------------------------------ Date: Mon, 2 May 94 11:42:09 PDT From: dill@hohum.stanford.edu (David Dill) Subject: Computer-Aided Verification 94 Conference Announcement CONFERENCE ANNOUNCEMENT Conference on Computer-Aided Verification CAV 1994 Stanford University, June 21-23, 1994 The Sixth Conference on Computer-Aided Verification will be held June 21-23 at Stanford University. The conference will be followed on June 24th by a one-day workshop on practical aspects of computer-aided formal verification. CAV 94 is sponsored by a group of companies with a strong interest in the topic area: AT&T, IBM, Intel, Motorola, Redwood Design Automation and Sun Microsystems. [...] FURTHER INFORMATION: You can send electronic mail to "cav@hohum.stanford.edu" if you want registration information, a copy of the program, or further information about the conference. ------------------------------ Date: 15 April 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. risks-15.75 gives WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.01 ************************ 3-May-94 0:34:37-GMT,1738;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10796; Mon, 2 May 94 20:34:36 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10582; Mon, 2 May 94 20:34:32 EDT Received: by chiron.csl.sri.com id AA01199 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Mon, 2 May 94 17:26:39 -0700 From: RISKS Forum Sender: RISKS Forum Date: Mon, 2 May 94 17:26:37 PDT Subject: RISKS DIGEST 16.01fix Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Monday 2 May 1994 Volume 15 : Issue 01fix FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator THE CONTENTS LIST WAS IN ERROR, AS TWO ITEMS (Slade and Dill) WERE OMITTED. THIS IS A CORRECTED CONTENTS LIST. THE ARCHIVE COPIES HAVE BEEN FIXED. Contents: Vandalism disrupts service at UK University (Peter Ladkin) Subjectively, it's eerie (Phil Agre) Miniature cameras on Sacramento-area alarm systems (Dan Zerkle) DIA delays due to programmers, mayor implies (Bear Giles [2]) Re: DMV Computer upgrade goes awry... (Shel Kaphan) Re: Unusual Newspaper Error (Stewart Rowe, David Wittenberg, Daniel B. Dobkin) Re: MIT student arrested for BBS ... ( Fredrick B. Cohen) "The Streetwise Guide to PCs" by Jerome/Taylor (Rob Slade) Computer-Aided Verification 94 Conference Announcement (David Dill) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- End of RISKS-FORUM Digest 16.01fix ************************ 3-May-94 16:20:42-GMT,29400;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19697; Tue, 3 May 94 12:20:41 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09265; Tue, 3 May 94 12:19:51 EDT Received: by chiron.csl.sri.com id AA02035 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Tue, 3 May 94 09:04:44 -0700 From: RISKS Forum Sender: RISKS Forum Date: Tue, 3 May 94 9:04:42 PDT Subject: RISKS DIGEST 16.02 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Tuesday 3 May 1994 Volume 16 : Issue 02 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: NEW YORKER article on library automation (Jon Jacky) Information Warfare: GM vs VW (Mich Kabay) TechWar: Cell Phone Jamming (Mich Kabay) Green Card Con Artists Exposed! (Bonnie L. Mahon via D.R. Hilton) New firewalls book - a great risk reducer (Ray Kaplan) Re: Drunk in charge (John Simutis, Andy Ashworth, Dan Astoorian) Boot Prom commits Denial of Service Attack (Butch Deal) Staying Informed of Security & Privacy Issues (David Johnson) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Mon, 2 May 1994 21:10:10 -0700 From: Jon Jacky Subject: NEW YORKER article on library automation The April 4, 1994 issue of the NEW YORKER had a long article by Nicholson Baker on library automation: "ANNALS OF SCHOLARSHIP: Discards". It runs from pages 64 through 87. My issue also came with a flyer stapled to the cover with the headline, "THE TRASHING OF AMERICA'S GREAT LIBRARIES." Baker reports that when most libraries replace their paper card catalogs with on-line systems, they simply discard the card catalogs. Baker argues that the card catalogs are an irreplaceable resource, and contain much scholarly content which is not carried over into the new systems. Baker also argues that the on-line systems often suffer from poor data quality, and make some kinds of searches (particularly subject searches) more difficult. RISKS readers will find much of interest about the difficulties of maintaining integrity and consistency in very large databases. Baker reports one instance where all instances of "Madonna" were replaced with "Mary, Blessed Virgin, Saint," causing reclassification of recent works by Ms. Ciccone. Some letters responding to the article appear in the May 2, 1994 NEW YORKER. - Jon Jacky, jon@radonc.washington.edu, University of Washington, Seattle ------------------------------ Date: 03 May 94 09:19:36 EDT From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Information Warfare: GM vs VW (cont'd) >From the Reuter newswire via Executive News Service on CompuServe (GO ENS): "BONN, April 30 (Reuter) - The German car manufacturer Volkswagen, accused by rival Opel of industrial espionage, on Saturday denied a magazine report that incriminating material had been found in the office of an employee. Der Spiegel magazine said on Saturday prosecutors found a computer disc containing plans for a high-tech small car factory in the office of Jaero Arthur Wicker, office manager of production head Jose Ignacio Lopez de Arriortua." The article continues with the following key points: o Lopez used to work for General motors; he's accused of having stolen confidential files when he was hired by VW. o VW claims the disk has plans submitted to both GM and VW and rejected by both companies. o The situation is under investigation by both German and US authorities. o The newest scuttlebutt is that GM has asked German prosecutors to investigate daughter Begona Lopez, whom they accuse of having stolen a disk containing information on cost reductions at GM. [Comments by MK: sounds like a tabloid newspaper's version of a rivalry between movie stars.] Michel E. Kabay, Director of Education, National Computer Security Assn [That would be a REALLY SMALL car factory if it were to fit into the office of Jaero Arthur Wicker, Jaerodynamically at least. PGN] ------------------------------ Date: 03 May 94 09:19:40 EDT From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: TechWar: Cell Phone Jamming >From the Reuter newswire via Executive News Service on CompuServe (GO ENS): "KINSHASA, April 30 (Reuter) - Zaire's main cellular telephone company, at loggerheads with a rival firm trying to muscle in on its territory, said on Saturday its signals were being deliberately jammed. Jim Galan, head of coordination at Telecel, said five or six microwaves had been trained on its main antenna for the last four days, drowning out many calls made from central Kinshasa." The article explains that the jamming is making cellular phone use impossible for Telecel's 4000 Kinshasa users. It is generally believed that a new company, Comcell, which is supported by the Zairian government, is using the frequencies originally assigned to Telecel by that same government. Legal action is in the works. [MK comments: RISKS of doing high-tech business where the rule of law is weak. Example of Information Warfare a la Winn Schwartau.] Michel E. Kabay, Director of Education, National Computer Security Assn ------------------------------ Date: Mon, 2 May 1994 20:02:25 GMT From: rosidivi@rintintin.Colorado.EDU (J Doe) Subject: Disbarrable under Tenn. Code (Canter/Seigel) Reply-To: drhilton@kaiwan.com Subject: Green Card Con Artists Exposed! Keywords: green card canter lawyers For Immediate Release October 13,1988 Contact: Bonnie L Mahon The Florida Bar Tampa Office Telephone: 813/875-9821 SUPREME COURT GRANTS ATTORNEY'S PETITION TO RESIGN PERMANENTLY TALLAHASSEE, Oct.13-- The Florida Supreme Court has granted attorney Laurence A. Canter's petition to resign permanently, effective November 7, 1988. Canter, of 240 North Washington Boulevard, Sarasota, was charged with numerous violations of the attorney disciplinary rules including neglect, misrepresentation, misappropriation of client funds and perjury. Several of the complaints against Canter involved his failure to file the necessary or appropriate documents with the United Stated Immigration and Naturalization Services in matters of permanent residency and work visas. In addition, Canter refused to refund clients' funds and neglected to notify his clients that he has been suspended from the practice of law as a result of a previous discipline. The Florida Bar further alleges that Canter committed perjury by filing a false affidavit with the Bar and while testifying under oath in a deposition. These charges resulted after an audit of Canter's trust account by the Bar showed that trust funds were held in Canter's account during the time period when he denied any funds were present. Canter was born in 1953 and admitted to The Florida Bar in 1980. The resignation without leave to apply is not final until time expires to file motion for rehearing and if filed, determined. The filling of a motion for rehearing shall not alter the effective date of this resignation. As an official agency of the Supreme Court of Florida, The Florida Bar and its Department of Lawyer Regulation are charged with the administration of a statewide disciplinary system to enforce Supreme Court rules of professional conduct for all lawyers. ------------------------------ Date: Mon, 2 May 1994 23:51:07 -0700 (MST) From: RayK Subject: New firewalls book - a great risk reducer Cross post to RISKS (via mail submission), comp.security.announce and comp.protocols.tcp-ip news groups, and a few other various places. Sorry if you see this more than once. Re: Firewalls and Internet Security - Repelling the Wily Hacker. Ray Kaplan - May 2, 1994 Buy this book! Gentle folk, Here is a risk reducer. With the wholesale rush to Internet connectivity, it's about time someone sat down and wrote a good book about how to do this exercise safely! And, sure enough, Cheswick and Bellovin have done just that, Heaping superlatives on something of which you are enamored is always problematic - the possibility of overstatement looms large. Accordingly I`ll cut to the chase. Buy this book! I do not get any money for saying this - I just believe you are well justified in getting it on your reading list - today. In May of this year, Addison Wesley is releasing an excellent new book by Bill Cheswick and Steve Bellovin: Firewalls and Internet Security - Repelling the Wily Hacker. ISBN 0-201-63357-4. It will retail for $26.95. Bulk purchases: 800- 238-9682, individual orders: 800-824-7799 (FAX 617-944-7273). Email orders over the Internet from bexpress@aw.com (no they don`t take plastic via Email). For those that are net-challenged, U.S. snailmail orders from Addison-Wesley, c/o Arlene Morgan, 1 Jacob Way, Reading, MA 01867 USA. Rumors loom large that at least one of the authors (Ches?) will be at Interop with copious quantities of this work of art. As dues of superlative authorship that is destined to be popular, I hope they both get writer`s cramp autographing! Details While worthwhile, well written, pace-setting, technically astute works of art are rare - this is certainly one of them. I am always hard pressed to identify any one thing as unique in its decade (especially when the decade is still in progress). Suffice it to say that this work is the most complete treatment of firewall technology and experience that is available. The availability of this work is exciting news for security firewall builders - including Internet security firewall builders - and, for the great number of people that seem to be befuddled by the complexity and the general issues of interconnecting networks. The book While my review copy (well dog-eared, now) is a bit dated (March 7, 1994), I think you can expect that it is close to the book`s final form: a standard (w=7.5in, h=9in) Addison-Wesley Professional Computing Series book like the ones that should already dot your shelves. (I don`t get any money for my obvious favorable bias toward this series. My bias is born out of the fact that the series (Brian Kernighan is the consulting editor for it) contains great authors and titles like Radia Pealman`s Interconnections - Bridges and Routers and Richard Sevens` TCP/IP Illustrated, Volume I - The Protocols.) 305 pages in 14 chapters, appendices, a bibliography, a list of "bombs" (security holes) and an index. Out of the box, the authors set the tone for their work by quoting F.T. Gramp and R.H. Morris: "It is easy to run a secure computer system. You merely have to disconnect all dial-up connections and permit only direct-wired terminals, put the machine and the terminals in a shielded room, and post a guard at the door." This is followed by a detailed discussion of the art and science of building a firewall. There is so much good stuff here, that all I can do is list the book`s contents - lest I write a tome which distracts you from picking up a copy of it ASAP. Chapters and content - from the table of contents. Getting started Introduction - Why security? - Picking a security policy - Strategies for a secure network - The ethics of computer security - Warning Overview of TCP/IP - The different layers - Routers and routing protocols - The Domain name service - Standard services - RPC-based protocols - The "r" commands - Information services - The X-11 service - Patterns of trust Building your own firewall Firewalls and gateways - Firewall philosophy - Situating firewalls - Packet-filtering gateways - Application-level gateways - Circuit-level gateways - Supporting inbound services - Tunnels - good and bad - Joint Ventures - What firewalls can`t do How to build an application-level gateway - Policy - Hardware configuration options - Initial installation - Gateway tools - Installing services - Protecting the protectors - Gateway administration - Safety analysis - why our setup is secure and fail-safe - Performance - The TIS firewall toolkit - Evaluating firewalls - Living without a firewall Authentication - User authentication - Host-to-host authentication Gateway tools - Proxylib - Syslog - Watching the network: Tcpdump and friends - Adding logging to standard demons Traps, lures and honey pots - What to log - Dummy accounts - Tracing the connection The hacker`s workbench - Introduction - Discovery - Probing hosts - Connection tools - Routing games - network monitors - Metastasis - Tiger teams - Further reading A look back Classes of attacks - Stealing passwords - Social engineering - Bugs and backdoors - Authorization failures - Protocol failures - Information leakage - Denial-of-service An evening with Berferd - Introduction - Unfriendly acts - An evening with Berferd - The day after - The jail - Tracing Berferd - Berferd comes home Where the wild things are: a look at the logs - A year of hacking Proxy use - Attack sources - Noise on the line Odds and ends Legal considerations - Computer crime statutes - Log files as evidence - Is monitoring legal? - Tort liability considerations Secure communications over insecure networks - An introduction to cryptography - The Kerberos authentication system - Link-level encryption - Network- and transport-level encryption - Application-level encryption Where do we go from here? Appendices Useful free stuff - Building firewalls - Network management and monitoring tools - Auditing packages - Cryptographic software - Information sources TCP and UDP ports - Fixed ports - MBone usage Recommendations to vendors - Everyone - Hosts - Routers - Protocols - Firewalls Bibliography - List of bombs - Index I have criticisms, complaints and suggestions. However, considering that this is such a darn fine piece of work - I hasten to get my recommendation that you buy this book out ASAP. Meantime, to whet your appetite: - Index - (a well done, 26 pages worth - you can actually find pointers to what you want to know! What a concept. - TCP ports discussion - a Comprehensive list and reasonable advice on what to do with them. - Bombs - a summarized list of the 43 major security holes that they identify. - Bibliography - Ahhhh. 19 pages of the best firewalls-related bibliography that I`ve seen. - Where to from here - excellent advice for techies and managers who don`t want to keep working at the job of firewalling or who simply want to spend a bit of resources on it only once. Kudos to the authors - buy this book. Of course - these are my own views, and they don`t necessarily reflect those of anyone - including my employer. However, in this case, they probably do. Ray Kaplan CyberSAFE, Corporation rayk@ocsg.com Formerly Open Computing Security Group (OCSG) (206) 883-8721 FAX at (206) 883-6951 2443 152nd Ave NE Redmond, WA 98052 Better living through authentication ------------------------------ Date: Fri, 29 Apr 94 15:12:34 PDT From: simutis@ingres.com (John Simutis) Subject: Re: Drunk in charge (RISKS-15.80) While I was a contract programmer at GM/EDS, there was an explicitly stated policy: it was permissible to drink alcohol, as having a beer with lunch, but ONLY if one did not plan to return to work that day. It was stated further that we were obligated to give the customer our best work, and alcohol was not consistent with that effort. John Simutis, simutis@ingres.com Alameda, California, USA ------------------------------ Date: Fri, 29 Apr 94 09:10:21 BST From: Andy Ashworth Subject: Re: drunk in charge...... (RISKS-15.80) I understand that British Rail have a policy that no personnel who can affect the safety of others is allowed to have alcohol in their bloodstream during working hours - the penalty for violating this rule is, I think, dismissal. This grouping includes engineering staff involved in the R&D of systems such as signaling. This is more than just "drunk in charge of a computer", this is, sensibly IMHO, "being under the influence of alcohol while capable of influencing the safety of others". I hope that the next time I fly in a fly-by-wire aircraft or drive my systems heavy car I can have confidence that the developers of the systems that could affect my safety applied a similar abstemious regime. Andy Ashworth, Lloyd's Register, 29, Wellesley Road, Croydon CR0 2AJ +44 (0)81 681 4723 Fax: +44 (0)81 681 4839 tcsaca@uk.co.lreg.aie ------------------------------ Date: Sun, 1 May 1994 11:31:00 -0400 From: djast@utopia.druid.com (Dan Astoorian) Subject: drunk in charge... (RISKS-15.80) Driving requires quick response time; electric work requires manual dexterity. Alcohol impairs both these things, and as noted, the dangers are obvious, immediate, and tragic. Software engineering requires very little in the way of fast responses or manual dexterity, unless one considers an inordinate number of typos a serious RISK. Moreover, the skills which *are* required to write software tend to be more of the problem-solving variety. I don't dispute that alcohol dulls these; however, when you take away one's problem solving skills, the result is that the problem doesn't get solved. I seem to vaguely recall an old study in which a group of people, some of which had been given a couple of drinks, were called upon to solve arithmetic problems of moderate difficulty, with no time limit. I believe the outcome was that those who had had the drinks took much longer to finish the problems, but their responses were *more* accurate than the teetotalers, presumably due to their awareness that they were prone to make errors. (I would therefore advise project managers to take Friday pub lunches into account when setting deadlines.) Incidentally, I'm not sure how one would distinguish between mistakes due to being under-the-influence and those due to being under stress (perhaps due to looming deadlines), or simple inexperience or incompetence, or even honest-to-God oversights. if the QA system for critical systems doesn't catch all such types of mistake, there's already a serious problem. Obviously this is not intended as an argument against reducing the number of errors to be found by QA, but still... a bug is a bug. (I'm reminded of a phrase a colleague used to repeat: "Sure, alcohol kills brain cells. But only the weak ones.") Dan Astoorian, Mississauga, Ontario, Canada djast@utopia.druid.com ------------------------------ Date: Fri, 29 Apr 1994 20:00:45 -0400 From: Butch Deal NRL Subject: Boot Prom commits Denial of Service Attack What is the risk here? People like to put blame one other systems all the time. I see this as only a matter of misconfiguration and miscommunication among the different system admins. What do the DEC stations need to run tftp for? Shouldn't they be logging in to a non-critical partition? Shouldn't the Suns have a similar tcpwrapper installed? Maybe they should all log to some central machine, with syslog maybe. The could be several machines that can serve a diskless station. The broadcast allows them to find the right one on the local network and come on up. I do not think it is at all fair to try to blame a hardware manufacturer because the equipment worked exactly as documented, but that happens not to be the way you want it to work. butch@keep.blackmagic.com Butch Deal ------------------------------ Date: Mon May 02 10:23:44 1994 From: worldwid@uunet.uu.net (David Johnson) Subject: Staying Informed of Security & Privacy Issues STAYING INFORMED: Resources for Privacy Seekers & Computer Security Buffs by David Johnson (Copyright 1994 under the International & Pan-American Copyright Conventions) Having conducted various types of security and investigative work that has taken me to ten Asian countries, I am quite familiar with various obstacles one must hurdle to obtain hard-to-find and elusive data. Even though our computers are valuable tools, adopting a multi-faceted approach to information gathering is the most effective way to cover all the angles. Use this listing to build your own private intelligence network. COMPUTER SECURITY PUBLICATIONS PRIVACY-RELATED PUBLICATIONS Auerbach Data Security Management Full Disclosure Magazine Information Systems Security Box 244 Lowell, MI 49331 USA 210 South St. Voice: (800) 633-3274 Boston, MA 02111 USA Voice: (616) 897-7222 Voice: (800) 950-1218 Fax: (515) 897-0705 Voice: (212) 971-5000 Fax: (617) 423-2026 International Privacy Bulletin 666 Pennsylvania Ave., S.E. Computer Security, Auditing & Controls Washington, DC 20003 USA 57 Greylock Rd. Box 81151 Wellesley Hills, MA 02181 USA Privacy and Security 2001 Voice: (617) 235-2895 504 Shaw Rd., #222 Sterling, VA 20166 USA Voice: (800) US-DEBUG Computer Audit Update Voice: (703) 318-8600 Computer Fraud & Security Update Fax: (703) 318-8223 Computer Law & Security Report Computers & Security Crown House, Linton Rd., Barking Privacy Journal Essex I611 8JU, England Box 28577 Voice: (44) 81-5945942 Providence, RI 02908 USA Fax: (44) 81-5945942 Voice: (401) 274-7861 Telex: 896950 APPSCI G (North American distributor) Box 882 Privacy Laws and Business New York, NY 10159 USA Box 23 Voice: (212) 989-5800 7400 GA, Deventer, Netherlands Voice: (31) 57-0033155 Fax: (31) 57-0022244 Telex: 49295 KLUDV NL Computer Control Quarterly 1 Southbank Blvd., Level 8 (North American Distributor) S. Melbourne, Vic. 3205, Australia 6 Bigelow St. Voice: (03) 6121666 Cambridge, MA 02139 USA Fax: (03) 6295609 Voice: (617) 354-0140 Computer Security Alert Computer Security Journal Privacy Times Box 21501 600 Harrison St. Washington, DC 20009 USA San Francisco, CA 94107 USA Voice: (202) 829-3660 Voice: (415) 905-2370 Fax: (202) 829-3653 Fax: (415) 905-2234 COMPUTER SECURITY ORGANIZATIONS Computer Security Digest 150 N. Main St. Center for Computer Law Plymouth, MI 48170 USA 1112 Ocean Dr. Voice: (313) 459-8787 Manhattan Beach, CA 90266 USA Fax: (313) 459-2720 Voice: (213) 372-0198 Computing & Communications Computer Security Institute (Law & Protection Report) 360 Church St. Box 5323 Northborough, MA 01532 USA Madison, WI 53705 USA Voice: (617) 393-2600 Voice: (608) 271-6768 Info Systems Security Assn. Data Security Manual Box 71926 Box 322 Los Angeles, CA 90071 USA 3300 AA Dordrecht, Netherlands Voice: (31) 78-524400 Voice: (31) 78-334911 Fax: (31) 78-334254 Nat'l Center for Computer Telex: 29245 KAPG Crime Data 4053 JFK Library - CSULA (North American Distributor) 5151 State University Drive Box 358 Los Angeles, CA 90032 USA Hingham, MA 02018 USA Voice: (213) 225-1364 Voice: (617) 871-6600 PRIVACY-RELATED RESOURCES Information Systems Security Monitor U.S. Department of Treasury F.E.C., Inc. Bureau of the Public Debt P.O. Box 959 AIS Security Branch Centro Colon 1007-91/12-0695 200 3rd St. San Jose, Costa Rica Parkersburg, WV 26101 USA (financial & personal privacy) Voice: (304) 480-6355 BBS: (304) 480-6083 Eden Press Box 8410 InfoSecurity News Fountain Valley, CA 92728 USA 498 Concord St. Voice: (714) 556-2023 Framingham, MA 01701 USA Fax: (714) 556-0721 Fax: (508) 872-1153 (various books on privacy) Journal of Computer Security Consumertronics Van Diemenstraat 94 Drawer 537, Alamagordo, NM 88310 USA 1013 CN Amsterdam, Netherlands Voice: (505)434-1778 Voice: (31) 20-6382189 Fax: (505) 434-0234 Fax: (31) 20-6203419 (technical invasion manuals) (North American distributor) Box 10558 Burke, VA 22009 USA Privacy Hotline (800) 773-7748 Voice: (703) 323-5554 (California only) 10am-3pm, M-F ******************************************************************************* David Johnson 2421 W. Pratt Boulevard, Suite 971 President, Worldwide Consultants Chicago, Illinois 60645 Editor, Information Gatherer Newsletter U.S.A. International Investigator Tel: (800) 316-0801 (24 hrs.) Security Consultant Fax (c/o World-Con): (908) 542-1266 Privacy Strategist E-mail: worldwid@uunet.uu.net ------------------------------ Date: 3 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. risks-15.75 gives WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.02 ************************ 5-May-94 23:10:07-GMT,29654;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27966; Thu, 5 May 94 19:10:06 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA16097; Thu, 5 May 94 19:08:49 EDT Received: by chiron.csl.sri.com id AA03804 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Thu, 5 May 94 16:01:57 -0700 From: RISKS Forum Sender: RISKS Forum Date: Thu, 5 May 94 16:01:55 PDT Subject: RISKS DIGEST 16.03 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Thursday 5 May 1994 Volume 16 : Issue 03 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Spelling correction (Phil Agre) Sigh -- security through obscurity is NOT security (Alan Wexelblat) Bellcore cracks 129-digit RSA encryption code (Steven Tepper) Risk of Non-Computerization? (Klaus Brunnstein) Computers Blamed For FAA Woes (Mark Thorson) Brief note re DIA fiasco (Paul Green) Followup on credit card policies (re: "Streetwise Guide ...") (Rob Slade) ABC Nightline re LaMacchia (Mich Kabay) Risks of electronic door locks for automobiles (Paul Wallich) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 3 May 1994 15:10:22 -0700 From: Phil Agre Subject: spelling correction We've had plenty of notes about spelling correctors, but I find this one particularly interesting. The otherwise excellent April 1994 issue of Z Magazine contained a particularly horrible editing error in an article by Sara Diamond about the "American Center for Law and Justice" (ACLJ). The ACLJ was created by conservative Christians in order to oppose the American Civil Liberties Union (ACLU) in court cases over issues like school prayer. Everyone has assumed that the similarity of acronyms is deliberate; ACLJ seems part of a fairly systematic conservative strategy of positioning public-interest groups as "liberal" by creating conservative mirror images of them. Well, as the Z editors explained in their May issue, their spelling correction program included ACLU but not ACLJ, with the result that every instance of "ACLJ" in Diamond's article got changed to "ACLU" except, somehow, for the very first one, which occurred (much as it does above) in parentheses after the first mention of "American Center for Law and Justice". Apparently there was an uproar, with some Z readers calling up the ACLU to ask why it had suddenly reversed its positions. The risk is subtle: in politics, things are often designed to outwardly resemble their opposites, or to invite confusion or sharply defined contrast (or both) with their opposites. As a result, it becomes impossible to define "close enough" in (for example) a spelling corrector without a great deal of specific background knowledge. Phil Agre, UCSD ------------------------------ Date: Tue, 3 May 94 17:26:46 -0400 From: "Alan (Miburi-san) Wexelblat" Subject: Sigh -- security through obscurity is NOT security Peter Ladkin introduces his post with the polite phrase: > a vandal exploiting a not-unknown security hole or, in American English: Some lazy person at the target site failed to plug a known hole, probably reasoning along the lines of "Oh, no one will know about this hole so I don't have to deal with it." There is no excuse for vandalism, including failure by sysops to plug known holes. However, if I was a user at that site I'd be more pissed at the person who failed to prevent the vandalism when such prevention was possible. --Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard, Media Lab - Advanced Human Interface Group wex@media.mit.edu 617-258-9168 ------------------------------ Date: Tue, 3 May 94 18:46:36 PDT From: greep@datatools.com (Steven Tepper) Subject: Bellcore cracks 129-digit RSA encryption code [Old news to some of us. Oddly no one reported it to RISKS until now, and I did not get around to entering anything on it. PGN] Excerpts from an article on page 14 of the May 2 issue of Network World: A team led led by Bell Communications Research last week announced it has cracked a 129-digit encryption code, which scientists had predicted would take "40 quadrillion years" to break. ... Breaking the RSA-129 public key required that the team find the two prime numbers that, when multiplied by each other, resulted in the 129-digit key number. ... This mathematically arduous task was accomplished in eight months by 600 volunteers in 24 countries who used their organizations' spare computing capacity. ... ------------------------------ Date: Wed, 4 May 1994 11:16:34 +0200 From: Klaus Brunnstein Subject: Risk of Non-Computerization? In a TV report (magazine FRONTAL, 2nd German TV channel ZDF, Tuesday May 3, 1994), recent motorsport accidents (3rd World Championship, formula 1 racing cars, Imola/San Marino) were discussed and analysed by experts (e.g. former World champion Niki Lauda/Austria). Besides general questions about deficiencies in safety and protective measures, the question was discussed whether the recent decision to forbid the computerized ground distance control may have contributed to the strange behaviour of both racing cars which after a curve went straight into a concrete wall, without visible signs of steering. In both cases (Austrian driver Hackenberger, in training for his 2nd race, and Brasilian driver Ayrton Senna, 3-times world champion), the cars crashed at almost 300 kilometers per hour, with both drivers dying upon impact. Until end-of-1993, formula 1 racing cars were equipped with a computerized control system aimed at maintaining a fixed but very small distance between the car's bottom and the track's surface, to allow for maximum contact and therefore maximum transfer of power on the wheels. Following arguments that a defect in the computer system may lead to serious crashes, the international authority for this sport forbidded this computer system from 1994. This decision may now have caused the problem on the very high speed track of Imola, where the cars reach maximum velocities over 300 km/h. According to the discussion quoted, the hydraulic steering support may be affected when the car's bottom contacts, at high speed, an uneven part of the track; in such a situation, the driver would no longer be able to steer the car and may even loose the ability to brake. Evidently, the decision to forbid the computer system was neither accompanied by an adequate risk analysis not were any additional measures taken to diminish the risks e.g. by reducing the car's speed or by enlarging the minimum distance between car's bottom and track ground. Only now, discussions take place to reduce the speed in certain parts of the track. Klaus Brunnstein (May 4, 1994) ------------------------------ Date: Wed, 4 May 94 01:06:17 PDT From: mmm@cup.portal.com Subject: Computers Blamed For FAA Woes This morning (3 May 1994), Transportation Secretary Federico Pena appeared on at least one morning TV show in addition the _MacNeil-Lehrer_ show to inform the public about the shocking state of the nation's air-traffic control technology. On both appearances that I saw, Pena said that the FAA needed to be a private corporation so it could acquire technology more quickly, outside of federal regulations. He used as an example the humble vacuum tube. He said that the FAA is the world's largest buyer of vacuum tubes. That I can believe. But then by way of comparison, he held up a vacuum tube and a computer chip. The tube was a big one, about the size of a #30, which is much bigger than the tubes used on any tube computer like ENIAC, whose tubes were about the size of a 5U4. He compared it against a computer chip (something packaged like an Intel 486), and claimed the latter could replace 3.5 million vacuum tubes! Apparently, Secretary Pena either: a) believes the FAA is running enormous, obsolete vacuum tube computers containing millions of tubes, or b) doesn't mind telling bald-faced lies to the American public to get support for his objectives. I'm not sure which is worse. Mark Thorson (mmm@cup.portal.com) ------------------------------ Date: Wed, 4 May 1994 21:14:59 GMT From: Paul_Green@vos.stratus.com (Paul Green) Subject: Brief note re DIA fiasco As someone who has been involved in fixing a number of terrible situations involving computers, and as someone who has not been involved in the DIA fiasco, other than as a fascinated observer, I'm sure that when the book is written on this, we'll find that there is ample blame for all of the parties involved in the project. Small groups of people make small messes. To get a really large mess, you need a large group of people working for many organizations. Anyone, or any reporter, claiming to know the source of the problems as this stage, is either quite naive or has an axe to grind. I think Bear Giles misses the point (in RISKS 16.01) about simple software errors leading to massive, unintended consequences. The issue is not (just) syntax checkers. Sure, we've got 'em...So what? The issue is that in a mechanical or analog system a small error in the input or operation generally leads to a small **and traceable** error in the output. But in a digital system, especially a software-based digital system that can experience memory or data corruption, a small error in the input or operation can have huge **and virtually untraceable** errors in the output. I seem to recall that it was indeed a small error that brought down the AT&T long-distance switching system. I have to agree with the writer on this one. Finally, judging by the number of bar-coded labels that I have to rip off my luggage, many airports must use bar-code readers. I have to believe that this piece of airport technology is reasonably mature. Finally, common sense says it has got to be more reliable to bar-code the luggage than the carts. Paul Green, Sr. Technical Consultant, Stratus Computer, Inc., Marlboro, MA 01752 Paul_Green@vos.stratus.com, PaulGreen@aol.com (508) 460-2557 ------------------------------ Date: Thu, 05 May 1994 15:21:10 -0600 (MDT) From: "Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067" Subject: Followup on credit card policies (re: "Streetwise Guide ...") PGN asked me to summarise the responses to my comments in the review of "The Streetwise Guide to PCs" by Jerome/Taylor. I had suspected that it might be a bit controversial, but I was surprised that the only substantive comments I received were in regard to the difference between Canadian and American law regarding credit card purchases. The most apposite information was from Bear Giles who wrote: ======== I don't remember the exact language, but in the U.S. consumers have the right to refuse charges made more than 50(?) miles from their home address. The refusal must be in writing, within 30 days, possibly with an explanation, etc. The bank must complete its actions within 60 days of receipt of this letter, cannot charge interest or late fees on the disputed amount, etc. (I would imagine the exact details are in the FAQ of various consumer advocacy groups.) The presumption is that the purchase was made over the phone or while on a trip, either situation making it difficult to impossible for the consumer to evaluate the quality of the merchandise prior to purchase. There is no corresponding law applying to purchases "near home"; this distinction is often lost on people. And of course the existence of an American law has no significance to a Canadian making a domestic purchase. BTW, another restriction (either U.S. law or merchant agreement) which is often overlooked is a requirement that charges not be placed against your account until the merchanise is actually shipped. I believe companies can still "reserve" credit, but the only effect the customer sees from this is a reduced available credit -- she does not have to make payments against it. ========== Much the same was said by Andrew Klossner who added: ========== Holders of U.S. credit cards can find these procedures detailed on the back of each monthly account statement. ========== So check the back of your statements for further details. (As I said, I suspected there would be some controversy: I expected it, however, to be in regard to my statements about the Better Business Bureau. I guess that most people have such low expectations on that score that they simply couldn't be bothered to comment :-) Vancouver Institute for Research into Security Vancouver Canada V7K 2G6 ROBERTS@decus.ca Robert_Slade@sfu.ca rslade@cue.bc.ca p1@CyberStore.ca ------------------------------ Date: 04 May 94 06:20:39 EDT From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: ABC Nightline re LaMacchia On 02 May 1994, ABC News _Nightline_ aired a program entitled, "Law and Order on the Information Superhighway_, which focused on the case of David LaMacchia, an MIT student accused of wire fraud for allegedly having run a BBS which permitted traffic in stolen software. The host was Chris Wallace, substituting for Ted Koppel. I ordered a transcript of the program from Journal Graphics, Inc. / 1535 Grant Street / Denver, CO 80203 / phone 303-831-9000 / fax 303-831-8901. The transcript is copyright (c) 1994 American Broadcasting Companies, Inc. and therefore I can provide only an abstract. [I received the entire abstract from Mich, who also provided me with an annotated version, which is included here. My apologies if I omitted anything necessary for understanding. However, because Mich included chunks of the abstract before each of his annotations, I could not run both the full abstract and the annotated version. PGN] U.S. Attorney Donald Stern accuses David LaMacchia of having tolerated the exchange of stolen software worth more than $1 million. Prof. Laurence Tribe of Harvard University Law School questions the implications of such an accusation; he argues that LaMacchia's BBS should be accorded the legal status of a common carrier, thus exculpating the owner of crimes committed through his communications channel. Analysis of the Nightline program about David LaMacchia and the software exchange BBS: [set flame = on] <> Silverglate's legalistic attitude is understandable (he _is_ a lawyer, after all) but fails to address the question of values. Many BBS operators exercise control over content of communications or files on their systems--not out of fear of legal prosecution, but because they don't want to be tacit or active supporters of bad things. As Sysop in the NCSA's security forum on CompuServe, I have removed abusive messages and written to their authors with reminders of the standards of decorum my fellow Sysops and I expect on the forum. Free speech doesn't enter into it: CompuServe is a privately owned network and Sysops have a responsibility to maintain an environment in which participants address the issues without descending to abusive, ad hominem attacks. We do these things because they fit our _values_. We do not assume that if something is not illegal it must be right. .... <> These predictions are wrong. Many people, including the Sysops on CompuServe and many moderators in Internet news groups, regularly impose restrictions on content on moral grounds and out of respect for possible legal entanglements. For example, although I regularly post extracts of the RISKS FORUM DIGEST on the NCSA Forum, I don't post what appear to be entire copyrighted articles. .... <> Corley exemplifies an attitude prevalent among criminal hackers: dehumanization of cyberspace. It seems to them that there are no people on the other end of the communications channel, only things. Stealing software in this context seems victimless; in reality, companies are losing money, and people are suffering monetary losses. Some small companies can go out of business entirely if they cannot get sufficient revenue to cover the months of grinding, often poorly-paid work by their employees. Human beings have smaller salaries or even lose their jobs because of software theft. Cyberspace is as much a part of the real world as speech, books, and telephones. No one would argue that stealing a book is a victimless crime--or would they? Some unscrupulous bookstores rip the covers off books, return the covers to the publisher for a credit, and then sell the mutilated books--with not a penny going to the _people_ who wrote, edited, printed, bound, and marketed the book. .... <> Criminal hackers and software thieves miss the key point about intellectual property or confidential information. It isn't the copying that causes harm, it's the owner's loss of control over a valuable resource. Software companies sell a license to use a product, not the product itself. Software thieves steal the ability to enter into a contract with a user; it is the lost revenue that is in question, not the extra copy itself. .... <> Corley implies that it is illegitimate to apply whatever price the creator wishes to a product or service. But a producer normally charges what the market will bear: a price which maximizes profit. Too high for perceived value and the market chooses alternatives--or they develop by less greedy competitors. Too low, and the producer risks going out of business. The other peculiar (wrong) suggestion in this passage is the idea that the ease with which an act is performed somehow mitigates responsibility. So a single-keystroke copy is more of an excuse for stealing software than a 20-character command? If a vandal demolishes a building by attacking it with an ice pick over a 5 year period, are we expected to perceive his act as worse than if he had blown it up by pressing a button to explode a nuclear bomb? Once again, Corley confuses technology with morality. .... <> Ah, the familiar fallacy of moral possibility. This error consists of believing that if something is easy it must be right. The corollary is that the victim is to blame for being victimized. Thus if a bank robber uses a howitzer to blow a hole in the wall of a bank, it serves the bank properly for having failed to encase its building in three-foot thick titanium beryllium alloy. So software manufacturers should impose the endless nuisances of copy protection on their products--even though these methods increase costs, enrage consumers, and don't work anyway because little creeps find ways of countering every single programmatic technique invented to date. Just because it's _possible_ to steal doesn't make it right. <> Here we have Corley taking up the unpaid position of marketing director for musicians as well as software companies. Decisions on how to market a product or service are rightfully the responsibility of the owners of that product or service. Criminal hackers have no moral justification for interfering with those decisions. <> So Corley recognizes that honest people either agree to abide by the software license agreement _or they don't use the product_. So what are we supposed to do about the creeps who jack _our_ price up by stealing the same products? Corley's attitude reminds me of the idiots who race by traffic jams by using the emergency lanes; these people are contemptuous of the rest of us, sitting in orderly lines, waiting to take our turn past the obstruction causing the holdup. But no, the scoff-laws, like Corley, feel that they don't have to abide by such rules. <> Ah, a new right. Many criminal hackers espouse the view that they have a _right_ to use any software they please without paying for it. The reasoning, such as it is, seems to be "I wannit--so it's mine." No one on this planet has a _right_ to use the database I have designed to track my projects. I wrote it, I debugged it, I refined it. It's mine and mine alone. If I _choose_ to let Albert use it and not Bob, that's my choice. If I _choose_ to sell it only if the buyer agrees not to shoot sparrows, this eccentric term in the license agreement can be accepted or rejected by a prospective buyer, but they have _no right_ to use the product without that contractual agreement. Can't afford MS-Word? Use another word processor. Don't like the terms of a license that doesn't let you make a copy for your portable computer? Buy another product or do without. But wanting to use somebody else's tool is not moral justification for stealing it. [set flame = off] Michel E. Kabay, Ph.D. / Dir Education / National Computer Security Assn ------------------------------ Date: Wed, 4 May 1994 21:56:20 -0400 (EDT) From: Paul Wallich Subject: Risks of electronic door locks for automobiles The underlying risk of electronic car door locks is that the state of the lock depends on what a microprocessor believes rather than whether someone has turned a key or pushed a latch button. In addition to the obvious failure modes (do you need a working battery to unlock the car?) the manufacturer can also program in more complex lock behavior. Drivers and passengers may find out the full range of lock states only when bitten by a previously unknown "feature". For example, last week I drove a two-door Chevy Cavalier that unlocks both doors when the ignition is turned off. Makes it harder to lock keys in the car, but could also pose a risk of theft if you don't notice. Compared to the Buick Century I was driving for a few days prior to that (and you'll understand why shortly), the Cavalier's behavior is positively benign. During a sudden spring blizzard at 2,500 meters in Northwest New Mexico, I discovered the Buick's quirk. I went onto the shoulder to avoid a pickup and trailer that had decided to stop in the middle of the road during a brief zero-visibility whiteout, and found myself stuck in a newly-minted snowbank. So I turned on the hazard flashers and went to see how hard it would be to dig out. Since I had left the engine running, the doors locked automatically behind me (I later verified that this is a "well-known" behavior to the rental agents in Albuquerque). The risks of standing outside a locked car in driving snow on a lightly-traveled mountain road (wearing clothing more suitable for low-altitude desert) should be obvious. Without the timely passage of two other tourists (bound from a monastery near Abiquiu to a commune at Taos) this posting might not have been possible. I was somewhat taken aback to note that it took the tow-truck operator less than a minute to unlock the car, equipped only with a small pry bar and a bent steel rod. So the electronic locking mechanism does not seem to add security. During the mechanical era, auto manufacturers figured out various way to make it difficult or impossible to lock your keys in a car; it's not a good sign that they seem to be relearning those lessons from scratch. ------------------------------ Date: 3 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. See risks-15.75 for WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.03 ************************ 10-May-94 16:10:06-GMT,27356;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28767; Tue, 10 May 94 12:09:59 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27600; Tue, 10 May 94 12:09:43 EDT Received: by chiron.csl.sri.com id AA08827 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Tue, 10 May 94 09:01:25 -0700 From: RISKS Forum Sender: RISKS Forum Date: Tue, 10 May 94 9:01:23 PDT Subject: RISKS DIGEST 16.04 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Tuesday 10 May 1994 Volume 16 : Issue 04 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Secret elevator codes baffle Metro Toronto government (Dave Leibold) Smoke or Malaria - Lesser of the two evils (Hiranmay Ghosh) Dartmouth prof spoofed (Mich Kabay) 11-digit ZIP code (Christine Harbs) Frozen computer scientist (David Honig) Re: Bellcore cracks 129-digit RSA ... (Paul C Leyland, Dik Winter, Paul Buder) Re: Streetwise Guide [Risks of following up on credit-card laws] (Robert Slade) Future of US health care? (Mark Stalzer) White House May Issue National ID Cards (Mitch Ratcliffe via W.C. Daugherity) Canadian long-distance service reseller blunders (Mich Kabay) Cheers to two companies (Michael J. Zehr) Re: MIT student arrested (David desJardins) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: 06 May 94 00:06:10 -0500 From: Dave.Leibold@f730.n250.z1.fidonet.org (Dave Leibold) Subject: Secret elevator codes baffle Metro Toronto government An article in _The_Toronto_Star_ on 5 May 1994 described secret codes which are necessary to maintain elevators at Metro Hall, the building which houses Metro Toronto municipal council and services. The elevators, made and maintained by Schindler Elevator Corp., require secret password codes in order to maintain them. This means that only Schindler staff can maintain the Metro Hall lifts, and as such forced Metro Council to award a 10 year contract of $3.5 million to Schindler. Meanwhile, Metro is also suing the building's developer, Marathon Realty, to try to get the codes. Without the passwords, elevator maintenance contracts cannot be given to a competing firm. Metro Councillor Howard Moscoe wanted the Council to issue a $10 000 reward to the first person to successfully crack Schindler's Code. This motion probably didn't get approval. David Leibold Fidonet 1:250/730 dave.leibold@f730.n250.z1.fidonet.org ------------------------------ Date: Mon, 9 May 94 09:07:35 IST From: Hiranmay Ghosh Subject: Smoke or Malaria - Lesser of the two evils RISKS usually features risks in high technology area, especially with computers. I am tempted to site one example for risks in a relatively low technology area encountered in a developing country like ours! In the '50s or early '60s, there had been a massive drive to eradicate malaria (a disease cheracterized by high fever and spread through mosquito bites) from India. The attack was primarily on the mosquitos; their lot were killed by pesticides and their hideouts destroyed. The operation was considered to be successful and a case of malaria was rare for about twenty years to come! Unfortunately, in late '80s, mosquitos came back with renewed a vigour and brought malaria back. How did the mosquitos come back? Some 'experts' assign the following reason: In '60s or '70s, most of the Indian household used hearths (coal-fire) to prepare the food. At that time, a popular sight at the dusk at an Indian town was the smoke coming out of every dwelling unit to mark the ignition of the hearth for preparation of the evening meals. In a city, where the population density had been high, the volume of smoke was significant and caused concern about pollution! But, that was the time, when the mosquitos invading the households (dusk is the peak activity hour for the mosquitos!) were repelled by the smoke. In the '80s, the hearths were replaced by 'modern' 'non-polluting' gas stoves. The coal-lit hearth was even banned in many cities in an attempt to curb pollution. So, now there is nothing to prevent the mosquitos to come and join us for dinner and spread malaria in the process! I am not sure, if the reason cited is a valid one, but the concern about the re-advent of malaria in India is beyond any doubt! [Next time, lease a collection of mutant boll weevils to eat the mosquitos and you will be confronted with a lessor of weevils. PGN] ------------------------------ Date: 09 May 94 06:31:56 EDT From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Dartmouth prof spoofed Here is some old news that was new to me: According to the _Dartmouth Life_ newsletter (Feb 1994--I'm just clearing up my in basket today), an article appeared in _The New York Times_ on 94.01.05 entitled "Confronting changing ethics of the computer age." The unsigned article begins, "Hanover, N.H. -- Somebody in Prof. David Becker's course on Latin American politics did not want to take the midterm exam, so he or she used Dartmouth's innovative electronic mail network to impersonate a department secretary and cancel the test. "At 11 o'clock on the night before the test in the Government 49 class, a message flashed on students' computer screens. Because of a family emergency, the message said, Professor Becker would be unable to administer the midterm." The article explains that half the class understandably failed to show up for the test. No one has been identified yet as the culprit. The rest of the article talks about the extensive electronic mail system on campus. One of the key concerns of the unregulated network is the rapid spread of rumours: "Late in August computer flashed an account of a woman being raped while jogging near campus. The message was intended as a warning, but there had been no rape." The Hanover police department were swamped with calls. The Chief of Police now has his own electronic mail account to try to squelch rumours. M. E. Kabay, Ph.D. (Dartmouth '76) / Dir Educn / Natl Computer Security Assn. ------------------------------ Date: Mon, 9 May 1994 14:28:30 -0700 (PDT) From: Christine Harbs Subject: 11-digit ZIP code According to the _Friday Report_ , Gene Del Polito, Exec. Dir. of the Advertising Mail Marketing Assn. is urging the Postal Service to adopt an 11 digit ZIP code. The 11 digits would consist of the original five + four, and the last two will be the last two numbers of YOUR house address. <> Translation? Better targeted junk mail. This means that, with only a ZIP code, marketers and harassers will darn near be able to pick out my house. Marketers do a lot of demographic research based on ZIP code. This could lead to _extremely_ targeted marketing. Although not everyone would consider this a risk... Another concern arises for people who are being stalked or harassed. Again, with just the ZIP code, the stalker could pin- point, at the very least, the victim's street. Systems which claim to protect privacy and confidentiality because it _just_ uses a ZIP code for identifiers, may have to be redesigned. <<'The reality we're stuck with is that many people in this country simply don't know what their accurate and complete address is,' said Del Polito.>> I am sure a lot of people make mistakes when addressing an envelope. I do not think the way to solve this problem is to create a system where 11 digits create a path to my doorway. ------------------------------ Date: Fri, 06 May 1994 10:01:10 -0700 From: David Honig Subject: Frozen computer scientist (RISKS-16.03) In the last RISKS someone writes about the dangers of automatically-locking doors when standing in a blizzard at 2500 feet wearing light clothing. The author posits a somewhat amusing possible outcome, had he not been saved by travelling communists: a computer scientist frozen to death next to his over-clever, running but locked, vehicle. Of course, more hardware-oriented types might have clued in to the brittleness of said vehicles' windows before hypothermia set in... :-) ------------------------------ Date: Mon, 9 May 1994 18:04:54 +0100 From: pcl@foo.oucs.ox.ac.uk (Paul C Leyland) Subject: Re: Bellcore cracks 129-digit RSA encryption code (RISKS-16.03) > predicted would take "40 quadrillion years" to break. ... > This mathematically arduous task was accomplished in eight months by > 600 volunteers in 24 countries who used their organizations' spare > computing capacity. ... There are two risks, one amusing. Ron Rivest now regrets ever making that 40 quadrillion years estimate. It was silly when he made it; his papers in the scientific literature from that era give estimates which are within an order of magnitude of how much computation we actually used. From those estimates, and the observation that way back then it wasn't feasible to hook together hundreds of computers, we can deduce that a late 70's supercomputer using the best algorithms available then would have taken a few decades, maybe a century. Certainly much less than the 40 quadrillion years. The risk is: making predictions about the runtime of computer programs can sometimes make you look silly 8-) The other risk is more serious. RSA is widely used to protect commercially significant information. 512-bit keys are widely used for this. Most, if not all, smart-card implementations are restricted to 512-bit keys. RSA-129 has 425 bits. I estimate (taking a risk 8-) that 512-bit keys are only about 20 times harder to break than 425-bit keys. Readers are left to draw their own conclusions. However, it is not by chance that I have a 1024-bit PGP key. Oh yes, as Arjen Lenstra had pointed out: if you had used RSA-129 as the modulus in a digital signature for a 15-year mortgage, you would have been cutting it pretty fine. It is the use of RSA for long-lived signatures which needs to be examined with a very critical eye. Paul Leyland (one of four RSA-129 project coordinators) ------------------------------ Date: Fri, 6 May 1994 02:45:26 +0200 From: Dik.Winter@cwi.nl Subject: Re: Bellcore cracks 129-digit RSA encryption code Perhaps because there is no risk beyond the known ones? Bob Silverman of MITRE (well known in number factoring circles) has publicly predicted already some time ago that it would require about 5000 MIPS years to factor the number. Reasonably close to the actual figure. That the team was led by Bell Communications Research is untrue. It is a team led by four people from Bellcore (Arjen Lenstra), MIT (Derek Atkins), Iowa State University (Michael Graff) and Oxford University (Paul Leyland). dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098 home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: dik@cwi.nl ------------------------------ Date: Thu, 5 May 94 20:02 PDT From: paulb@teleport.com (Paul Buder) Subject: Re: Bellcore cracks 129-digit RSA encryption code (RISKS-16.03) I've heard this 40 quadrillion years figure a couple of times now and I find it odd. Is that what the Scientific American said? I have the original document from MIT's Laboratory for Computer Science. It's titled "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems" by Ronald Rivest, Adi Shamir, and Len Adleman, April 1977. I can't do superscripting with vi so 10 10th means 10 to the 10th power. It has the following table in it: Digits Number of Operations Time =================================================== 50 1.4 X 10 10th 3.9 hours 75 9.0 X 10 12th 104 days 100 2.3 X 10 15th 73 years 200 1.2 X 10 23rd 3.8 X 10 9th years 300 1.5 X 10 29th 4.8 X 10 15th years 500 1.3 X 10 39th 4.2 X 10 25th years 200 digits was supposed to take 3.8 trillion years and 100 a mere 73. So where does the 40 quadrillion figure come from? paulb@teleport.COM Not affiliated with teleport. ------------------------------ Date: Mon, 09 May 1994 12:06:09 -0600 (MDT) From: "Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067" Subject: Risks of following up on credit card laws (last one) In response to my initial posting of the "Streetwise Guide" book review, and subsequent summary of the initial responses, I (and, I presume, PGN as well) am still receiving mail on the subject. Unfortunately, there is a lot of disagreement and a shortage of direct quotes from the relevant statutes. I pass along these messages, therefore, since they contain at least references to the names of specific acts. From: avm4@crux4.cit.cornell.edu =========== The quoted material appears to be backwards, judging foom the text on the back of my credit card statement and also from the misc.credit FAQ: Q504. Exactly which purchases qualify under the Fair Credit Billing Act? You are protected if all of the following are true: - The purchase was made with a credit card. (If it was a debit card, the money is already gone from your account and the bank won't get involved.) - The amount charged is more than $50. (The amount in dispute could be less, for example if you bought a $90 lamp but were billed $100. The amount in dispute is $10.) - You made the purchase somewhere in your home state, or within 100 miles of your mailing address. (I am not an attorney, but my understanding is that if you are having goods shipped to you by mail or phone order, the place of purchase is the address you are having them shipped to.) If some of the above are not true, you are still protected if the credit-card company owns or operates the merchant, or the credit- card company mailed you the advertisement for what you bought. In that case your purchase is covered by the rules no matter where you bought or how much you paid. In addition, you MAY successfully protest charges outside of these parameters, but there is no legal requirement for the credit card company to do so. ============ From: cramer@world.std.com (Bill Cramer) ============ >I don't remember the exact language, but in the U.S. consumers have the >right to refuse charges made more than 50(?) miles from their home address. >The refusal must be in writing, within 30 days, possibly with an explanation, >etc. The bank must complete its actions within 60 days of receipt of this >letter, cannot charge interest or late fees on the disputed amount, etc. This statement would seem to be in conflict with 15 USC 1666i(a), which states, in part, that a card holder can withhold payment only when the place of the transaction was **within 100 miles**. ============ There was also mention of a Consumer Credit Protection Act. This is as far as I go, since 1) I am not a lawyer, 2) I am not an American and 3) I am part of the larger world to which my original comments still basically hold good. ------------------------------ Date: Fri, 6 May 1994 10:13:31 +0800 From: stalzer@macaw.hrl.hac.com Subject: Future of US health care? For the past few months, my baby daughter has had a large rash. My wife took her to our HMO a few times and the doctor (gatekeeper) finally authorized a blood test and a visit to a dermatologist once the blood test results were available. Last night, we received a form authorizing the visit to the specialist that contained a clearly labeled diagnosis of Lupis. We assumed that this was the result of the blood test and I logged into Prodigy to find out more about Lupis. The online encyclopedia had a detailed description and my daughter appears to have some of the symptoms. Furthermore, the disease is very serious and can lead to death. We were very worried and I immediately contacted the HMO. This was about 6:30p and the front office staff couldn't help us (the doctors were gone) even though their computer generated the form! (I expressed my displeasure as forcefully as possible without using colorful language...) I then called the dermatologiest and what he had to say is very interesting. Apparently, the HMO contacted the dermatologist last week, described the symptoms, and asked for a list of possible diagnoses. He provided about half a dozen possibilities and the HMO doctor then picked the worst possible one so that it would get past the review committee! If he had put a more likely diagnosis, like an allergy or fungus, a specialist visit probably would not have been authorized. Also, the blood test results are not in, and based on my daughter's response to some medication, it looks like she has something simple that will clear up. Of course, she still gets to visit the dermatologist based on the "diagnosis" on the form. I'm thankful that the HMO doctor "worked the system" to get the best possible care for my daughter. However, this form with a diagnosis of a serious disease has me angry. Do health care providers really think it's okay to mail out something like that without making a personal contact? Do they tell people they have AIDS by mail now? Why didn't the front office staff at the HMO have a clue? Shouldn't doctors be spending their time helping people, not trying to figure out how to get around the system? And finally, do we really want the Clinton Administration to mandate this kind of system for all Americans? -- Mark Stalzer (stalzer@macaw.hrl.hac.com) ------------------------------ Date: 9 May 1994 15:26:52 GMT From: daugher@cs.tamu.edu(Walter C. Daugherity) Subject: White House May Issue National ID Cards >From Prodigy 5/9/94: White House May Issue National ID Cards The Clinton administration is working on a national ID card that every American would need in order to interact with any federal agency, reports Digital Media: A Seybold Report, a computer industry newsletter based in Media, Pa. The so-called U.S. Card would be issued to citizens by the Postal Service. It would be issued as a "smart card," with its own internal CPU, or as a plug-in "PCMCIA" card with megabytes of built-in memory. Administration approval of the plan "could come at any time," states the newsletter. Walter C. Daugherity daugher@cs.tamu.edu uunet!cs.tamu.edu!daugher Texas A & M University, College Station, TX 77843-3112 DAUGHER@TAMVENUS [Several folks sent me Mitch's piece from EFFector Online 07.08, and Digital Media, "Ever Feel Like You're Being Watched? You Will..." However, I cannot run it in RISKS because of its copyright notice. Contact Mitch Ratcliffe (NOT RISKS) if you want a copy of the whole article. PGN] ------------------------------ Date: 09 May 94 17:32:49 EDT From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Canadian long-distance service reseller blunders In November 1993, I signed up with a long-distance service reseller in Canada. I won't give the name because there's no longer any reason to embarrass the company. Shortly after registering, I received a friendly welcoming letter explaining how to use their service. As expected, there was a special number to dial; when we got the dial tone, we'd punch in a 3-number PIN and our own telephone number. Then we'd get another dial tone and we would dial our destination number. In the envelope were printed labels to stick on our phones with all of these instructions--including the PIN! I called the company and asked to speak to the chief of security. When I finally got to speak to her, she expressed horror at the prospect of having customer PINs stuck to their phones in plain sight, where any passing dishonest person could pick up their access codes and call expensive places. It seems that no one in marketing or customer service had every discussed this brilliant plan with her or with her staff. She assured me that she would report the breach of security and effect changes. Months passed. In January, I spoke to the chief of security again. This time, I cheerfully told her she was running out of time. I sent her a registered letter warning her of the dangers to consumers; pointed out that although theoretically the user of a phone system is responsible for calls, there would be no way to squirm out of the irresponsibility of having sent out thousands of stickers showing the PINs of countless users; and that even if the company absorbed the costs of fraud, they'd be unable to prosecute even dishonest users who abused their own phone codes. I then added what I think was the clincher: if I didn't hear back from them within a week I'd publish a report in the RISKS FORUM DIGEST and in Computing Canada and make them a laughingstock. I got a call from the VP to whom the security chief reports. He assured me that the problem was being solved. Indeed, a few weeks later, I received new stickers _without_ a pin. The system now uses ANI to identify the client. Attempting to access the trunk from an unauthorized phone immediately causes an alert at the company switchboard; repeated attempts to abuse the system can lead to termination of service. The authorized user is informed of such attempts. Moral: don't just ignore security breaches, fight them! Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn [Or threaten them with worldwide appearances in RISKS? PGN] ------------------------------ Date: Mon, 9 May 94 12:40:52 -0400 From: tada@MIT.EDU Subject: Cheers to two companies Although this forum is primarily for giving examples of computer problems, I'd like to give credit to two companies I recently dealt with that made an extra effort to reduce the risks in their systems. My company recently switched to Fidelity for managing it's 401(k) retirement plans. Fidelity has a phone number one can call to check balances, transfer investments between different funds, etc. When you call for the first time, you're asked to select and enter a PIN. To identify yourself, you need the plan number for your company, your social security number, and your birthdate. All these are easily obtained by others. To prevent misuse, the system sent confirmation by mail to the person's home address that a PIN was set up. (Allowing a PIN setup by phone worried me when I read their literature, but I felt this was a good way of minimizing the risk. Also it should be noted that one couldn't transfer money from one person to another, only transfer to different funds.) A few days ago I stayed at a Mariott Courtyard in Landover, MD. They have an express checkout system in which a copy of the bill is printed and slipped under your door your last night there. On the bill is printed the credit card number used for billing. The copy slipped under the door had the number overwritten with a heavy black marker. It's possible that one could determine the number anyway, but it reduces the risk of casual observance, and at least demonstrates that they're thinking about the problem. Cheers to both companies for thinking about the issues. -michael j zehr ------------------------------ Date: Tue, 3 May 94 13:43:20 EDT From: desj@ccr-p.ida.org (David desJardins) Subject: Re: MIT student arrested (Cohen, RISKS-16.01) Fredrick B. Cohen writes: > As to the issue of his intent to pirate software, that was not the charge > against him. It was wire fraud! I have read the copy of the indictment and > commentary and I find this awfully strange. According to his lawyer on Nightline (and this was not contradicted by the former FBI computer-crime head), Congress wrote the copyright law so that pirating software is not specifically criminalized unless one does it for profit. Whereas the wire fraud statute requires only a "scheme to defraud"; there need not necessarily be a profit motive. David desJardins ------------------------------ Date: 9 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.04 ************************ 11-May-94 18:55:12-GMT,29378;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13539; Wed, 11 May 94 14:55:07 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09380; Wed, 11 May 94 14:53:30 EDT Received: by chiron.csl.sri.com id AA10369 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Wed, 11 May 94 11:44:39 -0700 From: RISKS Forum Sender: RISKS Forum Date: Wed, 11 May 94 11:44:37 PDT Subject: RISKS DIGEST 16.05 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Weds 11 May 1994 Volume 16 : Issue 05 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Are we betting on horses or computers? (off-track betting) (Reva Freedman) Amusing computer-related anecdote about local cable service (H Morrow Long) MTV Sues Curry (Adam Curry) China Airlines A300 Crash (Mark Stalzer) Re: Elevators, Car bumpers and Cryptography... (Peter Wayner) Re: Bellcore cracks 129-digit RSA encryption code (Fred Cohen, Amos Shapir) Re: ACM Nightline (Robert Morris) Don't always believe those E-Mail addresses (A. Padgett Peterson) EFF's Kapor announces new cyberspace TV show (Kapor via Stanton McCandlish) Automation: request for input (Ken Funk) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 10 May 94 15:46:02 CDT From: freedman@merle.acns.nwu.edu Subject: Are we betting on horses or computers? (Risks of off-track betting) Illinois has off-track betting on horse races. You can place your bet at one of these legalized bookie joints, then watch the race on TV and collect your winnings. If you place your bet early in the day, you don't even have to wait around for the race. You can watch the race at home and come back later to collect. That's the theory, anyway. On Saturday, April 23, the computer system handling the betting for some of the remote sites crashed after the fourth race. People at the betting parlors were told that they couldn't place any more bets. But what about those who had placed their bets and left? When winners returned on Sunday to collect, they were surprised to learn that, from the racetrack's point of view, they had never placed a bet, and were offered only a refund of the cost of their ticket. So were losers, if they had kept their tickets and happened to hear about the computer crash. However, the fact that refunds were available was not listed in the newspaper with the race results, mentioned on the telephone hot line, or mentioned on cable TV broadcasts of the races. On Monday a class-action lawsuit was filed. By Tuesday, racetrack management had decided to pay up. The system, designed by Amtote International, had only been in operation for a month. On the other hand, state officials had sued Amtote before for deficiencies in the previous system. No description was given of the original failure, but newspaper reports (Chicago Tribune, 4/26/94 and 4/27/94) said that a hardware problem caused the backup system to fail. The new system was designed to be "user-friendly." I hate to say it, but the most user-friendly component in this incident was the lawyers! Reva Freedman freedman@merle.acns.nwu.edu ------------------------------ Date: 9 May 1994 17:21:07 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Subject: Amusing computer-related anecdote about local cable service A very interesting program was on Storer cable channel 70 last night [they call themself Comcast now, and serve the areas of West Haven, New Haven, and Hamden]. For a long time, only the following message was flashing at the top of the screen: ---------------------------------------------------------------- | Software Failure. Press left mouse button to continue. | | Error: 0000 0003 Task: 002006f0 | ---------------------------------------------------------------- Talk about having your software problems out where the world can see them. Didn't look like anyone was minding the store(r). I guess someone there had to press the left mouse button this morning... H. Morrow Long, Mgr of Dev., Yale Univ., Comp Sci Dept, 011 AKW, New Haven, CT 06520-8285, (203)-432-{1248,1254} Long-Morrow@CS.Yale.EDU [In the old days, it was not unusual for a mouse to nibble into a cable. Now we have cable nibbling at the mouse. Turn(er)about is fare prey. PGN] ------------------------------ Date: 10 May 1994 03:44:36 -0400 From: curryco@panix.com (Adam Curry) Subject: MTV Sues Curry [IMAGE] MTV SUES CURRY Last update: May 10 1994 _New Jersey, May 10 1994_ I had planned to keep the following quiet until more information was available, but since several journalists have already caught wind of it, I decided to get it out into the open so my side of the story is heard as well. The domain I maintain and operate on the Internet, mtv.com was founded approximately one year ago. At that time I registered mtv.com with the InterNIC, purely because it was a cool address to have, and it was available. What a great "vanity plate"! The site quickly became a frequently accessed "hangout" on the net, with an average of 35000 accesses daily from Mosaic clients alone. During the start up months I had many conversations with executives at MTV Networks about my endeavours, which btw, were all financed out of my own pocket, and vps from MTV Programming as well as Viacom New Media were aware of what I was doing on the internet, and although they stated "MTV has no interest in the internet" they gave me their blessing and supported my efforts. This was enforced when I set up several email accounts on mtv.com for use in MTV's on-air programming. Ever since the summer of '93, popquiz@mtv.com was used for trivia quiz questions, that were then aired on MTV's "Most Wanted" a program I hosted at the time. Solicitations were made on the air, and the address was shown on the screen. For MTV's annual Valentines video dedications, viewers were offered the choice of calling in their dedications, or sending them via email to elove@mtv.com. I never charged MTV Networks for this service, I purely saw it as a cool feature to introduce to MTV's programming, spreading the "gospel", so to speak. Then I started to get a lot of press about mtv.com, and some people started to wake up at 1515 Broadway (MTV's HQ in New York City). And I was served with a "Cease and desist" on the use of mtv.com. MTV's attorneys claimed that there could be "confusion" for users of the internet, when connecting to *anything* that had the letters mtv in the address, and then receiving music and entertainment information. I was obviously hurt by this move, but did see what point they were driving at, an asked if we could settle this matter amicably. The situation cooled down for a couple of months, but when I resigned on-air from my job as a VJ, which MTV chose not to air btw, things started to get ugly. Long story short, MTV Networks has filed a lawsuit against me, for copyright infringement of their "trademark", that being their "MTV" call letters, as well as having information online that was MTVN "property". In this case they are referring to several press releases I put up on mtv.com, such an announcement about Beavis and Butthead's "experience" cd release. Understand that MTVN sent me these releases over their own internal computer network for this very purpose! Again, I was only doing this to promote the channel, not for my own personal gain..after all...mtv.com is free access for all, no charge. Throughout all of this I have offered to maintain the site specifically for mtv, but again they said "we're not interested". Of course, I have no problem whatsoever removing all references to MTV Networks and it's projects from mtv.com, no that I don't work there anymore gives me even more reason to want to do this, but the kicker is they are moving for an injunction to make me stop using the internet address mtv.com! This is of course totally unacceptable: I registered the domain name, and I don't plan on giving it up. Sure MTV and their parent company Viacom have a vast legal team, but david also nailed goliath, so I have faith. In the long run, everyone knows that the only *true* winners will be the lawyers. There are many different viewpoints on this situation, but I feel that the use of mtv in an addressing scheme can't be seen as an infringement of intellectual property laws, and a search of the InterNIC database shows at least 15 domain names registered with mtv in the address. Irony is that I incorporated a company called ON RAMP, Inc (tm) and onramp.com was already registered to someone else, but I'm not suing them :) It appears to me that MTV has their mind set on the address mtv.com, maybe not for now, but possibly for future use, and I feel extremely used, in that I built up quite an audience for that address, and they are basically saying "thank you very much, you may go". A pre-motion hearing is scheduled for this thursday morning at 11am, wit the honourable Judge McKenna presiding, in an attempt to get an injunction to make me stop using the address mtv.com. I will update the situation as it unfolds. Adam Curry, adam@mtv.com ------------------------------ Date: Wed, 11 May 1994 09:02:33 +0800 From: stalzer@macaw.hrl.hac.com Subject: China Airlines A300 Crash The L.A. Times today (May 11) published a story on the A300 crash last month at Japan's Nagoya airport. I'll quote the first paragraph and then summarize the remainder of the story. "A terrifying battle between an inexperienced co-pilot and his airplane's super-sophisticated computer system preceded last month's crash of a Taiwanese jetliner that killed 264 people..." The events described in the rest of the article are as follows: 1. The plane was being hand-flown on approach to landing by its 26-year-old copilot. 2. About 2 minutes prior to landing, the A300 went into "go-around" mode for reasons unknown. 3. Even though the pilot warned the co-pilot 3 times in 30 seconds, as recorded by the voice recorder, the co-pilot continued to attempt to land the plane. The effect was that the auto-pilot was trying to pitch the nose up using the "horizontal stabilizer flaps" while the co-pilot was trying to pitch the nose down using the "elevator flaps" (the Times author might have this a bit confused). 4. The crew then switched the "go-around" mode off. However, the "stabilizer flaps remained set at a sharp angle." 5. The crew realized the plane was too high to land, so they set the "go-around" mode back on. 6. This caused the plane to climb sharply and approach a stall. The A300 stall-prevention system automatically increased the engine thrust but this INCREASED the climb angle to 53degs. 7. The airplane stalled. 8. The nose dropped and the airspeed increased to 150mph at an altitude of 260 yards. 9. At this point, the entire electrical system stopped functioning for reasons unknown, including the flight data and voice recorders. 10. The plane crashed, killing 264 people. There were 7 survivors. The root cause of this crash seems to be a confused co-pilot. However, the A300's automatic systems contributed in two ways. First, it continued to attempt the go-around even though the plane was still being flown by hand. Had the auto-pilot disengaged (with a suitable warning!) this whole disaster may have been adverted. I think a human supplying control inputs is the "final authority" and the automatic systems should "back off". Second, the stall-prevention system's actions (increasing thrust) contributed to the stall. This is a serious kind of failure, if a automatic system designed to prevent a problem makes it worse, it should do nothing at all! -- Mark Stalzer (stalzer@macaw.hrl.hac.com) ------------------------------ Date: Tue, 10 May 1994 15:37:05 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: Re: Elevators, Car bumpers and Cryptography... I once talked to a major elevator company about doing just what the Schindler Elevator Corp. is accused of doing by the Toronto government. (RISKS-16.04). The company told me that they were in the habit of selling the elevators at a loss so they could make up the money in service contracts. Then they found themselves battling independent service companies who undercut their prices. They hoped to use cryptography to lock out any other service provider without the right key. Of course, this loss-lead approach is common in many businesses. Car companies often sell their cars at a low price and hope to make it up selling spare parts later. That is why I discovered that a spare bumper for my car cost over $500. The difference is that other companies are now making duplicate parts. The major automakers can try and discourage them, but they can't lock them out of the business. Cryptographic locks, though, are a different story. They probably can't be broken in a reasonable amount of time. (See also 16-04) I'm not sure of the case law on this, but I would suspect that it might fall under questionable or illegal trade practices. At least in the US. ------------------------------ Date: Tue, 10 May 94 19:33:36 PDT From: Fredrick B. Cohen Subject: Re: Bellcore cracks 129-digit RSA encryption code (RISKS-16.04) I think a lot of people are missing the real point about the RSA. On my pocket PC, I can create a code that requires 5,000 MIP years to break in a matter of seconds. If I am willing to use several more seconds, I can make a code that takes 10^25 MIPS years to break. Compare this to any other encryption scheme, and you will find that the workload amplification of the RSA is quite good. And Shannon told us in 1949 that any non-perfect information transform can be broken with enough cyphertext - and developed the concept of workload for evaluating cryptosystems. If we want perfect cryptosystems we know how to get them, but it requires secure distribution. On the other hand, the RSA provides any degree of complexity we wish to generate (finite) and a fantastic complexity amplification factor, and the advantages of a dual public key system that can be used for both encryption and authentication. The point is that the RSA has not been broken, rather it has shown just how much of a David is required to defeat a given Goliath. After all, in terms of that story, David would have been a MIP second and Goliath 5,000 MIP years in relative sizes for a break-even fight. I'll take that David any day. FC ------------------------------ Date: 11 May 1994 15:19:01 GMT From: amos@CS.HUJI.AC.IL (Amos Shapir) Subject: Re: Bellcore cracks 129-digit RSA encryption code (RISKS-16.04) > So where does the 40 quadrillion figure come from? It comes from this very table. 10^9 is a billion, not a trillion, in the US system, and 40 quadrillion is 4 x 10^16, which is even less than what I get by interpolating to 425 bits (can anyone who has access to the original RSA article verify this?). There seems to be an interesting risk here: most encryption methods rely on "hard" problems, i.e. problems whose "brute force" solutions require computation resources which are an exponential function of the key length. But in a world in which computing power grows exponentially, such problems can be solved in polynomial (or even linear) time! Amos Shapir, The Hebrew Univ. of Jerusalem, Dept. of Comp. Science. Givat-Ram, Jerusalem 91904, Israel +972 2 585706,586950 amos@cs.huji.ac.il ------------------------------ Date: Wed, 11 May 1994 10:09:00 -0400 From: Robert Morris Subject: Re: ACM Nightline (Kabay, RISKS-16.03) >...they have _no right_ to use the product without that contractual agreement. This confuses several issues--that of theft, that of use and that of licensing, and in an important case Kabay's implied position is wrong. Certainly---and this is his main point---theft of intellectual property is theft. However, property protected by U.S. intellectual property laws, notably copyright and patent protection (especially the latter)---can not simply be withheld from use at the whim of the owner. For example, patent holders MUST license equally to all who meet reasonable terms. Indeed, the _purpose_ of copyright and patent protection is to promote the widest possible access to the new ideas by insuring that their creators have economic motivation to do develop them. The owners of intellectual property who want to restrict its distribution are expected to look to the trade secret laws to protect them. I'm not sure what requirements are imposed on copyright holders (and as an aside, I sure would like The National Computer Security Assn. to argue that copyright, not patent, is the only appropriate form of protestation for software! heh, heh, heh.), but I suspect they can not capriciously and arbitrarily withhold copy permission from some but not others, and it will even surprise me if they can put irrelevant terms in the copy permission. None of this speaks to licensing, but (I speculate) the only legal culprit in a licensing violation is the licensee who allowed the copy. And presumably that contract violation is a civil, not a criminal matter in American law. Bob, not an attorney, Morris ------------------------------ Date: Wed, 11 May 94 08:17:46 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson, Information Security) Subject: Don't always believe those E-Mail addresses One of the more subtle RISKS of E-Mail is in believing what you see. Recently a good friend of mine was repeatedly accused of posting not-so-nice messages on various news-groups. Not so blatant as to be unbelievable but morally damaging. This irritates me. A few months ago I was flamed in RISKS for talking about the use of Ethernet card firmware addresses as for tracking. Two weeks ago it enabled me to quickly and positively identify the source of repeated failed attempts to log into an Ethernet server as supervisor. When I asked the administrator for the data in the log, he told me that he had never known that the six hex bytes had a meaning. Similarly, forged E-Mail is possible only because many E-Mail packages throw away the Ethernet wrapper that made the communication possible in the first place, a wrapper that *must* contain the return address or "the mail won't go through". Here I have FTP Software's (plug) PCTCP which provides an MSDOS machine with more built-in features than many UNIX implementations (won't go into them all else it would be an adv't but will just say that it allows me to identify not only the source, but the path used to get here). For example what most people see in an E-Mail posting is this (lines have been wrapped to 80 characters & true returns masked) - Judge and Goat are two PCs in my office. ----------------------------------------------------------------- From Crusader_Rabbit@Jay.Ward.Cartoons Wed 11 May 1994 07:34 To: padgett@goat.ppp.qqq.rrr Return-Path: Demonstration of message headers. ----------------------------------------------------------------- What was actually received from the SMTP server was this but most newsgroups & many mailers strip the "Received: from..." as above: ----------------------------------------------------------------- From Crusader_Rabbit@Jay.Ward.Cartoons Wed 11 May 1994 07:34 X-Envelope-To: padgett@goat.ppp.qqq.rrr Return-Path: Received: from judge.ppp.qqq.rrr ([123.456.789.000]) by Goat.ppp.qqq.rrr (SMTPSRV); Wed 11 May 1994 07:34 Demonstration of message headers. ----------------------------------------------------------------- Note that not only the originating name is sent but also the true IP address [123.456.789.000]. Again this *must* be there. Not to say that this is not a valuable capability since I prefer that all incoming E-Mail come to a common point, just don't rely on them since they can be *anything* the sender wishes. Don't just toss those wrappers, dispose of them properly. Padgett ------------------------------ Date: Tue, 10 May 1994 20:47:23 -0400 (EDT) From: Stanton McCandlish Subject: EFF's Kapor announces new cyberspace tv show Stanton McCandlish * mech@eff.org * Electronic Frontier Found. OnlineActivist Forwarded message: Date: Tue, 10 May 1994 09:13:23 -0400 From: mkapor@kei.com (Mitchell Kapor) Subject: My tv show (I thought you might be interested in this.) New Cyberspace TV Program I am developing a new program on cyberspace in conjunction with WGBH-TV, PBS' Boston affiliate. The show is intended to be a window onto the world of computer networks for the television viewer, whose point of view is that the world of on-line communications is interesting because of what people do there, not because of the digital plumbing which enables it. We will be focusing on the human aspects of networking and the individual and social aspects of being on-line. Cyberspace will be portrayed as a not-so-really strange territory after all, where all of us will increasingly come to live and work. My role is to guide people through this new territory, introducing the audience to its native culture, its scenic attraction, and its sights and sounds. We assume our audience is motivated by curiosity to learn more about what goes on in cyberspace, but we do not assume they are knowledgeable or, in general experienced with it. On the other hand, we will not trivialize the subject matter by reducing it to a least common denominator. We will give the show a look and feel which is approachable and down-to-earth. Interview guests and roundtable participants will be drawn from the net community itself. There will be plenty of demos of cool net stuff from Mosaic, CU See Me, and other cutting-edge applications and services. We are taping two test shows in mid-June which will be shown in Boston and other cities and hope to have some sort of national distribution (to be determined) in the fall for a regularly scheduled program. We are also going to create a WWW server for the show, the segments of which will be downloadable. The server will be have on it additional material which won't fit into the show format. An Invitation: We would like to include some video clips of net citizens expressing their greatest hope and worst fear about the future of the net which we will edit into an on-air piece for our regular feedback session. It's important to me to have the voices heard (and faces seen) of people already on the net. This is an opportunity for those of us who enjoy appreciate the decentralized and democratic character to express that sentiment to a mass audience. I hope you'll take advantage of the opportunity. Guidelines: Since an individual on-air clip will run at most 20-30 seconds, please keep your statement succinct. In shooting the clip, please feel free to pick a location which says something about yourself, whether it's your computer, your pet, or the great outdoors. We can accept Quicktime movies, VHS cassettes, or 8mm tapes. If you enclose a mailer, we will return your tape. We can also pick up digital submissions from any FTP site, etc. Contact Information: email: cybertv@kei.com Postal: CyberTV c/o Kapor Enterprises, Inc. 238 Main St., Suite 400 Cambridge MA 02142 ------------------------------ Date: Thu, 28 Apr 94 06:59:08 PDT From: funkk@ENGR.ORST.EDU (Ken Funk) Subject: Automation: request for input Oregon State University, America West Airlines, and Honeywell are conducting a study of flightdeck automation for the Federal Aviation Administration which requires input from the scientific community. The increasing use of automation on the flightdecks of commercial transport aircraft has raised concerns about the overall safety effects of this equipment. While several studies have attempted to address some of these automation issues, until now no one has tried to systematically identify all issues that exist about flightdeck automation. The objectives of this study are to collect and compile a comprehensive list of all flightdeck automation problems and concerns and to address them in order to identify or generate recommendations and guidelines for the FAA, manufacturers, and operators. To achieve these objectives we are soliciting information on automation problems and concerns from individuals in a variety of disciplines. When we have compiled these problems and concerns we will prioritize them, study the highest priority items using analytic methods and simulator studies, and identify and develop recommendations based on our findings. Although we are primarily targeting the aviation community for sources of automation problems and concerns, we recognize that individuals in other disciplines have knowledge of other kinds of system automation and know of automation problems or have concerns about automation that would be very relevant to our study. Experts in computer science, human factors engineering, psychology, and other fields often deal with the automation of industrial systems, office equipment, and even consumer devices, so we welcome information from them. If you have direct knowledge about system automation and you know of problems with or have concerns about the safety of such automation, you can help us by filling out a copy of our Automation Problems and Concerns Questionnaire. This is an opportunity for you to contribute to flight safety and, if you wish, we will put you on our distribution list to receive copies of reports on the results of our study. If you would like to fill out a questionnaire, send a message to flight@engr.orst.edu (don't post your request to this newsgroup!). Request a copy of the Automation Questionnaire, and I will send you a copy via e-mail. When you have completed it (which should take between 15 and 30 minutes), just e-mail the completed version back to me. The problems and concerns you identify will be added to our database and used in our study. Ken Funk, Assistant Professor of Ind. and Mfg. Engineering, Oregon State Univ. flight@engr.orst.edu, funkk@engr.orst.edu (503) 737-2357 FAX: (503) 737-5241 ------------------------------ Date: 9 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.05 ************************ 12-May-94 23:46:07-GMT,30968;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13458; Thu, 12 May 94 19:46:00 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08578; Thu, 12 May 94 19:45:50 EDT Received: by chiron.csl.sri.com id AA12562 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Thu, 12 May 94 16:36:53 -0700 From: RISKS Forum Sender: RISKS Forum Date: Thu, 12 May 94 16:36:51 PDT Subject: RISKS DIGEST 16.06 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Thursday 12 May 1994 Volume 16 : Issue 06 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Plane accidentally ejects pilot into sea (Frank E Carey) Tax preparation programs; IRS privacy; IRS computerization (PGN and COOVEN) Digital Defamation in the UK (Brian Randell) We spy harder! (Mich Kabay) Killers sue over phone taps (Mich Kabay) Journalists attack credit card account (Mich Kabay) Fragmenting of the News (Mich Kabay) Software piracy vexes industry (Mich Kabay) Ultra-high dependability and the Channel Tunnel (R.J. Stroud) Re: Future of US health care? (Amy McNulty) Re: China Air A300 Crash (David Wittenberg) Re: Copyright/patent owners: quick correction (Mark Seecof) Re: Amusing computer-related anecdote about cable (Ry Jones, Paul N Hrisko) Re: 11-digit ZIP code (Ed Ravin) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 12 May 94 13:15:56 EDT From: fec@arch4.ho.att.com (F E Carey +1 908 949 8049) Subject: Plane accidentally ejects pilot into sea TOKYO (Reuter) - The test pilot of a trainer jet built for the Japanese air force was accidentally ejected when the emergency bailout system mysteriously functioned, the plane's makers said Tuesday. Pilot Masahiko Kameishi was later plucked from the sea by a military helicopter. He was reported to have suffered minor injuries to his arms and knees. Kameishi was flying the T-4 two-seater over the Pacific Ocean southwest of Tokyo on Monday when he was suddenly ejected into the sea with a parachute, a spokesman for manufacturers Kawasaki Heavy Industries Ltd said. His co-pilot, seated in the rear, landed the plane safely at a nearby military base. The Kawasaki spokesman said the company was looking into whether the ejection was activated by mechanical malfunction or by something the pilot may have touched. More than 100 T-4s are already in service with the Air Self-Defense Force, Japan's air force. Kameishi's plane was to have been handed over to the air force June 1. Frank Carey at Bell Labs f.e.carey@att.com ------------------------------ Date: Wed, 11 May 94 15:47:47 PDT From: "Peter G. Neumann" Subject: Tax preparation programs; IRS privacy; IRS computerization 1. The following item is apparently from COOVEN@MITRE.ORG (that's the address written on a FAX, but that address is not accepting mail). It was sent by SnailMail to Will Tracz, the new editor of Software Engineering Notes, presumably for the RISKS section. Will faxed it to me. From Law Practice Management, April 1994, p. 16: Well, it's April again and time for the annual buying frenzy for All The Latest tax-return software. Just so you're on notice -- last year at this time *PC Magazine* did a comparison of twenty different tax- return packages. When they ran a test scenario through the packages (see -- I don't actually have to say it out loud anymore -- you people know what's coming), that's right, *every single package* computed a different total tax due. Sort of like calling the IRS Help Line. 2. Colin Smiley sent me a note observing that his social security number was visible through the window of the envelope that contained his refund check, and pointing out the evident risks. 3. The IRS is now beginning the integrated computerization of its entire tax process. This presents many interesting risks relevant to our newsgroup, such as those relating to security, integrity, authenticity, insider abuse, fraud, violations of privacy, bogus returns, and so on. 4. Your RISKS Moderator is now a member of the IRS's Commissioner's Advisory Group (CAG), and cochairman of its Subgroup on Technology, Security, and Privacy. If you have problems that you believe need to be addressed, please send them to me (neumann@csl.sri.com) if you do not want them to appear in RISKS. The next meeting is coming up in midJune. PGN ------------------------------ Date: Thu, 12 May 1994 17:48:26 +0100 From: Brian.Randell@newcastle.ac.uk (Brian Randell) Subject: Digital Defamation in the UK The following article is quoted in its entirety from the (UK) Computer Weekly, issue dated 12 May 1994. [Brian Randell, Dept. of Computing Science, University of Newcastle, Newcastle upon Tyne, NE1 7RU, UK +44 91 222 7923 ]FAX = +44 91 222 8232] Why bulletin boards are a libel minefield Nick Braithwaite warns of the dangers of digital defamation and how network and bulletin board operators must guard against being unwitting participants in user's libellous missive Libel doesn't figure prominently in most network operators' list of priorities. Many assume that transient screen messages are private and unlikely to damage anyone's reputation. Electronic mail and bulletin boards foster informal communication, so users may be resistant to the idea that defamation risks are attached to electronic "conversations" . But beware if you run network or database. You could be in the firing line for a libel claim. In the first case of its kind in the UK, Canadian academic Dr Laurence Godfrey issued a libel writ in London against another academic based in Geneva claiming he was defamed by a bulletin board message posted on the Usenet system. If the claim succeeds, hosts and users could soon be contemplating sizeble pay-outs. In fact, there's nothing novel about the Godfrey case. Libel suits have been an occupational hazard for information providers and electronic database operators for many years, but now network hosts too have begun to experience defamation problems. Only recently, Compuserve was sued for libel in the US, while individuals in both the US and Australia have faced claims over uncomplimentary bulletin board messages. Are electronic messages "published" for libel purposes? The first requirement is a degree of permanence in the communication. Most experts now agree that, if defamatory, even transitory computer messages flashed on screen are sufficiently permanent, once stored in memory, to be libellous. Slurs posted on bulletin boards are even more likely to be held libellous. The "publication" requirement is minimal, satisfied if just one person other than the plaintiff sees the material. Despite the international aspects of the Godfrey case, one solitary viewing of a bulletin board in England allows a case to be litigated in London, where libel actions are hard to defend. The author of a defamatory statement is an obvious libel target, but corporations with deep pockets usually make more enticing defendants. Happily for US-based computer networks, the court in the Compuserve case ruled Compuserve could not, without editorial control, be liable for defamatory statements by users. In England, it is likely that operators will have to prove they were not negligent or reckless in allowing the statement onto the system. So if you follow the US standard, you should not exercise any editorial control at all. If you follow the English standard you should exercise maximum control. In fact there ought to be no real conflict, because it is difficult to imagine a court insisting that an operator should vet all messages on the system. Whichever standard of care prevails, database and public access network operators will have every incentive to minimise editorial control over what they carry. Plainly, for some databases and networks that will not be practical. But for libel purposes, the ideal is probably to emulate a telecoms carrier, disclaiming all responsibility for the content of messages. Some practical steps to keep the lawyers at bay are: Check you have a warranty from the subscriber that they will not input defamatory material. Or, if you are worried about staff messages, put a warning in their contract of employment. Consider a statement in your user contract that the operator has no editorial control over traffic on the system. Display a warning on-screen that the host does not endorse any defamatory statements. These may not solve every problem, but will help reduce risk. [Nick Braithwaite is a lawyer in the London-based media group of solicitors Clifford Chance] ------------------------------ Date: 11 May 94 21:51:19 EDT From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: We spy harder! >From the Reuter newswire via Executive News Service (GO ENS) on CompuServe: "FORT LAUDERDALE, Fla, May 9 (Reuter) - Three former owners of Value Rent A Car Inc pleaded guilty Monday to racketeering charges and face prison sentences of two to five years and fines totalling $2 million." They are also accused of having wiretapped the offices of Mitsubishi Motors executives. Mitsubishi Motors owned 80% of the firm at that time. [MK: This is known as taking an interest in management.] ------------------------------ Date: 12 May 94 12:25:19 EDT From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Killers sue over phone taps United Press newswire (94.05.11 @ 09:59 EDST) via Executive News Service on CompuServe: CAMBRIDGE, Mass., May 11 (UPI) -- A Massachusetts judge continued a hearing on a suit by eight convicted murderers who seek to end the state's new practice of monitoring inmate phone calls to the outside. The eight lifers, saying they are representing all 10,000 state prisoners, filed suit against Nynex and Massachusetts corrections officials for tapping their phone calls." The article continues with the following key points: o William "Lefty" Gilday, convicted of murdering a policeman, claims that the phone monitoring system is unconstitutional. o Corrections officials argue that "the taps are necessary to curb fraud, harassment and drug dealing by inmates." o Gilday was convicted in 1984 of running a credit-card fraud operation from prison and defrauding American Express of $4,000. [MK: set flame = on Interesting perspective on rights and responsibilities, eh? These folks remind me of the self-righteous anger of some criminal hackers when legal processes interfere with their self-proclaimed rights to attack other people's computer systems. "Rights for me, not for you; duties for you, not for me." Could we maybe apply the Key-Escrow Proposal to criminals? How about "Lock 'em Up and _Throw Away_ the Keys"? set flame = off Why is my neck turning red?] Mich Kabay / not representing anyone else this time. ------------------------------ Date: 11 May 94 21:51:29 EDT From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Journalists attack credit card account >From the Reuter newswire via CompuServe's Executive News Service (GO ENS): "FRANKFURT, May 10 (Reuter) - A journalist from a well-known German satirical magazine has cut off fugitive real-estate tycoon Juergen Schneider from one source of cash -- by ringing up Schneider's credit card company and cancelling his account. The magazine Titanic said journalist Bernd Fritz had telephoned the Eurocard company and blocked the account by giving Schneider's name and date of birth." The article explains that Schneider has been on the run for over a month and has filed for bankruptcy. He is under investigation for credit fraud. Asked for identifying information, including Schneider's bank, the journalist picked a bank at random--and was right. The magazine writers now claim that they will try to block credit cards for other fugitives. [Comment by MK: I have been saying for a long time we need PINs for credit cards! I hold no brief for the accused man, but it does seem odd that someone else be able to cancel a person's account. How would you like it if some prankster cancelled _your_ credit/bank/phone/... account with a simple phone call?] Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn ------------------------------ Date: 12 May 94 12:25:13 EDT From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Fragmenting of the News The Washington Post newswire (94.05.11) includes an interesting essay by Michael McKeon entitled, "Fragmenting of the News." The author discusses the declining importance of the mass media for distributing news and the rising importance of electronic communities where opinions are more uniform. <> He writes, "More ominously, they have the ability to deny access to anyone trying to reach them with a message." By this he means that faxes, videos, electronic mail and Internet or other newsgroups put control in the hands of the individual. He calls these non-official communications groups "the stealth medium." He sees these groups as the modern equivalent of the tavern conversations of a different generation. These "virtual communities" exist without geography; they consist of people with similar interests and sometimes with similar views. He worries that the information passing through the stealth medium is unchecked for accuracy. Furthermore, "the character of the information tends to be more emotional and, as a result, more reflective of peoples' true feelings." People tend to flame others when there is no face-to-face contact. And "people are often choosing information delivered by demagogues appealing to fear, anxiety and prejudice through heated rhetoric and distortion." Even worse, in the writer's view, politicians and the mass media are turning into their very own insular virtual community. Politicians and government officials speak to each other through the media but are losing their audience outside the Beltway. Politicians, he argues, must learn to address smaller and more specific audiences using the communications channels at hand. <> [Comment by MK: McKeon addresses an important question--how one ensures accuracy in cyberspace. At the moment, there are few mechanisms for generating consequences for defamatory, inaccurate or harmful "speech" in cyberspace. We don't even have universal mechanisms for identification, authentication and non-repudiation. I'm glad to see a mainstream non-technoid writer raising these points in the mainstream media. Naturally, I had to send it to my virtual community for discussion. ] Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn ------------------------------ Date: 12 May 94 12:25:02 EDT From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Software piracy vexes industry United Press International newswire (94.05.11 @ 01:46 EDST) reports on an interview with Business Software Alliance President Robert Holleyman during his visit to Microsoft offices in Redmond, WA. <> Writer STUART GLASCOCK's key points: o MS would be 4 times larger were it not for counterfeit software. o Total losses (not per year) to software thieves by US software companies alone exceed $12 billion. o Holleyman said, "Software piracy continues to plague the industry, stifling motivation, destroying incentives for creating new programs, and impeding growth. Strong copyright laws and enforcement measures are critical to enhance the legitimate market for software." o Other estimated annual losses due to software theft: Europe $4.9 billion Asia $3.9 billion US & Canada $2.4 billion Africa & MidEast $0.7 billion Latin America $0.8 billion Japan $1.9 billion o BSA represents the leading U.S. software companies. BSA members are Aldus Corp., Apple Computers Inc., Autodesk Inc., Computer Associates, Intergraph Corp., Lotus Development Corp., Microsoft Corp., Novell Inc., WordPerfect Corp. o "Untold numbers of U.S. jobs are lost to piracy," said Ann Woodliff, associate general counsel for Aldus Corp. "The numbers are staggering," Woodliff said. "It's difficult to put a number around it. Our piracy losses are over 40 million worldwide." o "BSA operates 20 hotlines around the world for callers seeking information about piracy or to report suspected incidents of software theft. Nearly 250 per day are received on these lines, the BSA claims. The number in the United States is 800-688-2721." <> [MK comment: I wish we could convince the criminal-hacker, "Information Wants to be Free" gang that encouraging software theft harms _people_ working in the software industry. I think everyone who works in the software field should be supporting or participating in local programs to reach schoolchildren and their parents and explain why stealing software is a Bad Thing. I've recently been asked to speak at a local school and am working with my synagogue to introduce a discussion of the morality of cyberspace to our community. Already, a friend has been so moved by my arguments that he has had discussions with his teenaged sons and has thrown out years of stolen software. When he was offered a stolen copy of a package last week, he turned it down for the first time in his life and said, "If I need it, I'll buy it." He told me he is getting used to the idea but feels good about it. "I realized that I was setting a terrible example for my children."] Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn ------------------------------ Date: Thu, 12 May 1994 11:49:04 +0000 From: R.J.Stroud@newcastle.ac.uk (Robert Stroud) Subject: Ultra-high dependability and the Channel Tunnel [Sent to RISKS courtesy of John Rushby . PGN] >From an article by William Hartston, *Independent on Sunday*, 8th May 1994, p.21 (numbers column) A major accident in the Channel Tunnel resulting in 70 or more deaths will happen once in 100,000 years, according to a report by Eurotunnel. Impressive, but how was it calculated? Give or take a few millenia, 100,000 years is the time homo sapiens has been around; 10,000 years ago, you could walk from England to France without getting your feet wet. So how did Eurotunnel look 100,000 years into the future? It began with statistics from 1984-90, which showed a total of 313 people killed in railway accidents in Britain, including 99 at stations. With 268 billion passenger kilometres traveled, simple arithmetic yields figures of 0.08 fatalities per 100 million passenger kilometres plus 0.95 fatalities per 100 million passenger journeys (for those killed at stations). These figures, and their French equivalents, were then combined and applied to the tunnel, as though it were a randomly selected 50km stretch of track, with a station at each end. The figure may then be modified by the decreased likelihood of anyone throwing himself in front of a moving train under the Channel. Fires and derailments, however, (estimated at 4.4 per cent and 18.5 per cent respectively of the "total system risk") are likely to have more serious consequences, which are, in turn, balanced by more stringent safety procedures. Eurotunnel concludes: 'The Channel Tunnel represents a significant advance in railway safety' which may be true. But for all the precision, it is little more than informed guesswork: 100,000 years is a long time on a train line. The Titanic was unsinkable. Has Eurotunnel overlooked an iceberg too?" [I believe Eurotunnel is planning for 10 trains/hour. I think that makes one accident every 100,000 years a 10 ^ -10 claim.. I also heard something about an independent report that had been suppressed that argued that the 10 trains/hour figure was unsustainable taking into account factors such as gradients, length and weight of trains, time to accelerate from stations, etc. Robert Stroud] ------------------------------ Date: Wed, 11 May 94 14:18 EDT From: Amy_McNulty@vos.stratus.com Subject: Re: Future of US health care? In RISKS-16.04, Mark Stalzer (stalzer@macaw.hrl.hac.com) wrote about his HMO doctor's deliberate "misdiagnosis" of his baby daughter's rash as lupus, in order to get past the HMO restrictions for referring her to a specialist. He was understandably quite upset at having received notification of this diagnosis in the mail, without any previous phone call or explanation from the doctor or other HMO personnel. In addition to the ridiculousness of the HMO doctor having to play games like this just to refer a patient to a specialist that the doctor feels the patient needs to see, there's another big risk in this story. In this age of nation-wide computer databases like the Medical Information Bureau, this little girl (and other people like her who were similarly "misdiagnosed" by the HMO doctors) may now be listed somewhere in some database as having a serious, pre-existing disease -- which could cause her to be unjustly rejected sometime next century when she applies for life insurance, medical insurance, a physically demanding job, college, or who knows what else. I won't try to address whether this kind of database is fair or just even when the information it contains is *accurate*, but it should be obvious to RISKS readers that in this case (and many others) it could also contain inaccurate, very damaging information. -- Amy McNulty (amy_mcnulty@vos.stratus.com) ------------------------------ Date: Wed, 11 May 1994 16:46:53 -0500 (EDT) From: David Wittenberg Subject: Re: China Air A300 Crash > The root cause of this crash seems to be a confused co-pilot. I think you're being much too harsh on the copilot. He was trying to fly the plane in a standard way, and the plane's auto-pilot did something inexplicable. While perhaps the copilot could have responded better (but note several other odd auto-pilot actions later), I would have to say the root cause was the "go-around mode for unknown reasons". Since people don't always diagnose unexpected behaviour correctly, it is important to decrease the chances of their being confronted with some unexpected behaviour in a time or place with little margin for error. The question one has to ask about the rather sophisticated auto-pilots now in use is not "are they perfect?" We know that they aren't. But, "How often do they fail, and can pilots reasonably be expected to recover from the failures?" By comparing the dangers of the new technology with the dangers of the old technology, we can make an intelligent choice. Unfortunately, the vendors try to convince us that their technology is perfect, which is clearly false. --David Wittenberg dkw@cs.brandeis.edu ------------------------------ Date: Wed, 11 May 1994 13:37:23 -0700 From: Mark Seecof PSD x77605 Subject: Re: Copyright/patent owners: quick correction I won't name names, but another RISKS contributor suggested that copyright owners or patent holders "MUST" license to all on reasonable terms. That is not true. In general patents or copyrights may be licensed on any terms the owner can get and the owner may pick and choose licensees at will. The exceptions are few, and are related to antitrust issues that do not apply to 99.99% of situations. Some (other than the U.S.) countries have mandatory licensing of various kinds of patents and copyrights (e.g., mandatory licensing of educational textbook copyrights in India), but again, with a few exceptions, the U.S. doesn't work that way. And for other pedants like me: I'm not gonna launch into a discussion of "fair use," music-performance situations, copyright collectives, weapon patents, and other stuff which would explain some of the "exceptions" to the general rule I've alluded to. Think about it. What competitive advantage would a patent confer if you had to license it to anyone? Ditto copyrights. The whole point of such rights is to limit the people who can exploit a certain work. Mark Seecof Publishing Systems Dept. Los Angeles Times ------------------------------ Date: Wed, 11 May 94 14:22:21 PDT From: Ry Jones Subject: Amusing computer-related anecdote about local cable service TCI Cablevison of Washington often has a similar display with a Guru Error (Amiga) for days on end on the Public Info channels. Also, Cablevision of Terre Haute, IN used to have a Apple ][+ that would bomb out and draw random lines on the PI channel. Terre Haute First National Bank built a new building complete with 6 huge automated computer displays (light-bulb type) and they often got out of sync, triggering an alarm that would display a very distinct Commodore Basic prompt on all six signs all night. ------------------------------ Date: Thu, 12 May 1994 16:54:23 EDT From: WJCS75A@prodigy.com (PAUL N HRISKO) Subject: Amusing anecdote about local cable svc. (Long, RISKS-16.05) long-morrow@cs.yale.edu (H Morrow Long) writes about the error he noticed on his local cable channel recently. Our local cable system and a couple of the surrounding ones use Commodore Amigas for such things as the on-line cable guide (The Preview Guide), local programming information screens, etc... My guess is that there is specialized software available to the cable operator from whatever company broadcasts The Preview Guide which is customizable by region, content or whatever (ad packages come to mind). A few years ago you could usually look forward to seeing the dreaded Amiga 'Guru Meditation Error' plastered on your cable guide screen whenever there was a big storm or over a long holiday weekend. It was amusing at first, but it soon became tiresome. Since it hasn't happened in the past couple of years I'm assuming they've invested in a battery backup or better equipment. One risk for them: Since Commodore has gone belly-up, what's going to happen to their equipment when it dies. Will they be relegated to searching the orphaned-computer parts bin at their local used computer store? Paul ------------------------------ Date: Wed, 11 May 1994 12:14:25 +22321159 (EDT) From: Ed Ravin Subject: Re: 11-digit ZIP code The existing 9 digit ZIP code already provides a path to your door -- in most cases, it maps out to either an individual house, four or five houses, apartment building, or cluster of floors in an apartment building. So there's no new RISK with the 11 digit code -- as a matter of fact, it's already in use on some barcoded mail (but the 11 digit ZIP is only used in the barcode, so you haven't noticed it yet). The RISK is that zipcode bloat makes addressing mail more and more complicated and error-prone for humans, or that adding extra digits to the ZIP code is being touted instead of making better use of the existing digits to make things easier for the bureaucrats in the Post Office. Ed Ravin, Prodigy Services Company, 445 Hamilton Avenue White Plains, NY 10601 +1 914 448 4737 elr@wp.prodigy.com [Similar comments were received from PMDebenham@email.meto.govt.uk, who noted Britain's system is often unique to 10 or 20 households, grayjw , who noted the use of the first few digits to determine insurance rates, Chuck Weinstock , Frederick Wheeler , marty@beta.lanl.gov (Martin G. Halvorson), msb@sq.sq.com (Mark Brader), who wondered about the (non)difference between giving out a unique address and a unique ZIP, and brown@wi.extrel.com (Vidiot), who noted that the U.S. Postal Service is already using the 11 digits. PGN] ------------------------------ Date: 9 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.06 ************************ 17-May-94 16:09:49-GMT,31265;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04523; Tue, 17 May 94 12:09:43 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04109; Tue, 17 May 94 12:09:20 EDT Received: by chiron.csl.sri.com id AA18288 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Tue, 17 May 94 08:58:00 -0700 From: RISKS Forum Sender: RISKS Forum Date: Tue, 17 May 94 8:57:58 PDT Subject: RISKS DIGEST 16.07 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Tuesday 17 May 1994 Volume 16 : Issue 07 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Crossover of Diagnosis and Procedure Code creates risk (Paul Stoufflet) The Italian Crackdown? (Fabrizio Sala via Stanton McCandlish) Umass/Amherst Suffers From Week-long Service Degradation (Randy Sailer via Jonathan Welch and Sullivan) More on the A300 crash at Nagoya on 26 April 1994 (Peter Ladkin) Palm-reading and immigration (John Oram) Computer-based Notice Boards and Emergency Information (John R. Gersh) Re: Killers sue over phone taps (Adam Shostack) Revision to the Secure Hash Standard (NIST message via Paul Carl Kocher) Automated address changes (Linus Sherrill) Re: Tandem and California DMV (Scott Hazen Mueller) Tracking (Phil Agre) Secret... not so secret [NYNEX PINs] (Alan Wexelblat) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Mon, 16 May 1994 15:23:49 +0000 From: pstouffl@dsg.harvard.edu (Paul Stoufflet) Subject: Crossover of Diagnosis and Procedure Code creates risk I work at a local HMO, Harvard Community Health Plan, on evenings and weekends. When we see patients, we get a printout of the recent visits by those patients, along with diagnoses, major and minor problems, medications, etc. HCHP uses a 4 character code for most of these, consisting of a letter followed by 3 numbers (for example, O991 is a headache). However, the same code can mean different things in different areas. I saw one chart that had a diagnosis of Chronic Lymphocytic Leukemia, which is odd as an isolated finding in a young adult. Curious as to how this devastating diagnosis got on this persons chart, I did some looking, and finally found that the same code was a procedure code for the administration of a particular vaccine, but it had been cast as a diagnosis instead. I alerted the patient (and medical records) to the problem, since otherwise I could see this person being denied life insurance in the future. Obviously, identical codes should not mean different things in different fields. Paul Stoufflet, Decision Systems Group, Brigham and Women's Hospital 75 Francis Street, Boston, MA 02115 pstouffl@dsg.harvard.edu (617) 732-7746 ------------------------------ Date: Mon, 16 May 1994 13:03:15 -0400 (EDT) From: Stanton McCandlish Subject: The Italian Crackdown? (fwd) [notes in brackets are mine. - mech@eff.org] Forwarded message: Date: Mon, 16 May 1994 12:29:14 +0200 (MET DST) From: Fabrizio Sala Subject: The Italian Crackdown?? To: BBS-L@SAUPM00.ing.unico.it Cc: eff@eff.org Hello. I'm the Sysop of one of the BBSs in Italy. I'm writing this message in this list to inform you, the BBS community, of what is going on in Italy. Some days ago, starting from Pesaro (Italy), our Police started a large perquisition through [inquisition against] many Amatorial [amateur] BBSs, mostly connected to the main networks (One for all: Fidonet... but also PeaceNet and many others) They're getting everything they can find: computers, monitors, drives, hard disks, floppy, cdrom, streamer tapes ... everything, without looking if they are or not in any way "illegal" ... Generally, every network in Italy is now full of holes... and many of us lost everything "in the name of the anti-piracy"... Nobody of us is doing anything in any way illegal, but they are still getting everything... They got more than 50 BBS and Police's work is still going on... I hope that everyone diffuses this message ... or in any way tells everybody what's going on ... ...and if you have any way to help us...please do it! We made our best to make the Italian telecommunication scene working... they are killing us! See you later... if they don't get me! ______ end fwd ______ Stanton McCandlish * mech@eff.org * Electronic Frontier Found. OnlineActivist ------------------------------ Date: Mon, 16 May 94 20:56:51 -0500 From: sullivan@geom.umn.edu Subject: Umass/Amherst Suffers From Week-long Service Degradation Date: Mon, 16 May 1994 09:09:11 -0500 From: Jonathan_Welch Subject: Umass/Amherst Suffers From Week-long Service Degradation Newsgroups: comp.dcom.telecom X-Telecom-Digest: Volume 14, Issue 229, Message 4 of 14 After slightly over a week of unreliable phone service things returned to normal and the following appeared in the May 13th edition of "The Campus Chronicle". Jonathan Welch VAX Systems Manager Umass/Amherst JHWELCH@ecs.umass.edu - - - Telephone system returned to normal As you know, the University had a major problem with the campus telephone system which began last Monday, May 2. The symptoms of the problem included calls being cut off, static, a "fast busy" tone when calling on campus and telephones without dial tone. The symptoms were sporadic and fairly random for both academic/administrative telephones and residential telephones. As soon as the problem started, Ericsson, the manufacturer and maintainer of the telephone system, responded. Ericsson staff worked straight through from Monday morning to late Thursday evening to diagnose and remedy the problem. In addition to the normal three on-site technicians, Ericsson brought in staff from their regional headquarters in Northboro, and flew in a high level technician/ system programmer from the Technical Assistance Center in Cypress, Calif. They also had programmers in Cypress and Sweden working remotely to stabilize the system and to determine the cause of the problem. The problem with the system resulted from a unique set of circumstances involving software parameters, system clocking and a normal maintenance procedure performed on the system. The problem was exacerbated by the increases of load on the telephone system we have experienced this year. The campus telephone system is a complex, distributed computer. Such systems are designed with a great deal of redundancy and can self-correct for many faults. Once the problem occurred, parts of the system were continually trying to reset themselves. In this instance, the complexity of the system and its attempts at self-correction made it difficult to trace the problem and stabilize the system. By Wednesday afternoon, Ericsson had made substantial progress in correcting the problem. They made a configuration adjustment in the system and implemented a slight but important programming change in the software. This adjustment, while straightforward, was difficult to install on the system because of the heavy call volume on campus and the size of the campus system (18,000 lines on 119 system modules). What Ericsson accomplished is analogous to fixing an electrical problem in a car traveling down the highway at 50 miles per hour. The parameter they adjusted did not initiate the problem, but the change allowed the system to return to normal operations. By early Thursday morning in the residence halls and noon on Thursday in the academic/administrative area of campus, service had considerably improved. Except for a brief interruption of service while circuits were being tested, calls in progress were no longer interrupted by static or cut off. There may have been some problems completing a call or placing long distance calls while work was in progress. However, in general TelCom was quite successful at assisting individuals in making their long distance calls. Ericsson has made adjustments in the system configuration, system clocking and maintenance procedures to ensure that this problem will not recur. I realize the telephone service problems last week were very frustrating for everyone. Telephone service is an important part of our daily lives and any interruptions or degradations in service are a very serious problem. I truly appreciate the patience of the campus community while we struggled to deal wilh the problem. We in TelCom, as well as the Ericsson staff, were even more frustrated (if that is possible) at not being able to get the problem resolved quickly. We apologize for the difficulties and will work closely with Ericsson to prevent this problem from occurring again. Randy Sailer, director, Telecommunication Services ------------------------------ Date: Fri, 13 May 1994 21:24:17 +0200 From: Peter Ladkin Subject: More on the A300 crash at Nagoya on 26 April 1994 On 26 April, a China Airlines A300-600 crashed on landing at Nagoya airport, killing 264 people. The crew had announced they were `going around' (aborting the approach and gaining altitude to come back for another landing attempt), but continued the approach. Near the ground, the aircraft pitched up (raised its nose in the air), stalled, and `hit the ground at a high rate of descent, tail-first and completely stalled'. (Flight International, 11-17 May 94, p5). Part of what is known so far is that the Flight Director or FD (a form of autopilot) was in `go-around mode', and the co-pilot was physically trying to counteract the guidance of the FD, specifically against published procedures (FI, op. cit.). The FD, trying to fly up with the co-pilot commanding fly-down on the elevator, counteracts with nose-up trim (the horizontal stabilizer at the tail is repositioned by the pilot or by the FD so as to maintain a desired attitude of the aircraft, climbing, cruising, or descending, simply by aerodynamic equilibrium. This is called `trim'). At 700 ft, both autopilots are disconnected. The aircraft pitches up steeply because full nose-up trim has been applied (this cannot be overcome by control-column input alone -- pilots must readjust trim). At 540 ft, the anti-stall system triggers full power, which gives additional pitch-up moment, and the aircraft enters a very steep climb with a pitch of 36 degrees. The pilots fail to readjust trim. At 980 ft, a pilot selects flaps-up to go-around setting causing a pitch-up to 52 degrees, and a speed decay from 124kt (slow) to 78kt (disastrously slow) (FI, op.cit.) To give an idea, light planes stall (their wing ceases to provide lift) when the angle of the wing to the `relative wind' (the airflow vector considered relative to the wing of the aircraft) becomes roughly 15 degrees. Transport aircraft are similar, but I don't know the stall angle of the A300-600 wing in landing configuration. The Japanese Transport Ministry's Aircraft Accident Investigation Committee is also looking into an apparent loss of all electrical power moments before the crash. The chairman, Manabu Matsumoto, has `no recollection of a case like this, an apparent failure of all power'. (International Herald Tribune, 11 May 94 p2). Features of this accident of potential interest to RISKS readers at this point are (a) the preliminary confusion of the crew about which control mode was selected on the autopilot; (b) the full nose-up trim consequence of the interaction between the co-pilot and the FD; (c) the autopilot triggering full-power and therefore a high nose-up moment when the nose was already high; (d) the apparent failure of all power. One should be cautious if trying to `second guess' the accident investigation. Airplanes such as this are meant to be flown a certain way, in which pilots are thoroughly trained. Pilots are generally legally required to hold to those procedures except in case of emergency. Peter Ladkin ------------------------------ Date: Sat, 14 May 1994 17:53:38 -0800 From: oramy92@halcyon.com (John Oram) Subject: Palm-reading and immigration In the May 12 Financial Times of Canada, there is an article entitled "How palm-reading can speed your way into the U.S." =-=-=-=-=-=-=-= Put your hand up if you've had it with the interminable lineups to pass through airport immigration checkpoints when travelling to the United States. That upraised hand could be your ticket to zipping right through. The U.S. Immigration and Naturalization Service (INS) is testing a new system that turns your hand into the only piece of identification you need to bypass immigration officials ans skip right through customs, cutting up to 45 minutes off the procedure for heading south. Called the INS Passenger Accelerated Service System (INSPASS), it works like this: a three-dimensional image of your hand is electronically recorded on a white, plastic, wallet-sized card. You run the card through a scanner, place your palm onto an electronic reader and, as long as your hand and the card match, you're issued a computer-generated receipt that opens a gate arm, sending you past immigration officials to custom inspection. [Summarizing the next few paragraphs, INPASS is being tested at three sites: Pearson (Toronto), JFK, and Newark. The article goes on to explain registration at INS offices, which takes about 10 minutes and is free during the indefinite test period. Open to citizens of Canada, Bermuda, Japan, New Zealand, most of Europe and the U.S., but have to make at least three business trips per year to qualify.] Concerned about privacy? Sally Jackson, director of public affairs for the Offices of the Information and Privacy Canada, says you shouldn't be. The only people participating are those who consent to putting their hand impression on the card; besides, no other record of the hand image is kept. So far, 26,502 people have signed up for INSPASS, including 2,764 Canadians. More people, no doubt, will follow when they realize how, uhhh, handy the system is. =-=-=-=-=-=-=-= What happens if the systems does not recognize your hand? I'm curious as to the recognition rate. For example, if you get married after registering, will a ring throw the system for a loop? Also, I find it interesting that the image is kept on the card only. Will the INS keep a record of your travels? (Or do they already?) John Oram oramy92@halcyon.com Victoria, BC Canada ------------------------------ Date: Mon, 16 May 1994 10:29:07 -0400 From: John_Gersh@aplmail.jhuapl.edu (John R. Gersh) Subject: Computer-based Notice Boards and Emergency Information RISKS-16.05 and -16.06 included discussion of problems with cable-TV notice-generation systems crashing and leaving cryptic or amusing error messages for all to see ("Amusing computer-related anecdote about local cable service," Long, Jones, Hrisko). Failures and usability problems with such computer-driven notice boards can sometimes have more serious consequences: My father lives in a retirement community in a high-rise building. While I was visiting there recently the building's fire alarm went off. My father immediately said, "Turn on the TV -- channel 8." The building's cable system includes a local notice-board channel that typically shows screens rotating through the dining room menu, daily events, and so forth. It's also used for emergency notices. Sure enough, within a few seconds, the notice channel stopped showing the lunch menu and switched to something like: The fire is on the 75th floor. Please follow the directions of your floor warden. (Evacuation procedures apparently differ according to location above or below the fire floor.) The problem with this notice is that the building has only 24 floors! Evidently someone in the management office soon realized the error. Everyone in the building was then treated to several minutes of cursor-dancing around the screen, as that person tried, unsuccessfully, to change the notice. A cursor would move around the screen, closing in on but failing to select the floor number; the screen would switch to a Master Menu Page and back to the fire notice again; more vain attempts would be made to select the floor number; back to the Master Menu; and so on. Finally things remained static for several minutes. "Aha," said I, they've gone to get The Expert." Sure enough, when screen activity resumed the floor number was immediately changed to a reasonable one, just in time for the all-clear. (It was a false alarm, as are most of the alarms in that building, but that's a different RISK.) Electronic notice boards in public or semi-public settings can be used for things other than routine bulletin-board postings. If they're going to be used for getting across emergency information, then the same requirements for usability under stress and that we'd expect for other safety-critical applications apply to them, too. We'd also expect that users of such systems ought to be thoroughly trained for emergencies, but system design ought to allow for situations where a not-so-thoroughly-trained user is all that's available. John R. Gersh (John_Gersh@aplmail.jhuapl.edu) The Johns Hopkins University Applied Physics Laboratory ------------------------------ Date: Mon, 16 May 1994 15:10:55 -0400 From: Adam Shostack Subject: Re: Killers sue over phone taps (Kabay, RISKS-16.06) Mich Kabay complains about criminals wanting their 4th amendment rights preserved. If the state wants to wiretap their conversations, odds are good that a judge could be convinced of probable cause. The fact is these wiretaps are warrantless, and should be replaced by wiretaps authorized by warrant. I've also yet to hear of criminals (outside of Congress) who want to deny others rights they claim for themselves. There are several clear risks in denying someone all of their rights because of a conviction. They include false convictions, a growing disregard for the Constitution, and the moral problems of punishments being chosen by prison officials/cops, rather than the judicial system. Adam Shostack adam@bwh.harvard.edu ------------------------------ Date: Mon, 16 May 1994 02:48:15 -0700 From: Paul Carl Kocher Subject: Revision to the Secure Hash Standard The following notice was released by NIST a couple weeks ago, but doesn't seem to have made it to RISKS yet. No additional information is available regarding the nature of the "minor flaw." I called NIST and the NSA when the announcement first came out, but was told that details of the problem were confidential. They also didn't know when a revised version would be available. It will be very interesting to see whether non-NSA cryptographers find the problem... Paul Kocher, Data security consultant kocherp@leland.stanford.edu (The following bulletin is available via anonymous FTP at csrc.ncsl.nist.gov as pub/nistnews/sec_hash.txt) --- Begin Included Message --- April 22, 1994 Contact: Anne Enright Shepherd (301) 975-4858 MEDIA ADVISORY NIST ANNOUNCES TECHNICAL CORRECTION TO SECURE HASH STANDARD The National Institute of Standards and Technology today announced it will initiate a technical modification to a computer security standard used to support the authentication of electronic messages. The revision will correct a minor flaw that government mathematicians discovered in a formula that underlies the standard. The Secure Hash Standard, adopted as a federal information processing standard (FIPS 180) in May 1993, can be used for computing a digital signature and remains a highly secure way to ensure the integrity and authenticity of data used in electronic mail, electronic funds transfer, software distribution and data storage applications. NIST expects that products implementing the current standard can be used until the technical correction becomes effective. Researchers at the National Security Agency, who developed the formula and discovered the flaw in a continuing evaluation process, now believe that although the formula in FIPS 180 is less secure than originally thought, it is still extremely reliable as a technical computer security mechanism. The discovery of this flaw indicates the value of continued research on existing and new standards. The Secure Hash Standard specifies a secure hash algorithm for computing a condensed representation of a message or data file. This 160-bit condensed message "digest" represents the original message and can be used in computing a digital signature to authenticate the integrity of the message. It is highly probable that any change to the message after it has been signed will result in a different message digest, and the recipient will not be able to verify the signature. Signing the message digest rather than the whole message usually improves the efficiency of the digital signature process. It is very highly improbable that today's computation equipment can figure out any message that corresponds to a given message digest. The standard applies to agencies of the federal government for protecting unclassified information when a secure hash algorithm is required. Private and commercial organizations have been encouraged to use this standard on a voluntary basis. The SHS was designed to be used with the proposed Digital Signature Standard, which is based on the digital signature algorithm and has not yet been approved. As a non-regulatory agency of the Commerce Department's Technology Administration, NIST promotes U.S. economic growth by working with industry to develop and apply technology, measurements and standards. NIST also is responsible, under the Computer Security Act of 1987, for developing standards and guidelines for the cost-effective protection of unclassified federal computer systems. National Institute of Standards and Technology, Public Affairs Division Admin. A903, Gaithersburg, MD 20899-0001 --- End Included Message --- ------------------------------ Date: Tue, 10 May 94 15:19:40 EDT From: julius!sherrill@sky.com (Linus Sherrill) Subject: Automated address changes Recently I've had a problem with incoming mail to my home address. A few months ago, mail started arriving (late) with just the wrong zip code and sometimes with the wrong town name too. The incorrectly addressed mail was usually magazines and junk mail but when credit card bills started arriving (or not arriving) with the wrong address it was time to investigate. My wife checked at the local post office and they said that this was a problem for the whole zip code; the whole town had been affected. The post office officials had no explanation as to how this might happen. They explained that it our responsibility to correct those who have the wrong address. The more important ones were corrected over the phone, although it was sometimes difficult to convince the operator that we hadn't moved, the address had spontaneously changed. Whatever generated the wrong address is still at work. After getting the mail addressed correctly for a few months, the wrong address would reappear. The post office's solution to this problem is to print bar-coded labels with the correct zip code and stick them to the mail. Mail is now arriving on schedule even with the wrong address. I've all but given up on correcting the wrong addresses. I'm guessing that some address verification service shipped a data base with the wrong zip code for our town. (I wonder how many other towns were affected?) Some mailers just updated the zip code and others trying to get a canonical address used the new (wrong) zip code to determine the town name. ------------------------------ Date: Sat, 14 May 94 21:20 PDT From: scott@zorch.sf-bay.org (Scott Hazen Mueller) Subject: Re: Tandem and California DMV Recently a bit ran in risks about the California DMV computer upgrade fiasco; the original story mentioned Tandem Computers in a poor light. I'd just like to point to a reference on the World-Wide Web to Tandem's official statement on the issue, at . Also, a copy of the California Legislative Analyst's report on the topic is online at ; there is a hyperlink to this latter item from within the first document. Claimer: Tandem is my day job. DisClaimer: I am not an official spokesperson for Tandem; one such is however listed in the dmv.html document. Scott Hazen Mueller scott@zorch.SF-Bay.ORG or (tandem|ub-gate)!zorch!scott [Thanks. The original item was in RISKS-15.80. Actually, the item noted the DMV position that neither the software vendor nor the hardware maker were responsible. Of course, the consulting firm was fired from the job. PGN] ------------------------------ Date: Tue, 5 Apr 1994 15:31:31 -0700 From: Phil Agre Subject: tracking "There is something a little eerie about picking up a car phone and having a voice describe your location to within a few feet on a pleasant if unremarkable street of colonial and tudor-style houses." That's a quote from a second article in the New York Times promoting the Avis project to track the company's rental cars through GPS hardware and wireless communications. The full reference is: Peter Marks, For a few lucky motorists, guidance by satellite, New York Times, 2 April 1994, pages 1, 16. The reporter apparently went for a ride with the system, and was enthralled. No doubt it was a fascinating experience. This article does at least mention privacy concerns, in a parenthetical note, as follows: "On the Nynex computer screens, the cars show up as small dots moving along the roads on the computer maps. Nynex officials say, however, that for the sake of privacy, a car's position will only show up on a screen for the duration of a driver's call to the Project Northstar number." Note that "privacy" only extends to what's presented on the operator's screen. Nothing is said about the more fundamental issue, what records are stored in the computer. Phil Agre, UCSD ------------------------------ Date: Fri, 8 Apr 94 12:16:59 -0400 From: "Alan (Miburi-san) Wexelblat" Subject: Secret... not so secret [EDUPAGE:] > A sweepstakes promotion sponsored by Nynex-owned New York Telephone used > replicas of customers' calling cards, including their secret personal > identification numbers, or PINs. The mailing has caused an uproar among > some of the three million recipients, who worry about unauthorized use of > their calling cards. Nynex has offered to change the PINs of customers who > complain and cover any fraudulent charges. (New York Times 4/7/94 A1) What's wrong with this picture? Well, changing the PINs only of customers who complain is a bad plan -- what if I didn't see the ads and don't know I should change my PIN? Giving out real data (even card #s, let alone PINs) to a 3rd party (the ad agency) is another bad plan. Not treating customer data as secure is a third bad plan; it's especially galling since NYNEX sends out these little reminder cards to customers telling us not to divulge our PIN to anyone. Speaking of galling, how "generous" of them to cover fraudulent charges. As if they didn't already do this. It's a fancy way of saying "we're not going to do anything about this." The thing that particularly strikes me is that it appears NYNEX is, once again, treating this as a special case. This is a particularly annoying RISK we see over and over again, where incidents are treated as aberrations and the symptoms are treated with no thought given to the structural problems which caused them. I have no idea how to counteract this particular RISK, except by target educating the relevant people, assuming we can find them. --Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard Media Lab - Advanced Human Interface Group wex@media.mit.edu 617-258-9168 [Also noted by wb8foz@netcom.com (David Lesher). PGN] ------------------------------ Date: 9 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.07 ************************ 18-May-94 18:00:55-GMT,29000;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24562; Wed, 18 May 94 14:00:53 EDT Received: from [192.12.33.73] by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA23201; Wed, 18 May 94 14:00:44 EDT Received: by chiron.csl.sri.com id AA19940 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Wed, 18 May 94 10:48:42 -0700 From: RISKS Forum Sender: RISKS Forum Date: Wed, 18 May 94 10:48:39 PDT Subject: RISKS DIGEST 16.08 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Weds 18 May 1994 Volume 16 : Issue 08 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Phone system crash at San Jose airport (Tarun Soni) Logging on as root is easy! (Eddy) Computer Crime on Wall Street (Sanford Sherizen) Going by the Book [air accidents] (Richard Johnson) Editor functionality mutates code (Kevin Lentin) UK ATM Spoof (Mich Kabay) The RISKS of complex procedures (Ry Jones) Tactical research (Phil Agre) FIPS to be tied... [hashing hashed, Capstone] (Peter Wayner) Re: INS recordkeeping (Jonathan Corbet) Re: killers sue over phone taps (Robert Morrell Jr.) Re: Secret... not so secret (Tony Harminc) Novel risk of medical records (David Honig) Crossover of Diagnosis and Procedure Code ... (Carl Ellison) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 17 May 1994 15:01:08 -0700 From: tarun@windchime.arc.nasa.gov (Tarun Soni) Subject: Phone system crash at San Jose airport I was travelling from San Jose to San Diego two weeks ago (Fri. evening: 29 April) and showed up at the airport an hour early (Fri. evening rush hour expectations.. ) This is when the fun started: I found that the phone systems in the airport were not working. The supposed reason was a pacific gas and electric problem (that's the local utilities company). The immediate effects included: a> air traffic control computers were no longer able to talk to each other? (Southwest airlines assured people that they would go back to the technology of the 60's and there was no real danger) b> flights were delayed. c> reservation computers were down and out.. - the fact that I had a reservation and for certain flight was known only to me and the airline personnel took me on trust. - the fare amount was not known to the airline personnel in general, and they had to confer with their manager for some of the fares .. (in my case they accepted the figure I told them ) - The computers could not talk to the central database and this led to my being given a one way ticket while I really wanted a round trip. (This led to my waiting in line for another hour in San Diego on my return trip.. ) d> credit card approvals were no longer possible.. they took me on trust. e> oh, the most comic of them all, flights were delayed and a number of people (I have to admit, I fell for it too !) were seen trying to call up their receiving parties in other parts of the country (and slowly realizing that the phone were not working !) I assume there were other effects which i was not able to witness. and to use a phrase I see on the digest fairly often : The risks are obvious. Tarun Soni ------------------------------ Date: Wed, 18 May 94 15:29:19 BST From: eddy Subject: Logging on as root is easy! This _really_ alarmed me; but this is Un*x, so I guess it could just be a well-known `feature' ... We mount a couple of disks from a neighbouring department's machine, mbfs.bio. They had some emergency maintenance to do (well I assume it was an emergency -- taking the machine down with < a minute's warning is pretty d*mn unsound otherwise) so did a shutdown. When I got the notification for this, I set about unmounting the disks asap: eddy@eddy> su Password: NFS server mbfs.bio not responding still trying but never got as far as delivering a password because of the downtime. So my machine hung and there was nothing I could do about it. Perfectly normal hassle, irritating but no surprises. So I go shopping and come back to find mbfs.bio is back up and running ... however, my `su' has _succeeded_ despite the fact that I never typed the password: NFS server mbfs.bio ok eddy.gen.cam.ac.uk# whoami root Nice secure operating system this. Eddy ------------------------------ Date: Sat, 14 May 94 11:40 EST From: Sanford Sherizen <0003965782@mcimail.com> Subject: Computer Crime on Wall Street I'm surprised that no one has commented on the case of Joseph Jett, a managing director/chief government bond trader at Kidder Peabody, who allegedly created an estimated $350 million in phantom profits, resulting in his 1993 performance-based bonus of $9 million. Experts quoted in in recent articles indicate that he must have made something like $35 BILLION in false trades without anyone asking questions or the controls raising alarms. At this time, lots of blaming is going on within Kidder Peabody as well as GE, the corporate parent of Kidder. Is this a computer crime? It seems to me that this manipulation could only have been accomplished through extensive computer manipulation by Jett and possibly by others. This may turn out to be one of the largest computer crime losses to date. It illustrates several points. 1. The growing problem of high level executives who are not being adequately or in many cases even partially supervised. They are in position to commit crime by instructing others to enter a transaction and then destroying evidence of their instructions or the transaction. This is a growth area for computer crime. Not a hacker in sight for this case. 2. Audit and accounting controls are often insufficient for large financial systems and inadequate review requirements result in many of crimes being overlooked, buried, or disregarded. Wait until companies sign onto the Information Superhighway! 3. Computer crimes and financial misdeeds get some (but inadequate) coverage in the business press but very little in the material read by other relevant people, such as computer professionals. If this is a $9 million crime (his false profits), a $350 million crime (the company's false profits) or maybe an even larger loss (the company's negative reputation and possible financial penalties due to legal proceeding), then how large of a loss must be reached before a crisis is indicated? Even the Volkswagen case of several years ago, where an employee working in foreign currency transactions used his access to computers to cause the loss of the equivalent of $US 256 million, didn't raise many eyebrows in the business or computing communities. If around a quarter of a billion dollar loss doesn't indicate that computer crime is serious, then what figure is enough to decide that the controls and the laws are inadequate to meet the technological challenges? Finally, anyone want to comment on the following statement of GE Chairman John F. Welch, Jr.? "It's a pity that this ever happened. (Jett) could have made $2 or $3 million honestly." Sanford Sherizen, Data Security Systems, Natick, MA ------------------------------ Date: Fri, 13 May 1994 08:11:26 -0700 (PDT) From: rdj@plaza.ds.adp.com (Richard Johnson) Subject: Going by the Book The 9 May 1994 "Aviation Week" (pp. 46-51) has an article on Controlled Flight into Terrain (CFIT) -- when controllers or procedures fly you into the ground short of the runway, usually in mountainous and/or poor weather conditions. The article includes the following data (but given as a bar chart, and oriented the other way). Worldwide Airline Fatalities Classified by Type of Accident 1988 - 1993 Source: Boeing (for aircraft > 60,000-pound takeoff weight) (Excludes sabotage & military action) Category # accidents # fatalities ---------------------------------------------------------- Controlled Flight into Terrain 28 1883 Loss of Control (airplane caused) 10 460 Loss of Control (crew caused) 14 357 Airframe 4 278 Mid-air Collision 1 157 Ice/snow 4 134 Fuel exhaustion 5 107 Loss of Control 2 79 Runway Incursion 3 43 Other 5 15 76 total accidents, 3513 fatalities. (How do you have *1* mid-air? They must be counting accidents, not aircraft involved.) I'm dismayed by the size of the category called "Loss of Control (airplane caused)", especially since they differentiated between that and airframe. This implies (to me at least) software errors. I can't help but remember all the discussions we've had in RISKS about poorly-designed cockpit management and fly-by-wire systems. Rather than pointing out the obvious, as they do in the article, I chose to rework the table a little, and make the bins wider. Category Totals ---------------------------------------------------------- Procedural CFIT-28/1883, Mid-air-1/157, runway-3/43 32/2083 Aircraft LoC (plane)-10/460, airframe-4/278 14/738 Crew LoC (crew)-14/357, fuel-5/107 19/464 Weather Ice/Snow-4/134, LoC (WX)-2/79 6/213 Other ???-5/15 5/15 One the one hand, if the flight crews blindly follow procedures, they risk CFIT. On the other hand, if they don't follow procedures, or forget things, they run out of fuel or into adverse weather or onto an active runway. We should also remember that, unlike private pilots, these transport pilots are expected to fly into and through moderate to severe weather all the time. The risks? We can all learn from this, no matter what we're working on. We need to examine all of our procedures with an eye to long-term consequences when put into actual practice. The human tends to learn, then memorize, and eventually internalize (habituate) routine behavior. Sometimes this routine can be fatal. I'm not sure how we make procedures good enough to be complete and quick, yet flexible enough to not grow boring. It's not just procedures in use on the aircraft, either. Consider our own motivation in whatever job we have. How many of those airframe failures could have been prevented on the shop floor? How many of those software failures could have prevented before the first compile? We who manipulate symbols all day don't often get the opportunity to "feel" the true meaning or impact of our work. Finding a way to do so might produce both better products and more satisfied programmers. Richard Johnson (rdj@plaza.ds.adp.com) (richard@agora.rdrop.com) ------------------------------ Date: Wed, 18 May 94 11:57:10 +1000 From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin) Subject: Editor functionality mutates code The following story was related to me by a colleague of mine this morning. She was editing some C source using a 'vi' compatible editor called 'vim'. vim is a vi clone that adds some very useful features to the editor. Many of us use it in place of vi. On this occasion she was logged in to a Sparcstation via a terminal annex and modem from home. She observed that numbers in here code kept on changing. Specifically, decreasing by one for no apparent reason. A screen redraw might change: x = 1; into x = 0; and then x = -1; It turns out that vim has a nifty feature whereby CTRL-A and CTRL-S add 1 and subtract 1 from a number respectively when in command mode. At the same time, her modem was set up for XON/XOFF flow control and it seems that somehow the CTRL-S's were getting through not only the modem but also through her stty settings which might otherwise have interpreted the CTRL-S as a STOP character. The upshot of all this was that in an attempt to regulate data flow through the modems, the XON/XOFF protocol was actually mutating her source if the cursor was on a number when a CTRL-S came through. The RISKS of this are painfully obvious. Critical code can end up being mutated and having serious effects later on if the changes are undetected. I am reminded of stories about a missing '-' causing a certain NASA mission to fail in decades past. Whether this situation can occur easily or whether it was an unfortunate combination of settings, especially 'stty stop' which I suspect was changed from the normal ^s, I do not know, but I will certainly be verifying all my modem and terminal settings when I get home tonight. Kevin Lentin kevinl@bruce.cs.monash.edu.au ------------------------------ Date: 17 May 94 16:00:20 EDT From: "Mich Kabay [NCSA Sysop]" <75300.3232@CompuServe.COM> Subject: UK ATM Spoof According to the Reuter newswire (via Executive News Service on CompuServe), LONDON, May 16 (Reuter) - Crooks used a stolen cash dispensing machine set up in a fake finance shop to steal 250,000 pounds ($374,400) in a high-tech swindle, a British newspaper said on Monday. The cash dispenser, ripped out of its legitimate location using a mechanical shovel and a fork-lift truck, was installed in a shop in London's Bethnal Green district painted to look like an advice centre for home loans, the Sun tabloid reported." Apparently the stolen ATM simply recorded the card info and PIN of everyone who tried to use it. Total thefts from other cash dispensers amounted to over 240,000 pounds in 6 weeks. The Sun reports that "A man has been charged with conspiracy to defraud...." [MK comment: now consider whether this scam would have been effective if users were issued smart cards for their bank and credit functions. The user approaches the ATM and inserts the smart card. The ATM challenges the smart card (or prints a challenge string on a screen) and the smart card responds with a cryptographic function of its serial number and a seed such as time of day and date (or the user enters the challenge on a membrane keyboard and copies the one-time response from the card's LCD into the keypad). The ATM or banking network validates the response and continues the transactions. Results of setting up a spoof on a stolen ATM: zero.] M. E. Kabay, Ph.D., Dir Educ, Natl Computer Security Assn, Carlisle PA USA ------------------------------ Date: Tue, 17 May 94 16:15:55 PDT From: Ry Jones Subject: The RISKS of complex procedures I bought a lot of money orders at my local branch bank (to pay bills, they're free and clear faster) and watched the teller make them. Here's what goes on: 1) I give her the check. 2) She verifies the funds. 3) She makes the money orders. 4) She hands them to me. 5) She hits the "Hold Funds" button and stamps the check "HELD" in red ink. 6) Transaction ends. I asked why she waited until she gave me the money orders to hold the funds. She said they do so because the procedure to un-hold funds is very difficult and time consuming, requiring many signatures. Fraud opportunity: 1) Steps 1 and 2 as above. 2) While she is in steps 3 & 4, I use my cell phone to signal my accomplice. 3) My accomplice withdraws the cash from an ATM. 4) She does step 4. I run out (or hand off the money orders). Whatever. 5) She cannot HOLD the funds, but I have the money orders. My accomplice has the cash. RISKS to this fraud? 1) They know me by name at my local branch. 2) My account is real. It would need to be enough cash to escape the country, yet be under my maximum daily withdrawal limit ($1000). The maximum value of the funds would be $2000, unless multiple people coordinated multiple simultaneous withdrawals (like the bank personnel wouldn't notice) 3) many others... the cash reward for the risk is too small, but the window of opportunity exists. Ry rjones@halcyon.com ------------------------------ Date: Tue, 17 May 1994 14:04:49 -0700 From: Phil Agre Subject: tactical research The 17 May 1994 Wall Street Journal includes an article, excerpted from a new book (which I have not seen) entitled "Tainted Truth" by Cynthia Crosson, about the practice of "tactical research", the creation of customized policy research as part of public debates. She details the example of computerized life-cycle analysis for cloth versus disposable diapers. As with most computer models, you can get a wide variety of answers depending on the estimates you give for a large number of hard-to-measure quantitative variables. (How many times does a cloth diaper get changed in its lifetime? How often do people use two diapers rather than one?) I have heard many, many anecdotes of computer models being manipulated to give the desired answers; you probably have too. It's certainly not a new phenomenon, having risen to prominence in during the zenith of the systems modeling fad in the 1960's. Crosson's article tries to explain how this manipulation comes about. Are the modelers consciously trying to fool people? Much as I resist that answer, out of an ideological preference for more more complex and systemic kinds of answers, that's basically what she says. Once you start making your living making models whose answers are convenient to certain sorts of people, she says, a sort of treadmill gets going and it's hard to get off. The phenomenon is particularly important in the context of the ongoing US health care debate, in which a blizzard of made-to-order numbers circulates through advertisements and talk show hosts, all of them resting on more assumptions than you could shake a stick at. What's the answer? How about a public education campaign about the concept of sensitivity analysis? The more reputable polling agencies might frequently use loaded questions, but at least they feel obligated to explain that the numbers have a statistical margin of error of +/- 3% or whatever. Likewise, people presenting models should expect to be asked, "what are your input variables, and how sensitive is your answer to the range of plausible values for each?" That's a simple enough question that a fairly large percentage of the population can understand and ask it. It's not adequate, of course, since assumptions can be built into computer models in a wide variety of ways. But I expect that it's sufficient to get rid of the first 90% of the bogus uses of modeling. Phil Agre, UCSD PS Here are some relevant references: Cynthia Crosson, How "tactical research" muddied diaper debate, The Wall Street Journal, 17 May 1994, page B1 (marketing section). Cynthia Crosson, Tainted Truth: The Manipulation of Fact in America, New York: Simon and Schuster, 1994. Kenneth L. Kraemer, Siegfried Dickhoven, Susan Fallows Tierney, and John Leslie King, Datawars: The Politics of Modeling in Federal Policymaking, New York: Columbia University Press, 1987. Ida R. Hoos, Systems Analysis in Public Policy: A Critique, revised edition, Berkeley: University of California Press, 1983. ------------------------------ Date: Wed, 18 May 1994 10:39:28 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: FIPS to be tied... [hashing, Capstone] There are two interesting lessons hidden in the fact that the NSA discovered some flaw in the Secure Hash Algorithm (RISKS-16.07) and announced that they were working on a fix: *) They're become slightly more open-- if only to authentication technology. *) This proves the RISK of using a hardware based standard. Apparently there is a whole batch of now obsolete CAPSTONE chips sitting in a warehouse. Capstone was supposed to be Clipper + authentication, but now it will have to wait for a new version. Imagine if Capstone was widely distributed when the error was found? Would you replace your phone/modem/PCMCIA card is you had bought a version that was made obsolete by progress? How long would it take the country to recover from such a problem? What if the standard was blown wide-open? ------------------------------ Date: Tue, 17 May 1994 11:01:16 -0600 From: Jonathan Corbet Subject: Re: INS recordkeeping John Oram finishes an interesting submission about the installation of "palm readers" at the border with: > Also, I find it interesting that the image is kept on the card only. Will > the INS keep a record of your travels? (Or do they already?) Anybody who wonders about that need only have gone to Nicaragua in 1985, as I did. My travels take me out of the country a few times a year, so it became immediately apparent that I had made some sort of list when, on scanning my passport, the immigration officer would invariably write the magic code on my entry form that means something like "give this one a hard time." For about 4-5 years (after which I evidently aged off the list for lack of further "infractions") I had to allow a solid three hours of connection time when entering the country so that they could search my bags, count my money, grill me about my life, and so on. I had never been searched before this period; I have never been searched since. But I was searched *every* time in between. Many people who travelled in Central America during that period have much worse stories to tell. As a result of all this, (1) I am not worried about palm readers, since they give the INS no capability that they do not already have, and (2) I have no illusions about the benign nature of government power, even in a relatively free (so far) country such as this. Jonathan Corbet, National Center for Atmospheric Research, Atmospheric Techn. Div. corbet@stout.atd.ucar.edu http://www.atd.ucar.edu/rdp/jmc.html ------------------------------ Date: Tue, 17 May 1994 13:12:14 -0400 (EDT) From: "Robert Morrell Jr." Subject: Re: killers sue over phone taps Adam Shostack, in bemoaning the invasion of convicted killer's privacy said probably the most outrageous thing I have ever seen in the RISKS forum: "I've also yet to hear of criminals who want to deny others rights they claim for themselves" Really? I believe that the right to =life=, =liberty=, and the pursuit of happiness is somewhat well known, and a convicted killer, kidnapper or robber has certainly shown a willingness to deny others those rights.... In our ongoing and totally justifiable drive to insure the integrity of our informational system, I think we should, at least once a day, do a reality check. The RISKS of not doing so is to have safety, security and privacy =only= in virtual realities, and not in physical ones. Bob Morrell ------------------------------ Date: Tuesday, 17 May 1994 13:11 ET From: tony.harminc@amail.amdahl.com Subject: Re: Secret... not so secret (Wexelblat, RISKS-16.07) Alan Wexelblat writes about NYNEX/New York Telephone mailing out replicas of customers' calling cards, complete with PINs. There is an underlying historical problem with telephone calling cards in North America that leads to a lot of this sort of trouble: those last four digits were not intended to be a PIN in the first place. The concept of PIN as a 'something you know' identifier to be combined with the 'something you have' card was kludged on to the original calling card scheme only after massive fraud in the 1970s. A simple (and widely publicized) check digit scheme was previously used by operators to manually verify card numbers. Current calling cards are unlike any other card one might carry, in that they usually have the 'PIN' embossed on the card and encoded on the magstripe. Some newer cards (typically those that do not have a phone number as the first ten digits of the number) do not have this problem. Tony Harminc Antares Alliance Group Toronto Software Development Centre ------------------------------ Date: Sun, 15 May 1994 15:44:09 -0700 From: David Honig Subject: novel risk of medical records (comment on "Future of US health care?") In RISKS-16.06, Amy_McNulty@vos.stratus.com writes about how a little girl's doctor's trick of using a serious 'diagnosis' to let the HMO's bureaucracy authorize a specialist "could cause her to be unjustly rejected sometime next century when she applies for life insurance, medical insurance, a physically demanding job, college, or who knows what else." Its *worse* than that. The job she may be denied need not be "physically demanding". There is some big military-industrial firm (whose name I forget) which publicly claims it will no longer hire *smokers* because they increase the cost of group insurance. (I suppose this has not caused major activism as smokers "choose" to smoke.) One wonders what the future holds... "I'm sorry, Ms Jones, but during your probationary period you overvisited the candy machine and that places you in ... " ------------------------------ Date: Tue, 17 May 1994 13:57:45 -0400 From: Carl Ellison Subject: Crossover of Diagnosis and Procedure Code ... (Stoufflet, RISKS-16.07) It is inexcusable to use code numbers in the first place, much less to re-use them. This is left over from human procedures on paper forms. The computer is capable of freeing us from this kind of stupidity -- with arbitary length on-line form fields, either intentionally readable by a human or intentionally encrypted for privacy. Even in the latter case, a decent code for a field will be both unique and redundant (checked) so that a 1 or 2 digit typo won't hit another defined code word. P.S. I'm a customer of HCHP and I'm not sure I want to continue to be, given this! ------------------------------ Date: 17 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.08 ************************ 25-May-94 16:16:35-GMT,28046;000000000001 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09047; Wed, 25 May 94 12:16:34 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13038; Wed, 25 May 94 12:16:10 EDT Received: by chiron.csl.sri.com id AA27805 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Wed, 25 May 94 09:06:04 -0700 From: RISKS Forum Sender: RISKS Forum Date: Wed, 25 May 94 9:06:01 PDT Subject: RISKS DIGEST 16.09 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Weds 25 May 1994 Volume 16 : Issue 09 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Call Your OPERATER! (Martin Minow) Bank goof creates millionaire (Andy Fuller) Two risk-related articles from Edupage 5/24/94 (Terry Alford) Dell monitors too hot to handle (Mich Kabay) Canada, The Internet, and the Homolka trial [anonymous] Risks of setting up awful puns (Aaron Barnhart) Re: China Airlines A300 Crash (John Yesberg) Re: Computer Crime on Wall Street (Mike Rosenberg, Marc Horowitz) Cable / Closed Circuit TV Info Display Risks and 911 (Bob Richardson) Re: Logging on as root is easy! (Dan Franklin, Eddy) Re: UK ATM Spoof (Gary Preckshot) Privacy Digests (reminder) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 24 May 94 13:08:26 -0700 From: Martin Minow Subject: Call Your OPERATER! >From rec.humor.funny, but it belongs in Risks, too... (True) In an effort to snag more long distance telephone calls (charged to a credit card or a third number), AT&T reserved the toll-free number 1-800-OPERATOR. Not to be outdone, and perhaps knowing the public better, MCI reserved the number 1-800-OPERATER and has been scooping up calls intended for its arch-rival. Walter C. Daugherity Texas A&M University daugher@cs.tamu.edu [So now we need legislation on Truth in Mispelings and Mistouchtonings? PGN] ------------------------------ Date: Wed, 25 May 94 08:57:43 EDT From: acfa@callisto.eci-esyst.com (Andy Fuller) Subject: Bank goof creates millionaire >From the Tampa Tribune, Wednesday May 25, 1994 Howard Jenkins was a multimillionaire for about a half a day. About a week ago he lost his checkbook and called his bank to have a hold put on his account. "When he went to make a deposit Fiday morning, he was told to check the automated teller machine outside to make sure the account was working." He made a small withdrawal and the receipt told him his account balance was $889437.93. He went home and called the bank's automated telephone account inquiry system, and was informed that his balance was now more than $88 million. He went back to the bank and asked a teller for his balance, and was given an 8 digit number. She asked if he had received "an inheritance or something". He withdrew $4 million in cashier's checks and cash, requiring a bank manager's signature on each check, and they "didn't bat an eye". He returned later that day, accompanied by his lawyer, and returned the money. The bank attributes the erroneous balance to a computer error, probably linked to the hold transaction. Several things stand out to me: 1) He was told to check an ATM to see if his account was working. Whoever told him this should have been able to check directly using the bank's terminal. The bank (and reasonably so) puts a great deal of trust in the computer. 2) The balance shown on the ATM receipt was different than that given him by the automated telephone information system and the teller. Is this a user interface problem, or something more involved? 3) The computer error is likely to be the fault of inadequate testing or a user interface inadequacy (calling up a deposit transaction instead of an account hold transaction). Both topics have been discussed at length in this forum. 4) Nobody questioned this withdrawal or the large deposit. The teller who checked his balance was the only one mentioned in the story that even noticed his windfall. Proper software and human procedural checks would have caught this error. If a pre-computer bank teller had been handed a deposit of this size, the bank manager would have been notified. When the withdrawal was made, the manager would have known about the deposit and been confident that the request was legitimate. Are similar human checks and balances included in modern banking computers? Andrew C. Fuller, E-Systems, ECI Division, St. Petersburg, FL acfa@callisto.eci-esyst.com (813) 381-2000 x3194 72417.612@CompuServe.com ------------------------------ Date: 25 May 1994 15:51:31 GMT From: talford@mitre.org (Terry Alford) Subject: two risk-related articles from Edupage 5/24/94 ATTENTION LIBRARIANS -- FATAL BOOKSHELVES A union claims that Library of Congress employees are exposed to potentially fatal crushing hazards caused by sliding mechanical bookshelves, and asserts in a lawsuit that the bookshelves have occasionally started up unexpectedly, undeterred by safety sensors. The government insists the bookshelves have experienced "only three or four failures," none of which resulted in employee injury. (BNA Occupational Safety & Health Reporter 5/18/94 p.1787) RISK-TAKING Information technology visionary George Gilder calls Michael Milken a risk-taker, "who was willing to plunge $2 billion into a company with $100 million in assets and $200 million in revenues. He had a great eye and really did it brilliantly. The people who prosecuted him did not understand what he was doing at all. It was mysterious to them and he was making too much money to be legal [laughs]." (Upside, June 94, p.55) ------------------------------ Date: 25 May 94 07:45:30 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@CompuServe.COM> Subject: Dell monitors too hot to handle Dell has issued a recall of 63,000 monitors after receiving 32 reports of overheating or fires starting. The problem monitors bear the number DL-1460NI on the back. Owners of the monitors with that number should call 1-800-913-3355 to set up free pickup and repair. Arrangements also can be made through Dell forums on CompuServe and America Online or by dialing Dell Computer Corp.'s bulletin board at 512-728-3589. Dell will ship packing materials to owners of the monitors, who then will send them by Airborne Express to the company for repair within three to five working days. Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn [Watch out for The Foamer in the Dell. PGN] ------------------------------ Date: Fri, 20 May 1994 22:00:16 -0400 (EDT) From: [anonymous] Subject: Canada, The Internet, and the Homolka trial As reported in Toronto's EYE Newspaper [eye@io.org] (similar to New York's Village Voice) dated 19 May 1994: The London Ontario detachment of the Ontario Provincial Police have begun a campaign of harassment against local University Internet users who are attempting to use the net to gain information on the Karla Homolka trial. A University of Western Ontario (London) student had his Internet account frozen by the university computer staff when requested by the Police. The reason for this lay in the student's name being left on the text of a FAQ of the details of the trial. Another student in Toronto had Faxed this material (which had been Emailed to him) to the Toronto media, and the offices of the Premier of Ontario and the Attorney-General as an act of provocation against the Ban (his regular anonymous forwarding site was not working). The problem was that he had forgotten to remove the other persons name and account number from the original E-mail that was sent out. The police action against the student's account was done without a warrant, and also involved the questioning of the student at the local police station. Likewise the students home computer was searched without a warrant by using the threat of criminal charges. The Student's computer account was reinstated, but he was required to turn over all incoming Email to the police under the threat of criminal charges if he did not cooperate. A list of about 50 people who had received Homolka FAQ's were passed on to the police. The important part of this entire situation is that no one, including the Ontario Attorney-General office is certain that the ban applies to the Internet. The ban states that details of the trial cannot be published in the print media but there is no ban on possession of information. There is no mention of the Internet, nor the use of computer systems in the ban. Further, there is no official investigation of the Internet on the part of the Ontario Provincial Police, except for this one detachment. One of the questions raised is the ethics of the University of Western Ontario's computer department. Their cooperation with the police was based on a fear of having their computer equipment confiscated (similar to the case of the University of Cambridge in England). If the situation had taken place with in the library system of the university, it would not have been tolerated by the library staff due to the long held tradition in that profession of the defence of freedom of speech. If the Internet is to remain open this set of values will have to become part of the professional commitment of the MIS staff of universities as well. ------------------------------ Date: Wed, 18 May 94 13:12 CDT From: barnhart@mcs.com (Aaron Barnhart) Subject: Risks of setting up awful puns If Schindler Elevator gets a black eye as a result of the Toronto controversy, at least they have an ace in the hole. They can just change their name to Schindler's Lifts. [Remarkably, this was also suggested in various contexts by Mark Bartelt , roedder@netcom.com (Spencer Roedder), jcook@epoch.com (Jim Cook), davis@ilog.ilog.fr (Harley Davis). I am absolutely delighted that I am not carrying the entire burden of elevating the level of discourse. PGN] ------------------------------ Date: Fri, 20 May 1994 10:14:31 --9-30 From: jdy@itd0.dsto.gov.au (John Yesberg) Subject: Re: China Airlines A300 Crash (Stalzer, RISKS-16.05) > ... This is a serious kind of failure, if an automatic system designed to > prevent a problem makes it worse, it should do nothing at all! This is probably true for conventional aircraft. For fly-by-wire aircraft, however, the computer systems can never "do nothing". I understand that the main computer system (in, e.g. A320) has six (approx) flight modes, and that it responds slightly differently to manual inputs depending on which mode it is in. Pilots are required to understand the differences between the modes. I imagine that, in non-emergency situations, the pilot would not need to worry about these differences: the aircraft would respond "intuitively" to command inputs. In very unusual situations, the required inputs to the machine may be counterintuitive. This can probably be overcome in two ways: (i) Give the flight computer more modes to be in, so that it could behave "properly" or "intuitively" in the various situations. (ii) Give the pilots enough simulator training so that the intuition takes into account the mode that the aircraft is in. In critical manoevres, like landing and go-around, pilot confusion is to be avoided at all costs. John Yesberg (jdy@itd.dsto.gov.au) ------------------------------ Date: Wed, 18 May 1994 14:48:51 -0400 From: mkr@fid.morgan.com (Mike Rosenberg) Subject: Re: Computer Crime on Wall Street (RISKS-16.08) re: joe jett's alleded fraud: > It seems to me that this manipulation could only have been accomplished > through extensive computer manipulation by Jett and possibly by others. I believe this is incorrect. It probably happened because the accounting system did not handle the trade properly. i would guess that no outright manipulation of data or code was necessary. also, his gross strips position was probably growing larger and larger as time went on. this should have raised some red flags. mike rosenberg mkr@fid.morgan.com ------------------------------ Date: Sat, 21 May 94 16:45:30 EDT From: Marc Horowitz Subject: Re: Computer Crime on Wall Street >> 76 total accidents, 3513 fatalities. (How do you have *1* mid-air? >> They must be counting accidents, not aircraft involved.) Although you are probably right, this is not impossible. Several months ago, several people were killed in a small airplane over Massachusetts when it collided with a skydiver (who survived with a broken leg). One plane, midair collision. Marc ------------------------------ Date: Tue, 17 May 1994 14:41:55 -0700 (PDT) From: Bob Richardson Subject: Cable / Closed Circuit TV Info Display Risks and 911 John Gersh writes regarding an information channel display that showed an incorrect floor number during a fire alarm. Other contributors have written regarding cable-TV channels reporting "Software Failure" for hours or days on-end. As a manufacturer of such equipment for the Cable Television Industry, I hope I can provide some insight. A very common computer used in systems for broadcast applications is the Amiga. This is because of it's relatively low cost for this application, as well as the fact that it generates clean video at standard NTSC/PAL rates. On older versions of the operating system, if a program crashed severely (the Amiga OS does not provide memory protection or resource tracking, yet is fully multitasking), a flashing red "guru" message would appear, requiring an acknowledgement from the user to reboot the machine. Unfortunately, due to the nature of cable transmission, these machines are usually located in very remote sites. Of course, many cable companies are too lax in even monitoring for crashed displays. Under newer versions of the OS, this problem is solved in that after a timeout (usually 30 seconds), these requesters go away and the reboot proceeds normally. Since the Amiga isn't a very widely supported or understood platform, most of these cable operators do not upgrade to newer OS's, and some machines cannot legally be upgraded (physically they can, but since ROMs are not available from Amiga, you have to make a copy of the OS and install it on the hard drive of the machine, which is technically illegal.) Our solution for our customers was to create a "watchdog" program that would reboot the machine in the event that our main task failed in any way. We then discovered something interesting: Most of the crashes occurring were not a result of our program (or our competitors), but of line spikes and brownouts trashing the machine. We now insist that our customers at least purchase a line conditioner or a UPS as a result. One contributor to this list asked what cable companies will do now that Commodore is out of business, regarding replacement parts. For quite some time now, it has been quite difficult to obtain support from Commodore anyway, so my company as well as others have been acquiring spare parts from used machines. One should note, however, that Commodore's death is being exaggerated on the net, and that there is indeed a buyer, but specifics have not been made public at this time. An interesting incident reported to me by a customer: During the March, 1993 earthquake in Klamath Falls, Oregon, cable service was not interrupted. The 911 emergency center was being swamped with calls, many of them for non-life-threatening situations. They called the cable company and requested that a message be posted on the air to tell people with minor emergencies to use an alternate number to reach the 911 center. Unfortunately, the number provided to the cable company was incorrect, and was for the main 911 center's outgoing lines (non-emergency). The administrative office was then swamped with calls, and could not obtain and outgoing line to call the cable company and tell them to change the number. As a result, the 911 center wants modem access to our software so that they can alter displays themselves. (I don't see how that could have prevented this particular situation.) We are currently evaluating how best to achieve this. There are several liability issues that open up when you allow third parties access to your airwaves. Not to mention the fact that while our software is password-protected at this time, anyone with a password also has access to the billing and setup functions. We now have to segment our security further so that outsiders can not mess with private or operation-critical information. Bob Richardson, Product Development Supervisor, Sound Concepts / MagicBox (503) 752-5542 bob@csos.orst.edu ------------------------------ Date: Wed, 18 May 94 14:40:16 -0400 From: dan@copernicus.bbn.com (Dan Franklin) Subject: Re: Logging on as root is easy! I am somewhat skeptical of the apparent failure in security described by in RISKS-16.08. I have been in the situation eddy describes many times, and the "NFS server ..." message always appeared AFTER I typed the password, if the password prompt appeared at all (sometimes it did not). In fact since the code in question queries you for the password and then waits to collect it, it is difficult to imagine what it could be doing in between those two operations that would involve NFS access. Also, if the included transcript is literally accurate eddy@eddy> su Password: NFS server mbfs.bio not responding still trying then, since the "Password:" prompt does not end in a newline, eddy must have at least typed a newline before getting the "NFS server ..." message, and the possibility that the entire password was typed before that newline cannot be ignored; after all, until that much-loathed message appeared, eddy was presumably expecting to "su" as usual so as to be able to unmount the soon-to-disappear filesystems. Of course, this is computer software, so I'm not saying it's impossible! But I'd like to see it duplicated before I believe it. Unfortunately eddy's message did not give the UNIX version involved in this scenario, so I cannot do it here. The _real_ risk is that once you've entered the password, you've got a nascent superuser shell that anyone can type at once the server comes back up. Yet one hardly wants to stick around and guard it... In a university environment, this seems risky indeed. Dan Franklin ------------------------------ Date: Thu, 19 May 94 13:35:12 BST From: eddy Subject: Re: Logging on as root is easy! (Franklin, RISKS-16.09) > The _real_ risk ... superuser shell that anyone ... In a university Interesting point. The risks of leaving the terminal unattended aren't the usual ones for a university; this is a lockable office which I share with folk that I trust not to abuse a root shell and who would have locked the office if they'd gone out in my absence -- ie, we don't get random undergraduates wondering in in our absence -- but I hadn't typed the password, so this wouldn't have been a problem (except that I'd feel shy of letting random UG's get at _my_ account, of course; which is one of our reasons for locking the door). > ... if ... literally accurate ... possibility ... cannot be ignored ... The transcript is literally accurate; I copied the text from the command-tool to the mail window by raw cut-and-paste. I had not typed anything at the password prompt when the NFS server message came up; what I did type (a tenth of a second later -- thus before I'd noticed the message) was only the first three letters of the password and I soon removed those with ^U because they were being echoed ! I followed that with a return and several ^Cs (a strategy which doesn't trick su normally -- the first experiment I tried on discovering what had happened) so that nothing should sensibly have been able to go wrong. > ... after all ... eddy was ... expecting to "su" [so as] to unmount ... Dead right there; but, as I say, I noticed what was happening _before_ I'd typed the whole password. > I am somewhat skeptical ... And all Dan's reasons for skepticism (which I respect as such given that he only has the information third hand) are exactly the reasons for my horror upon discovering that I'd managed to become root without having typed the magic words. > I'd like to see it duplicated before I believe it. ... UNIX version ... Yes, duplication under controlled conditions is the only way to confirm. The machine I'm running on is a Sun SPARCclassic running SunOS 4.1.3. Eddy [A similar correspondence occurred between Caveh.Jalali@eng.sun.com (Caveh Jalali) and Eddy, but it is not included here because of the overlap. PGN] ------------------------------ Date: 19 May 1994 11:22:34 U From: "Gary Preckshot" Subject: Re: UK ATM Spoof Subject: Time:10:57 AM OFFICE MEMO Re: UK ATM Spoof Date:5/19/94 Date: 19 May 1994 From: gary_preckshot@lccmail.ocf.llnl.gov Subject: Re: UK ATM Spoof >.....copies the one-time response from the card's LCD into the keypad). >The ATM or banking network validates the response and continues the >transactions. Results of setting up a spoof on a stolen ATM: zero.] Surely this is an example of the risk of becoming too enamoured of your own ideas. Regardless of the elaborate scheme proposed, all the fake ATM machine needs to do is look like it is responding correctly, and the user will enter his or her PIN. The issue isn't validation, it's getting information out of the user by deceit, and anything that fools the user will work. Only other information, not available easily either to the user or to the credit card thief, will fill this security hole. Instead, there probably has to be a piece of information possessed by the "smart" card which cannot be obtained without correct authorization. Only an ATM hooked up correctly to the bank could obtain the passwords to unlock the card, which then provides some internal code unrelated either to the PIN or to the card account number. However, this raises other issues, such as how could you use such a card for phone charges? Or how could charges be validated at the point of sale? Somehow the same challenge/response would have to occur at Macy's as it does at the ATM, or what good would the internal validation code do? Thus, the challenge would be available for analysis on the general telecommunications system, and a significant communications burden would be placed on the system due to wide spread usage. Somehow, I don't think it's quite so simple. Gary DRTOPE@delphi.com ------------------------------ Date: 18 May 94 Subject: Privacy Digests From: RISKS-request@csl.sri.com Periodically I will 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 general 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 Leonard P. Levine. 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@uwm.edu and administrative requests to comp-privacy-request@uwm.edu. 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: 17 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.09 ************************ 4-Jun-94 1:45:15-GMT,16777;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04157; Fri, 3 Jun 94 21:45:14 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05662; Fri, 3 Jun 94 21:39:48 EDT Received: by chiron.csl.sri.com id AA08247 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Fri, 3 Jun 94 16:48:45 -0700 From: RISKS Forum Sender: RISKS Forum Date: Fri, 3 Jun 94 16:48:43 PDT Subject: RISKS DIGEST 16.11 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Friday 3 June 1994 Volume 16 : Issue 11 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Flaw in Clipper detected (Jim Huggins) Re: Solo midair collisions (Martyn Thomas) Donuts with Ears, Part II (Peter Wayner, David Wright) Ollie North on the high seas...Big toys, big egos, E-trails (David Honig) Nonexistent Risks (Re: Call Your OPERATER!) (Gregory B. Sorkin) Risks of faxing (Adam Shostack) The Ghost in the Modem (Loka Alert 1:6 via Phil Agre) Zimmermann statement on PGP 2.6 (Philip Zimmermann) "The Hacker Crackdown" by Bruce Sterling (Rob Slade) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 2 Jun 1994 13:55:23 -0400 (EDT) From: Jim Huggins Subject: Flaw in Clipper detected The following is summarized from an article in the _Detroit_Free_Press_, 2 June 1994, pages A5-6. The article was written by John Markoff of the New York Times [and appeared on the front page of the Times on that day]. AT&T Bell Labs researcher Matthew Blaze has been quietly circulating a report among computer researches and federal agencies which demonstrates a flaw in Clipper. Using Blaze's technique, two parties can use Clipper to have a conversation which could not be decrypted by government officials using the proper escrowed keys. The flaw would not permit third parties without the escrowed keys to decrypt the conversation either; essentially, this technique would reduce Clipper to the status of other commercially-available cryptography which is computationally infeasible to break. Stanford's Martin Hellman, who has reviewed Blaze's work, states "People who want to work around Clipper will be able to do it." In a written statement, NSA directory of policy Michael Smith stated that Clipper would still remain useful: "Anyone interested in circumventing law-enforcement access would most likely choose simpler alternatives." Smith claims that Blaze's technique would be too difficult and time-consuming for practical use. Comments: of course, this will probably re-ignite most of the Clipper controversy again, since this seems to strike at the heart of NSA's purposes in creating Clipper (secure cryptography with a mandatory back-door for the government). I'm more interested in NSA's statement that says in essence that Clipper can be avoided more simply: perhaps this shows that Clipper won't be all that useful after all? Jim Huggins, University of Michigan (huggins@umich.edu) ------------------------------ Date: Wed, 1 Jun 94 11:19:15 +0100 From: Martyn Thomas Subject: Re: Solo midair collisions The account of a collision with a sky-diver reminds me of an incident some years ago when a commercial jet hit a salmon at altitude, which smashed through the nose, demolished the co-pilot's rudder pedals and broke his leg, ending against the rear bulkhead of the cockpit [the salmon, presumably, not the rudder pedals or the leg]. The accident report assumed an eagle had dropped it. [The eagle salmoned up all its carriage? PGN] ------------------------------ Date: Thu, 2 Jun 1994 18:17:26 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: Donuts with Ears, Part II A spokesman from Dunkin' Donuts tells me that the chain has ordered all DD to remove their listening equipment. Apparently, the front-page news about their listening devices finally brought the public sentiment to their attention. Maybe if they had stronger mikes they would have gotten the message sooner? ------------------------------ Date: Fri, 03 Jun 94 10:15:41 EDT From: David Wright Subject: Re: Eavesdropping hits NSA [RISKS 16.10] [...] The security cameras that are installed in in many stores will remain, however; the company said they are a proved deterrent to robbery. -- David Wright, Hitachi Computer Products (America), Inc. Waltham, MA wright@hi.com ------------------------------ Date: Fri, 03 Jun 1994 11:41:15 -0700 From: David Honig Subject: Ollie North on the high seas...Big toys, big egos, electronic trails In the 3 Jun 1994 Wall Street Journal there is an article about a Whitbread sailboat race. The story includes a description of how one team is accusing one of its members of telling another team about the weather, which is apparently against their rules. The evidence for this is *computer logs of faxes* sent between the individuals, who are also possibly romanticly linked. (There may also be financial motives connected with boat sponsorship.) Anyway, the risk to perpetrators in not covering their electronic trails (tails?) is present even on a sailboat in the South Pacific. ------------------------------ Date: Tue, 31 May 94 18:13:03 -0500 From: sorkin@watson.ibm.com (Gregory B. Sorkin) Subject: Nonexistent Risks (Re: Call Your OPERATER!) There is the RISK of not double-checking dubious information, including information in the Risks Digest. I dialed 1-800-OPE-RATO[R] (I didn't dial that last R -- for "redundancy"), and sure enough, I got a "(pong) AT&T". Then I dialed 1-800-OPE-RATE[R], and sure enough, I got . . . nothing. Is there a regional discrepancy, or is the rumor of MCI's devious cunning just an urban myth? [I got RINGING with NO ANSWER after 20 rings. Maybe that is exactly the point? Ultimate denial of service, intended to make you want to go elsewhere when you think you are getting AT&T? PGN] There were also several Risks Digest items about clever color copiers blocking the reproduction of US and some foreign currencies. This seems almost impossible algorithmically, and indeed appears to be fictional, based on what testing one can do legally. [We have gone around on that one in the past. PGN] What are the Risks here? Just that people will go about spreading urban myths, I guess. Greg Sorkin (sorkin@watson.ibm.com) ------------------------------ Date: Wed, 1 Jun 1994 09:16:16 -0400 From: Adam Shostack Subject: Risks of faxing This appeared in rec.humor.funny. I'm submitting it to RISKs because nothing on the risks of faxing has appeared in a while. The problems are that there is often little way to ensure your fax is going to the correct place, and that the faxed paper is out of your control once faxed, and might be copied, and redistributed with your name & private correspondence. Public-key encryption programs, such as PGP, would have allowed the unfortunate applicant to encrypt this (as email). If it was mail, he would have to type the wrong address twice, once for the mail address, and also for the encryption recipient. He might have had a chance at getting the job. (Of course, using the phone would also have avoided the problem, but can be inconvenient & expensive when colleagues are overseas.) > You might enjoy this. > A candidate for the Director of our Research Center faxed a > colleague to request a letter of recommendation. It was > accidentally faxed here instead. It read in part: > "Iowa is too wet and droll. But it's a directorship > so I should apply..." > The fax is now part of his permanent application file. ------------------------------ Date: Sun, 29 May 1994 21:01:06 -0700 From: Phil Agre Subject: The Ghost in the Modem (Loka Alert 1:6--from the Washington Post) Date: Sun, 29 May 1994 22:40:43 -0500 (EST) From: RESCLOVE@amherst.edu To: loka-l@amherst.edu Subject: The Ghost in the Modem (Loka Alert 1:6--from the Washington Post) Loka Alert 1:6 (May 29, 1994) >From the Sunday _Washington Post_: IF INFORMATION HIGHWAYS ARE ANYTHING LIKE INTERSTATE HIGHWAYS--WATCH OUT! Friends and Colleagues: This is one in an occasional series of e-mail postings on democratic politics of science and technology, issued by The Loka Institute. You are welcome to post it anywhere you feel is appropriate. The following essay, written by Loka Institute members, is reprinted from the Outlook Section of _The Washington Post_, Sunday, May 29, 1994. --Dick Sclove Executive Director, The Loka Institute, P.O. Box 355, Amherst, MA 01004-0355, USA Tel. 413 253-2828; Fax 413 253-4942 E-mail: resclove@amherst.edu ***************************************************************** THE GHOST IN THE MODEM For Architects of the Info-Highway, Some Lessons From the Concrete Interstate By Richard Sclove and Jeffrey Scheuer Vice President Gore envisions the information superhighway as the second coming of the interstate highway system championed by his father, former U.S. Senator Al Gore, a generation ago. Let us hope that the junior Gore is proven wrong. Rush-hour traffic jams, gridlock, garish plastic-and-neon strips, high fatality rates, air pollution, global warming, depletion of world oil reserves--have we forgotten all of the interstate highway system's most familiar consequences? It's not that Gore's analogy is wrong, only that his enthusiasm is misplaced. Comparing the electronic and asphalt highways is useful--but mostly as a cautionary tale. Building the new information infrastructure will not entail the degree of immediate, physical disruption caused by the interstate highway system. But sweeping geographic relocations, and accompanying social transformations, seem probable. And the risk of inequity in contriving and distributing electronic services--or, conversely, imposing them where they are not wanted--is clear. Indeed, disparities in access to new information systems have already begun to surface. A study released this past week by a group of public interest organizations, including the National Association for the Advancement of Colored People and the Center for Media Education, notes that low-income and minority communities are underrepresented in U.S. telephone company's initial plans for installing advanced communications networks. Unequal access is only the most obvious among many social repercussions that may lie in store for us. The real history of the interstate highway system suggests how we can think about and control the vast implications of new technologies and a new national public infrastructure. It is widely assumed that Americans' infatuation with cars led to the construction of America's superhighways. But actually when Congress passed the Interstate Highway Act in 1956, car sales were slack, and there was no popular clamor for building a new road system. At the time only about half of American families owned an automobile; everyone else depended on public transportation. Congress was responding to aggressive lobbying by auto makers and road builders, plus realtors who saw profits in developing suburban subdivisions. The act's key provisions included support for bringing freeways directly into city centers and earmarking gasoline tax revenues for highway construction. As the interstate highways were built, city and suburban development adapted to the quickening proliferation of autos. Soon more Americans found themselves forced to buy a car in order to be able to shop or hold a job. The Highway Trust Fund, by assuring the rapid atrophy of competing public transit systems, bolstered this trend. Thus the asphalt highways--and the society around them--are a reflection of successful lobbying by powerful business interests and external compulsion, not simply the free choices of consumers. There is no guarantee that the process of wiring consumers and employees into the electronic highway system will be different. The effects of the interstate highway system on American communities were profound, especially in the cities. As historian James Flink notes, "Ambitious programs for building urban freeways resulted in the massive destruction of once viable poor and minority neighborhoods." In other cases, new highways encircled poor neighborhoods, physically segregating minorities into marginalized ghettos. Gradually, a black and Hispanic middle-class did emerge. Its members too fled along the interstate to the suburbs, further draining economic and cultural resources from the inner city. This contributed to the emergence of a new social phenomenon: today's desperately deprived, urban underclass. Elsewhere the effects were subtler but still significant. The noise and danger from growing numbers of autos drove children's games out of the street, and neighbors and families off their front porches. Before long, suburbs without sidewalks came to signal an unprecedented paucity of local destinations worth walking to. Suburban housewives found themselves leading increasingly isolated daytime lives at home. Highways made shopping malls possible, enabling franchise and chain store sales to boom. But this sapped downtown centers. For some teenagers and senior citizens, today's anonymous, consumption-mad expanses provide a semblance of community space-- having swallowed up the general store, the soda fountain, the Main Street sidewalk, and the town square. There is ample danger of the new electronic technology extending these losses. Remember too that it is easy to romanticize new technology. The popular arts glorified life on the highway. People read Jack Kerouac's "On the Road," watched "Route 66" on television, and recall the Merry Pranksters' psychedelic bus-capades during the '60s. In fusing alienation and rebellion with youthful exuberance, each of these foreshadows contemporary cyberpunk culture. Yet real-life experience on the interstate is mostly banal and uneventful. McDonald's, Pizza Hut, and Wal-Mart look about the same wherever you exit. There are also political ramifications of a vast new public infrastructure. Interstate highways contributed to national and even international economic integration. But while GNP soared, mom-and-pop production and retailing declined. That meant greater local dependence on national and global market forces and on distant corporate headquarters--powers that communities simply couldn't control. The locus of effective political intervention thus shifted toward more distant power centers. But because those are realms in which everyday citizens cannot be as effectual as in smaller political settings, democracy was impaired. If the growth of the highways is revealing, so too is the opposition to freeway construction that emerged. As citizens became more politically mobilized during the 1960's and early '70s, opposition to relentless highway expansion arose from environmentalists and from local communities, both rich and poor. Transportation engineers reeled at the specter of upright citizens rejecting their good works. Many current telecommunications engineers and true-believing entrepreneurs are no less convinced of the unalloyed beneficence of their art. The importance of the analogy between the information and asphalt highways lies in the political procedures that create them. What if a wider range of people, including non-car owners, had been involved in transportation planning all along? Considering the alternatives envisioned by critics such as Lewis Mumford, it seems likely we would have a smaller and different road system today. As in Europe and Japan, there probably would have been greater investment in public transit. Modern America might exhibit less sprawl, less dependence on foreign oil, and more cohesive urban neighborhoods. Three lessons for the construction of the information superhighway suggest themselves: o _No Innovation Without Evaluation_: To help reduce adverse social impact, the federal government should mandate evaluated social trials of alternative electronic services. Analogous to environm 6-Jun-94 23:07:45-GMT,2838;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17672; Mon, 6 Jun 94 19:07:44 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24132; Mon, 6 Jun 94 19:07:39 EDT Received: by chiron.csl.sri.com id AA11473 (5.67b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Mon, 6 Jun 1994 16:01:26 -0700 From: RISKS Forum Sender: RISKS Forum Date: Mon, 6 Jun 94 16:01:23 PDT Subject: RISKS DIGEST 16.11a Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Monday 6 June 1994 Volume 16 : Issue 11a FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: RISKS-16.11: D-DAY is Disk-Day at CSL? (RISKS OF RISKS!) (PGN) ---------------------------------------------------------------------- Date: 6 June 1994 Reply-to: RISKS-request@csl.sri.com From: The RISKS management (evidently not adept in Risk Management!) Subject: RISKS-16.11: D-DAY is Disk-Day at CSL? RISKS-16.11 was apparently truncated in most of the main mailings that were sent out late on 3 June. (I have to keep the list in 12 sublists, and each one may have been handled somewhat differently. I do not know whether the problem caused truncation consistently from one sublist to another. We also experienced a disk overflow problem, and I could not FTP the archive copy to CRVAX until today.) The truncation problem appears to affect only longer messages, so I'm keeping this one short in hopes of staving off the large number of messages I have received noting the truncation. I WILL REPOST RISKS-16.11 as soon as the problem is identified (not yet) and fixed. In the meanwhile, RISKS-16.11 is intact on the CRVAX and csl.sri.com www server. I will hold off on sending RISKS-16.12 until the situation improves. This message will not appear in the issue-summary listing in RISKS-16.00. PGN ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. bitftp@pucc.Princeton.EDU and WAIS could be alternative repositories, if anyone has already updated the complete version of RISKS-16.11 from the CRVAX archive site. ------------------------------ End of RISKS-FORUM Digest 16.11a ************************ 8-Jun-94 19:03:03-GMT,28592;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10154; Wed, 8 Jun 94 15:03:02 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA14723; Wed, 8 Jun 94 15:02:55 EDT Received: by chiron.csl.sri.com id AA14336 (5.67b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Wed, 8 Jun 1994 11:54:12 -0700 From: RISKS Forum Sender: RISKS Forum Date: Wed, 8 Jun 94 11:54:09 PDT Subject: RISKS DIGEST 16.11 (retry #1... gateway was hosed...) Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Friday 3 June 1994 Volume 16 : Issue 11 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Flaw in Clipper detected (Jim Huggins) Re: Solo midair collisions (Martyn Thomas) Donuts with Ears, Part II (Peter Wayner, David Wright) Ollie North on the high seas...Big toys, big egos, E-trails (David Honig) Nonexistent Risks (Re: Call Your OPERATER!) (Gregory B. Sorkin) Risks of faxing (Adam Shostack) The Ghost in the Modem (Loka Alert 1:6 via Phil Agre) Zimmermann statement on PGP 2.6 (Philip Zimmermann) "The Hacker Crackdown" by Bruce Sterling (Rob Slade) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 2 Jun 1994 13:55:23 -0400 (EDT) From: Jim Huggins Subject: Flaw in Clipper detected The following is summarized from an article in the _Detroit_Free_Press_, 2 June 1994, pages A5-6. The article was written by John Markoff of the New York Times [and appeared on the front page of the Times on that day]. AT&T Bell Labs researcher Matthew Blaze has been quietly circulating a report among computer researches and federal agencies which demonstrates a flaw in Clipper. Using Blaze's technique, two parties can use Clipper to have a conversation which could not be decrypted by government officials using the proper escrowed keys. The flaw would not permit third parties without the escrowed keys to decrypt the conversation either; essentially, this technique would reduce Clipper to the status of other commercially-available cryptography which is computationally infeasible to break. Stanford's Martin Hellman, who has reviewed Blaze's work, states "People who want to work around Clipper will be able to do it." In a written statement, NSA directory of policy Michael Smith stated that Clipper would still remain useful: "Anyone interested in circumventing law-enforcement access would most likely choose simpler alternatives." Smith claims that Blaze's technique would be too difficult and time-consuming for practical use. Comments: of course, this will probably re-ignite most of the Clipper controversy again, since this seems to strike at the heart of NSA's purposes in creating Clipper (secure cryptography with a mandatory back-door for the government). I'm more interested in NSA's statement that says in essence that Clipper can be avoided more simply: perhaps this shows that Clipper won't be all that useful after all? Jim Huggins, University of Michigan (huggins@umich.edu) ------------------------------ Date: Wed, 1 Jun 94 11:19:15 +0100 From: Martyn Thomas Subject: Re: Solo midair collisions The account of a collision with a sky-diver reminds me of an incident some years ago when a commercial jet hit a salmon at altitude, which smashed through the nose, demolished the co-pilot's rudder pedals and broke his leg, ending against the rear bulkhead of the cockpit [the salmon, presumably, not the rudder pedals or the leg]. The accident report assumed an eagle had dropped it. [The eagle salmoned up all its carriage? PGN] ------------------------------ Date: Thu, 2 Jun 1994 18:17:26 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: Donuts with Ears, Part II A spokesman from Dunkin' Donuts tells me that the chain has ordered all DD to remove their listening equipment. Apparently, the front-page news about their listening devices finally brought the public sentiment to their attention. Maybe if they had stronger mikes they would have gotten the message sooner? ------------------------------ Date: Fri, 03 Jun 94 10:15:41 EDT From: David Wright Subject: Re: Eavesdropping hits NSA [RISKS 16.10] [...] The security cameras that are installed in in many stores will remain, however; the company said they are a proved deterrent to robbery. -- David Wright, Hitachi Computer Products (America), Inc. Waltham, MA wright@hi.com ------------------------------ Date: Fri, 03 Jun 1994 11:41:15 -0700 From: David Honig Subject: Ollie North on the high seas...Big toys, big egos, electronic trails In the 3 Jun 1994 Wall Street Journal there is an article about a Whitbread sailboat race. The story includes a description of how one team is accusing one of its members of telling another team about the weather, which is apparently against their rules. The evidence for this is *computer logs of faxes* sent between the individuals, who are also possibly romanticly linked. (There may also be financial motives connected with boat sponsorship.) Anyway, the risk to perpetrators in not covering their electronic trails (tails?) is present even on a sailboat in the South Pacific. ------------------------------ Date: Tue, 31 May 94 18:13:03 -0500 From: sorkin@watson.ibm.com (Gregory B. Sorkin) Subject: Nonexistent Risks (Re: Call Your OPERATER!) There is the RISK of not double-checking dubious information, including information in the Risks Digest. I dialed 1-800-OPE-RATO[R] (I didn't dial that last R -- for "redundancy"), and sure enough, I got a "(pong) AT&T". Then I dialed 1-800-OPE-RATE[R], and sure enough, I got . . . nothing. Is there a regional discrepancy, or is the rumor of MCI's devious cunning just an urban myth? [I got RINGING with NO ANSWER after 20 rings. Maybe that is exactly the point? Ultimate denial of service, intended to make you want to go elsewhere when you think you are getting AT&T? PGN] There were also several Risks Digest items about clever color copiers blocking the reproduction of US and some foreign currencies. This seems almost impossible algorithmically, and indeed appears to be fictional, based on what testing one can do legally. [We have gone around on that one in the past. PGN] What are the Risks here? Just that people will go about spreading urban myths, I guess. Greg Sorkin (sorkin@watson.ibm.com) ------------------------------ Date: Wed, 1 Jun 1994 09:16:16 -0400 From: Adam Shostack Subject: Risks of faxing This appeared in rec.humor.funny. I'm submitting it to RISKs because nothing on the risks of faxing has appeared in a while. The problems are that there is often little way to ensure your fax is going to the correct place, and that the faxed paper is out of your control once faxed, and might be copied, and redistributed with your name & private correspondence. Public-key encryption programs, such as PGP, would have allowed the unfortunate applicant to encrypt this (as email). If it was mail, he would have to type the wrong address twice, once for the mail address, and also for the encryption recipient. He might have had a chance at getting the job. (Of course, using the phone would also have avoided the problem, but can be inconvenient & expensive when colleagues are overseas.) > You might enjoy this. > A candidate for the Director of our Research Center faxed a > colleague to request a letter of recommendation. It was > accidentally faxed here instead. It read in part: > "Iowa is too wet and droll. But it's a directorship > so I should apply..." > The fax is now part of his permanent application file. ------------------------------ Date: Sun, 29 May 1994 21:01:06 -0700 From: Phil Agre Subject: The Ghost in the Modem (Loka Alert 1:6--from the Washington Post) Date: Sun, 29 May 1994 22:40:43 -0500 (EST) From: RESCLOVE@amherst.edu To: loka-l@amherst.edu Subject: The Ghost in the Modem (Loka Alert 1:6--from the Washington Post) Loka Alert 1:6 (May 29, 1994) >From the Sunday _Washington Post_: IF INFORMATION HIGHWAYS ARE ANYTHING LIKE INTERSTATE HIGHWAYS--WATCH OUT! Friends and Colleagues: This is one in an occasional series of e-mail postings on democratic politics of science and technology, issued by The Loka Institute. You are welcome to post it anywhere you feel is appropriate. The following essay, written by Loka Institute members, is reprinted from the Outlook Section of _The Washington Post_, Sunday, May 29, 1994. --Dick Sclove Executive Director, The Loka Institute, P.O. Box 355, Amherst, MA 01004-0355, USA Tel. 413 253-2828; Fax 413 253-4942 E-mail: resclove@amherst.edu ***************************************************************** THE GHOST IN THE MODEM For Architects of the Info-Highway, Some Lessons From the Concrete Interstate By Richard Sclove and Jeffrey Scheuer Vice President Gore envisions the information superhighway as the second coming of the interstate highway system championed by his father, former U.S. Senator Al Gore, a generation ago. Let us hope that the junior Gore is proven wrong. Rush-hour traffic jams, gridlock, garish plastic-and-neon strips, high fatality rates, air pollution, global warming, depletion of world oil reserves--have we forgotten all of the interstate highway system's most familiar consequences? It's not that Gore's analogy is wrong, only that his enthusiasm is misplaced. Comparing the electronic and asphalt highways is useful--but mostly as a cautionary tale. Building the new information infrastructure will not entail the degree of immediate, physical disruption caused by the interstate highway system. But sweeping geographic relocations, and accompanying social transformations, seem probable. And the risk of inequity in contriving and distributing electronic services--or, conversely, imposing them where they are not wanted--is clear. Indeed, disparities in access to new information systems have already begun to surface. A study released this past week by a group of public interest organizations, including the National Association for the Advancement of Colored People and the Center for Media Education, notes that low-income and minority communities are underrepresented in U.S. telephone company's initial plans for installing advanced communications networks. Unequal access is only the most obvious among many social repercussions that may lie in store for us. The real history of the interstate highway system suggests how we can think about and control the vast implications of new technologies and a new national public infrastructure. It is widely assumed that Americans' infatuation with cars led to the construction of America's superhighways. But actually when Congress passed the Interstate Highway Act in 1956, car sales were slack, and there was no popular clamor for building a new road system. At the time only about half of American families owned an automobile; everyone else depended on public transportation. Congress was responding to aggressive lobbying by auto makers and road builders, plus realtors who saw profits in developing suburban subdivisions. The act's key provisions included support for bringing freeways directly into city centers and earmarking gasoline tax revenues for highway construction. As the interstate highways were built, city and suburban development adapted to the quickening proliferation of autos. Soon more Americans found themselves forced to buy a car in order to be able to shop or hold a job. The Highway Trust Fund, by assuring the rapid atrophy of competing public transit systems, bolstered this trend. Thus the asphalt highways--and the society around them--are a reflection of successful lobbying by powerful business interests and external compulsion, not simply the free choices of consumers. There is no guarantee that the process of wiring consumers and employees into the electronic highway system will be different. The effects of the interstate highway system on American communities were profound, especially in the cities. As historian James Flink notes, "Ambitious programs for building urban freeways resulted in the massive destruction of once viable poor and minority neighborhoods." In other cases, new highways encircled poor neighborhoods, physically segregating minorities into marginalized ghettos. Gradually, a black and Hispanic middle-class did emerge. Its members too fled along the interstate to the suburbs, further draining economic and cultural resources from the inner city. This contributed to the emergence of a new social phenomenon: today's desperately deprived, urban underclass. Elsewhere the effects were subtler but still significant. The noise and danger from growing numbers of autos drove children's games out of the street, and neighbors and families off their front porches. Before long, suburbs without sidewalks came to signal an unprecedented paucity of local destinations worth walking to. Suburban housewives found themselves leading increasingly isolated daytime lives at home. Highways made shopping malls possible, enabling franchise and chain store sales to boom. But this sapped downtown centers. For some teenagers and senior citizens, today's anonymous, consumption-mad expanses provide a semblance of community space-- having swallowed up the general store, the soda fountain, the Main Street sidewalk, and the town square. There is ample danger of the new electronic technology extending these losses. Remember too that it is easy to romanticize new technology. The popular arts glorified life on the highway. People read Jack Kerouac's "On the Road," watched "Route 66" on television, and recall the Merry Pranksters' psychedelic bus-capades during the '60s. In fusing alienation and rebellion with youthful exuberance, each of these foreshadows contemporary cyberpunk culture. Yet real-life experience on the interstate is mostly banal and uneventful. McDonald's, Pizza Hut, and Wal-Mart look about the same wherever you exit. There are also political ramifications of a vast new public infrastructure. Interstate highways contributed to national and even international economic integration. But while GNP soared, mom-and-pop production and retailing declined. That meant greater local dependence on national and global market forces and on distant corporate headquarters--powers that communities simply couldn't control. The locus of effective political intervention thus shifted toward more distant power centers. But because those are realms in which everyday citizens cannot be as effectual as in smaller political settings, democracy was impaired. If the growth of the highways is revealing, so too is the opposition to freeway construction that emerged. As citizens became more politically mobilized during the 1960's and early '70s, opposition to relentless highway expansion arose from environmentalists and from local communities, both rich and poor. Transportation engineers reeled at the specter of upright citizens rejecting their good works. Many current telecommunications engineers and true-believing entrepreneurs are no less convinced of the unalloyed beneficence of their art. The importance of the analogy between the information and asphalt highways lies in the political procedures that create them. What if a wider range of people, including non-car owners, had been involved in transportation planning all along? Considering the alternatives envisioned by critics such as Lewis Mumford, it seems likely we would have a smaller and different road system today. As in Europe and Japan, there probably would have been greater investment in public transit. Modern America might exhibit less sprawl, less dependence on foreign oil, and more cohesive urban neighborhoods. Three lessons for the construction of the information superhighway suggest themselves: o _No Innovation Without Evaluation_: To help reduce adverse social impact, the federal government should mandate evaluated social trials of alternative electronic services. Analogous to environmental impact statements, these trials should precede full-scale deployment of any major components of new information infrastructures. o _No Innovation Without Regulation_: We should conserve cultural space for face-to-face social engagement, traditional forms of community life, off-screen leisure activities and time spent in nature. How about a modest tax on electronic home shopping and consumer services, rebating the revenue to support compensatory, local community-building initiatives? o _No Innovation Without Participation_: A number of European nations are out-competing America in including lay people in technology decision-making. For instance, the Danish government appoints panels of everyday citizens to cross-examine a range of experts, deliberate among themselves and then publish their own social assessments of technological alternatives. Sweden, Norway and Germany have pioneered processes for involving workers directly in designing new production systems. The coming revolution in information systems is going to change life for everyone--including the multitude who, by circumstance or choice, never use computers. It is imperative to develop mechanisms for involving all segments of our society in designing, evaluating and governing these new systems. Data highway enthusiasts may see such measures as wasteful obstructions of market forces. But what entrepreneurs call red tape is really democracy in action. __________________ Richard Sclove is executive director of the Loka Institute in Amherst, Mass., a public interest research organization concerned with science, technology and democracy. He also directs the Public Interest Technology Policy Project at the Institute for Policy Studies. Jeffrey Scheuer, a New York writer, is a fellow of the Loka Institute. ***************************************************************** [If you would like more info regarding the Loka Institute, please send an e-mail message to that effect to: resclove@amherst.edu ; however, the staff warns that they may be slow in responding, due to travels. PGN] ------------------------------ Date: Fri, 3 Jun 1994 01:39:59 -0600 (MDT) From: Philip Zimmermann Subject: Zimmermann statement on PGP 2.6 -----BEGIN PGP SIGNED MESSAGE----- From: Philip Zimmermann, author of PGP To: People interested in PGP Date: 28 May 94 On 24 May 1994, the Massachusetts Institute of Technology released PGP (Pretty Good Privacy) version 2.6. PGP is a software package that encrypts electronic mail, using public key cryptography. Over the past three years, PGP has become the worldwide de facto standard for email encryption. PGP 2.6 is being published under the terms of the RSAREF license from RSA Data Security, Inc (RSADSI). This is a significant milestone in PGP's legal development. Export of this software from the US or Canada may be restricted by the US Government. PGP version 2.6 is being released through a posting on a controlled FTP site maintained by MIT. This site has restrictions and limitations which have been used on other FTP sites to comply with export control requirements with respect to other encryption software such as Kerberos and software from RSA Data Security, Inc. These special mechanisms are intended to preclude export of cryptographic software from the US. The MIT FTP site that carries PGP is net-dist.mit.edu, in the pub/PGP directory. This new freeware version of PGP is for noncommercial use. For commercial use, you may get ViaCrypt PGP, available on a variety of platforms. ViaCrypt may be contacted at 602-944-0773, or via email at viacrypt@acm.org. PGP 2.6 is as strong as earlier versions. It contains no back doors. It can read messages, signatures, and keys from PGP versions 2.5, 2.4, 2.3a, and 2.3. Beginning in September, a built-in software timer will trigger PGP 2.6 to begin producing messages, signatures, and keys that cannot be read by earlier versions of PGP. It will still retain its ability to read things from earlier versions after that date, so that users who upgrade to 2.6 will not be inconvenienced, particularly if everyone else upgrades by that time. The reason for the change in format is to grant RSADSI's request to MIT to encourage all users to stop using older versions. ViaCrypt's new products will support the new formats used by PGP 2.6. Details of the compatibility issues and their reasons are outlined in the PGP User's Guide, included in the release package. See also the official statements released by MIT for further details. Version 2.6 also has some bug fixes and improvements of the version 2.5 released by MIT on 9 May 1994. Both the 2.5 and 2.6 versions were produced in a joint project between myself and MIT. Both versions were released by MIT after extensive review by MIT's administration and their legal counsel. I am told by MIT that MIT's legal counsel believes that both versions 2.5 and 2.6 do not infringe the RSA patents in any way, and they both comply with the terms of the RSAREF licenses that each were released under. But regardless of the noninfringing nature of version 2.5, I urge all PGP users in the US to upgrade to version 2.6, to help move toward eradication of earlier, pre-RSAREF versions of PGP. This will improve the overall political and legal landscape surrounding PGP. MIT will publish details on the simple format change so that earlier European versions of PGP may be independently upgraded by the Europeans. This note does not attempt to answer all the questions you may have about the implications of this new release of PGP. For further details, see the information released by MIT, or see the PGP User's Guide in the new release package. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLegMXmV5hLjHqWbdAQE0NAQAiTafSwM8eNfYYvkslNR6bun/GIelvziA M/9h5fn3zUQt2Bc6rkuz1TBlnMZUoduufinI9eSr+cdXbfhxNIQmRArhw3EJd1f+ siZaPmTR3YXvUwuXMcruMbUvEYpSBmtBVrxTzxNSIwx3/hJJB2z9sT1/B+UZdFwi EZX1O/mpiZw= =ULD1 -----END PGP SIGNATURE----- ------------------------------ Date: Wed, 01 Jun 1994 12:50:45 -0600 (MDT) From: "Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067" Subject: "The Hacker Crackdown" by Bruce Sterling BKHKRCRK.RVW 940314 Bantam Books 1540 Broadway New York, NY 10036 "The Hacker Crackdown", Sterling, 1992, 0-553-56370-X, U$5.99/C$7.50 It is important to keep in mind that the crackdown of the title refers to a specific incident: the series of raids in 1990 by various United States law enforcement agencies which tend to be collectively, if incorrectly, subsumed under the code name, "Operation Sundevil". The book brings together a number of the stories surrounding this event, as well as giving some background, particularly in regard to AT&T and the US Secret Service. There are, however, significant gaps which prevent it from being an overall analysis of either the cracker/phone phreak culture or the data security/law enforcement community. As an overview of the 1990 raids, the book is entertaining, often informative, and generally well written. Digressions often provide very interesting background, although at times they consume entire chapters without much bearing on the central issues. Those who were around for the electronic discussions of the 1990 raids will possibly be glad of the collection of all the stories into one place. (Those who have dealt with the crackers, phone phreaks and wannabes will readily recognize some of the descriptions, as well as the repeated emphasis on braggadocio as a primary character trait.) Although Sterling is aware of the debate over the term "hacker"; indeed, he worries over contributing to the degradation of the term; he does not distinguish between the various communities of electronic outlaws. In fact, he states, at one point, that all are the same. Similarly, his contacts with law enforcement and data security people are limited. For these reasons, the book is not useful as a general introduction to the field. The writing is highly opinionated. The US-centric view of technology borders on jingoism. In general, neither law enforcement nor the cracking communities are seen with any favour. Although we can sympathize with Sterling's motivation in wanting to bring to light the injustice done to his friend, the extreme sarcasm which cloaks most of the first half of the book makes it difficult to understand what point he is trying to make. For those involved in data security, a very entertaining read. For newcomers, please take it with a very large grain of salt. copyright Robert M. Slade, 1994 BKHKRCRK.RVW 940314 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: 31 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.11 ************************ 8-Jun-94 21:39:00-GMT,31529;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19569; Wed, 8 Jun 94 17:38:59 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07842; Wed, 8 Jun 94 17:38:42 EDT Received: by chiron.csl.sri.com id AA14692 (5.67b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Wed, 8 Jun 1994 14:31:43 -0700 From: RISKS Forum Sender: RISKS Forum Date: Wed, 8 Jun 94 14:31:39 PDT Subject: RISKS DIGEST 16.12 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Wednesday 8 June 1994 Volume 16 : Issue 12 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: RISKS OF RISKS again (PGN) Hazards of the real-time switchover of a prison system (Ray T. Stevens) Campaigns and Elections (Phil Agre) Library fines unstoppable after earthquake (Geoff Kuenning) Flames and viruses in e-mail - article in the New Yorker (Martin Minow) Tetris addiction? (Mich Kabay) Re: Closed Doors in Glasgow - Trapped Guard Dies in Fire (John Vilkaitis) Re: Risks of too-simple responses (UK ATM Spoof) (Henry J. Cobb, Mathew Lodge, Jerry Leichter) Re: Clipper (Gene Spafford, Sidney Markowitz [2], A. Padgett Peterson, Paul Carl Kocher) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 8 Jun 94 12:00:01 PDT From: "Peter G. Neumann" Subject: RISKS OF RISKS again Sorry for the inconvenience on RISKS-16.11 for those of you who got a truncated original, and apologies for the duplicate in case any of you actually got an untruncated original copy. Our gateway was timing out on even moderately sized outgoing mail and FTPed files (also preventing me from updating the CRVAX archive copy). ------------------------------ Date: 04 Jun 94 15:56:30 EDT From: "Ray T. Stevens" <74074.1746@CompuServe.COM> Subject: Hazards of the real-time switchover of a prison system Our local newspaper, The Herald Times, had a several page spread on the problems relating to a switchover of the local prison to a new control system. Given the length of the spread, and considering that most of it was human interest and not technical, I summarize it here. The prison is being switched from a mechanical to a fully automated system, and this is being done while it contains prisoners. The jailers are complaining about huge amounts of overtime, and spending the whole day "on a dead run". One incident of a technology breakdown was especially insightful. The lights are going to be controlled by this new system, and the wiring for the new system must be run through some of the old wire traces. In order to safely install the new wiring, the existing wiring had to be disconnected, for both the lights and an intercom system so that inmates can contact the guards for requests. To maintain functionality, temporary wiring was used to replace the existing wiring for the lights. To save money, no on-off switches were included. The prisoners must sleep with the lights on. One of the prisoners has sued, requesting release because of cruel and unusual punishment. This has been rejected. A more serious incident occurred with another prisoner. A light had started to burn out, but since it couldn't be turned off, it couldn't be changed, and it started blinking rapidly. One of the prisoners had epilepsy, and the blinking light triggered a seizure. The inmates injuries were exacerbated by the other prisoners not being able to call for help. Pounding on the cells did no good, as this is a common sound in the prison. A lawsuit is in progress. Another prisoner is now using this as grounds for his immediate release. He has a heart condition, and is claiming that this situation puts him too much at risk. No ruling yet. I see one more lawsuit from this. The best defence in a criminal case is frequently delay. I can see what may be a very valid comment from the a defendent's lawer. "I must request a continuance on the basis of temporary incompetence of my client. The county has been illegally depriving my client of sleep, and he is now too sleepy of competently participate in his own defence." Under the right circumstances, I would say this might be worth about a two-month delay. ------------------------------ Date: Mon, 6 Jun 1994 18:09:55 -0700 From: Phil Agre Subject: Campaigns and Elections I encourage everyone to have a look at an issue of the magazine "Campaigns and Elections". It's a monthly, sold at many newsstands (in the US anyway), for the people who run political campaigns. Every issue includes numerous references to the growing role of computers in campaigning. Now I'm sure that this trend has its good sides and its neutral sides and its complicated sides. But inside the back cover of the May 1994 issue is an advertisement from a political software company whose headline is "The age of individual targeting is upon us". In other words, everyone gets their own personalized direct-mail pitch, based on a detailed database of information relevant to your likely political leanings. One use of such databases is basic demographics for choosing issues to emphasize; another is deciding who should be approached personally and urged to vote. But a scarier use of such databases, not mentioned in the ad, is the tailoring of messages to individual voters. For example, a group of land developers in San Diego is promoting an initiative for tomorrow's primary election that would open up the last parcel of wild land in San Diego to development. Their campaign has been incredibly sophisticated, including numerous tactics that aren't relevant here. The part that *is* relevant here is a letter I received over the weekend encouraging me to vote Yes on the initiative. Along with the letter were two inserts containing endorsements from the leader of the local AFL-CIO and a Hispanic city council member from another district. Did the guy around the corner with the "Rush is Right" bumper sticker get the same inserts? He didn't have to, if the developers had access to a suitably "enriched" database. In the future you won't even have to bother putting together a coherent coalition; just find out what everybody's hot issues are and make them all whatever promises you need to make, one by one, the Saturday before the election, so nobody has time to compare notes. Campaigns and Elections, 1511 K St NW #1020, Washington DC 20005, USA. Subscriptions $30/year in the US, write for prices elsewhere. Phil Agre, UCSD ------------------------------ Date: Tue, 31 May 94 13:31:29 -0700 From: geoff@FICUS.CS.UCLA.EDU (Geoff Kuenning) Subject: Library fines unstoppable after earthquake >From an article by Rebecca Bryant in the Los Angeles Times Valley Section, Thursday May 19th: The Los Angeles City library system is sending out overdue notices for books that had been checked out before the January 17th earthquake. The only problem is that readers have been told that they can hang on to their books until the damaged branches reopen. "Now wait a minute," writes Bryant. "Who[m] do you believe? The library? Or, uh, the library?" The problem arose because the computer system used to generate the notices does not allow notices to be selectively disabled based on the branch at which the book was originally checked out. The only way to stop the notices would be to stop sending notices for all branches. But many branches remain open, and of course there are always delinquent readers. According to Robert Reagan, a library spokesman, the system is due to be replaced soon. Although the article does not state this explicitly, there is an implication that the new system will support better per-branch control. This is in many ways not just a computer risk. The original programmers, designing an integrated system, can be forgiven for failing to predict the day when their customers would want to shut down only half of it, based on unforeseen criteria. Furthermore, it is easy to imagine an integrated manual system with the same (if you will excuse the expression) fault. Nevertheless, readers are confused and the library is embarrassed. I guess it's a pretty minor, though amusing, footnote to a major disaster. Geoff Kuenning geoff@ficus.cs.ucla.edu geoff@ITcorp.com ------------------------------ Date: Sat, 4 Jun 94 13:42:43 -0700 From: Martin Minow Subject: Flames and viruses in e-mail - article in the New Yorker RISKS readers might find John Seabrook's article in the June 6, 1994 issue of the New Yorker interesting. He had previously written a profile of Bill Gates, chairman of Microsoft (January 10, 1994) and received an obscene and obnoxious message from "a technology writer who does a column about personal computers for a major newspaper." In true New Yorker tradition, Seabrook used this message as a vehicle to comment on network etiquette and on the possibility that some strange aspects of the message might indicate that the message contained a "worm" or "virus." (My own reading of the evidence presented is that there is nothing to worry about.) Of particular interest to Risks readers might be Seabrook's fear that any strangeness in the message might indicate an attack, and on the general way in which extending the net to "an estimate twenty-three million users ... ten million of which have come on-line in the last nine months" has affected the culture of network communications. RISKS readers -- at least those of us who have been around since the net was a self-regulated anarchy -- will find his comments on the way this anarchy is, or soon will be, dying away very interesting. Martin Minow minow@apple.com ------------------------------ Date: 28 May 94 21:41:39 EDT From: "Mich Kabay [NCSA Sys_Op]]" <75300.3232@CompuServe.COM> Subject: Tetris addiction? >From a Canadian newspaper, _The Globe and Mail_, 28 May 1994, p. D1: <> by Jim Carlton of the Wall Street Journal <> The author continues with the following key points: <> o Nintendo estimates that 40% of the purchasers of its handheld video game, Game Boy, are women--twice the percentage of woman buyers of other game machines. Nintendo guess that the difference may be due to the Tetris game bundled into the Game Boy. o Several anecdotes are presented about women who enter trance-like states as they play the game. o Seattle psychologist Barbara Mackoff works for Nintendo; she thinks that busy women see Tetris as "a mind-soothing break." o Gini Graham Scott is a sociologist from Oakland, CA who also works for Nintendo. She wonders if "neatly aligning Tetris' falling clusters" is peculiarly satisfying to women because of their "craving for order." o Dr Scott also wonders if Tetris appeals to women's "holistic way of seeing things." o Dr Mackoff warns that playing compulsively with Game Boy can lead to "driven, pleasureless participation that excludes socializing and other creative forms of relaxation." o One woman wrote to Nintendo in alarm because her mother, a 66-year-old retired teacher, now spends an average of five hours a day playing Tetris. Her reading has fallen from two books a week to two books a month. Her mother doesn't think there's anything wrong. <> [MK comments: 1) There is no convincing evidence provided in this article about the supposedly different rates of addiction or compulsion to Tetris by men and by women. The article simply relates anecdotes and speculation. 2) Professor Mihaly Csikszentmihalyi of the University of Chicago has been studying what he terms "autotelic" behaviour for many years. Examples include computer programming, rock-climbing, many competitive sports, running, making models and so on. The essential attributes of an autotelic activity are that it is repetitive, is at the limits of one's skill, and provides many opportunities for measuring progress or achievement. When in the midst of an autotelic activity, Prof. Csikszentmihalyi explains, one loses track of time and even of normal body responses such as hunger or tiredness. Programmers who have said to themselves (or their spouses), "Just one more compile and then I'll come home" and then found themselves fourteen compiles and three hours later have experienced what Csikszentmihalyi calls "Flow" (the title of one of his recent books*). Participating in this Forum, for example, is an autotelic activity. I have to consciously govern how often I log on to check on new messages. Left to uncontrolled impulse, I might end up online all the time--to the detriment of the rest of my life and with severe consequences for my marriage (here my wife concurs vigorously). Computer games are analogous to any other kind of game. However--and this is sheer speculation--the combination of speed, colour, sounds and control may make the games even more likely to cause Flow than mechanical games do. Consider, for example, the attraction of mechanical pinball vs games with marbles; or of a mechanical shooting gallery compared with a video gun game. Another factor may increase addictiveness: computer-controlled games often increase their difficulty as a function of the player's skill; this tendency puts them in line with Csikszentmihalyi's ideas about Flow. I wonder if the propensity for flaming is an expression of Flow? Do people provide a positive feedback loop simply by seeing their own expressions of anger or dislike? Devoid of other people's reactions while they write, perhaps flamers reach a paroxysmal state of rage and bliss all by themselves. Finally, the same phenomena may be part of the attraction of role playing games, discussed in RISKS some months ago in connection with a young man who became addicted to his fantasy world.] Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn *Csikszentmihaly, M. (1990). _Flow: The Psychology of Optimal Experience_. Harper and Row (New York). ISBN 0-06-016253-8. xii + 303 pp. ------------------------------ Date: Sat, 4 Jun 1994 00:37:06 -0700 From: javilk@netcom.com (John Vilkaitis) Subject: Re: Closed Doors in Glasgow - Trapped Guard Dies in Fire Failure to provide a reliable emergency exit is usually a violation of local fire and other ordinances. The RISK is civil and criminal prosecution, not MERELY lost sales. This, and many other seemingly senseless problems have at their root, a failure of the analyst to IMAGINE HIMSELF using the system. Sometimes this is the fault of the analyst, often it is simply because management refused to give the analyst (or the programmer) time to calmly "daydream" himself using the system and encountering typical situations and problems. If you cannot imagine in your head what you are building, you RISK building trash, often dangerous trash. "Imagination is more important than facts" - Albert Einstein It takes both FACTS and IMAGINATION to build good systems, but no one seems to teach us to use the broader power of our imagination, insisting we use the far narrower term "THINKING". -JVV- (J. Vilkaitis, javilk@netcom.com, 408-983-0518 voice/fax) [John, I guess you have to be THIN-KING to slip through the emergency exit. See my article, Psychosocial Implications of Computer System Development and Use: Zen and the Art of Computing, in Theory and Practice of Software Technology, D. Ferrari, M. Bolognani, and J. Goguen, eds., North-Holland, 1983, for a discussion of how both left-brain and right-brain activities must be used and properly integrated. PGN] ------------------------------ Date: Wed, 1 Jun 1994 19:52:49 -0700 From: "Henry J. Cobb" Subject: Re: Risks of too-simple responses (UK ATM Spoof) (RISKS-16.10) Jerry Leichter suggests that ATMs be "hardened" to spoofery by reading the "noise" built into the card during manufacture rather than the digital signals encoded on them. The risk to this is once the scanner that detects the noise is out in the field in large numbers, it becomes just another fixed system to spoof. Before you counter with "We'll just push down to the quantum level!" consider if you'd want real people in the real world walking around with cards depending on this. (And please no "Are you displeased to see me, or is that just a quantum in your pocket?" jokes from the moderator.) Digitally secure smartcards are not only the geek thing to do, they're the right thing to do. As for the installed base of "dumb" cards, this can be wiped clean by proper legislation or simple liability. All that is needed is to abolish the NSA and go back to being a free nation. ------------------------------ Date: Fri, 3 Jun 94 17:22:47 BST From: Mathew Lodge Subject: Re: Risks of too-simple responses (UK ATM Spoof) (RISKS-16.10) Perhaps Jerry has never been to France. All French credit cards are smart cards, and have been in mass use for several years now. The French don't seem to be having any problems with fragility or expense. As to backward compatibility, this is solved by the extraordinarily simple measure of allowing the card readers to deal with both smart cards and ordinary magnetic stripe cards. Thus I can use my Visa card in France with no problem (the only difference is that there is no immediate validation using my PIN as there is for smart cards). > In practice, my bet is that we will *never* see the replacement of magnetic > stripe cards by smart cards. I think this is a little too pessimistic. Mathew Lodge, Software Engineer, Schlumberger Technologies, Ferndown, Dorset, UK, BH21 7PP lodge@ferndown.ate.slb.com) +44 (0)202 893535 x404 ------------------------------ Date: Fri, 3 Jun 94 22:07:00 EDT From: Jerry Leichter Subject: Re: UK ATM Spoof (Cobb, Lodge, RISKS-16.12) On Henry J. Cobb's fixed system to spoof: We've been using pin-tumbler and mechanical combination locks for many, many years. In fact, that's exactly what protects the money actually stored inside of ATM's - along with fairly simple electrical alarms, which haven't changed much in many years either. All "just another fixed system to spoof". Clearly the only hope is "digitally secure smartcards", a technology that has seen all of 20 years worth of development and testing in the real world, against real attackers. By all means, let's convert everything immediately. After all, these new systems are based on *digital computers*! Clearly they are better, more secure! Computers never make mistakes, after all! On Mathew Lodge's response to my statement ("In practice, my bet is that we will *never* see the replacement of magnetic stripe cards by smart cards."), saying that he thinks this is "a little too pessimistic": As Mark Twain said, it's a difference of opinion that gives us horse races. (Well, he said it better, but I don't recall the exact words.) We've both made our predictions. I'll sharpen mine: Five years from now, smart cards will represent no more than 5% of the US market for bank and charge/debit cards; some variation of magnetic stripe technology will make up essentially all the remaining 95%. Shall we revisit this in 1999? ------------------------------ Date: Fri, 03 Jun 94 19:20:45 -0500 From: Gene Spafford Subject: Clipper In today's mail I got a glossy brochure extolling Clipper. It promises to "Expand your creative universe with real-world solutions." Is it a new ploy by the government to subvert our privacy? No, it's an advertisement by a company named Dynamic Graphics for their CD-ROM clip art magazine. "Clipper" is their registered trademark. I wonder if they registered the trademark recently? I would have pitched the flier immediately had I not noticed the word "Clipper" in large letters. I can't recall hearing about them before, either.... Has "Capstone" been registered yet, or "Tessera"? :-) On the other hand, it might be they had the name picked out over a year ago and their business will go south as a result of recent events. The risk? Naming a product something catchy just before a government agency nicknames something unpopular the same name. (Alternatively, there's a risk in trying to avoid this -- naming a product "Facist Thought Control" is likely safe from collision, but won't help sales. :-) ------------------------------ Date: Fri, 3 Jun 1994 20:14:29 -0700 From: sidney@taurus.apple.com (Sidney Markowitz) Subject: Details of flaw in Clipper I have seen lots of discussion about the New York Times report on Matt Blaze's discovery of a flaw in Clipper's key escrow system, with more confusion than anything else. Here is the best article that I have seen on the net explaining exactly what Dr. Blaze has found. There's also confusion about the implications. My understanding is that this method might allow someone with a Clipper chip device to have a secure communication with another person with a Clipper device that could not be decrypted by law enforcement *and* it does not require the cooperation of the second person. That last part is what makes this significant, since two people can agree to just encrypt their messages with, say PGP, if they want to be secure from law enforcement decryption. But if Blaze's method is practical, the widespread use of Clipper would make it harder on law enforcement by making it easier than it is now for someone to have secure communication with people without having to plan with them to do so. -- sidney markowitz [begin quote of Message-ID: crossposted to sci.crypt, talk.politics.crypto, alt.policy.clipper] [Run in RISKS with permission of "Perry E. Metzger" . PGN] Many people have misconceptions about what Matt did. Based on his paper (no, you can't have a copy since he told me not to distribute it; I'm sure he'll release it when its ready for prime time) and discussions with him, the trick is this. [The Escrowed Encryption Standard is abbreviated as EES.] The LEAF acts much as an key to tell the EES unit that it should function. It contains three elements: 1) the 32 bit unit id of the EES unit generating the LEAF 2) the 80 bit session key, encrypted in the escrowed key for that unit. 3) a 16 bit checksum based on the unencrypted session key and the initialization vector (IV) for the session. All three components are concatenated to form a 128 bit unit, which is encrypted in the family key in order to produce the LEAF, reportedly using a unique mode of Skipjack. The remote unit takes in the LEAF, decrypts it with the family key, and checks the cleartext session key and IV to see if they produce the proper 16 bit checksum. If so, it accepts the LEAF and functions properly. Note that the encrypted key inside the LEAF is useless to the remote EES since it doesn't have the other EES's escrowed key. It has to rely on the cleartext session key and IV alone to check that the checksum looks right. Sadly for the NSA, the checksum is only 16 bits long. Given a session key and initialization vector, I can fairly quickly generate a large number of fake LEAFs (chosen at random) and find one that a captive EES unit will accept as being the right LEAF for a given session key/IV. The contents of the LEAF will be garbage, but the remote unit will not know that, and will happily go along with using it. I needn't know the family key, or even the checksum algorithm. The point here is, of course, that I can freely interoperate with non-rogue EES units -- I can communicate with non-subverted units without revealing my privates hidden beneath the LEAF. (sorry for the pun.) [*] By the way, Matt had to figure out the components of the checksum on his own -- the mechanism for calculating it and where it came from were not documented. BTW, for those who have asked, in case the preceding didn't make it clear, can't you just reuse an old LEAF or a stolen LEAF because the session key/IV won't correspond and the checksum won't be right -- you have to generate and test. Perry Metzger perry@imsi.com [end quoted message] [*] [Turning over a new LEAF is better than if you LEAF well enough alone, he suggested FIGuratively. PGN] ------------------------------ Date: Mon, 6 Jun 1994 19:29:45 -0700 From: sidney@taurus.apple.com (Sidney Markowitz) Subject: Blaze's Clipper paper available via ftp Matt Blaze is the AT&T researcher who has made the news recently for discovering a flaw in the Clipper protocol. I saw an announcement from him that a preliminary draft of his paper "Protocol Failure in the Escrowed Encryption Standard" is available via anonymous ftp from resarch.att.com in the file /dist/mab/eesproto.ps in PostScript format. He cautions that there will be a final version of the paper which will likely include additional material on the production version of the PCMCIA card, and that this draft is based on his examination of a prototype card. -- sidney markowitz ------------------------------ Date: Sat, 4 Jun 94 22:35:29 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Flaw ? in Clipper This has already gotten out of hand on the Usenet. In simplest terms, what Matt Blaze found is that is is possible to spoof a CLIPPER LEAF (law enforcement access field). IMHO this is almost meaningless since *both* ends will need to do this (AFAIR each side sends a LEAF. If only one LEAF is spoofed, it will just be necessary for a legal tapper to use the other one). Thus to be effective, both ends will need special spoofing equipment and in that case they might as well use something other than Clipper. Even better use something different but prefix a valid Clipper LEAF. Right. Remember Occam's Gillette. Dr. Blase also mentioned that it would take about 20 minutes to come up with a valid checksum. Much easier would simply be to record a valid LEAF from another chip and use that. The most important element is that the SKIPJACK algorithm is in no way affected by this and is as strong as ever, only the government's ability to use the LEAF may be compromised. I still expect the government to drop key escrow when the hardware is ready and that there will still be two means available to defeat Clipper available to the government - without using any backdoor/trapdoor and without any weakness in SKIPJACK (see my earlier postings - one is similar to the way GSM can be tapped now). Personally, I feel that Clipper is a valuable mid-range low-announced- cost device that is "good enough for government work". PGP or triple DES used in combination with Clipper is a viable next step up. Padgett P.S. Anyone notice Enigma-Logic's announcement of a one-time-password-token emulation for the PC @ US$10/user (maybe less) ? Certainly an answer to sniffers. ------------------------------ Date: Tue, 7 Jun 1994 03:19:55 -0700 From: Paul Carl Kocher Subject: Re: Flaw in Clipper detected (Huggins, RISKS-16.11) Although I doubt people will modify devices with hard-wired Clipper chips, this is seems to be a very serious blow to Tessera (the government's PCMCIA card with a Clipper chip). Tessera has a standard programming interface that passes the programmer's calls to the encryption card. Any experienced assembly language programmer could easily add "support" for Blaze's technique for bypassing the LEAF (Law Enforcement Access Field) validation check. This could be done transparently and without significantly impacting performance. It could also fix up the side effects of the attack (e.g. the first block is bad in CBC mode, etc). Under MSDOS this could be done with a TSR that would intercept calls to the card directly, so it would work with all Tessera applications. The same TSR could also substitute pre-computed and/or brute-forced LEAFs for interoperability with non-cheating users. We were told that the reason for having escrowed keys and a secret algorithm was to keep terrorists from having strong crypto. Now the bad guys have full-strength SkipJack, the public has a flawed "standard," and because the algorithm is classified we can't look for other problems. I'm also wondering what's going on inside NSA -- DSS originally had alarmingly-small keys and has been widely criticized, SHA was defective, and now this... -- Paul Kocher kocherp@leland.stanford.edu ------------------------------ Date: 31 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. EXCERPT. SEE OTHER ISSUES FOR FULL STATEMENT. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. ------------------------------ End of RISKS-FORUM Digest 16.12 ************************ 10-Jun-94 0:17:52-GMT,29136;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04568; Thu, 9 Jun 94 20:17:51 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11854; Thu, 9 Jun 94 20:16:22 EDT Received: by chiron.csl.sri.com id AA16601 (5.67b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Thu, 9 Jun 1994 17:07:44 -0700 From: RISKS Forum Sender: RISKS Forum Date: Thu, 9 Jun 94 17:07:41 PDT Subject: RISKS DIGEST 16.13 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Thursday 9 June 1994 Volume 16 : Issue 13 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: RISKS summer slowdown (PGN) False alarm in Channel Tunnel (John Colville) Apathy toward computer errors (Chip Seymour) Mailing-list software security problem (Jim Patterson) GIF contains more than just a picture (Matthew David Aldous) Re: "The Ghost in the Modem" (Scott Dickson) Re: China Airlines A300 Crash (Mark Terribile) Re: Flaw ? in Clipper (A. Padgett Peterson, Robert I. Eachus) WWW Virtual Library page on safety-critical systems (Jonathan Bowen) "Network Security Secrets" by Stang (Rob Slade) Re: "The Hacker Crackdown" by Bruce Sterling, via WWW (John Oram) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 7 Jun 94 9:42:08 PDT From: "Peter G. Neumann" Subject: RISKS summer slowdown RISKS is about to enter its customary summer slowdown period, including the next month or so during which I will have only sporadic net access. Please do not expect to get rapid response to your requests or frequent issues. However, please keep the incisive contributions coming, and I will get to them whenever possible. I wish you all a peaceful and productive summer season. PGN ------------------------------ Date: Wed, 8 Jun 1994 11:06:17 +0100 (BST) From: John Colville Subject: False alarm in Channel Tunnel As reported on BBC Radio, Wednesday 8 June 1994: A train travelling through the Channel Tunnel from England to France, was evacuated after an emergency light came on in the driver's cabin. The drivers of the 10 lorries [Amer: trucks (JC)] who were being carried on the train were evacuated to the English end of the Tunnel, through the access tunnel. This was the first emergency on the Channel Tunnel which officially opened last month. It turned out that the emergency was a false alarm. John Colville, Visiting Brunel University John.Colville@brunel.ac.uk +44 895 274000 ext 2561 until June 1994, from University of Technology, Sydney ------------------------------ Date: Tue, 31 May 1994 08:27:36 EST From: Chip Seymour Subject: Apathy toward computer errors The Worcester (MA) Telegram of Saturday, May 28, carries a front-page article regarding "a mistake by the city Election Commission [which] nearly cost [name deleted] his wife." A week before, a city resident "opened his mail to find a computer-generated census form from the city." Apparently, he didn't look at the form closely, and when he handed it to his wife for her signature, she noticed the name of the person living with him at the same address was not hers. She had just returned from one of many extended visits with an out-of-town daughter. "'Who is this Beverly that's living with you?' his wife, Barbara demanded. 'Come on, Barbara ... nobody is living with me,' he shot back. 'Well, they got it right here,' she countered, pointing to the name Beverly A. [different last name] on the form. 'If I find out, I'm going to get a divorce.'" After a call to the city Election Commission, he discovered that the presence of the Other Woman is an error that may be attributed to the fact that he lives in an apartment building for senior citizens, and the Other Woman lives in another apartment in the same building. A spokesman for the Election Commission said if the victim "crosses out the incorrect information and mails the form back to City Hall, it will be corrected in the computer." The victim "says he has no intention of signing and sending in the erroneous form - and if his name is removed from the voter registration list, which is the penalty for failing to respond to the census, 'somebody else is going to have a lot more trouble.'" "'I'm not going to send it in. They make too many mistakes, and I'm not going to rectify their mistakes,' he said. 'I can't see why people have to keep paying for their mistakes all the time.'" He says this is the "last straw." The RISKS? If the City Election commission relies solely on returned census forms, accidental and intentional inaccuracies will remain. Given the current economic climate in the NorthEast, it's not likely local government will verify the information on every returned census form containing corrections. Another risk is the perceived apathy on the part the public. If this fellow refuses to correct and return the form, how is the Election Commission going to correct the error? What if others follow his lead? A third risk was mentioned by the Other Woman, who had not received a census form this year: "The census form is supposed to be confidential, but went to the wrong place." ------------------------------ Date: Tue, 7 Jun 1994 21:24:49 -0700 (PDT) From: jhp@photon.com (Jim Patterson) Subject: Mailing-list software security problem Several perfect examples of software risks here. First is running a security mailing list with software that has security problems. Then the ever popular quick change to complicated software that generates unexpected (and annoying) results. Finally, there were the users sending messages complaining about the duplicate messages to the list which were promptly forwarded to the list, in triplicate. from the keyboard of bugtraq-owner@cscns.com -> > Sorry. I made some changes to the list code because of a serious > security hole found within the list software (a popular one). > This apparently caused things to go bonkers. Please stay patient. > The author of the mailing list software will release information > regarding the security vulnerability within the next few days. > --Scott Hope you found this as amusing as I did. Jim Patterson Photon Research Assoc. jhp@photon.com ------------------------------ Date: Thu, 9 Jun 94 17:34:40 EST From: aldous@mundil.cs.mu.OZ.AU (Matthew David ALDOUS) Subject: GIF contains more than just a picture I'm currently involved in a software development project, writing software to assist medical diagnosis of brain scans. Although I've ploughed through abound 50 pages of documentation now, without actually coding a single line, I decided it was time to whip up some "vapourware" snap shots of the screen I was intending to use. These I created in a paint program, and whisked off to the supervisor for a critical review, etc.. Paper can only say so much.. The response I got was going as would be expected. Some suggestions for layout, color schemes, font sizes, etc.. Until I got to section 6.. ---- 5 yellow cross-hairs stand out better - is the red arrow for some reason? Not apparent what (or if) 6 not knowing what all the options were, I tried playing with a few. I certainly ended up with some images I did not expect. I figured I should be able to get back to where I started by a judicious choice of operations. Alas - not so judicious. I certainly did not expect to get the text in mirror-image form, even if the picture was. I also thought 'normal' would redraw the original image, but this was not so. Is there some easy option to get back to where you started? ---- I was quite taken back. I had only submitted a gif, but my supervisor was suddenly telling me about all the "options" etc. Gollies, a GIF with a built in OS independent GUI... Turns out, the supervisor had been using "xv" to view the GIF, and had accidentally clicked the right mouse button on the picture at some stage, opening the "xv edit screen", and assumed that the new window was part of the submission ,etc. (Gosh, that _IS_ overwork.) The RISK ? Having a totally foreign program pretending to be mine, without any intent. Was "xv" too user-friendly? Gollies, I was subsequently told that if I hadn't questioned the response that it would have been assumed I was working extra hard.. :) We all had a good chuckle over it, and went back to work :) [Hmm, I suppose that someone is going to come along and refer to "xv" as the FIFTEEN program, which is NINE more than "vi", which is sometimes mistakenly referred to as the SIX EDITOR (according to a sighting reported to me by Caveh Jalali)! PGN] ------------------------------ Date: Wed, 8 Jun 94 11:11:41 PDT From: scott@ontek.com (Scott Dickson) Subject: Re: "The Ghost in the Modem" (RISKS-16.11) Regarding a recent RISKS posting of the article "THE GHOST IN THE MODEM" by Richard Sclove and Jeffrey Scheuer of The Loka Institute, I fail to see how the rather insightful analysis of the impacts of government meddling in favor of highway-based transportation supports the conclusions: > Three lessons for the construction of the information superhighway > suggest themselves: > > o _No Innovation Without Evaluation_: ... federal government should > mandate evaluated social trials ... > > o _No Innovation Without Regulation_: We should conserve cultural > space ... > ... modest tax on electronic home shopping and consumer services ... > > o _No Innovation Without Participation_: ... the Danish government > appoints panels of everyday citizens ... These conclusions would lead us down the same road of the government using regulatory and taxing powers to distort the application and development of technology. A common mistake is for people to observe or foresee a danger and demand that government do something about it. They fail to take into account the risks involved in getting government involved, with its tax and regulation sledgehammers. This is appropriate when the dangers to be mitigated are great enough, but is not something to be suggested lightly. In many cases, people may be better off accepting the risk of the danger than putting up with the effects of government involvement. The kind of preemptive government involvement advocated in this case is particularly questionable, since the dangers aren't really known and premature government meddling may actually make things worse (as the authors argue may have happened in the case of transportation). Scott Dickson scott@ontek.com ------------------------------ Date: Fri, 3 Jun 1994 18:48:11 -0400 From: mole-end!mat@uunet.uu.net Subject: Re: China Airlines A300 Crash (Yesberg, RISKS-16.09) The proper solution is not to increase the number of modes, but to decrease the number of modes--to ONE. `Less advanced' aircraft, which I believe include Boeing aircraft, use their sophisticated flight control systems to make the plane behave like a simple plane with simple controls. `Fly by wire', to their designers, means `make the best, and best-behaved, simulation of a plane with direct linkage from controls to control surfaces.' `More advanced,' in Airbus case, means `having a greater chance for error.' This has been debated in the aircraft industry, but the FAA has not seen fit to refuse certification to Airbus. My own belief, unsupported by professional qualification of any kind, is that this is a serious mistake, perhaps unavoidable due to the political nature of the Airbus Consortium. If I understand correctly, Airbus was forced to use these multimode control systems because some of its aircraft use sidestick controllers. Sidestick controllers provide very little range of motion compared to the traditional yoke (wheel on a moving stick/post), and the pilot effectively flies using pressure rather than position of the sidestick. This is fine during normal flight, but during takeoff and landing the control surfaces must be moved through large excursions, and the additional control modes are needed to allow this. There is another serious problem with the control mechanism described: the autopilot used one set of control surfaces (stabilizer trim) while the pilot continued to operate another (elevators). In effect, the aircraft and its inherent flight laws provide the summing of the control inputs. For such an arrangement to work at all, the summing process must remain linear, must not interfere with the flight of the aircraft in other ways, etc. Clearly, this did _not_ happen. An unqualified person such as myself has to wonder what happens when the stabilizer is canted one way and the elevator is canted the other. The result, it seems to me, should be excess drag and a disrupted airflow, leading to reduction or loss of control response to both inputs. There is a third problem: the pilot has no indication through his controls that the autopilot--in effect, the aircraft's control laws--are actively working against him. In an emergency, there are only two things he is likely to pay attention to--the primary instruments and the controls under his hands and feet. If he were to put the plane to the edge of a stall, either the natural buffet of the stall or an artificial stick-shaker designed to simulate the buffet would alert him. _That_ is probably the proper place to inform the pilot that he is working the aircraft against the edge. I don't fly much, but if I find myself booked on an Airbus plane I will look for an alternate booking. Mark Terribile mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ ------------------------------ Date: Thu, 9 Jun 94 13:43:58 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: Flaw ? in Clipper Earlier I wrote re Clipper LEAF spoofing: >> IMHO this is almost meaningless since *both* ends will need to do this >> (AFAIR each side sends a LEAF. If only one LEAF is spoofed, it will >> just be necessary for a legal tapper to use the other one). and received the following correction: >According to a talk here at MIT given by two NSA mathematicians the >day the NYT broke the story (a happy coincidence :-), this is not >true. Using Capstone/Tessera, only one LEAF is sent, by the >originating party. I wrote: >> Dr. Blase also mentioned that it would take about 20 minutes to come >> up with a valid checksum. Much easier would simply be to record a >> valid LEAF from another chip and use that. and was again corrected: >Can't do that, as Perry said. The LEAF is a function of the session >key, so it needs to be spoofed for each session. What happens appears to be (after reading the draft of Dr. Blase's paper but with some inference - any mistakes are mine) that the receiving Baltimore Clipper decodes the LEAF sent by the originator using the family key, replaces the sender's unit-key-encrypted session key with its own clear session key, mixes in the originator's unit id (also in the LEAF), calculates a new checksum, and compares this with the one received. The obvious implication is that what Dr. Blase was altering may not have necessarily been the checksum (IMHO it was the unit ID) but probably was the last sixteen bits of the LEAF. I leave the implications to those who have the good fortune to have received samples. But then and again it is all moot since IMHO the gov (or at least the Clips, Billary may not have been completely filled in) do not intend to use the LEAF anyway. Padgett [Various similar comments are not included here.] ------------------------------ Date: Thu, 9 Jun 1994 10:28:23 -0400 From: "Robert I. Eachus" Subject: Flaw ? in Clipper [Some duplication w. the previous item] A. Padgett Peterson (padgett@tccslr.dnet.mmc.com) wrote: > IMHO this is almost meaningless since *both* ends will need to do > this (AFAIR each side sends a LEAF. If only one LEAF is spoofed, > it will just be necessary for a legal tapper to use the other > one). As far as I am concerned, this is why the flaw Dr. Blase discovered is so damning. If the effect of an authorized wiretap on an EES phone is that the correspondents [?] key is removed from escrow, this destroys the entire purpose of the system. For example, a call in a mobile system would involve a chip in the phone, and a chip in the base station. If the result of a legal wiretap on a LEAF-blower equipped mobile phone is that the keys of all the base stations in the vicinity are turned over to the tappers, the escrow system protects no one. > Dr. Blase also mentioned that it would take about 20 minutes to > come up with a valid checksum. Much easier would simply be to > record a valid LEAF from another chip and use that. This is a double misapprehension. First, the twenty minutes (divided by the number of chips used) delay is only associated with some modes of use. Second, the problem is not in collecting LEAFs, but in finding one that will be accepted by your correspondent for THIS call. In some cases that will be doable in advance, in others it will be easy, and in a few cases it may have to be done "the hard way" after the call has been initiated. > The most important element is that the SKIPJACK algorithm is in no > way affected by this and is as strong as ever, only the > government's ability to use the LEAF may be compromised. Not quite true. Being able to "peer through" the crypto protection is usually the first step in a complete crack. In this case it opens up (actually makes more effective) avenues of attack, which while they seem computationally infeasible today, may shorten the effective lifetime of the EES system. Robert I. Eachus ------------------------------ Date: Thu, 9 Jun 94 14:57:32 BST From: Jonathan.Bowen@comlab.oxford.ac.uk Subject: WWW Virtual Library page on safety-critical systems I have created a WWW Virtual Library page on safety-critical systems, including links to on-line RISKS information, under: http://www.comlab.ox.ac.uk/archive/safety.html Relevant information with URL links for possible inclusion, preferably in HTML format, is welcome. Jonathan Bowen Oxford University Computing Laboratory http://www.comlab.ox.ac.uk/oucl/people/jonathan.bowen.html ------------------------------ Date: Thu, 09 Jun 1994 10:24:59 -0600 (MDT) From: "Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067" Subject: "Network Security Secrets" by Stang BKNTSCSE.RVW 940324 International Data Group 155 Bovet Road, Suite 310 San Mateo, CA 94402 USA tel 415-312-0650 fax: 415-286-2740 "Network Security Secrets", Stang, 1993, 1-56884-021-7, U$49.95/C$64.95 norman@digex.com It's hard to have confidence in a book on data security that starts off with two examples of "back doors" -- neither of which have the slightest connection to back doors. Then, there is the example of radiation risks which cites a study probably more related to chemical exposure. Do not lose heart, however. These are apparently aberrations in what is otherwise a very practical and down-to-earth security manual. That opening chapter on specific examples starts a section on risk analysis. Security mavens may find it lacking in rigour and overlong in verbiage, but most micro/LAN/office managers have little formal training in the formal aspects of data security and need the example after example approach. The questionnaires and quizzes probably drive the point home as well as, or better than, Stang's love of charts. Part two is a bit weaker. It opens with a questionable chapter on the "players" in the game: data security versus the hackers. There is a chapter on the security aspects of network design. Given Stang and Moon's background in the NCSA the two virus chapters are no surprise, and generally good. Part three gives more detail (*lots* of detail in the tabular reviews of chapter 12) on security solutions, policies and products. Not exhaustive: the password chapter, in looking at security *breaking* programs, makes no mention of the HACK program for obtaining any passwords used over Ethernet or the KNOCK program which exploits a bug in versions of NetWare which allows anyone to gain SUPERVISOR access without passwords. Still, there is much practical help for the LAN manager here. Part four looks at specific network operating systems and the security features and functions thereof. As well as comparisons of the different systems, there are chapters collecting the security commands and concepts of each. These are handy, but not necessarily more so than the original documentation. NetWare "effective rights", for example, continue to bedevil LAN managers using Novell's software. All the parts are included here, but the calculation of effective rights is not deal with. (There is also one "oops". The chapter on UNIX security contains a description of the VMS "WANK" worm.) Part five looks at ways to implement security. An unusual, but very valuable, section in the chapter on training is an extensive list of training available in a variety of security related areas. (Most of the virus courses seem to be given by an outfit called Norman Data Defense Systems. Oh well.) Part six briefly describes the shareware files on the included disks. A series of appendices primarily give contact information. It'll be difficult to get a busy LAN manager to sit still long enough to read this. But it'll be worth it. copyright Robert M. Slade, 1994 BKNTSCSE.RVW 940324 DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 BCVAXLUG ConVAXtion, Vancouver, BC, Oct. 13 & 14, 1994 contact vernc@decus.ca ------------------------------ Date: Thu, 9 Jun 1994 00:39:34 -0800 From: oramy92@halcyon.com (John Oram) Subject: Re: "The Hacker Crackdown" by Bruce Sterling, via WWW Bruce Sterling has released 'The Hacker Crackdown' electronically. It is available via WWW at http://www.eecs.nwu.edu/hacker_crackdown/index.html (This is a mirror of http://www.scrg.cs.tcd.ie/scrg/u/bos/hacker/hacker.html) [But be sure to read the preface about the copyright and why and how Bruce is also making the book available on-line. I have excerpted the beginning of the preface here, because it is too long to include here. PGN] The Hacker Crackdown Preface to the Electronic Release of The Hacker Crackdown Out in the traditional world of print, The Hacker Crackdown is ISBN 0-553-08058-X, and is formally catalogued by the Library of Congress as "1. Computer crimes -- United States. 2. Telephone -- United States -- Corrupt practices. 3. Programming (Electronic computers) -- United States -- Corrupt practices." `Corrupt practices,' I always get a kick out of that description. Librarians are very ingenious people. The paperback is ISBN 0-553-56370-X. If you go and buy a print version of The Hacker Crackdown, an action I encourage heartily, you may notice that in the front of the book, beneath the copyright notice -- "Copyright (C) 1992 by Bruce Sterling" -- it has this little block of printed legal boilerplate from the publisher. It says, and I quote: "No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. For information address: Bantam Books." This is a pretty good disclaimer, as such disclaimers go. I collect intellectual-property disclaimers, and I've seen dozens of them, and this one is at least pretty straightforward. In this narrow and particular case, however, it isn't quite accurate. Bantam Books puts that disclaimer on every book they publish, but Bantam Books does not, in fact, own the electronic rights to this book. I do, because of certain extensive contract maneuverings my agent and I went through before this book was written. I want to give those electronic publishing rights away through certain not- for-profit channels, and I've convinced Bantam that this is a good idea. Since Bantam has seen fit to peaceably agree to this scheme of mine, Bantam Books is not going to fuss about this. Provided you don't try to sell the book, they are not going to bother you for what you do with the electronic copy of this book. If you want to check this out personally, you can ask them; they're at 1540 Broadway NY NY 10036. However, if you were so foolish as to print this book and start retailing it for money in violation of my copyright and the commercial interests of Bantam Books, then Bantam, a part of the gigantic Bertelsmann multinational publishing combine, would roust some of their heavy-duty attorneys out of hibernation and crush you like a bug. This is only to be expected. I didn't write this book so that you could make money out of it. If anybody is gonna make money out of this book, it's gonna be me and my publisher. My publisher deserves to make money out of this book. Not only did the folks at Bantam Books commission me to write the book, and pay me a hefty sum to do so, but they bravely printed, in text, an electronic document the reproduction of which was once alleged to be a federal felony. Bantam Books and their numerous attorneys were very brave and forthright about this book. Furthermore, my former editor at Bantam Books, Betsy Mitchell, genuinely cared about this project, and worked hard on it, and had a lot of wise things to say about the manuscript. Betsy deserves genuine credit for this book, credit that editors too rarely get. [...] ------------------------------ Date: 31 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.13 ************************ 13-Jun-94 23:07:46-GMT,31920;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15850; Mon, 13 Jun 94 19:07:45 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00439; Mon, 13 Jun 94 19:07:34 EDT Received: by chiron.csl.sri.com id AA21037 (5.67b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Mon, 13 Jun 1994 16:00:47 -0700 From: RISKS Forum Sender: RISKS Forum Date: Mon, 13 Jun 94 16:00:44 PDT Subject: RISKS DIGEST 16.14 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Monday 13 June 1994 Volume 16 : Issue 14 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Unconventional Telephones (Mike Hoffberg) Ex-deputy police chief charged over Computer Records (Mich Kabay) RISKS in UK Election Voting Process (Thomas Rushton) Big brother wants the shirt off your back (Lynn R Grant) Re: GIF contains more than just a picture (Castor Fu) Re: How to feel safer in an Airbus (Peter Ladkin) Airbus A3(0?)0 deductions (Phil Overy) Correction for address of Clipper paper (Sidney Markowitz) Chunnel vision (David Honig) RISKS of real-time image processing (Andy Cunningham) Re: Women and Tetris addiction (Hilarie Orman) Re: Campaigns and Elections (Robert J. Burkhart) Re: Apathy toward computer errors (Tom Yurkiw) Security? Maybe.... (Neill Clift) Re: Call Your OPERATER (Hardwire) Re: Risks of too-simple responses (Ross Anderson) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Sun, 12 Jun 94 21:45:24 CDT From: hoffberg@aps.anl.gov (Mike Hoffberg) Subject: Unconventional Telephones I just got a new 900 MHz telephone made by Bel-tronis. Plastered all over it is the fact that it "Styled by BRONDI, Italy". I guess I should be impressed. Well today I prepare to make a call on it to SouthWest Airlines (1-800-I-FLY-SWA). Guess what? The phone does not have a "W" on it. On the #9 key it has XYZ. It is missing the "Q" though. It kind of reminds me of the (sorry about the non-PC reference) Polish joke of the day 555-POLZ. Except it would not work on this phone. Michael Hoffberg hoffberg@phebos.aps.anl.gov mike@anl.gov ------------------------------ Date: 12 Jun 94 09:26:26 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@CompuServe.COM> Subject: Ex-deputy police chief charged over Computer Records >From the Reuter newswire (94.06.10 @ 16:59) via Executive News Service (GO ENS) on CompuServe: LOS ANGELES, June 10 (Reuter) - A former deputy police chief who is now a private detective has been accused of obtaining highly sensitive criminal records from his old department, a spokeswoman for the District Attorney's Office said Friday. Spokeswoman Sandi Gibbons said Daniel Sullivan, former deputy chief of the Los Angeles Police Department, was charged Thursday with 11 misdemeanor counts of being in possession of criminal records. According to the article, Sullivan allegedly used an inside collaborator to get the data. The collaborator and another private detective who received confidential police files were also charged with misdemeanors. Some of the stolen information concerned people in official witness-protection programs, relocated to protect their lives. ------------------------------ Date: Fri, 10 Jun 94 16:24 BST From: Thomas Rushton Subject: RISKS in UK Election Voting Process A colleague (call him ZX) has just told me about how he voted in the recent European Elections, and I thought I would share it with you. He realised that he didn't have his voting card with him, but went to vote anyway. The voting hall contains several tables, where you exchange your card for a voting slip, and the usual booths / boxes etc. The procedure: Go to the table which is labelled with your street name, hand over your card, and receive a voting slip. ZX (with no card), went to the appropriate table, and explained that he wanted to vote, but did not have his voting card with him. The clerk said ``Oh, that's OK -- which street do you live in?''. ZX replied [RISK area -- pick a street, any street, from the following...] The clerk then looked up in his copy of the electoral register for that street, and asked ZX for the number of the house he lived in. [RISK area -- the names in the register were marked in a way that indicates who has voted already] ZX replied with his house number, the clerk said ``Oh, you must be Mr X'', and handed ZX a ballot slip. The obvious conclusion is that J. Random Voter can go to any polling station, say he's left his voting card at home, give a street name (supplied on the tables), pick the number of a house on that street from which no one has voted (by reading the electoral roll copy), and vote, without having had to produce any for of ID. The RISKs here are even higher when you consider that approx only 30% of the total electorate participated in this election.... Question: Should the UK update its voting system? Thomas Rushton SwEng / SEES, RMCS, Shrivenham, Swindon, WILTS, SN6 8LA, UK rushton@rmcs.cranfield.ac.uk tel: +44 (0)793 785684 ------------------------------ Date: Mon, 13 Jun 94 16:16 EDT From: Lynn R Grant Subject: Big brother wants the shirt off your back Here's another risk on the horizon. We may have to wait a few years, though. From the June 1994 issue of Bobbin, "The premier news and information source of the global sewn products industry": Groups such as the American Textile Partnership (AMTEX), a research consortium that links the sewn products industry with the Department of Energy's national laboratories, also are looking at RF technology as a means to improve the production process. In a research project called the Embedded Electronic Fingerprint, long-term work is underway to develop a computer-type device the size of a grain of wheat that could be attached to a garment and used through the entire product life cycle. "A manufacturer could program into the device information unique to a garment, such as the size, color, style, line, or plant of manufacture, care instructions, etc.," explains Jud Early, director of research and development for the Textile/Clothing Technology Corp, [TC]**2. "There also would be a large amount of blank memory that could be used for anti-counterfeit tracking and more." Since each tag would have a unique identity, in-process inventory could be tracked easily using RF units--without ever touching garments or having to open shipping boxes. For example, a carton could be passed through a reading system, which would verify the contents against the packing list. So, all that is needed is for the clerk at the store to capture the identity of the shirt, perhaps through a barcode on the tag (so they wouldn't have to install the special shirt readers), and they already know your identity from your credit card number (unless someone else buys your shirts for you), so they can track your movements by setting up shirt readers in various places. But that might take more collusion between government and the stores than we want to speculate. So try this: a crime is committed. A few days later, you walk past a hidden shirt reader, and are immediately approached by an officer of the law, who arrests you for the crime. "But I was nowhere near the scene of the crime," you protest. "On the contrary," the officer counters, "one of our hidden shirt readers detected you shirt in the vicinity of the crime. You must be guilty." One would hope that the manufacturers of these devices don't accidentally program duplicate serial numbers in them. And you should think twice about lending your shirt to your girlfriend. Lynn Grant Grant@DOCKMASTER.NCSC.MIL ------------------------------ Date: Thu, 9 Jun 1994 23:10:30 -0700 From: Castor Fu Subject: GIF contains more than just a picture (Aldous, RISKS-16.13) So does this mean that xv - vi = une ix ? [To which PGN replied, However, if ix were masculine, we would have un ix.] [To which Castor replied, One could argue that the gender of Unix is somewhat ill-defined.] [So, we need a language such as Latin with a neuter gender, and in which "un" is an indefinite article. PGN] [Kevin Kenny (kennykb@dssv01.crd.ge.com) noted that the other popular image viewer, `xli,' is the FORTY-ONE program!] ------------------------------ Date: Fri, 10 Jun 1994 11:04:40 +0200 From: Peter Ladkin Subject: Re: How to feel safer in an Airbus [Terribile, RISKS-16.13] Mark Terribile offered some interesting comments on Airbus aircraft design. But some of his speculation is ill-founded, and should not pass without comment. > If I understand correctly, Airbus was forced to use these multimode control > systems because some of its aircraft use sidestick controllers. > [...] > There is another serious problem with the control mechanism described: This is confused. His first comment refers to the Airbus A320 aircraft, which is the first `fly-by-wire' commercial transport. His second comment refers to the crash of a China Airlines A300 in Nagoya, which is a different aircraft, with the usual mechanical and hydraulic primary control systems and relatively limited use of computers. It does not have sidestick control. His speculation on the A320, that Airbus were forced to use modes because they chose a sidestick design, is incorrect. Fly-by-wire aircraft use modes because they have to. What toys you give the pilot to convey her instructions to the computer is almost an independent choice. If the plane is flown by computer, she doesn't need a large lever to move the control surfaces. > There is another serious problem with the control mechanism described: the > autopilot used one set of control surfaces (stabilizer trim) while the > pilot continued to operate another (elevators). This arrangement is used on more or less every transport aircraft flying, as well as all tiny planes big enough to warrant a three-axis autopilot. If this is a `serious problem', all aircraft have it. (Also, the trim system is not primary control as the elevators are. It serves a different function.) > There is a third problem: the pilot has no indication through his controls > that the autopilot--in effect, the aircraft's control laws--are actively > working against him. This is false for the A300, as for most conventional transports. In fact, the copilot who was flying had to work quite hard to counteract the nose-up trim. This is one of the puzzles of the accident. A further comment about the Nagoya accident is appropriate. Current knowledge is that the pilots failed to follow normal, explicit procedure for control of the aircraft, and secondly that they had both been drinking alcohol, which is illegal for good reason. Responsible senior management of China Airlines has resigned because of this accident. The FAA has virtually insisted that China Airlines work with it on improving safety procedures including crew training and oversight. Trying to draw conclusions about aircraft design from details of this particular accident is probably unwise. Those wary of fly-by-wire transport aircraft design might also like to know that Boeing's next airplane, the 777, is full fly-by-wire - just like the A320, but, of course, different. Peter Ladkin ------------------------------ Date: Fri, 10 Jun 94 09:06:53 BST From: Phil Overy RAL Subject: Airbus A3(0?)0 deductions re: Mark Terribile's posting:- 1) Boeing sell similar automation to the A320 - they also caused the second- worst Japanese crash and in this case much more directly (the fuselage broke). 2) whether you se sidestick or yoke, a modern airliner has no direct "cables" to the rudders - it relies on multiple links either electrical or hydraulic which would work equally well with sidesticks. A300s have been around for 20 years - this was an A320. 3) This is one of three crashes involving a simple confusion that I remember - the first Tri-Star crash (neither pilot had switched off the auto-pilot); the Kegworth crash (on a BOEING - the pilot shut down the wrong engine when it caught fire) and this one (the younger pilot didn't switch off the auto-pilot and didn't relinquish control. I automatically think of my poor (fortunately very quick-witted) gliding instructors when I read of this particular crash- thank you for not letting me land on the crosswind runway, Barry Hogarth!. 4) as for mode-switching and elevators etc - the senior pilot seems to have tried to recover without switching off the auto-pilot, the junior pilot seems to have flown as if the auto-pilot wasn't on. Reports will not say this as it's a conclusion, not a fact - it does however sound like the explanation. 5) Since several A320s have crashed when silly things have been happening, perhaps the automation, like the "watertight" hull of the Titanic, is creating a too-complacent pilot. As a far-too-complacent pilot myself in the past, I can understand this. I do not pretend any insight into the cause of the crash, all I can say is that if Mark Terribile is basing his preferred flight on the logic presented here, he won't fly at all. Regards Phil Overy Rutherford-Appleton Laboratory (computer programmer with a chequered past, not a pilot or a designer, although I have used gliders to exploit the many rain clouds over England) ------------------------------ Date: Fri, 10 Jun 1994 13:18:05 -0700 From: sidney@taurus.apple.com (Sidney Markowitz) Subject: Correction for address of Clipper paper Perhaps the subject should be "RISKS of not using available spelling checker technology". In RISKS-16.12, I had a typo in the address for the ftp site containing Matt Blaze's paper. The correct site name is research.att.com and the file is in /dist/mab/eesproto.ps and is in PostScript format. Thanks and my apologies to the people who took my creative spelling of the word "research" literally and sent me mail informing me of the error. -- sidney markowitz [My spell checker always balks on net addresses, so the "resarch" slipped by me. It also let a Blase go through in RISKS-16.13. PGN] ------------------------------ Date: Fri, 10 Jun 1994 15:54:36 -0700 From: David Honig Subject: Chunnel vision (beaten to the pun) Colville reported in RISKS-16.13 on the first false alarm in the Chunnel. One might predict that these will be common at first. In the public's lexicon "False Alarm" might be replaced by "Channel Tunnel Syndrome" :-) ------------------------------ Date: Fri, 10 Jun 94 08:50:36 BST From: andyc@eurovi.uucp (Andy Cunningham) Subject: RISKS of real-time image processing I had a first hand demonstration of a new road-side traffic monitoring system here in the UK earlier this week. I was driving into some road works on the M1 motorway and was slowing down to take account of the 50m.p.h. speed limit which had been imposed. Immediately (10 yards) after the speed limit sign was a bridge, and mounted on this bridge was a camera. On the other side of the bridge was a large dot matrix display, which immediately flashed up the message: SPEEDING L123 ABC 58 MPH (actual registration number changed to protect the guilty). RISKS: first of all, I'm expecting to get a warning about the consequences of speeding in the mail. (In the UK, the police usually won't give you a ticket unless you're at least 10mph over the speed limit). More importantly some drivers might be surprised by this and cause an accident. This technology starts to get real "big brother" overtones if it's used to actually send out tickets (camera/radar systems which produce photographic evidence of speeding are already in place, but human intervention is required to actually send out the tickets). And just how accurate is the character recognition anyway? Andy Cunningham, VI Corporation (Europe), Ilex House, Mulberry Business Park, Fishponds Road, Wokingham, RG11 2GY +44 734 892111 Fax: +44 734 892090 ------------------------------ Date: Fri, 10 Jun 1994 19:05:16 -0700 From: Hilarie Orman Subject: Re: Women and Tetris addiction There are indeed deep psychological forces that draw women to the game of Tetris. I've been a Tetris junky, and I can give my testament to the risks of this particular addiction. First, I admit that I am, by nature, susceptible. I've been through several 12 step programs to rid myself of addictions in the past: adventure, pacman, rogue, hack. Yes, I've been there, and in several other autotelic hells as well: elisp, C++, interrupt handler bugs, and more recently I've been developing a WWW browsing problem. It started in childhood with a Revell model of a "car of the future" (lime-green with huge tailfins and clear bubbles over the occupants in their bucket seats) and continued with more plastic cars, battleships, airplanes, then those chests of little steel girders, then calligraphy, ..., OK, OK, I'm autotelic, I'm a woman, and I'm going to tell my Tetris tale. First, let me establish my credentials as a Tetris hard-core. I found it while on vacation in Maui. I dragged my family in our Aloha clothing to a video games den every evening after we cleaned up from a day on the beach. The clientele was young, local, kind of tough. Ordinarily I'd feel uncomfortable spending 5 minutes in such a place. But with a stack of quarters and a Tetris machine, I was transported. The locals would sit behind me sneering and asking if they could "PLEASE" use the machines. At first, I'd let them. But things changed when we got back home to Los Angeles. I found a video parlor in Marina Del Rey with Tetris. The clientele was even more disturbing, but again, the game presented a world of its own. One afternoon, a woman with two small children attempted to take the machine away from me. While I was concentrating on the play, she informed me that her kids wanted to use the machine. Without looking up, I told her that I'd only yield if it was management policy to impose a time limit. After a moment of shock she began screaming insults at me and dragged the children away. Though I didn't ever look up to see what kind of person she was, it did pretty much ruin my timing for that level. I got busy with various home and work projects shortly after that, and I haven't played much since. For a while I tried using xtetris on my workstation, but it wasn't the same. And I've never actually used a GameBoy, because it's hard to get the little kids to share them, and even if they do they won't let you play for more than a few minutes before they start whining. So I'm going to talk only about my experiences with the big machines in the video arcades. So what is it exactly that draws women to Tetris? I think it's refrigerators. At first I thought it was cabinets, but I've been over this in my mind a lot, and I'm convinced that refrigerators are the key. The sociologist who mentioned women's "craving for order" seemed way off base, she'd obviously never been within a mile of a teenage girl's room, but still, that's the key to it. Women spend a lot of time trying to get things into refrigerators. The point is, they don't have a natural sense of order, but they've got to get the damn stuff into the fridge so it doesn't fall out, and that requires ingenuity. Cabinets are similar, but they use different reasoning skills than refrigerators. For example, it's OK to push something to the back of a cabinet and lose it for a year. And things that go into cabinets nest --- you've got to be careful with those graduated bowls if they're from different sets, because if you put one inside the other you'll need a screwdriver and pliers to get it out. Now refrigerators and Tetris are much the same thing. The Tetris shapes are like Tupperware boxes and milk cartons and packages of cheese. But unlike real household items, they remain sparkling and attractive no matter how long you leave them there. And if you pack them very carefully along the bottom, instead of rotting and giving off foul odors, they are conveniently whisked away, while more continue falling. This is sort of like having your husband help unload the groceries --- there you are trying to get the vegetables packed carefully into the bottom bins, and there he is stuffing soft drink cans into the dairy products section. As you move through the various difficulty levels of Tetris, it's even more like a refrigerator --- you don't get to start with a clean space, but instead have what looks like piles of debris from unknown previous users. Women know that these unseen entities are teenagers and you've got to be very resourceful and controlled to work around them. But what's the payoff in this contest? Well, mainly it's being able to exercise a skill that women already have, but with lots more positive feedback than real life. And for me, the video arcade games have two really important features. One is a cute little Slavic dance tune that plays in the background and helps with the timing. But the real clincher is that as you get proceed through the difficulty levels, there's entertainment. Little Russian men come out onto the screen and dance in that style where they fold their arms and bend their knees and kick straight out. Yes, that's the real thing about Tetris for some of us older ladies, it's the dancing men. In all my years of cleaning out the refrigerator, I've never had a man dance a jig for me. Well, that's why I play Tetris; I'm not sure about anyone else. ------------------------------ Date: Sun, 12 Jun 94 23:04 EST From: "Robert J. Burkhart" <0006344755@mcimail.com> Subject: Re: Campaigns and Elections (Agre, RISKS-16.12) ... just find out what everybody's hot issues are and make them all whatever promises you need to make, ... And so (once again) fact follows fiction ... Eugene Burdick (Co-Author of THE UGLY AMERICAN) wrote this script in his futurist novel THE 480. I thought this was also the same computer-assisted campaign process used for the last presidential campaign! Bob Burkhart at Twin Cities ACM Senior Consultant - The Security Board ------------------------------ Date: Sat, 11 Jun 1994 17:57:23 -0400 From: "Tom Yurkiw (Tommy the Yurk)" Subject: Re: Apathy toward computer errors (Seymour, RISKS-16.13) >"'I'm not going to send it in. They make too many mistakes, and I'm not going >to rectify their mistakes,' he said. 'I can't see why people have to keep >paying for their mistakes all the time.'" He says this is the "last straw." The RISKS? If people place unreasonable trust and expectations on the accuracy of computer information, they are bound to be disappointed. Also, people quickly forget the advantages of using a particular system, and zero in on the drawbacks. Does this guy really want to stand in line for 8 hours or so, like they do in non-computerized elections? Finally, this illustrates the RISK of working for government institutions - people are far more aggressive in dealing with government agencies -- they speak in terms of `rights', they make demands rather than requests. The relationship is different from the company-customer framework - even the most obnoxious individuals must be humoured. ------------------------------ Date: Sun, 12 Jun 1994 08:47:13 BST From: Neill Clift Subject: Security? Maybe.... I posted this to comp.os.vms and somebody suggested it would be of interest to risks readers. I am a risks reader but it didn't cross my mind until I was told. X-NEWS: macro.demon.co.uk comp.os.vms: 22614 Path: macro.demon.co.uk!neill From: neill@macro.demon.co.uk (Neill Clift) Newsgroups: comp.os.vms Subject: Security? Maybe... Message-ID: <1994Jun11.221520.201@macro.demon.co.uk> Date: 11 Jun 94 22:15:20 BST Organization: None Lines: 38 One of our customers employees asked me to have a quick look at two security packages for VMS that he was evaluating. The purpose of my quick look was to determine if there where any obvious holes that these packages introduced or if their auditing features where easily evaded. I spent less than a couple of hours on each one (I wasn't getting paid just having a laugh :-)). Package 1 This s/w had a facility for performing checksums on various files to enable detection of tampering. I asked their representative what algorithm they used for their checksum. All he would say was that it was proprietary. You would expect 'proprietary' to mean that there was at least some thought behind it. I found the algorithm to consist of summing the file as a contiguous set of longwords and a recording of the modification date. Files could easily be fixed up after modification! Why didn't they implement one of the many checksums something like tripwire supports? This s/w trapped AUDIT_SERVER messages via a mailbox. The protection on the mailbox allowed read and write access to the world so that data could be read out before the auditing s/w could get at it with a simple copy command. Fake audits could also be introduced. This s/w had mechanisms for DCL command procedures to take actions based on the audits passing parameters extracted from the alarm data (evil grin). Package 2 On looking what this s/w installed I spotted a privileged image that looked a good target. Within 20 mins I had decided that I could probably use it to obtain all privileges as an unprivileged user. After an hour or two of programming I had done just that. In the end I exploited what I thought was the quickest bug to use but this bit of code appeared to be teaming with problems. Both of these packages looked very flash and professional from the outside. Sad but true. Neill. Neill Clift neill@macro.demon.co.uk ------------------------------ Date: Mon, 30 May 94 18:57 EST From: Hardwire <0003436453@mcimail.com> Subject: Re: Call Your OPERATER (RISKS-16.09) I remember reading about this in NETWORK WORLD. It's kind of funny: MCI already owned 1800 OPERATER long before AT&T released 1800 OPERATOR (Which was 5 months after MCI released 1800 COLLECT). MCI was using the OPERATER number internally for something, but not collect calls. They noticed after AT&T released their collect call product: 800 OPERATOR they were getting a lot of calls from people who misdialed. MCI was directing them to the correct number or 800 COLLECT. Due to the large number of calls MCI finally decided to send 800 OPERATER to the 800 COLLECT system. According the NETWORLD WORLD article, MCI was making about $200K a month thanks to people with the 'Quayle' syndrome. ------------------------------ Date: Thu, 9 Jun 1994 17:51:46 +0100 From: Ross.Anderson@cl.cam.ac.uk Subject: Re: Risks of too-simple responses (Lodge, RISKS-16.12) > ... All French credit cards are smart cards, and have been in mass use > for several years now. The French don't seem to be having any problems > with fragility or expense. This is not quite so. One of the standard ways of defrauding the French smartcard system is to destroy the chip, whether by stamping on it or by an overvoltage. This causes the terminal to revert to standin mode, which is quite vulnerable. Fraud was reduced slightly by the introduction of smartcards - in France it is about 0.08%, against 0.2% for MasterCard and 0.1% for VISA - bit it has by no means been eliminated (source: `Cards International' 22 July 1993). Quite apart from fraud, the French card failure rate of 3% was the reason why smartcards were not introduced in Belgium (source: `Cards International' 27th October 1993). Also, there was a furore recently when French banks announced that all merchants would have to move over to electronic terminals. This would have cost over half a million small family businesses perhaps Ffr20,000 each, and the main beneficiary would have been Bull - a struggling state-owned company which was losing billions and being supported by the French government (which seems to have been behind the move on terminals). The risk? There are several - in not understanding the trade-off between security and reliability, and in letting governments set security standards before the technology is properly mature. Ross Anderson Cambridge University Computer Lab ------------------------------ Date: 31 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.14 ************************ 15-Jun-94 15:38:44-GMT,31183;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA23391; Wed, 15 Jun 94 11:38:38 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11400; Wed, 15 Jun 94 11:38:33 EDT Received: by chiron.csl.sri.com id AA22825 (5.67b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Wed, 15 Jun 1994 08:30:36 -0700 From: RISKS Forum Sender: RISKS Forum Date: Wed, 15 Jun 94 8:30:33 PDT Subject: RISKS DIGEST 16.15 Reply-To: risks@csl.sri.com Mime-Version: 1.0 Content-Type: multipart/digest; boundary="----------------------------" To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Weds 15 June 1994 Volume 16 : Issue 15 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Privacy: Your Secrets For Sale (Les Earnest) Life imitates Bart Simpson (Jeffrey S. Sorensen) "Computer Ethics" by Deborah Johnson (Rob Slade) Re: More Chunnel vision (Philip H. Smith III) Re: Airbus (Mary Shafer, Robert Dorsett, Phil Overy, Wesley Kaplow) Re: Risks of speed enforcement (Jonathan Clark, Clive D.W. Feather) Re: RISKS in UK Election Voting Process (Doug Tooley, Kent J Quirk, John C Sager, Sean Matthews, Peter Robinson, John Gray) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------- Date: Sun, 12 Jun 94 17:39:31 -0700 From: Les Earnest Subject: Privacy: Your Secrets For Sale ABC's Nightline programs on June 9 & 10 focussed on invasions of privacy that are facilitated by computers and other electronic media. The program mainly covered things that we are familiar with but performed a valuable service, I believe, by bringing some important privacy issues to the attention of the general public in a fairly clear and direct way. The program began with Ted Koppel presenting results of a public opinion poll on two questions: Is the sale of records to mail order companies an invasion of privacy? YES - 73% NO - 27% Are you concerned about threats to your privacy? YES - 85% NO - 15% Koppel went on to assert that the amount of personal information that is available online is currently quadrupling each year. An interview followed with an information broker named Al Schweitzer, who they mentioned is currently on probation for bribery in connection with information gathering. They gave him names and social security numbers of a couple of people and he showed that in less than 24 hours he could get a great deal of information about them from legal sources, including their residential addresses going back a number of years, the amounts of all outstanding loans and credit card debts and terms of a divorce settlement. Schweitzer could not resist mentioning that he could get additional information, including detailed phone bills and lists of credit card purchases through illicit but readily accessible channels and could get the person's income through another such channel at a cost of $50. He showed a list of kinds of information, both legal and illegal, that are available and the schedule of fees for these services. There was a discussion of the fact that state and local governments sell a great deal of information to direct marketers, including voter registration, property owners lists, court records, and (in many states) motor vehicle and drivers license registrations. These agencies derive a great deal of income from selling this information, which has assisted direct marketers to keep track of 80 million Americans. Thus they have a mutually beneficial relationship, arguably at the expense of the public. It was mentioned that Barbara Boxer's bill, which has passed the U.S. Senate, would restrict dissemination of information by all state departments of motor vehicles. They interviewed a "reformed hacker" named Ian Murphy who is now a security consultant. Murphy pointed out that all calls to 800 or 900 numbers make the caller's phone number available and that with a computer and an available database this can be mapped into the subscriber's name and address. He also discussed how it was possible to intercept a telephone conversation from a specific cellular phone. He noted that this is illegal but that it is almost impossible to catch anyone who does it. He concluded that "Laws can't keep up with technology." In a discussion of the Clipper Chip there was a short interview with John Perry Barlow in which he remarked that with it "The government can sit in your living room and hear everything you say." A woman from Houston, Texas, named Carol Gibbs told her horror story about having her credit usurped by another person and the fact that it has taken her two years to get her life back together. It was pointed out that even though it is now illegal to sell video rental records, it is perfectly legal to sell personal medical records! The second program concluded with a discussion between Koppel, Schweitzer, Sally Katzen of the "Clinton Privacy Group" and Representative Ed Markey, who discussed his proposed "Privacy Bill of Rights." Markey said that this bill would impose two requirements: (1) That individuals must be given knowledge that information is being gathered about them electronically; (2) Individuals must be given notice when information that has been gathered is proposed to for a use other than the one for which it was gathered. Katzen mentioned that it has been over 20 years since the Code of Fair Information Practices was developed and that technology has changed substantially: in 1973-74 most records were paper-based but computer-based records now dominate. She asserted that the law has to catch up. In parting it was mentioned that a representative of one of the "big three" credit information houses had originally agreed to participate in the discussion but decided not to come after learning who else would be there. -Les Earnest ---------------------------- Date: Mon, 13 Jun 1994 23:14:34 -0400 From: "Jeffrey S. Sorensen" Subject: Life imitates Bart Simpson This is a Risk only fans of The Simpsons will appreciate: (Paraphrased from New Haven Register Sunday, June 12, 1994 [With my comments!]) Northeast Utilities reported that it had failed to follow proper safety procedures on 2 occasions in April at its Millstone 2 plant in Waterford. On April 23, an indicator showed that some of the control rods were stuck. The crew concluded that the problem must have been with the indicator and left for the day. When the new crew arrived, they discovered the rods were indeed stuck but failed to shutdown the reactor as quickly as they should have and underclassified the seriousness of the event. [See stdrisks.h sections on incredulous operators ignoring unexpected warnings. Also see section on It's Not MY Problem/It's Miller Time (After a HOT day at work, everyone's _dying_ to get home)] After the incident, some of the plant's operators failed a Northeast Utilities test on reactor theory and were removed from duty for training. The utility's report blamed the problem in part on the operators' failure to understand reactor theory and a failure of plant management to "fully appreciate the implications" of the safety-related event and to provide sufficient oversight. [sound clip of Homer: Dough!] [sound clip of Mr. Burns: Excellent...] The other incident involved a coolant leak from the plant's reactor. In this case, the operators again underclassified the seriousness of the event. Notification of federal authorities was delayed by 16 hours. [Guess they were just letting off a little steam after failing their tests...] [sound clip of Bart: Aye Carumba!] Jeffrey Sorensen sorenjs@pb.com ---------------------------- Date: Tue, 14 Jun 1994 11:55:07 -0600 (MDT) From: "Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067" Subject: "Computer Ethics" by Deborah Johnson BKCMPETH.RVW 940322 Prentice Hall 113 Sylvan Avenue Englewood Cliffs, NJ 07632 (515) 284-6751 FAX (515) 284-2607 phyllis@prenhall.com 70621.2737@CompuServe.COM Alan Apt Beth Mullen-Hespe beth_hespe@prenhall.com "Computer Ethics", Johnson, 1994, 0-13-290339-3 Unlike the famous quote about life in the state of nature being nasty, dull, brutish and short, Johnson's examination of the state of ethics in computing is readable, interesting, discerning--and short. Unlike the usual treatment of ethics as proof by exhaustion, Johnson does a complete and reasonable job. Without recourse to mounds of collected work (of dubious merit), the major points of professionalism, property rights, privacy, crime, and responsibility are addressed. Even in this brief space, ethics are studied more rigorously than in more weighty tomes. Not content with the usual reliance on relativism and utilitarianism, Johnson points out the flaws in each. "Complete" is, I suppose, an overstatement. Although it is difficult to imagine a scenario that the book does not touch upon at some point, ultimately this book is a good primer and discussion starter. Although possibly the definitive work in the field to date, it does not, in the final analysis, get us much closer to a computer ethic. Recommended. Should be required reading for all computer science students. Exposure wouldn't hurt any number of professionals and executives, either. copyright Robert M. Slade, 1994 BKCMPETH.RVW 940322 ====================== DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 BCVAXLUG ConVAXtion, Vancouver, BC, Oct. 13 & 14, 1994 contact vernc@decus.ca ---------------------------- Date: Tue, 14 Jun 94 06:46:18 EDT From: PHILS@RELAY.RELAY.COM (Philip H. Smith III, (703) 506-0500) Subject: More Chunnel vision I had always hoped the Chunnel would allow auto traffic, with HOV restrictions, thus enabling the dreaded "Carpool Tunnel Syndrome". ...phsiii ---------------------------- Date: Tue, 14 Jun 94 07:51:24 PDT From: shafer@ferhino.dfrf.nasa.gov (Mary Shafer) Subject: Airbus A3(0?)0 deductions (Overy, RISKS-16.14) Phil> 1) Boeing sell similar automation to the A320 - they also caused Phil> the second- worst Japanese crash and in this case much more Phil> directly (the fuselage broke). Not true--Boeing does not have any fly-by-wire aircraft in operational status. They have flown precisely ONE fly-by-wire aircraft, the prototype 777. And it made its first flight last week. Phil> 2) whether you se sidestick or yoke, a modern airliner has no Phil> direct "cables" to the rudders - it relies on multiple links Phil> either electrical or hydraulic which would work equally well Phil> with sidesticks. A300s have been around for 20 years - this was an A320. Not entirely true, as the Douglas DC-11 and DC-12 have cables that run from the pilot controls (yoke and rudder) all the way back to the wing and tail, for ailerons or elevators and rudders respectively. The control surfaces are hydraulically actuated, it's true, but most of the control run is cables. I think that the 747 also has similar cables. Phil> 5) Since several A320s have crashed when silly things have been Phil> happening, perhaps the automation, like the "watertight" hull of Phil> the Titanic, is creating a too-complacent pilot. As a Phil> far-too-complacent pilot myself in the past, I can understand this. Well, no doubt, but wasn't this accident a 300, not a 320? The 300 has a conventional FCS, not fly-by-wire. Just because they both start with 3's doesn't make them the same aircraft. That's like saying that an A-10 and a KC-10 are identical because they both have 10 in the designator. Mary Shafer SR-71 Chief Engineer NASA Dryden Flight Research Center, Edwards, CA shafer@ferhino.dfrf.nasa.gov ---------------------------- Date: Mon, 13 Jun 1994 19:41:40 -0700 From: rdd@netcom.com (Robert Dorsett) Subject: Re: How to feel safer in an Airbus Ladkin, RISKS-16.14 >His speculation on the A320, that Airbus were forced to use modes >because they chose a sidestick design, is incorrect. Fly-by-wire >aircraft use modes because they have to. This is not true. Early FBW aircraft were essentially open-loop analog systems. They were reactive, very simple, providing very simple feedback and control loops. They were not anywhere near as modal as modern systems. Keep in mind that Airbus' position is that fly-by-wire systems have to provide a supermarket of user features. In reality, the primary operational benefit is to be simplicity and weight savings. What a manufacturer does from that point onwards is totally arbitrary and subject to market forces. The Airbus design has long struck me as a being in support of an interface which, in turn, was probably the result of a marketing decision. Certainly, the decision to use sidesticks--which provide no active feedback, and which are not interlinked--ran contrary to the preferences of many pilots. The lack of said characteristics has resulted in more modes (and the necessity of protections) and a variety of rather impressive kludges (such as the "take-over" arrows which point to the other pilot when he pushes his "take- over" button). >From what I've read of the Boeing 777 design, it's much less modal than the Airbus design, providing unified and conventional flight characteristics from takeoff roll through landing roll. >A further comment about the Nagoya accident is appropriate. Current >knowledge is that the pilots failed to follow normal, explicit >procedure for control of the aircraft, Really? I've not seen that anywhere. "Explicit" suggests that the systems' characteristics were clear and well-understood. Such is not the case here. In fact, given that Airbus control philosophies tend to be rather subtle in their feedback and invocation procedures, I'd certainly not suggest that "pilot error" was a likely or trivial error in this case, at least not at this point. >and secondly that they had both >been drinking alcohol, which is illegal for good reason. This has also not been substantiated. The investigators will not comment, and it is not clear whether the presence of alcohol in the corpses was a result of ingestion or decomposition of tissues. In any event, the *presence* of alcohol is not illegal. The illegality is determined by the *amount* of alcohol present. >senior management of China Airlines has resigned because of this accident. Because of the fifth major accident in as many years, was the way I understood it. And Phil Overy RAL writes: > re: Mark Terribile's posting:- > 1) Boeing sell similar automation to the A320 - they also caused the second- > worst Japanese crash and in this case much more directly (the fuselage broke). I do not understand this paragraph. To the naive reader, it could appear that you're claiming a Boeing automation issue was responsible for the struc- tural failure of an airplane. This is clearly false. Nor was the JAL crash the simple result of structural failure: it was primarily the result of a faulty repair, which destroyed the tail, taking the airplane's hydraulic systems along with it. Moreover, Boeing automation is significantly different from AI automation, from the ground up. The 777 flight control system (assuming you're referring to flight control systems) uses a different machine architecture and has a fundamentally different mission requirement, governed by the use of a different interface. If you're referring to more conventional functions, such as cockpit auto- mation and the navigation systems, again, Boeing philosophy is demonstrably different from Airbus philosophy. It's debatable whether either is "better," but to even a casual observer, they are sufficiently different to cause at least a few customers to scratch their heads when it comes to running fleets with airplanes from multiple vendors. In many cases, the differences are not trivial. > 2) whether you use sidestick or yoke, a modern airliner has no direct > "cables" to the rudders - it relies on multiple links either electrical or > hydraulic which would work equally well with sidesticks. In point of fact, the hydraulic actuators are controlled via cables. And in a few airplanes (727, DC-9 derivatives) the pilots still retain aircraft control via control tabs in the event of complete hydraulic failure. > 4) as for mode-switching and elevators etc - the senior pilot seems to have > tried to recover without switching off the auto-pilot, the junior pilot seems > to have flown as if the auto-pilot wasn't on. Reports will not say this as > it's a conclusion, not a fact - it does however sound like the explanation. And reports also claim a 15-year-old boy crashed an A310-600 when he nudged against the control column. Hmm. I wonder why two airline pilots couldn't figure THAT one out. Robert Dorsett rdd@netcom.com ---------------------------- Date: Wed, 15 Jun 94 08:38:51 BST From: Phil Overy Subject: Correction of my post on "A-THREE-HUNDRED" crash at Nagoya After a mail from Peter Ladkin I am now sure of my ground and wish to write what I wanted to write in the first place - despite your correspondent (and a newspaper report I unfortunately used to check my memory, not my Independent or Peter Ladkin's Herald Tribune which got it right), the worst crash in Japan was AN A300 (ie an "old", un-computerised type NOT with sidesticks). The Taiwanese plane did not crash after any kind of automation or airframe failure, but when the auto-pilot was left on until too late. Peter Ladkin tells me that the president of the airline resigned after the crash, so it doesn't sound as if they are trying to transfer responsibility to the manufacturers. The crash at Nagoya was not like Japan's second-worst disaster when a Super 747 (high-altitude model) crashed when the pressure bulkhead at the rear collapsed; on that occasion the makers were Boeing, however I leave accusations to lawyers -- there are plenty of these around and I may have flown on one (and lived :-) ). [lawyers?] I could have phrased it better, but I would point out that Boeing also now use fly-by-wire (on the brand new 777), so the earlier correspondent was misguided in thinking that Boeing were staying away from fly-by-wire. The 777 is also a much bigger plane than the A320... Phil Overy ---------------------------- Date: Tue, 14 Jun 1994 09:51:48 -0400 From: Wesley Kaplow Subject: Does it matter why A3??'s have a poor record? The average persons response to all of the A3?? technical discussion would probably be that it frankly it does not matter why these planes crash!. To me, if we play only on the statistics, I want a airplane with a good safety record. Already, Airbus Industry has lost more planes per delivered plane than other major aircraft manufacturer in the past 3 decades (Lockheed, Boeing, MD). To the average person, who for example reads in Consumer Reports that XYZ product can burst into flames after extended use, does not care why!. The same is true for airline equipment. It is also reassuring to note that some committee decided (or individual) decided that an A320 does not think it has landed until the wheels spin up to something like 90 kts. How reassuring to think that all of the possible consequences of this decision have been carefully thought out and that a full fault-effect analysis has been performed. Wesley K. Kaplow, AT&T Bell Laboratories, Rensselaer Polytechnic Institute kaplow@att.com kaploww@cs.rpi.edu ---------------------------- Date: Tue, 14 Jun 94 12:13 EDT From: jhc@hostel.lincroftnj.ncr.com (Jonathan Clark) Subject: Re: risks of speed enforcement (Cunningham, RISKS-16.14) Andy Cunningham mentions some possible risks of over-zealous speed enforcement, with (presumably) a radar gun linked to a video camera and some automatic licence-plate recognition software. Such a system was until last year under test in New Jersey. A law was then passed banning it after it was found that there was no way to let people off after they had been ticketed, so that politicians, off-duty police officers and other members of the nomenklatura would then have to conform to the same rules of the road as the rest of the populace. I guess the risk here is that of trying to apply rules to people they obviously weren't meant for! Designers take note - you always have to leave *some* way to circumvent the system :-) I should note that in the U.S. speeding tickets are frequently (many would say primarily) used to generate revenue, rather than for any considerations of safety or traffic management. On the other hand, I understand that photo-radar systems work in the infra-red. This is preferable to an experience I had some years ago while driving late at night at high speed on an autoroute in Belgium - I drove under a bridge and was dazzled by a *powerful* flash going off behind me. Now there's an unexpected risk of driving too fast... Jonathan ---------------------------- Date: Tue, 14 Jun 1994 11:10:07 +0100 (BST) From: "Clive D.W. Feather" Subject: RISKS of real-time image processing (Cunningham, RISKS-16.14) > ...actually send out tickets (camera/radar systems which produce photographic I don't think this is a likely problem. The current camera/radar systems don't work like that. The radar is used to detect likely speeders, and then the camera takes two pictures a known time apart; the position of the car in each is used to determine whether the car was speeding. Clive D.W. Feather, Santa Cruz Operation, Croxley Centre, Hatters Lane, Watford WD1 8YN, United Kingdom clive@sco.com Phone: +44 923 816 344 ---------------------------- Date: Tue, 14 Jun 1994 12:44:41 -0400 From: Doug Tooley Subject: Re: RISKS in UK Election Voting Process The UK is not alone in their lack of voting security. In Canada, as "proof of identification" all we had to do to identify ourselves at the registration station was to bring an envelope mailed to our address (with our name on it) with a second piece of identification. Sounds straightforward... The people are nice and accommodating too: A roommate of mine couldn't make it to the registration, so we were able to register for him *very* easily. Given the (lack of) care being put into actually checking the identification (to test this, I deliberately didn't show them the address on my envelope, I merely waved it at him, and that was sufficient) literally anyone could have registered to vote. The registration process was optimized for speed (we had to wait 30-40 mins) and for friendliness, (they were very willing to accept my word at face value) but no REAL effort was made to authenticate the participants. Doug Tooley 4C Co-Op CS/C&O student at U of Waterloo, Ontario, Canada djtooley@undergrad.math.uwaterloo.ca ---------------------------- Date: Tue, 14 Jun 1994 03:22:40 GMT From: kentq@world.std.com (Kent J Quirk) Subject: Re: Voting Systems - UK, US In the two towns I've lived in here in Massachusetts, they have a similar voting system to that mentioned in England, except that no voter card is required. They ask for a street address and a house number, but anyone who can read upside down could simply pick a name out of a hat. The risks to the would-be fraudulent voter is that even in our relatively large town of 25,000 people there is a decent chance that the person behind the counter knows the person you are naming, or that the person will later attempt to vote and uncover the fraud (not that there's much that could be done about it at that point). The news media, in covering questionable elections around the world, often speak of "massive election fraud". It seems to me that since massive fraud is really the only kind that has any predictable benefit, spoofing the blue-haired volunteers behind the desk is not really all that much of a worry. [Similar comment regarding Mass. from Andrew_Marc_Greene@frankston.com .] ---------------------------- Date: Tue, 14 Jun 94 09:17:49 BST From: John C Sager Subject: Re: RISKS in UK Election Voting Process (Rushton, RISKS-16.14) This is not uncommon - I did exactly the same thing. Admittedly there is a RISK, but you also have to consider cultural factors. Accusations of ballot-rigging in UK elections are rare. If someone picked an address at random and voted as a resident there, as suggested, then there would be major investigations & lots of publicity when the real voter turned up with a valid poll card. Yet this does not happen. There is no culture of ballot-rigging in the UK (except long ago in Northern Ireland, but that was done a different way). John C Sager B67 G18, BT Labs, Martlesham Heath, IPSWICH IP5 7RE England jcs@zoo.bt.co.uk +44 473 642623 ---------------------------- Date: Tue, 14 Jun 94 10:32:18 +0200 From: sean@mpi-sb.mpg.de (Sean Matthews) Subject: Re: RISKS in UK Election Voting Process > Question: Should the UK update its voting system? Answer: No. Actually, at least, in Northern Ireland, the election procedure has been tightened: because there is a real, as opposed to theoretical, problem with impersonation (vote early, vote often) they insist that you now have to have some form of ID with you (or at least did, I haven't voted there for some years, but I don't imagine that it has changed). Traditionally, polling stations in Britain have someone local who is familar with the people of the area, a doctor or vicar or something, around as an informal check for impersonation (this would probably work better in rural, than urban areas though). I don't think there is much of a problem really, with the UK procedure. If they need to be careful (like in NI) they can make things much better, just by always asking for ID, or to see the registration card. But since they don't actually need to at the moment, why bother. After all, a problem with voter impersonation would be obvious if it happened on any sort of scale and if it does happen there are separate procedures for dealing with it. There is the risk here of fixing something that is not obviously broken, by assuming a purely theoretical worst case. Sean Matthews Max-Planck-Institut fuer Informatik Im Stadtwald, D-66123 Saarbruecken, Germany +49 681 302 5363 [Further similar comments from Peter Robinson ] Date: Tue, 14 Jun 94 11:33:31 BST From: grayjw Subject: Re: Risks in UK Election Voting Process (Rushton, RISKS 16-14) Thomas Rushton is correct to identify this problem (of getting names from the electoral roll. There are two points to make. 1) You don't need ID to vote in the UK. Instead you must satisfactorily answer two "statutory questions" having given the name and address: a) Are you XY, resident at (address) (yes) b) Have you already voted in this election (no) 2) The problem is worst in the case where the "real" turnout is low, because it would be possible, in disguise, to vote several times under different names. However, in a high turnout election, it's more likely that the person whose ID you have used will turn up to vote. They are *not* denied a vote. If you turn up at the polling station, and give your name, and it's already marked on the register, then you will be asked the questions, and given a different colour of ballot paper, which you complete in the same way. If the final result is close enough for these papers to matter, then the election may have to be resolved in court. I agree that for low-turnout elections there is a problem with the system. This strikes me as a common risk in any democratic system: if you don't use your influence, someone else will. John Gray ---------------------------- Date: 31 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.15 ************************ 16-Jun-94 0:22:07-GMT,28334;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26984; Wed, 15 Jun 94 20:22:06 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18428; Wed, 15 Jun 94 20:22:01 EDT Received: by chiron.csl.sri.com id AA23686 (5.67b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Wed, 15 Jun 1994 17:17:21 -0700 From: RISKS Forum Sender: RISKS Forum Date: Wed, 15 Jun 94 17:17:19 PDT Subject: RISKS DIGEST 16.16 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Weds 15 June 1994 Volume 16 : Issue 16 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Congressman Jack Brooks' Statement on Crypto (David Banisar) WSJ article: RFI hoses medical equipment (Robert Allen) Summary of safety-critical computers in transport aircraft (Peter Ladkin) More on Airbuses (Robert Dorsett, Peter Ladkin, Wesley Kaplow, Pete Mellor, Kaplow again, Bob Niland) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ------------------------------ Date: Tue, 14 Jun 1994 14:20:25 -0400 From: David Banisar Subject: Congressman Jack Brooks' Statement on Crypto The following statement by Rep. Jack Brooks (D-TX) was today entered in the Congressional Record and transmitted to the House Intelligence Committee. Rep. Brooks is Chairman of the House Judiciary Committee and played a key role in the passage of the Computer Security Act of 1987 when he served as Chairman of the House Government Operations Committee. David Sobel Legal Counsel Electronic Privacy Information Center ============================================================= ENCRYPTION POLICY ENDANGERS U.S. COMPETITIVENESS IN GLOBAL MARKETPLACE For some time now, a debate has been raging in the media and in the halls of Congress over the Administration's intention to require U.S. corporations to use and market the Clipper Chip, an encryption device developed in secret by the National Security Agency. The Clipper Chip will provide industry and others with the ability to encode telephone and computer communications. The use of the Clipper Chip as the U.S. encryption standard is a concept promoted by both the intelligence and law enforcement communities because it is designed with a back door to make it relatively easy for these agencies to listen in on these communications. The law enforcement and intelligence communities have a legitimate concern that advances in technology will make their jobs more difficult. But the issue here is whether attempts to restrict the development, use and export of encryption amounts to closing the barn door after the horse has already escaped. The notion that we can limit encryption is just plain fanciful. Encryption technology is available worldwide -- and will become more available as time goes on. First, generally available software with encryption capabilities is sold within the U.S. at thousands of retail outlets, by mail, even, over the phone. These programs may be transferred abroad in minutes by anyone using a public telephone line and a computer modem. Second, it is estimated that over 200 products from some 22 countries -- including Great Britain, France, Germany, Russia, Japan, India, and South Africa -- use some form of the encryption that the Government currently prohibits U.S. companies from exporting. According to the May 16, 1994 issue of _Fortune_, not only are U.S. companies willing to purchase foreign encryption devices, American producers of encrypted software are also moving production overseas to escape the current export controls. Third, encryption techniques and technology are well understood throughout the world. Encryption is routinely taught in computer science programs. Text books explain the underlying encryption technology. International organizations have published protocols for implementing high level encryption. Actual implementations of encryption -- programs ready to use by even computer novices -- are on the Internet. The only result of continued U.S. export controls is to threaten the continued preeminence of America's computer software and hardware companies in world markets. These restrictive policies jeopardize the health of American companies, and the jobs and revenues they generate. I support, therefore, the immediate revision of current export controls over encryption devices to comport with the reality of worldwide encryption availability. I believe law enforcement and the intelligence community would be better served by finding real, and targeted ways to deal with international terrorists and criminals rather than promoting scattershot policies, which restrict American industries' ability to design, produce and market technology. Now -- more than ever -- we cannot afford to harm our economic competitiveness and justify it in the name of national security. ------------------------------ Date: Wed, 15 Jun 1994 11:37:44 -0700 From: Robert.Allen@eng.sun.com (Robert Allen) Subject: WSJ article: RFI hoses medical equipment The 15 Jun 1994 Wall St. Journal has an interesting front-page article about how RFI generated by radios & cellphones is screwing up operation of sensitive medical equipment such as heart defibrillators, diagnostic equipment, and even electric wheelchairs. Some of the horror stories sound apocryphal, like the electric wheelchair "zapped by radio waves" that sent it's passenger over a cliff. Others sound entirely possible: a 72 year old man died in an ambulance when the heart defib. device he was on failed due to RFI from the ambulance two-way radio. The ambulance mfgr. had replaced the steel roof with a fiberglass dome, and put the antenna on top (duhhhhh). The best story however was about some poor sap who had a pacemaker installed after diagnostic equipment indicated he needed one. It was later discovered the diagnosis was in error, and was caused by RFI from a television in the same room. Runners up for best story were from the mother who's use of a cellphone in the car affected the ventilator her child was using in the back seat. In a hospital ward a whole bunch of ventilators alarmed when the handyman keyed his transceiver. As is demonstrated by the TV case, even having technicians install and test new equipment can't account for the fact that just moving the stuff around during a spring cleaning might put two pieces in juxtaposition to cause problems. Having recently seen more than my share of medical equipment, I'm solely unimpressed with the ruggedness of it (it sort of reminds me of ICOM radios). Still, with more and more people using cellphones I figure we'll have more and more problems. I wonder if cellphones will be the health hazard in the '90's that radium watch dials were in the '40's? Robert ------------------------------ Date: Wed, 15 Jun 1994 22:13:19 +0200 From: Peter Ladkin Subject: Summary of safety-critical computers in transport aircraft Given the interest in RISKS on computers in aviation, and some confusion concerning characteristics of Airbus aircraft, I thought it might be useful to summarise for RISKS readers some of the current state of things. I believe there have been three major accidents involving Airbus aircraft in the last year: an A320 ran off the end of the runway in Warsaw in September 1993, killing two people and injuring many; the crew of an Aeroflot Airbus A310 lost control during cruise flight, which led to the death of everyone on board; and a China Airlines A300 crashed recently tail-first (!) on landing at Nagoya, killing all or almost all on board. The A300 and A310 aircraft have `conventional' control, that is, physical control of the aircraft is transmitted by mechanical or hydraulic means to most of the flight control surfaces. The normal flight control of the Airbus A320, A321, A330 and A340 aircraft, in contrast, is achieved by computer, to which the pilots' sidestick movements are one set of inputs. This is colloquially known as `fly-by-wire'. `Fly-by-wire' aircraft have been in regular use by the military for over 20 years, but the A320 is the first commercial `fly-by-wire' transport, introduced in the early 90's. Pilots have extremely limited direct physical control of A320/21/30/40 aircraft should the flight control computers be unavailable, a situation which is anticipated not to occur during the lifetime of the fleet. The first flight of the Boeing 777 took place on Sunday 12 June, 1994. The B777 is Boeing's first `fly-by-wire' commercial transport, which it is hoped will be `certificated' in April 95 with delivery to its first customer, United Airlines, in May 95. The B777 is a significantly different design from the A320, and I would be very surprised if there were to be any accidents attributable to features common to A320/21/30/40 and B777 aircraft which are not also common features of conventional aircraft such as the B737. Airbus claims its design philosophy is `evolutionary', that is, the systems are not designed from scratch, but introduced gradually into the company's designs after success in previous designs. Nevertheless, there are steps, such as that to `fly-by-wire' in the A320, which RISKS readers may consider more significant than others. See the article by J.P. Potocki de Montalk, Head of Airbus Cockpit/Avionic Engineering at Airbus, in Microprocessors and Microsystems 17(1). A useful and readable reference for those interested in A320 accidents is RISKS contributor Peter Mellor's long paper `CAD: Computer-Aided Disaster!' which contains a description of the design of the A320 Electrical Flight Control System, and detailed commentary on all A320 accidents to date, and is to my knowledge the only single source to do so. A version of this paper is to appear in High Integrity Systems journal. Apart from the flight control on A320/321/330/440s and B777s, there are potentially RISKy computer-based systems on almost all modern transport aircraft, of which maybe the most important are the autopilot/Flight-Director and the FADEC (Full-Authority Digital Engine Control). All commercial aircraft have autopilots of various degrees of sophistication (and most have Flight Directors, which provide passive guidance rather than active control), and these may be suspect in certain incidents (e.g. the Collins autopilots on B757 and B767 aircraft: see PGN in RISKS-15.08, and my posting in RISKS-15.13). Many modern aircraft also have FADEC, which has occasionally come under investigation, but I can't think of occasions so far on which they have been considered primary cause of accidents or incidents. Human factors are very important. A taskforce has recently been convened to study incidents of `controlled flight into terrain', in which the continued safe flight of the aircraft is impeded by a cloud with a crunchy center (see The Economist, June 4-10 1994, p92). In these accidents the physical performance of the airplane is generally not a factor, but they may nevertheless be computer-related, since guidance and air traffic control relies on computers to various degrees. Aircraft accidents are amongst the most well-studied of failures in any engineering discipline. I have never held any position in the aviation industry, but some of my research interests and hobbies bring me there. My continuing experience is that it pays to try to take as much care in forming opinions about them as it does to report them accurately in the first place. I wish I could be better at both. Peter Ladkin ------------------------------ Date: Wed, 15 Jun 1994 13:56:56 -0700 From: rdd@netcom.com (Robert Dorsett) Subject: Re: Overy, RISKS-16.15 From: Phil Overy wrote: Subject: Correction of my post on "A-THREE-HUNDRED" crash at Nagoya > > The Taiwanese plane did not crash after any kind of automation or airframe > failure, but when the auto-pilot was left on until too late. This is not clear. There are normally three or four ways to disengage any autopilot: - a switch on the glareshield. - a deactivate switch on the yoke - pushing or pulling forcefully on the yoke - a circuit breaker as a last resort In this case, it appears the crew were aware of the problem for over TWO MINUTES--an eternity--and fought the airplane to the ground. I refuse to see this trivially dismissed as "operator error" or "they didn't turn off the autopilot until it was too late." This is a horrifying situation, and if there is a mechanical or interface or modal failure lurking beneath the scenes, it needs to be rectified. AND UNDERSTOOD: if it's even as simple as a service or maintenance issue, then the problem could recur on other airplanes. > Peter Ladkin tells me that the president of the airline resigned after the > crash, so it doesn't sound as if they are trying to transfer responsibility > to the manufacturers. Again, after a long string of crashes. I believe the president or VP of JAL was ultimately compelled to resign after the 747 SR crash in Japan. This has nothing to do with culpability: it's accountability. A form of personal responsibility which seems to be quite absent in Western corporate culture. There is nothing more one can draw from it than that. >I could have phrased it better, but I would point out that Boeing also now use >fly-by-wire (on the brand new 777), so the earlier correspondent was misguided >in thinking that Boeing were staying away from fly-by-wire. The 777 is also a >much bigger plane than the A320... Airbus has continued evolving its aircraft line. There are now the A330 and A340, heavy long-range transports. Same interface. And > From: Wesley Kaplow writes: > Subject: Does it matter why A3??'s have a poor record? > The average persons response to all of the A3?? technical discussion would > probably be that it frankly it does not matter why these planes crash!. There are many people reading this newsgroup whose job descriptions include understanding and solving these problems so that future generations of aircraft do not cost lives or resources. The reason that RISKS keeps harping on airplane automation is that it has broad ramifications to the computer industry in general, and safety-critical systems in particular. What gets established as "safe" in aviation will undoubtedly define standards of "safety" for other disciplines: this includes specification and development paradigms. So these crashes should be of interest to ALL computer professionals and computer scientists. And there are certainly people out there whose job descriptions do include making managerial-level equipment decisions, who may not be aware or sensitized to some of these issues. ------------------------------ Date: Wed, 15 Jun 1994 21:18:54 +0200 From: Peter Ladkin Subject: Quarrelling over spilt airplanes [Dorsett, RISKS-16.15] In RISKS-16.15, Robert Dorsett disagrees with two quotes from my posting in RISKS-16.14. I disagree with his disagreements: > > Fly-by-wire aircraft use modes because they have to. > > This is not true. Early FBW aircraft were essentially open-loop analog > systems. I wasn't thinking about history when I made my assertion. There are many fly-by-wire aircraft types around *nowadays*, all but two of which are military, as of last Sunday. Do any of these aircraft *not* use modes? I can't think of one (but I would like to know of the exception that proves my rule). Robert's strong rejection may be as misleading as he thought my assertion was. Robert holds the view that sidestick control may have been the result of non-engineering decisions. That may be true (or not), but I don't consider it relevant to whether sidestick control is well-engineered or not in a given aircraft. > >A further comment about the Nagoya accident is appropriate. Current > >knowledge is that the pilots failed to follow normal, explicit > >procedure for control of the aircraft, > > Really? I've not seen that anywhere. Flight International, 11-17 May 1994 p5, "a pilot pushes forward on the control column to counteract the autopilot nose-up input. *This is against the published procedures ...*" (my emphasis). FI and David Learmount are regarded as accurate on such matters. > >and secondly that they had both > >been drinking alcohol, which is illegal for good reason. > > This has also not been substantiated. The investigators will not comment, Robert's assertions do not necessarily contradict mine. It may help to understand more of the context. The investigators will not comment officially, but then they're required not to - the official report on the Warsaw A320 accident is not out yet either, but that doesn't stop us knowing most of the factors involved there. Concerning the Nagoya A300 accident, there are normally-reliable aviation journal reports (sorry, the ref's buried) on the precise blood-alcohol level of the pilots which lead to my conclusion. > >senior management of China Airlines has resigned because of this > > accident. > > Because of the fifth major accident in as many years, > was the way I understood it. ..which are two ways of reporting the facts associated with the same event. Peter Ladkin ------------------------------ Date: Wed, 15 Jun 1994 13:50:41 -0400 From: Wesley Kaplow Subject: Not quite (re: Pete Mellor) Thanks to Peter Mellor it has some to my attention that my statement about loss of craft per craft delivered is not true. Unfortunately, I added that comment based on previous information about per-mile crash rates. The focus that I intended was that the average person does not really care why, only that they perceive that there is a potential safety problem. A good parallel might be the Audi 5000 series of reported "sudden-acceleration" problems. Although the Audi 5000 may not have had a larger incident rate of sudden acceleration than other cars, ultimately perception was the driving factor. People did not say: "oh that sudden acceleration problem, well that Audi 5000 was owned by someone from the '3rd' world, it must be his fault". Ultimately, the car had at least its name changed, and it probably cost Audi car sales. At least in the case of the Audi, I could choose not to buy the car. In the case of airline travel, and cannot make the choice between airframes because the information is not available. I may be making the choice based on poor information, but it is my poor decision to make. Also, the airframe loss statistics can be somewhat misleading as well, as crashes in the information Peter sent to me does not say, for example, if the 747 statistics includes losses such as the Canary Island collision, or the Lockerbee terrorist loss. Once again, I apologize of the incorrect statement. Wesley Kaplow, AT&T Bell Laboratories & Rensselaer Polytechnic Institute ------------------------------ Date: Wed, 15 Jun 94 17:52:23 BST From: Pete Mellor Subject: Re: Does it matter why A3??'s have a poor record? Wesley Kaplow writes in RISKS DIGEST 16.15: > Already, Airbus Industry has lost more planes per delivered plane > than other major aircraft manufacturer in the past 3 decades (Lockheed, > Boeing, MD). I would be interested to learn the source of this information. The following table shows the number of crashes per hull in service for different aircraft types. The source is Lundfahrtindustrie, and the table is quoted from ``Der Traum von Total Sicherheit'', Focus, 38, 1993, pp18-21. Aircraft No. in Hulls % Losses Type Service Lost DC-9/MD-80 2065 68 3.29 Boeing 727 1831 62 3.39 Boeing 737 2515 57 2.27 Boeing 747 988 22 2.23 DC-10 446 21 4.71 Airbus A300/310 636 7 1.10 Airbus A320 411 4 0.97 Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB Tel: +44 (71) 477-8422, Fax.: +44 (71) 477-8585, E-mail (JANET): p.mellor@csr.city.ac.uk ------------------------------ Date: Wed, 15 Jun 1994 13:29:15 -0400 From: Wesley Kaplow Subject: Re: Does it matter why A3??'s have a poor record? (Re: Mellor) Dear Pete, Unfortunately I did a back of the envelope calculation that is probably more suited to comparing the number of takeoffs/landings against accident rates. I remember seeing statistics on the number of 757 lost per total mile (or sorties) vs. A3??. The numbers were quite heavily in favor of the Boeing. However, you are absolutely correct. I should not have made sure that I have accurate data before such a broad statement. Please delete that section the message. I should know better. The real point that I wanted to make is that the general public does not care about root-cause analysis, fly-by-wire, or different flight modes. Perceptions of safety, like those that plagued the DC-10 for several years, and like the Audi 5000, are what people care about. Our rationalization that these crashes occurred due to pilot error in 3rd world countries does not make me feel any safer. It would be interesting to know the breakdown of the essential reasons for the airframe losses in the table you provided. There are three categories I would like to see: 1) Loss on the ground (at least 2 of the 747's were lost this way) 2) Loss due to mechanical defect 3) Crew error. Also, which accidents cause a total loss or just loss of the frame. For example, a 747 was lost part of its skin, but landed safely (with MOST of its passengers). A 737 got a moon roof, but landed safely (with all of its passengers and MOST of the crew). A DC-10 (with the blown cargo door) landed with most of its passengers and crew. I assume that these airframes are gone, but are they really "losses" in the sense that the average person would think they are crashes. Moreover, some of these craft were blown out of the ski by terrorists, or set fire on the ground. I believe that this changes the numbers in the table. For example, if one does the following 22 hulls lost for the 747 (are there really only 988 in service?) - 2 Canary Island - 1 Lockerbee ----- 19 "Crashed Hulls" 19/988 = 1.92% losses this is compared to the 2.23% losses in the table. Another possibly category, since the blame seemingly points to problems of third world operators, is how many of these crashes are airlines that have questionable maintenance. The last category is time. Although I am chancing fate, when was the last DC-10/MD-11 crash? What is the current rate, as compared to previous years. Do these planes just need to get over "infant" problems, or is the rate essentially constant? Moreover, if we look at unexplainable crashes, at least for the Boeing and DC/MD planes we can usually identify a real design flaw to pin the crash on (cargo doors, engine mount pins) I can proudly say (well not really) OUR DARN AMERICAN PLANS CRASH BECAUSE OF DESIGN FLAWS WE CAN FIGURE OUT AFTER A COUPLE OF REALLY BIG CRASHES! (a smiley face goes here). However, there is a point here and that is why are the A3?? losses seemingly predominately cause by some pilot to ship interface problem. Once again, I'm sorry to have submitted unsubstantiated information, and I promise not to do it again. Wesley Kaplow, AT&T Bell Laboratories & Rensselaer Polytechnic Institute ------------------------------ Date: 15 Jun 1994 16:42:03 GMT From: rjn@hpfcla.fc.hp.com (Bob Niland) Subject: Re: Airbus (Kaplow, RISKS-16.15) > ... if we play only on the statistics, I want a airplane with a good > safety record. ... If the statistics bear this out, it raises a point I haven't seen mentioned in the periodic discussions about the AirBus Industrie family of flying machines. If AI is indeed experiencing more hull losses than comparable airframes from other makers, then as a passenger, I don't really care that AI is having greater success in obtaining "pilot error" determinations in many of the crashes. If their aircraft are more susceptible to pilot error, then AI's aircraft in fact have a problem, and I won't ride them. Whether computer or airliner, successfully blaming system inadequacies on the user is no substitute for designing usable systems in the first place. A comparison of incident/accident rates by airframe, showing the percentage resolved as "pilot error", would be interesting. Bob Niland 1001-A East Harmony Road, Suite 503, Fort Collins Colorado 80525 USA rjn@csn.org CompuServe: 71044,2124 ------------------------------ Date: 31 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.16 ************************ 17-Jun-94 15:53:49-GMT,30259;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17996; Fri, 17 Jun 94 11:53:47 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07348; Fri, 17 Jun 94 11:53:34 EDT Received: by chiron.csl.sri.com id AA25450 (5.67b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Fri, 17 Jun 1994 08:41:48 -0700 From: RISKS Forum Sender: RISKS Forum Date: Fri, 17 Jun 94 8:41:46 PDT Subject: RISKS DIGEST 16.17 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Friday 17 June 1994 Volume 16 : Issue 17 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** SORRY FOR ABORTIVE ATTEMPT AT MIME-ING RISKS in RISKS-16.15. ***** I MAY TRY AGAIN SOME DAY IF I GET THE RIGHT FORMAT! ***** See last item for information on RISKS (comp.risks) ***** Contents: Poulsen guilty of L.A. charges (Mich Kabay) Counterfeit graduation tickets (Mich Kabay) "Virtual Billboard" on TV (R. Peter Jackson) Misdirected Mail (Jeffrey Austen) Revenue Canada database allows birthday change (John Howard) NIST Response to Blaze Attack on Clipper (Ed Roback) ROLM phones and "Do Not Disturb": how to lose calls (Rob Levandowski) A320 hull losses: Lies, damned lies and statistics (Pete Mellor) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: 16 Jun 94 18:01:35 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@CompuServe.COM> Subject: Poulsen guilty of L.A. charges >From the United Press International newswire (94.06.14 @ 18:45 EDST) via Executive News Service (GO ENS) on CompuServe: "Hacker Pleads Guilty to Fraud", By ELKA WORNER LOS ANGELES, June 14 (UPI) -- A computer hacker accused of breaking into computer systems to rig promotional contests at radio stations, eavesdrop on private citizens and thwart police investigations, pleaded guilty Tuesday to fraud. Kevin Poulsen, 28, of Menlo Park, faces 40 years in prison and a $1,750,000 fine when he is sentenced Oct. 17. He pleaded guilty in federal court to computer fraud, interception of wire communications, mail fraud, money laundering and obstruction of justice. The author summarizes the case against Poulsen [I added details she didn't include]: o [manipulated the phone systems to cheat in radio-station call-in contests that awarded prizes to a specific caller in sequence]; he stole "two Porsches from radio station KIIS-FM, $20,000 in cash from KPWR-FM and at least two trips to Hawaii and $2,000 in cash from the same station." o used lies and counterfeit IDs to claim and then sell his prizes. o uncovered FBI-run businesses, spotted FBI wiretaps and listened in on conversations of ordinary citizens. o called a confederate "minutes after his arrest to ... hide the computers used in his illicit activities." o lived on the run for 18 months after being indicted in San Francisco by a grand jury until his arrest in April 1991 . o in July 1994, he will be tried "on 18 counts of telecommunications and computer related fraud, including charges that he stole Pacific Bell access codes to invade an Army computer network and to obtain information used in FBI investigation of former Philippine President Ferdinand Marcos." o worked for the Soviet consul in S.F. by obtaining unpublished telephone numbers." Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn ------------------------------ Date: 16 Jun 94 18:01:29 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@CompuServe.COM> Subject: Counterfeit graduation tickets >From the Reuter newswire (94.06.14 @ 14:25 EDST) via Executive News Service (GO ENS) on CompuServe: DARTMOUTH ALUMNUS CAUGHT SELLING PHONY GRADUATION TICKETS HANOVER, N.H., June 14 (Reuter) - A former Dartmouth College student was arrested for selling counterfeit graduation tickets for the event at his Ivy League alma mater, police said Tuesday. Corby Edward Page, 23, a computer programmer from Houston, Texas and a 1992 Dartmouth graduate, admitted to making the fake tickets on his computer and selling them before the June 12 graduation for $15 each, said Hanover Police Sergeant Christopher O'Connor." According to the story, a student who bought a bogus ticket "called police after noticing the fake tickets were different from the real ones." The idiot grad was caught "in the lobby of the posh Hanover Inn, opposite the Dartmouth campus, as he sold tickets, police said." He was charged with fraud. ------------------------------ Date: Thu, 16 Jun 1994 23:07:10 -0700 (PDT) From: "R. Peter Jackson" Subject: "Virtual Billboard" on TV On Wednesday, June 15, 1994, the Los Angeles Times reported on page D7 in their relatively new weekly section called "The Cutting Edge Computing/Technology/Innovation" the following: "Virtual Billboard" Is Sign of the Times Baseball teams would love the revenue from behind-the-batter billboards, and advertisers like the idea of being on screen without fear of remote-control zapping. But purists denounce the idea as antithetical to the tradition of the game, and some players say the signs make it harder to see the ball. Now inventors have devised a system that will create electronic billboards visible only to people watching on TV. Princeton Electronic Billboards Inc. in Princeton, N.J., has been testing "virtual billboards" with the Baltimore Orioles and its telecasters. Working with the David Sarnoff Research Center, the firm developed a computerized system that inserts images electronically into TV shows. Before a game, the TV cameras scan the arena and "memorize" features of the park, such as creases in the padded wall behind home plate and other boundaries that define a virtual billboard. When the camera passes those features during the telecast, the system inserts the sign, or the part of it visible in the camera's frame of reference. Ballplayers on the field appear to walk in front of the sign. Ideally, the TV audience will be unable to tell whether the billboard hangs in the ballpark or only in cyberspace. Local sponsors could buy a billboard in a national telecast, and a national advertiser could deliver different messages in each market. Princeton Electronic hopes to make the system available commercially before the baseball season ends this fall." It seems obvious that the RISKS increase as the truth of the picture in the TV medium can be selectively and partially modified. It is difficult enough now for many people to tell whether what is seen on TV is real or fake [note the many similarities between national network TV news, major metropolitan network news and the recreated news in Hard Copy and its several competitors.] R. Peter Jackson, Mariposa Computer Services, 982 Jimeno Road, P. O. Box 149, Santa Barbara, California 93102-0149 USA 1-805.963.4305 ------------------------------ Date: Thu, 16 Jun 1994 11:24:16 -0600 From: jra1854@tntech.edu (Jeffrey Austen) Subject: Misdirected Mail I received the following in the mail the other day. Quite amusing. I wonder if the CIA would send out a similar message if one of their secrets got out? >One of IBM's electronic mail distribution nodes experienced a >problem routing mail from Wednesday June 8, 1994, through >approximately 7:00pm Thursday June 9, 1994. This may have >resulted in your having received proprietary information that >was not intended for you. If you have received such >information, please return it to the Internet address: > xxx@xxx.ibm.com >without retaining any copies of it. If you have already >destroyed or discarded the information, please confirm this by >sending a note to this address stating that the information >you received has been destroyed. > >If you are not sure whether you should have received certain >information or if you have any other questions, please call >xxx xxx at (xxx) xxx-xxxx. Jeffrey Austen, Tennessee Technological University, Box 5004 Cookeville Tennessee 38505 U.S.A. jra1854@tntech.edu (615) 372-3485 ------------------------------ Date: Thu, 16 Jun 94 23:03:48 PDT From: jhoward@sol.uvic.ca (John Howard) Subject: Revenue Canada database allows birthday change Something has just come to light that might be of interest to Risks readers concerning my end of the year taxes here in Canada. For whatever reason, my new accountant (who resides in a different city) filed my tax with a typo on it: my birthday was off by one day. Well, as expected, the system the Feds have sent me a note saying my birthday had changed from the last time I had filed. The form asked me to come down to my local office to correct the error, or if this wasn't an error don't worry about it. How can they say "don't worry about it"? As far as I know people aren't allowed to change their birthday! I chatted with the teller that helped me correct the error. He said that his most memorable error was a situation where a senior had transposed the middle digits of his year of birth to make him younger by decades. The error was caught when the computer found a young person claiming pension benefits. The teller enlightened me by saying that personal data is taken from only the most recent filing. I suppose this would be ok for a change of address or even of name, but of birthday! Imagine your favorite ten risks.... John Howard ------------------------------ Date: Thu, 16 Jun 1994 17:29:40 -0400 (EDT) From: ROBACK@ENH.NIST.GOV Subject: NIST Response to Blaze Attack on Clipper Note: The following material was released by NIST in response to recent articles regarding AT&T/Matt Blaze and the key escrow chip. A second more technical response follows. ------------------------- June 2, 1994 Contact: Anne Enright Shepherd (301) 975-4858 The draft paper by Matt Blaze* describes several techniques aimed at circumventing law enforcement access to key escrowed encryption products based on government-developed technologies. As Blaze himself points out, these techniques deal only with the law-enforcement feature, and in no way reduce the key escrow chips' inherent security and data privacy. -- "None of the methods given here permit an attacker to discover the contents of encrypted traffic or compromise the integrity of signed messages. Nothing here affects the strength of the system from the point of view of the communicating parties...." p. 7. Furthermore, Blaze notes that the techniques he is suggesting are of limited use in real-world voice applications. -- "28 minutes obviously adds too much latency to the setup time for real-time applications such as secure telephone calls." p. 7. -- "The techniques used to implement them do carry enough of a performance penalty, however, to limit their usefulness in real-time voice telephony, which is perhaps the government's richest source of wiretap- based intelligence." p. 8. Anyone interested in circumventing law enforcement access would most likely choose simpler alternatives (e.g., use other nonescrowed devices, or super encryption by a second device). More difficult and time-consuming efforts, like those discussed in the Blaze paper, merit continued government review -- but they are very unlikely to be employed in actual communications. All sound cryptographic designs and products consider trade-offs among design complexity, costs, time and risks. Voluntary key escrow technology is no exception. Government researchers recognized and accepted that the law enforcement access feature could be nullified, but only if the user was willing to invest substantial time and trouble, as the Blaze report points out. Clearly, the government's basic design objective for key escrow technology was met: to provide users with very secure communications that will still enable law enforcement agencies to benefit from lawfully authorized wiretaps. It is still the only such technology available today. Today, most Americans using telephones, fax machines, and cellular phones have minimal privacy protection. The key escrow technology -- which is available on a strictly voluntary basis to the private sector -- will provide the security and privacy that Americans want and need. * Statements from "Protocol Failure in the Escrowed Encryption Standard," May 20 draft report by Matt Blaze, AT&T Bell Laboratories ----- Note: The following provides additional technical material in response to questions regarding a recent paper by Matt Blaze on key escrow encryption. -------------------------------------- Technical Fact Sheet on Blaze Report and Key Escrow Encryption Several recent newspaper articles have brought attention to a report prepared by Dr. Matthew Blaze, a researcher at AT&T's Bell Labs. These articles characterize a particular finding in Blaze's report as a ~flaw~ in the U.S. government's key escrow encryption technology. None of the findings in Dr. Blaze's paper in any way undermines the security and privacy provided by the escrow encryption devices. The finding which has received the most publicity could allow a non-compliant or ~rogue~ application to send messages to compliant or ~non-rogue~ users which will not be accessible by law enforcement officials through the escrowed encryption standard field called the Law Enforcement Access Field (LEAF). Dr. Blaze's approach uses the openly disclosed fact that the LEAF contains 16-bit checkword to prevent rogue users from modifying the law enforcement access mechanism. This 16-bit checkword is part of the 128-bit LEAF, which also includes the enciphered traffic key and the unique chip identifier. Dr. Blaze's method is to randomly generate different 128-bit LEAFs until he gets one that passes the checkword. It will take on average 216, or 65,536 tries. This is not a formidable task; it could be done in less than an hour. Dr. Blaze questions the adequacy of a 16-bit checkword and suggests using a larger one, to ensure that the exhaustion attack would be so time consuming as to be impractical. The chip designers recognized the strengths and limitations of a 16-bit checkword. Following are the reasons why they chose to use a checkword of only 16 bits: * There were four fundamental considerations that the designers considered in choosing the LEAF parameters. These were: (1) ease of access by authorized law enforcement agencies, (2) impact on communications, (3) a sufficiently large identifier field which would not constrain manufacturers, and (4) the difficulty required to invalidate the LEAF mechanism by techniques such as those described by Dr. Blaze. * The purpose of the LEAF is to preserve law enforcement's ability to access communications in real-time. The encrypted traffic key, which enables them to do this, is 80 bits long. In addition to this 80-bit field, the LEAF must contain the unique identification number of the key escrow encryption chip doing the encryption. * The size of the identifier field was the subject of considerable deliberation. In the earliest considerations it was only 25 bits long. The chip designers recognized that 25 bits did not offer enough flexibility to provide for multiple manufacturers of key escrow devices. Different chip manufacturers would need manufacturer identifiers as well as their own chip identifiers to ensure that identifiers are unique. Eventually, the designers agreed that 32 bits would adequately meet this requirement. * In many environments, error-free delivery of data is not guaranteed, and there is considerable concern by communication engineers that requiring error-free transmission of a fixed field (the LEAF) could make the encryption device difficult to use. In early discussions with industry, they were opposed to any checkword. In the end, they agreed it would be acceptable if the size of the LEAF was restricted to 128 bits. This left 16 bits for a checkword to inhibit bypassing the LEAF. While recognizing the possibility of exhausting these 16 bits, the designers concluded that 16 bits are adequate for the first intended application. Security enhancements are being made for other applications, such as the TESSERA card. Note that computations are required to search for a matching checkword, which then has to be properly substituted into the communications protocol. The performance and cost penalties of the search operation are significant for telephone, radio, and other such applications, thus providing adequate protection against this technique for bypassing the LEAF. In summary: * Although this technique would allow one to bypass the LEAF, the security provided by the escrow encryption devices would not be altered. Users' information would still be protected by the full strength of the encryption algorithm. * Dr. Blaze was accurate in noting that these attacks are of limited effectiveness in real-time telephony. * When designing the key escrow chip, NSA emphasized sound security and privacy, along with user friendliness. The attacks described by Dr. Blaze were fully understood at the time of initial chip design. The use of 16 bits for the checkword was an appropriate choice in view of the constraints of a 128-bit LEAF. It provides excellent security for real-time telephone applications with high assurance that law enforcement's interests are protected. * Dr. Blaze's research was done using prototype TESSERA cards. As part of the family of planned releases/upgrades, NSA already has incorporated additional security safeguards into the production TESSERA cards to protect against the kinds of attacks described by Dr. Blaze. ------------------------------ Date: Thu, 16 Jun 94 12:26:55 GMT From: rlvd_cif@uhura.cc.rochester.edu (Rob Levandowski) Subject: ROLM phones and "Do Not Disturb": how to lose calls Here at the University of Rochester, students are given ROLMphone 120DCMs in their rooms. These phones (or, more precisely, the digital switch that they are connected to) have a function called "do not disturb". When the appropriate code is entered into the keypad, the line is put into DND mode, and it -will not ring- for any reason. However, if someone tries to call, they hear ringing. There are two problems with the implementation of this feature. First, the code to activate and de-activate the feature is anything but intuitive. Having lived off-campus for a while, I forget the exact code, but it is along the lines of #6x. The code for speed-dialing numbers is #3x. On more than one occasion I meant to hit a speed-dial and instead activated do-not-disturb. This wouldn't be a big problem... except that there is no indication whatsoever that you are in DND mode. No lights, no tones, no message to callers. I missed calls for days the first time I did this... and a lot of people got concerned because I "was never home". This system should at the least have some sort of different dialtone or indicator light to show that you won't be getting any calls. (God knows the ROLM 120 has enough blinky-lights...) Likewise, since the switch is equipped with PhoneMail, it would be nice if it could give an announcement... "The party you have dialed is not accepting calls at this time." The privacy may be nice when you're using your dorm room for, shall we say, after-hours social research ;) -- but if you're forgetful like me, the implementation is pretty troublesome. Rob Levandowski, Computer Interest Floor associate / University of Rochester macwhiz@cif.rochester.edu ------------------------------ Date: Thu, 16 Jun 94 19:45:06 BST From: Pete Mellor Subject: A320 hull losses: Lies, damned lies and statistics This thread of the discussion was originally started by Wesley Kaplow in RISKS DIGEST 16.15 under the title: "Does it matter why A3??'s have a poor record?" To recap, Wesley said (without citing a source): > Already, Airbus Industry has lost more planes per delivered plane > than other major aircraft manufacturer in the past 3 decades (Lockheed, > Boeing, MD). I contradicted this in RISKS 16.16, citing a table of statistics from an article entitled ``Der Traum von Total Sicherheit'' ["The Dream of Total Safety"], in the German magazine Focus, 38, 1993, pp18-21, and Wesley has since agreed that his statement requires support (see his follow-up mailings). The table was as follows:- >Aircraft No. in Hulls % Losses >Type Service Lost > >DC-9/MD-80 2065 68 3.29 >Boeing 727 1831 62 3.39 >Boeing 737 2515 57 2.27 >Boeing 747 988 22 2.23 >DC-10 446 21 4.71 >Airbus A300/310 636 7 1.10 >Airbus A320 411 4 0.97 Focus magazine cited "Luftfahrtindustrie" (NOTE: not "Lundfahrtindustrie", as I originally transcribed it) as the source. Since then, I have been jumped on from a great height by several RISKS contributors who have accused me of abusing statistics. Since this is not something I do deliberately, I would like to make the following points (taking into account the various objections raised by those who have written to me):- 1. I am well aware that the statistics above are incomplete. They do not allow for the total operating time of each type. They do not distinguish between losses due to on-board system failure and losses due to other causes which could not possibly be blamed on the manufacturer (e.g., the Lockerbie bombing, the Vincennes shoot-down). They do not take account of wear-out and natural retirement, so that the number shown may be the "number sold" and not the "number in service". I quoted them because they were all I had at the time (while being acutely aware of their imperfections). 2. Wesley's original statement *is*, however, refuted by these statistics *provided they are correct* (see point 3). A secondary question arises: "Is this a meaningful measure of the safety of a type of aircraft?" I will return to this in point 4. 3. Peter Ladkin pointed out to me that the source name that I had originally misread as "Lundfahrtindustrie" and assumed to be some official body which records air accident statistics, is in fact "Luftfahrtindustrie" (well, it was in small print! :-) and means simply "Air Travel Industry". In other words, the source cited by Focus magazine is totally vague, and (as Peter said) about as authoritative as "I read it on the net"! :-) The statistics I naively quoted therefore need substantiation. 4. What would convince Joe Public that a given aircraft type was safe to fly? There are several possible measures of the safety of an aircraft design (note: I do *not* pretend that this list is exhaustive):- a) Deaths per passenger mile on the given type. This is used by the aircraft manufacturing industry. Conclusion: air travel is the safest way of going anywhere. b) Deaths per passenger *hour* on the given type. This makes flying about as safe as driving, but the risk would seem to be tolerable, since a probability of 10^-4 per year of dying in a road accident doesn't seem to worry most people (figures based on official UK statistics). c) Crashes (i.e., hull write-off) per revenue flight hour. This is used by the certification agencies (FAA, JAA, etc.) when awarding an airworthiness type certificate. The target is a maximum probability of loss of aircraft of 10^-6 per flight hour due to *all* causes. Historically, statistics show that *system-related* causes account for 1 in 10. The conservative assumption that there are 100 critical systems on board then leads to the famous 10^-9 requirement for probability of failure of an individual flight-critical system. d) Crashes per cycle (take-off plus landing). e) Crashes per example delivered (which is where we came in! :-) f) Passenger deaths per cycle. g) Serious incidents per flight hour or per cycle. (Q: "How many accidents has the A320 had?" A: "Five - You forgot about Lille, where an A320 landed on top of a Mooney, taking off both its wings and the empennage, and collapsing the A320's front gear. Since nobody was hurt, it doesn't count, or does it?") The whole picture is confused by the fact that the public perception of risk is biased *against* rare events that kill lots of people, and less against common events that kill a few. (In assessing any event that loses the aircraft, you must assume the worst case: that you kill everyone on board. If you crash a car, it's just you and the guy you hit!) I don't pretend to give an answer here, simply raise a few pertinent questions, whose answers (IMHO) are far from obvious. 5. A fairer comparison would be between the A320 and competing aircraft *of the same generation*. I would like to thank Robert Dorsett for the following:- 757 = 0 in eleven years. 767 = 1 in twelve years. (Lauda) A320 = 4 in five years. (Air France, Indian Airlines, Air Inter, Lufthansa) 6. Given that all the statistics above are deficient (basically, they lack an exposure time base), they do still tell us *something*. (In considering a fleet above a certain size, we could assume roughly the same operating hours per day for each example, and things like maintenance time, etc., would average out.) We could *tentatively* conclude that the A320 is a long way from being a flying coffin, but also a long way from being the safest aircraft ever, or even as safe as it should be, given its modernity. The public perception of the A320 seems to be that it is the most dangerous thing that ever left the ground. IMHO this is wrong, and we should be careful not to spread false alarm. There are, of course, better statistics (e.g., from Flight International) and I shall attempt to locate a few. The best come from the air insurance industry, but I am not sure that I can get my grubby paws on those for reasons of confidentiality. In the meantime, if anyone knows of a good source ... :-) Also, how can I phrase an argument to convince my mother that I stand a greater chance of being run over crossing St. Johns Road while walking from Farringdon tube station to the University than I do of dying in an air crash? Then I won't have to make long distance 'phone calls from the airport in B*m***k Egypt to tell her we landed safely every time I go to a conference! :-) Peter Mellor, Centre for Software Reliability, City University, Northampton Sq London EC1V 0HB +44 (71) 477-8422 p.mellor@csr.city.ac.uk ------------------------------ Date: 31 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.17 ************************ 21-Jun-94 16:15:41-GMT,17145;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07697; Tue, 21 Jun 94 12:15:40 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03719; Tue, 21 Jun 94 12:15:34 EDT Received: by chiron.csl.sri.com id AA29388 (5.67b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Tue, 21 Jun 1994 09:10:18 -0700 From: RISKS Forum Sender: RISKS Forum Date: Tue, 21 Jun 94 9:10:16 PDT Subject: RISKS DIGEST 16.17 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Tuesday 21 June 1994 Volume 16 : Issue 17 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Physical Location via Cell Phone (Derek Atkins) RF Interference (unattributed alt.shenanigans item via Elana) EDI mail storm (Cheryl Berthelsen via Brian D. Renaud) Re: Campaigns and Elections (Peter J. Denning) Re: Airframe Safety (Bill Murray, Mark Staler, Andy Dingley, Tom Lane) Shopping Risks... (Philip R. Banks) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Sun, 19 Jun 94 01:32:47 EDT From: Derek Atkins Subject: Physical Location via Cell Phone I'm sure many people have heard this already, even though it only happened yesterday (Friday, 17 June). I'm sure most people have heard about O.J. Simpson [he was charged with a double murder], and Friday evening he took a long drive around the LA Highway system. Police said that they discovered his location (and even his very car) through the use of the Cellular Phone system. The RISKS are obvious: Being able to locate someone just by their cell phone, and by extension, just keeping a cell-phone turned on transmits enough information to be located. For example, if anyone carries a Digital Personal Communicator (DPC), or other such flip-top cell phones, or any cell phone, for that matter, they can be physically tracked, basically, anywhere in the country through the cellular phone system. And as the cells get smaller, the location detail gets better. What will happen when we have micro-cellular phones, a cell for every building, or even a cell for every office! Think about the level of personal tracking that can be done with this level of detail! -derek ------------------------------ Date: Sun, 19 Jun 1994 02:18:02 GMT From: elana@netcom.com (Elana Who?) Subject: a risk from alt.shenanigans of all places (!!!) [No, I did NOT make this post up!!! Elana] >From alt.shenanigans... scott.baldwin@castles.com (Scott Baldwin) writes: >M>because we tend to get blamed for any interference unless we can find >M>the actual source!) >M>Radio direction finding is fun... > We used to do this all the time as well! HF radios of course. What I >found to be pleasing, is this old VW Bug (about a '63 I think) would >always be going down the freeway during the afternoon at the same time I >would be going to work. I heard that if you had high enough RF power >you could disturb the electric fuel pump, so I tried this one day using >a 600 Watt PEP amp and keyed an AM carrier, and what did I see??? > A VW bug slowing down and starting to pull over >:) I did this for an >entire week... hehe! ------------------------------ Date: Fri, 17 Jun 94 11:14 EDT From: brena@hcia.com (Brian D. Renaud) Subject: EDI mail storm [Seen on the Health Information Management Listserv -- Brian] Date: Thu, 16 Jun 94 23:04:54 -0500 From: Cheryl Berthelsen Subject: IS THE WHAT EDI IS ALL ABOUT? The following article was published today in the Jackson Clarion-Ledger. Is this what Electronic billing does for us? Are the Medicare fiscal intermediary software programs for claims processing really that stupid? WOMAN GETS THE MESSAGE, OK? Dorothy Joyce's mailman brought her 131 letters in one visit, and none of it was junk mail. All were from one correspondent: MEDICARE. "The postman said, 'Lady, I've never delivered so much mail to one person before,'" Joyce, 77, said. Each envelope contained four notices concerning Joyce's claim for a $29.97 doctor's visit. Each cost 46 cents to mail; the government spent $60.26 to tell Joyce her claim was invalid. After her May 17 visit to Dr. Samual P. Robinson's Gulfport office, Robinson's computer notified Medicare's computer that Joyce had been there. And kept on notifying, said Margaret Brundidge, a clerk with Travelers Insurance Co. Medicare office in Jackson. Cheryl Berthelsen, PhD, Assistant Professor, Univ. of Mississippi Medical Center, School of Health Related Professions (SHRP), Jackson, MS 39216 ------------------------------ Date: Fri, 17 Jun 94 12:51:23 EDT From: pjd@cne.gmu.edu (Peter J. Denning) Subject: Re: Campaigns and Elections (Agre, RISKS-16.12) Phil Agre recently said he found it "scary" that some political campaigners are apparently tailoring political ads to probable interests of individuals, based on extracts from available databases. He is, however, describing an activity that is already happening with advertising in general. I don't understand the grounding for his assessment that tailored political ads are "scary". Few of us like the telemarketers who call at dinner and seem to know things about us, but most people would call this "annoying" not "scary". Peter Denning ------------------------------ Date: Thu, 16 Jun 94 17:27 EST From: William Hugh Murray <0003158580@mcimail.com> Subject: Airframe Safety If I recall correctly, this thread began when someone asserted that AI aircraft were just too unsafe for him. I remember thinking at the time that that was a "nationalist" position not supported by facts. One set of facts looks something like this: >DC-9/MD-80 2065 68 3.29 >Boeing 727 1831 62 3.39 >Boeing 737 2515 57 2.27 >Boeing 747 988 22 2.23 >DC-10 446 21 4.71 >Airbus A300/310 636 7 1.10 >Airbus A320 411 4 0.97 According to this data a rational person might actually prefer AI airframes. Based upon the data a rational person would certainly prefer the A320 to, let us say the B727. However, based upon public perception, one would certainly prefer the B727. The 727 enjoys a well-deserved public reputation for safety. On the other hand, those of us who have been adults since the 727 was introduced remember that early in their use they fell out of the sky like hail stones. In response to a number of crash landings the operations manual was changed. The landing configuration was changed from nose-down low-revs to nose-high high-revs. That change contributed greatly to the enviable safety record of the 727. Based upon the data above, one might prefer the A320 to the DC10. On the other hand, the data could be very misleading. The DC10s, having been around a great deal longer, may have lost far fewer airframes per operation. (Besides, I like to fly on DC10s. In many configurations, they are the most comfortable planes in the air. I do not pretend to be completely rational. If I were, I would certainly prefer any of these planes to my car.) My point is that, given the sizes of the (Ns) numbers above and given what they measure, it is simply not possible to make a rational choice between the planes. It probably is not possible even to rationally prefer them to automobiles. I make my living trying to help my clients make rational and safe choices in areas where there is all too much data about the consequences of an event and all too little about the rates of occurrence. Given the statistical significance of this data, I doubt that I could change the client's life expectancy by more than a few seconds, one way or the other, by making a systematic choice between those planes, on that or any other available data, even if she took a flight every day. Taken across the entire population likely to fly on those planes, I could do a tiny bit better. However, I could not do sufficiently better to justify public policy. I sympathize with those charged with doing so. There seems to be a political demand, or at least an expectation, in our current culture for zero risk. The real world does not work that way. William Hugh Murray New Canaan, Connecticut 06840 ------------------------------ Date: Thu, 16 Jun 1994 13:01:03 +0800 From: stalzer@macaw.hrl.hac.com Subject: Flighty statistics In RISKS-16.16 p.mellor@csr.city.ac.uk presented the following data: >Aircraft No. in Hulls % Losses >Type Service Lost > >DC-9/MD-80 2065 68 3.29 >Boeing 727 1831 62 3.39 >Boeing 737 2515 57 2.27 >Boeing 747 988 22 2.23 >DC-10 446 21 4.71 >Airbus A300/310 636 7 1.10 >Airbus A320 411 4 0.97 Unfortunately, there is no way to interpret this data. Maybe the DC-10s were flown several times a day and the A320s were parked. You must supply miles flown vs. hulls lost, or, even better yet, hops vs. hulls lost (since most accidents happen in takeoff/landing). Mark Stalzer stalzer@macaw.hrl.hac.com ------------------------------ Date: Thu, 16 Jun 94 21:27:58 GMT From: dingbat@codesmth.demon.co.uk (Andy Dingley) Subject: Airbus Risks On a lighter note, this discussion of Airbus RISKS reminds me of an article in Flight International a few years ago, on the Airbus and its software problems. The Airbus has many new software-related systems, and had many teething troubles with them. Navigation systems were mentioned as problematic, as were the concerns about fly-by-wire. The crucial problems, as far as operations were concerned, weren't about any of these high profile systems; they were about something as mundane as the computer controlled lavatory valves. If you have a navigational failure, the co-pilot needs to get their manual plotter and charts out again, but you can still fly on. OTOH, a plane full of a few hundred incontinent pensioners on their way to Tenerife isn't going *anywhere* unless the toilets are working ! Andy Dingley Codesmiths of Newcastle dingbat@codesmth.demon.co.uk ------------------------------ Date: Sat, 18 Jun 94 20:50:15 -0700 From: Tom Lane Subject: How to lie with statistics (Re: Does it matter why A3??'s have a poor record?) Pete Mellor writes: > The following table shows the number of crashes per hull in service for > different aircraft types. I can't believe that anyone would propose such numbers as a useful measure of safety. The Airbus models are much newer than the ones they are being compared to. 727s, for instance, are quite old (most of 'em are approaching retirement, are they not?) and would have seen many more flights than A3xx craft. The low rates reported for A3xx probably just reflect the youth of the fleet. I would find loss rates per mile flown, or perhaps per departure, far more credible. Anyone have that data? tom lane ------------------------------ Date: Sat, 18 Jun 1994 13:40:01 +1200 From: Subject: Shopping Risks... I am sure most people reading the RISKS DIGEST have been bitten by the automated supermarket checkout machines. However, having been bitten recently, I believe it bears repeating. It has been a weekly routine with my family to help my mother on thursday nights do the shopping. Normally we take along a list, a calculator and generally have a fairly good chat while we take care of the groceries. Now the supermarket we shop at has a checkout system based on a barcode scanner that they pass the goods over to tot the price up. We double check the price using the calculator by adding up the shelf listed prices as we procure the items from the shelf. But in over two years of doing this we have *never* had a calculator result that tallied exactly with the given price. Often this can be explained as human error but the supermarket has an array of interesting tricks that often account for this difference. 1) Not listing the price. Anywhere. This is often the case in the bread section. 2) Listing the *wrong* price. Several times we have bought a product that has been listed at one price and has rung up on the checkout counter at another price. Usually we only spot the difference once we have returned home and tried to identify why the calculator result was out. Invariably the price change is in the supermarket's favour. 3) Double scanning products. That way it gets rung up twice and you get charged twice for the one product. 4) The bar code information is for the wrong product. Presumably data entry errors occur and the bar code on the product you are buying is linked to the wrong price data. Now I am not suggesting that any of these practices are deliberate but it is easy to see why supermarkets are not terribly keen to stamp out such problems. All it requires is a hundred or so errors, a week, like this to occur and the supermarket accrues, on average, another $300 of profit. (Our average difference is usually around the $3 mark.) What makes it worse is that alot of the supermarket staff believe the computer to be infallible and incapable of error. When I assure them that, due to my profession of programming the things, I know very well that they can go wrong it a large number of ways they almost invariably remain dubious of my assertion. The risks are fairly clear. It is worthwhile double checking the price you get charged for your groceries. While the system itself is fairly reliable it naturally cannot cope with the human error side of things due to faulty use or data entry into the system. Philip R. Banks Syntax: mail < banks_p@kosmos.wcc.govt.nz > ------------------------------ Date: 31 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.17 ************************ 6-Jul-94 0:14:29-GMT,31589;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24493; Tue, 5 Jul 94 20:14:28 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21348; Tue, 5 Jul 94 20:14:26 EDT Received: by chiron.csl.sri.com id AA12719 (5.67b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Tue, 5 Jul 1994 17:07:12 -0700 From: RISKS Forum Sender: RISKS Forum Date: Tue, 5 Jul 94 17:07:09 PDT Subject: RISKS DIGEST 16.19 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Tuesday 5 July 1994 Volume 16 : Issue 19 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: A330 crash: Press Release (Pete Mellor) States crack down on "cyberfraud" (Mark Seecof) AI to screen bad from good cops in Chicago (Christopher Maag) Going to a Computer Conference? Don't use your real name! (Steve L. Rhoades) Fraud on the Internet (Mich Kabay) ACM Releases Crypto Study (US ACM, DC Office) USACM Calls for Clipper Withdrawal (US ACM, DC Office) Re: Physical Location via Cell Phone (Lauren Weinstein, Willis H. Ware, Robert Morrell Jr.) Cellular Confusion (Bob Frankston) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Fri, 1 Jul 94 16:44:40 BST From: Pete Mellor Subject: A330 crash: Press Release The following are the contents of a fax message sent to me today by Dan Hawkes of the CAA (to whom my thanks). Peter Mellor, Centre for Software Reliability, City Univ. Northampton Square, London EC1V 0HB +44 (71) 477-8422, p.mellor@csr.city.ac.uk AI/GC-I 22/94R 30th June 1994 Issue 1 A330 FLIGHT TEST ACCIDENT, 30TH JUNE 1994 Airbus Industrie regrets to confirm that a flight test A330, powered by Pratt & Whitney PW4168 engines, crashed at 17.50 today at Blagnac Airport, Toulouse, within the airport boundary. Seven people were on board the aircraft: four members of Airbus Industrie personnel, including the Chief Test Pilot, and three airline pilots. There were no survivors. The aircraft involved in the accident was serial number 042, which made its first flight on 14th October 1993 and had accumulated 362 flight hours as part of Airbus Industrie A330 flight test programme. The flight being undertaken aimed to test a new autopilot standard intended for certification with Pratt & Whitney engines for all-weather Category III operations. The test was planned to take place with maximum aft centre of gravity, at minimum speed and with maximum angle of climb. Immediately after take-off, once the maximum flight attitude was reached (between 25 and 30 degrees), the test sequence involved switching on the aircraft's autopilot, simulating an engine failure and cutting off the engine's associated hydraulic circuit. For reasons which are yet to be determined, the aircraft suffered a sudden loss of lateral control. Although it would appear that the pilot regained control, the altitude of the aircraft was too low to avoid impact with the ground, especially bearing in mind the extreme conditions of this particular test flight. For further information, please contact: AIRBUS INDUSTRIE - PRESS DEPARTMENT Tel.: (33) 61.93.33.87 or 61.93.34.31 [A list of the deceased was appended to the original. PGN] ---------------------------------------------------------------------------- Date: Fri, 1 Jul 1994 13:25:43 -0700 From: marks@bierce.latimes.com (Mark Seecof PSD x77605) Subject: States crack down on "cyberfraud" Commentary, quote choice, and paraphrasing by Mark Seecof . In a story on page D-2 of the 1 July 1994 Los Angeles Times by Scot J. Paltrow, we learn of "investigations and enforcement actions directed at individuals who solicit money for dubious or fraudulent investments through the financial bulletin boards of on-line services such as Prodigy, America Online, and CompuServe." Missouri, New Jersy, and Texas regulators are leading the charge with the members of the "North American Securities Administrators Assn., the organization of state regulators" behind them. "The action also represents an effort by state regulators to assert jurisdiction over financial solicitations on the bulletin boards, even if the messages are posted from other states or countries. The Securities and Exchange Commission enforcement staff confirmed Thursday that the federal agency is also looking into the issue." Among other things, "regulators say penny-stock scammers have moved onto the bulletin boards, hyping thinly traded low-priced stocks by posting notes with wildly inflated claims about the companies' propects." "The on-line services say they are cooperating with regulators but are not equipped to police the thousands of messages posted daily. They also say it is not a proper role for service operators to limit the free flow of communication, although on-line services often censor sexually explicit or politically offensive messages." ------------------------------ Date: Mon, 4 Jul 1994 15:55:12 -0400 (EDT) From: Christopher Maag Subject: AI to screen bad from good cops in Chicago [PGN excerpting] Good cop, bad cop at fingertips: Computer could see possibilities Peter Kendall, The Chicago Tribune, 1 July, 1994 The Chicago Police Department has a new computer program that they say will produce a list of officers likely to "go bad" by committing crimes using excessive force or participating in other offenses that can get them fired. The program, built on an $850 off-the-shelf software package, looks at demographic data and work histories of officers who have been fired for disciplinary reasons, then scours police personnel databases for current officers with similar profiles. Officers who appear on the list would be contacted by supervisors and counseled on how to avoid committing acts that could get them fired, sued or even arrested. The profile of "bad" cops was developed on the basis race, sex, age, education, number of traffic accidents, reports of lost weapons or badges, marital status and other factors, relating to 191 officers discharged between 1988 and 1993. A comparison of that profile with 2,000 current officers turned up 141 of those officers who were considered "at risk" for committing an offense that could get them fired. Not surprisingly, the officers' union, the Fraternal Order of Police, is wary. "It's another form of Big Brother watching you," said Bill Nolan, president of the FOP. ------------------------------ Date: Wed, 4 May 1994 01:54:33 GMT From: srhoades@netcom.com (Steve L. Rhoades) Subject: Going to a Computer Conference? Don't use your real name! [Excerpted from MicroTimes April 18, 1994 Issue #122] At the fourth Computers, Freedom, & Privacy conference in Chicago last month, the spotlight was on the growing conflict between the rights of individuals and the role of government in the digital age. A luckless Whitehouse House representative and a lawyer for the NSA tried to convince a varied and skeptical crowd that government control of cryptography was somehow a Good Thing; Meanwhile, in their search for fugitive criminals Kevin Mitnick and wooden-legged "Agent Steal", the FBI erroneously arrested one unfortunate attendee whose name happened to resemble one of Mitnick's aliases and interrogated two others, including an ex-Marine and CIA veteran Robert David Steele of Open Sources. ... Steve L. Rhoades, :30 Second Street, Mt. Wilson, Calif 91023 (818) 794-6004 srhoades@netcom.com [An article by John Markoff on Mitnick appeared on the front page of The New York Times, July 4, 1994. PGN] ------------------------------ Date: 30 Jun 94 12:13:32 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Fraud on the Internet >From the Associated Press newswire via Executive News Service (GO ENS) on CompuServe: "I-Way Robbery", By DAVID GRAM, AP Writer MONTPELIER, Vt. (AP) -- Say you're cruising the information superhighway from the comfort of your home computer and come across what appears to be private, inside information on a hot new company. "You spend $10,000 on stock -- and lose your money. "You've just become a victim of what securities regulators say is the latest trend in investment scams: frauds perpetrated over computer networks or bulletin board