RISKS-LIST: Risks-Forum Digest Thursday 6 Jun 2002 Volume 22 : Issue 11 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/22.11.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Impact of inadequate software testing on US economy (Rick Kuhn) "Truncation error" found in GPS code on Int'l Space Station (George White) FBI's Carnivore hampered anti-terror probe (Marc Rotenberg) Sex, Truth and Videotaping (Gary Marx) Kursk submarine: to test or not to test ...? (Ken Knowlton) Deja vu: Stockholm power outage hits high-tech companies (Ulf Lindqvist) Inadvisable instructions from Sun on StarOffice 5.2 (John Sullivan) Confirming cricket score reason for delay (R. Jagannathan) Students provide bulk of tech support in schools (NewsScan) More on typos and homographs (Martin Wheatman) Please ignore the anti-shoplifting device! (Mario Hendricks) Re: The Klez Effect (Paul van Keep, Greg Searle) Re: Klez and mail loops (A. Harry Williams) More on Klez (Hal Lewis) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 05 Jun 2002 14:53:35 -0400 From: Rick Kuhn <kuhnat_private> Subject: Impact of inadequate software testing on US economy NIST has released a new study conducted by the Research Triangle Institute that should be of interest to readers: "The Economic Impacts of Inadequate Infrastructure for Software Testing". Comments and discussion are welcome. http://www.nist.gov/director/prog-ofc/report02-3.pdf Rick Kuhn From the summary: NIST engaged the Research Triangle Institute (RTI) to assess the cost to the U.S. economy of inadequate software testing infrastructure. Inadequate testing is defined as failure to identify and remove software bugs in real time. Over half of software bugs are currently not found until downstream in the development process leading to significant economic costs. RTI identified a set of quality attributes and used them to construct metrics for estimating the cost of an inadequate testing infrastructure. Two in depth case studies were conducted. In the manufacturing sector, transportation equipment industries were analyzed. Data were collected from software developers (CAD/CAM/CAE and product data management vendors) and from users (primarily automotive and aerospace companies). In the service sector, financial services were analyzed with data collected again from software developers (routers and switches, financial electronic data interchange, and clearinghouse) and from users (banks and credit unions). ...the annual cost to these two major industry groups from inadequate software infrastructure is estimated to be $5.85 billion. Similarities across industries with respect to software development and use and, in particular, software testing labor costs allowed a projection of the cost to the entire U.S. economy. Using the per-employee impacts for the two case studies, an extrapolation to other manufacturing and service industries yields an approximate estimate of $59.5 billion as the annual cost to the nation of inadequate software testing infrastructure. ------------------------------ Date: Thu, 30 May 2002 08:45:11 -0300 (ADT) From: George White <aa056at_private> Subject: "Truncation error" found in GPS code on Int'l Space Station The following excerpt describes the resolution of a problem in the GPS attitude control for the International Space Station. > From j.vanoeneat_private Thu May 30 08:28:31 2002 Date: Wed, 29 May 2002 06:43:17 -0700 From: Jacques van Oene <j.vanoeneat_private> Newsgroups: sci.space.news Subject: ISS On Orbit status 28-05-2002 "The troubleshooting of the GPS (global position system) attitude errors has been successful. At first thought to be due to the high solar Beta angle (where fewer GPS satellites are in sight), the cause has now been traced to the software, which did not calculate attitudes correctly due to a truncated parameter. The error was eliminated, and the system is now working fine, even at high Beta angles, supplying state vector and attitude data. With Russian concurrence, GPS will now also provide the periodic updates of the SM's BINS strapdown navigation and guidance system, instead of requiring lengthy manual data takes by the crew using the optical PUMA system, thus saving valuable crew time." Not to mention the psychological benefits to the crew of one less "area of concern" in a setting where resolving glitches in a critical subsystem can easily become an exercise in "staying alive". George White <aa056at_private> Halifax, Nova Scotia ------------------------------ Date: Tue, 28 May 2002 17:03:50 -0400 From: Marc Rotenberg <rotenbergat_private> Subject: FBI's Carnivore hampered anti-terror probe FBI's CARNIVORE SYSTEM DISRUPTED ANTI-TERROR INVESTIGATION INTERNAL MEMO CALLS OVER-COLLECTION OF DATA PART OF "PATTERN" SHOWING "INABILITY OF THE FBI TO MANAGE" FOREIGN INTELLIGENCE WIRETAPS Washington, DC -- An FBI anti-terrorism investigation possibly involving Usama bin Laden was hampered by technical flaws in the Bureau's controversial Carnivore Internet surveillance system. The incident, which occurred in March 2000, is described in newly-released FBI documents obtained under court order by the Electronic Privacy Information Center (EPIC). A written report describes the incident as part of a "pattern" indicating "an inability on the part of the FBI to manage" its foreign intelligence surveillance activities. An internal FBI e-mail message dated April 5, 2000, and sent to M. E. (Spike) Bowman, Associate General Counsel for National Security Affairs, recounts how the Carnivore "software was turned on and did not work correctly." The surveillance system captured not only the electronic communications of the court-authorized target, "but also picked up E-Mails on non-covered" individuals, a violation of federal wiretap law. According to the Bureau document, the "FBI technical person was apparently so upset that he destroyed all the E-Mail take, including the take on [the authorized target]." The botched surveillance was performed by the FBI's International Terrorism Operations Section (ITOS) and its "UBL Unit," which refers to the government's official designation of bin Laden. The Bureau document indicates that an official at the Justice Department's Office of Intelligence Policy and Review (whose name has been deleted) became aware of the problem, and "To state that she is unhappy with ITOS and the UBL Unit would be an understatement of incredible proportions." The reported problem apparently was not the first to arise during the course of FBI implementation of the Foreign Intelligence Surveillance Act (FISA). The internal document concludes its report of the "UBL Unit" incident by noting, "When you add this story to the FISA mistakes covered in [another, unreleased document], you have a pattern of occurrences which indicate to OIPR an inability on the part of the FBI to manage its FISAs." Two Bureau documents written one week later discuss Carnivore's tendency to cause "the improper capture of data," and note that "[s]uch unauthorized interceptions not only can violate a citizen's privacy but also can seriously 'contaminate' onoging investigations" and that such interceptions are "unlawful." An FBI lawyer (whose name has been deleted) writes that the Bureau must "go out of our way to avoid tripping over innocent third party communications." The lawyer concludes, "I am not sure how we can proceed to test [Carnivore] without inadvertently intercepting the communications of others, but we really need to try." The Bureau lawyer notes that "missteps under FISA lead to mandatory reporting to the President's Foreign Intelligence Advisory Board, and such errancies must be reported/explained/justified to Congress." The documents do not indicate whether the "UBL Unit" incident was reported to either body. Since its existence became public in 2000, the Carnivore system has been criticized by EPIC and other privacy groups, as well as members of Congress, because it gives the FBI unprecedented, direct access to the data networks of Internet service providers. The FBI has publicly downplayed the system's potential for over-collection of private communications, although internal documents released earlier to EPIC confirmed such a risk. An independent review of Carnivore commissioned by the Justice Department also found that the system is capable of "broad sweeps" and recommended technical changes to address the problem. Neither DOJ nor the FBI has indicated publicly whether those recommendations were ever implemented. The newly-released FBI documents were provided to EPIC on 24 May 2002, in response to a court order issued by U.S. District Judge James Robertson in the privacy group's ongoing Freedom of Information Act lawsuit seeking the disclosure of material concerning Carnivore. The order directed the Bureau to conduct a second search for relevant documents after EPIC successfully argued (over the Bureau's objections) that an initial FBI search was inadequate and likely overlooked responsive records. The case is being litigated by EPIC's General Counsel, David Sobel, who said, "These documents confirm what many of us have believed for two years -- Carnivore is a powerful but clumsy tool that endangers the privacy of innocent American citizens. We have now learned that its imprecision can also jeopardize important investigations, including those involving terrorism." Sobel added, "As we suggested when it first became public, Carnivore's use should be suspended until the questions surrounding it finally can be resolved. Our FOIA lawsuit shows that there's a great deal about Carnivore that we still don't know." The newly-released FBI documents are available at: http://www.epic.org/privacy/carnivore/ Contacts: DAVID SOBEL 202-483-1140 x105 WAYNE MADSEN x104 ------------------------------ Date: Tue, 28 May 2002 20:45:20 -0700 From: "gtmarx" <gtmarxat_private> Subject: Sex, Truth and Videotaping At-Home Spying: Privacy Wanes as Technology Gains Surveillance may be legal, but is that the only standard? Commentary by Gary T. Marx, 28 May 2002, *Los Angeles Times* [Reprinted with the permission of the author] Recently in France, a father who was concerned about the possible mistreatment of his 3-year-old son by a baby-sitter's boyfriend hid a miniature camera in his home to record any suspicious behavior. The father found some, but it was not abuse of the child; the camera revealed the baby-sitter and her boyfriend amorously entangled while the child slept soundly in the next room. The father paid a penalty. In France, such videotaping is a violation of criminal and civil law. The father was arrested and ordered to pay a fine for invasion of privacy. Did the father do something wrong? Is there a victim here? As the ubiquitous advertisements for cameras concealed in teddy bears and other unlikely places remind us, parents have an obligation to protect their children. A hidden video camera offers an easy way to do this--to the extent that seeing is believing. If nothing is found, the responsibly vigilant parents rest well knowing that the child was not harmed. If something is found, there is tangible evidence for taking protective and even legal action. Different privacy standards characterize home and work, as well as areas within these. The baby-sitter after all was not filmed in her own home but at her place of work. Yes, the French parents had alternatives. They could have discussed their concerns with the sitter, checked to see whether other employers had had problems with her, banned the boyfriend or simply found another baby-sitter. If there are some grounds for doubt, why take a chance by spying? And, as it turns out, the law was on the baby-sitter's side. In the U.S., the employer largely sets the conditions of work. To use the French baby-sitter as an example, the camera was in the living room, not in a bathroom where the expectation of privacy would have been greater. The place and the video equipment belonged to the parents, and the baby-sitter willingly came to the home. The images weren't sold on the Internet, used as blackmail or stolen. To cast the best light on the father, he wanted to have the evidence in hand before deciding to fire the sitter. The use of hidden cameras is hardly an uncommon or exotic means for this. And, had the father been living in the U.S. instead of France, in most jurisdictions he would have broken no law. Yet this videotaping, even if well-intentioned and revealing nothing incriminating, is patently offensive. E.M. Forster captured this well in noting: "For it is a serious thing to have been watched. We all radiate something curiously intimate when we believe ourselves to be alone." Secretly recording people violates their dignity and can put the individual at an unfair strategic disadvantage. We assume, or at least morally expect, that under ordinary circumstances behavior behind closed doors, in darkness and at a distance will be protected from the eavesdropping of third parties. We also have a right to assume that interaction and communication are ephemeral and transitory and are not subject to being captured and preserved through hidden video or audio means without our knowledge. Another unintended consequence is that sometimes people seeking specific information--i.e., whether their child is being mistreated--may observe something even they didn't want to know. In addition, remotely transmitted signals might be picked up by others in the vicinity. The behavior of the spy is thus doubly troubling. Not only is he invading the privacy of those he is watching, but he may unwittingly enable others to invade as well. The fact that there is still a legal right to secretly record images in the U.S. does not mean that it is the right thing to do. We would do well to learn from the French the general principle of respect for private life, a principle that holds no matter what new technologies are offered to us that allow us to spy on others. Gary T. Marx, a Massachusetts Institute of Technology emeritus professor, is the author of "Undercover: Police Surveillance in Comparative Perspective" (Kluwer Law, 1995). Web site: garymarx. net. ------------------------------ Date: Thu, 30 May 2002 08:23:45 EDT From: Ken Knowlton <KCKnowltonat_private> Subject: Kursk submarine: to test or not to test ...? Another Hubble Telescope story, of sorts: *Time Magazine* (3 Jun 2002) reports that when the Russian submarine Kursk sank, 23 of the momentarily surviving crewmen rushed to the floating rescue capsule located in the rear. But it failed to disengage. It had never been tested. ------------------------------ Date: Thu, 30 May 2002 09:08:17 -0700 (PDT) From: Ulf Lindqvist <ulfat_private> Subject: Deja vu: Stockholm power outage hits high-tech companies In RISKS 21.27, Mar 15 2001, I reported about about a large and long-lasting power blackout in Stockholm, Sweden: > A fire in a tunnel containing power cables caused a long-lasting > blackout for 50,000 people and a large number of high-tech > companies in several Stockholm suburbs. [...] The largest employer > in the area, Ericsson, told 11,000 employees to stay at home > Monday as their workplace had no power. Guess what - something very similar happened again on May 29 2002 in the same tunnel, with roughly the same consequences. In a press release, the utility company Birka Energi claims that this is actually not exactly the same situation as last time. In March 2001, it was an 11 kV cable in the tunnel that caught fire, and they claim that the cause of that particular problem has been eliminated. This time, however, they received a ground fault indication on a 33 kV cable right before the fire. To their customers, who will be without power for a couple of days, that information will not make much of a difference. The risk is a familiar one: addressing specific symptoms instead of the underlying vulnerability. PGN's comment about tunnel vision is unfortunately still appropriate. Ulf Lindqvist, System Design Lab, SRI International, 333 Ravenswood Ave, Menlo Park CA 94025-3493, USA +1 650 859-2351 http://www.sdl.sri.com/ ------------------------------ Date: Wed, 29 May 2002 23:29:30 +0100 From: John Sullivan <johnat_private> Subject: Inadvisable instructions from Sun on StarOffice 5.2 I heard today that Sun are withdrawing the free download of StarOffice 5.2, so I went over to their website to investigate. Having downloaded the package (in this case a single .bin file which is actually an executable) I went to the installation instructions at: http://wwws.sun.com/software/star/staroffice/5.2/get/download.html Here we are told: Note for Linux and Solaris[tm] customers only: It will be necessary for a chmod command to be executed to set read, write, and execute permission. For example: % chmod 777 *.bin Once you have set the permissions, you can run the setup, and StarOffice 5.2 will do the rest. One hopes that anyone seriously likely to be at risk of exploit due to this would not be inexperienced enough to actually follow their instructions blindly! However a sufficiently inexperienced user, even though they are most probably not running a system shared with an adversary capable of attacking them because of this, may well absorb that command as some sort of "magic rune" and issue it at other times in the future when the window of opportunity is much wider. ------------------------------ Date: Tue, 4 Jun 2002 00:48:23 -0700 From: "R. Jagannathan" <jaganat_private> Subject: Confirming cricket score reason for delay http://www.cricket.org/link_to_database/ARCHIVE/CRICKET_NEWS/2002/JUN/012194_NATION_03JUN2002.html An interesting article from a "dependability" standpoint. Mismatch between what a computer thought was the revised target and what the umpire manually computed caused a 20-minute delay during which the teams had to play without knowing the revised target. The game between India and West Indies was won by India and the West Indian captain later rued the fact that their team did not know the score for 20 minutes, which affected how they played. All this for a one-run difference between the manual and computed calculation. The Duckworth-Lewis method is an empirically-derived table (by the two mathematicians) to compute revised targets when a one-day cricket match gets shortened by rain or other similar disruptions. ------------------------------ Date: Thu, 06 Jun 2002 08:48:37 -0700 From: "NewsScan" <newsscanat_private> Subject: Students provide bulk of tech support in schools Fifty-four percent of U.S. schools rely on students to provide technical support for their computer systems, according to a report titled "Are We There Yet?" (http://www.nsbf.org/thereyet/index.htm), released yesterday by the National School Boards Foundation. In 43% of the 811 districts surveyed, students troubleshoot for hardware, software and other problems, and 39% of the districts, students are tasked with setting up equipment and wiring. Nearly as many districts also report that students perform technical maintenance. The fact that students are providing so much hands-on assistance is viewed as a "win-win" situation by John Bailey, director of education technology for the Department of Education. Their tech savvy helps compensate for a dearth of tech support funding in school budgets and teachers who are "unevenly prepared for using technology as a tool for teaching and learning," according to the NSBF, which reports that 69% of the survey respondents rated new teachers as average or novices in computer skills. The role reversal signals a shift in the relationship between teachers and students as online lessons become integrated into the school curriculum, says Anne Bryant, executive director of the National School Boards Association: "Teachers become the guide on the side, instead of the sage on the stage." [AP 5 Jun 2002; NewsScan Daily, 6 June 2002] http://apnews.excite.com/article/20020605/D7JV8EP00.html ------------------------------ Date: Tue, 28 May 2002 11:52:02 +0100 From: Martin Wheatman <Martin.Wheatmanat_private> Subject: More on typos and homographs I use a national bank in the UK called Lloyds TSB (which is a recent amalgamation of Lloyds Bank and the Trustee Savings Bank), and I'm naturally keen to use their online services. However, I misspelt the name earlier this year (www.llyodstsb.com), and was taken to the real www.lloydstsb.com. I didn't immediately spot the typing error until I noticed that the Webmaster, rather incompetently perhaps (if it were a real scam), was using a free Web host service (www.uk2.net), which displays the redirected Web site underneath their banner advertising free Web hosting (I use the same company as they do provide a good, cheap, "no frills" service). Writing a program to redirect traffic to the end service is trivial (no need to even provide Web content!), as would filtering usernames and passwords. It's slightly different to the homograph scam as it relies on the typist to make errors (ad htat nerver hapens!), rather than providing the links already embedded in Web content, and feeds off www.websiteswithreallylongnames.com , and probably the fact that there will (I suspect) be a lot more combinations of typos than homographs. Also, the simple (but probably unheeded) solution to display mixed character sets wouldn't work... :( One protection, in the UK at least, is to access commercial sites thought the ".co.uk" domain which is managed by Companies House (effectively the Government), who will only allow registered companies to use their registered names. Ok, so you could register a company wth the misspelt name, but I suspect that Companies House (and the company being scammed) will no doubt be interested in the reasons for the similar name (probably using the same mechanism as protection for trademark laws / passing off?). P.S. As a responsible citizen, I notified my bank (it was rather scary!), and although the site is still registered it is no longer used to redirect traffic (whether these two events are linked, I still don't know - presumably the Bank is still bothered by adverse publicity). ------------------------------ Date: Thu, 06 Jun 2002 13:26:46 -0400 From: Mario Hendricks <mario.hendricksat_private> Subject: Please ignore the anti-shoplifting device! The other day I went into my local Apple store to buy an external floppy drive. On my way out of the mall to my vehicle, I decided to take the shortest route, through a nearby Eddie Bauer store. As a I walked into the store, the anti-shoplifting device sounded an alarm. As there were no other people within 5 or 10 meters, I realized that my recent purchase (from Apple) must have set off the alarm. I also realized that the alarm would likely sound as I exited at the other end of the store. When I got near the parking lot exit, I encountered an Eddie Bauer employee. Rather than to get accosted as attempting to shoplift by this employee, I decided to warn him that the anti-shoplifting device would probably sound as I exited. The employee saw that I was carrying an Apple Computer bag (they have very distinctive shopping bags) and responded along the lines of "Oh, yeah, stuff from Apple always set off the alarm." Sure enough, when I left the store the alarm sounded. The risks of such a false positive alarm are obvious. The fact that employees know to ignore the alarm (in at least this one case) raises even more risks. Of course, if anyone should ever want to shoplift from this store, there seems to be a tested procedure. You would think that either the store's management or the anti-theft device manufacturer would be concerned about such issues. ------------------------------ Date: Tue, 4 Jun 2002 10:43:54 +0200 From: "Paul van Keep" <paulat_private> Subject: Re: The Klez Effect Yesterday I received a bounce from risksat_private because I 'allegedly' sent a Klez.H infected e-mail to Peter. Of course I didn't (I thoroughly removed Outlook from my system and only use Polarbar, a Java mailer). But the interesting side effect is that the virus firewall nicely bounces the message to me, first stripping the infection payload. But what doesn't get stripped is the document that Klez attaches to each mail it sends out. So with each bounce I get a nice bonus. The Klez e-mails with me as originator come from somebody who seems to be a designer. I now have a collection of three different jpgs with nice pictures of jewelry and home appliances. (S)he must also be a RISKS reader, the only link between me and the RISKS e-mail. The risk is that virus firewalls, by not stripping all attachments from infected e-mails, not only block viruses from spreading, which is good, but also help in distributing potentially sensitive documents to third parties. P.S. I'm still waiting to get a nice Word document with good takeover information so I can do some serious insider trading [Classic case of address spoofing. There are also lots of spoofs allegedly from RISKS. Don't Believe a Word! PGN] ------------------------------ Date: Tue, 4 Jun 2002 16:36:39 -0400 From: "Greg Searle" <greg_searleat_private> Subject: Re: The Klez Effect Listmasters are really getting hit, but you don't need me to tell you that. Just today, another list that I subscribe to urged its members to rid themselves of the virus. There's good news, however. According to MessageLabs (http://www.messagelabs.com/viruseye/), Klez is finally starting to slowly recede. It peaked two weeks ago at about forty thousand viruses intercepted by the company per day. Now it's around 27K/day. So far, I've only had a couple of firewalls send me warnings that I "sent" the virus. No live person ignorant of Klez's forged header has complained yet. ------------------------------ Date: Tue, 28 May 2002 09:26:18 EDT From: "A. Harry Williams" <HARRYat_private> Subject: Re: Klez and mail loops (Pool, RISKS-22.10) In discussing the Klez virus/worm, Martin Pool makes a common mistake among UNIX admins, assuming that what is available on their system in TCP/IP utilities accurately and completely implements RFC specs. X- headers are user-defined headers, and therefore cannot be an RFC network standard header. I just searched, and can only find Precedence: in RFC 2076, where it is defined as "non-standard, controversial and discouraged". The real problem is that these auto-responders, including many Out of Office programs, try to use the email Headers, rather than the envelope headers. A simple MAIL FROM:<> that was correctly honored would stop many loops, and that is its purpose. ------------------------------ Date: Mon, 27 May 2002 19:27:19 -0700 From: hal lewis <hlewisat_private> Subject: More on Klez (Garfinkel, RISKS-22.10) >It makes you wonder if there should be any liability for these individuals. Who needs to wonder? This is theft, pure and simple. ------------------------------ Date: 29 Mar 2002 (LAST-MODIFIED) From: RISKS-requestat_private Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, send e-mail requests to <risks-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_private . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 21" for volume 21] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 22.11 ************************
This archive was generated by hypermail 2b30 : Thu Jun 06 2002 - 17:59:15 PDT