RISKS-LIST: Risks-Forum Digest Wednesday 13 June 2001 Volume 21 : Issue 47 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/21.47.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Computer train trauma (Lord Wodehouse) Elevator emergency override drowns woman (Daniel Norton) ATM network center flooded (Daniel Norton) Supreme Court ruling on thermal-imaging scanners (PGN) And you thought Keith Lynch was kidding! (PGN) DoD declares unclassified hard drives no longer need be destroyed (PGN) Risks of URL-forwarding services (Justin Mason) New technology for sneaky advertising (Greg Searle) ScanMail's "sophisticated" filtering blocks PRIVACY Forum Digest (Lauren Weinstein) Risks of heuristics and marketers (Dan Birchall) Re: Dutch government to act against virtual child pornography (George Dinwiddie) Security notice for recent EarthBrowser purchasers (Matt Giger via Ben Laurie) Excel date munging: what a difference --four years and-- a day makes (Tom Walker) Dead men produce no documentation (Kirt Dankmyer) REVIEW: "Inside Internet Security", Jeff Crume (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 12 Jun 2001 13:10:42 +0100 From: Lord Wodehouse <w0400at_private> Subject: Computer train trauma >From *Computer Weekly* 7 Jun 2001, on the back page. ... a tale of cutting edge IT going off the rails. It reads, "I had an interesting journey home from London last night. I was onboard a new 100% computer-controlled train. In the middle of the Chester countryside, the train ground to a halt. The automated station-announcement system then ran through its program of station announcements in quick succession until it said the final destination." "It then attempted to open the doors (in the middle of nowhere). The guard ran to the driver's cab. The driver and the guard then ran through the carriages muttering that the computer had gone berserk and was telling them that the rear of the train was on fire. After checking, the driver, in a state of mild panic ran back to the cab, turned off all the engines, cut off all the power (leaving us in pitch darkness), and yes, you've guessed it, waited the customary - 10 seconds and rebooted the train. I wonder if anyone can confirm this wonderful story. The risks are self-evident. SCS Global Services Internet/Intranet Operations, GlaxoSmithKline, Medicines Research Centre, Gunnels Wood Road, Stevenage SG1 2NY UK ------------------------------ Date: Sun, 10 Jun 2001 20:50:28 -0400 From: Daniel Norton <Danielat_private> Subject: Elevator emergency override drowns woman cf. http://www.chron.com/cs/CDA/story.hts/metropolitan/936841 Though not mentioned in this article from the *Houston Chronicle*, NPR reported (via KUHF?) that the elevator detected an emergency situation and automatically attempted to move to the ground floor. While that's often a good idea in case of a fire, in a flood it's the *worst* way to respond and, in this case, tragically lethal. [I was in an elevator at BBN in Rosslyn VA once when the control computer crashed. The elevator very slowly worked its way to the TOP floor, which might seem to make sense -- *except* in a fire. Thus, we need an intelligent system that figures out which way to go, and therein lie even more risks -- especially in a fire that results from a short caused by a flood. PGN] ------------------------------ Date: Sun, 10 Jun 2001 20:59:46 -0400 From: Daniel Norton <Danielat_private> Subject: ATM network center flooded The Pulse EFT network's main and backup power systems in Houston were flooded by Tropical Storm Allison, disabling their 22-state ATM network. "PULSE Enacts Disaster Recovery Program Early Saturday morning, the PULSE electronic funds transfer system experienced a major disruption of both our primary power source and our emergency back-up supply system, as a result of unprecedented flooding in Houston. A disaster recovery program has been instituted and efforts are underway to resume operations at a remote processing center located in Dallas. Until technical connections in the system can be restored, disruption of ATM and point-of-sale services at some locations will be experienced. PULSE has a proud record of 99.99% availability and we regret any inconvenience to our financial institutions, merchants, processors and cardholders that this extraordinary event may have caused. [...] http://www.pulse-eft.com/ ------------------------------ Date: Tue, 12 Jun 2001 12:12:13 -0700 (PDT) From: "Peter G. Neumann" <neumannat_private> Subject: Supreme Court ruling on thermal-imaging scanners In the Kyllo case, the Supreme Court ruled 5 to 4 that using an Agema 210 thermal-imaging device to scan for unusual heat sources in someone's house (i.e., searching for marijuana growing activities) is unlawful search if carried out without a warrant, violating the Fourth Amendment. http://www.supremecourtus.gov/opinions/00slipopinion.html http://supct.law.cornell.edu/supct/html/99-8508.ZS.html http://www.wired.com/news/politics/0,1283,44444,00.html ------------------------------ Date: Mon, 12 Jun 2001 12:17:11 -0700 (PDT) From: "Peter G. Neumann" <neumannat_private> Subject: And you thought Keith Lynch was kidding! (Re: RISKS-21.42) http://www.utm.edu/research/primes/curios/48565...29443.html One of the strangest consequences of the DMCA is that it would seem to outlaw possession of certain integers. The above URL gives the decimal form of a prime number whose HEX form just happens to be the gzip-ed C source code for DeCSS (which breaks the DVD Movie encryption -- see RISKS-21.37). This observation is due to Phil Carmody. [Thanks to Mark Brader for the Subject: line!] ------------------------------ Date: Sat, 9 Jun 2001 23:17:52 -0700 (PDT) From: "Peter G. Neumann" <neumannat_private> Subject: DoD declares unclassified hard drives no longer need be destroyed http://www.cnn.com/2001/TECH/ptech/06/08/pentagon.computers.ap/index.html The aggregation, inference, and sensitive-unclassified stuff is ubiquitous and often damning. This could be a harbinger of future RISKS stories. ------------------------------ Date: Thu, 07 Jun 2001 12:44:09 +0100 From: jm-risksat_private (Justin Mason) Subject: Risks of URL-forwarding services I'm the maintainer of a free-software application called sitescooper, which reformats Web sites for viewing on PDAs. When I started writing sitescooper a few years ago, I hosted it on my ISP at http://www.clubi.ie/~jmason/software/sitescooper/ . Since this URL was quite cumbersome (especially when read on a PDA screen!) I also set up a forwarding URL with a domain called "tsx.org", which offered free URL forwarding. At that stage, tsx.org was a reasonably reputable URL-forwarding service. Since then, sitescooper has grown in popularity, and has moved to the easier-to-remember sitescooper.org domain. I left the tsx.org forwarding in place, updated to its new address, to catch old links and avoid link-rot, and forgot about it. This morning I received a mail from a potential user, who'd decided to download sitescooper and take a look. The mail stated: I'm writing about your Web site. [...] If you are aware of the way your site behaves then you should just close up shop and leave the Web because no contribution to software development is worth the hassle your site causes. If not, then I apologize for the above and I'll describe it for you. If your site: sitescooper.tsx.org is opened using a script-enabled browser (e.g., IE or NS), from a windows platform, it proceeds to plaster the screen with windows full of trashy ads that CANNOT be deleted. The windows have no controls and right-clicking the taskbar icons is disabled. THE ONLY WAY to delete this trash is to bring up the Task Manager via ctrl-alt-del, and kill the processes. NO WEBSITE SHOULD BE THIS INVASIVE. This is blatant abuse of the trust a user puts in you when they click a link to your site. Hopefully, you're not involved in it and it's being done by tsx - In which case I STRONGLY advise you to dump them as fast as possible and find a new Web host. I surfed over to sitescooper.tsx.org and took a look. Sure enough, it popped up 5 windows - 1 with no frame masquerading as a Windows alert, asking if I want to visit the BEST ADULT SITES AROUND, 2 full-screen unclosable windows, 1 normal(ish) ad window with a normal window frame, and (finally) the page I *wanted* to go to. Gah. Needless to say, sitescooper.tsx.org is now no more. I'd prefer if people hit a 404, and were forced to search Google, than run into this. The risk? There ain't no such thing as a free lunch, I guess. I'd assumed that the forwarding system would offer a consistent quality of service over several years; instead, in my opinion, they took advantage of their situation to increase their ad revenues at the expense of their users. ------------------------------ Date: Thu, 7 Jun 2001 14:42:57 -0400 From: "Greg Searle" <gsearleat_private> Subject: New technology for sneaky advertising First came SPAM, with its authors finding more and more sophisticated methods of hiding themselves from their victims so they could send out massive amounts of advertising without fear of retribution. Then came pop-up window ads. These are bad enough, but now a company, www.fastclick.com, has come up with a way to sneak these pop-up windows onto your screen without you knowing where they came from. Worse, established corporations such as The NY Times (www.nytimes.com), AltaVista (www.altavista.com), and Epinions (www.epinions.com) are using the technology. The trick involves a timer, a cookie, and a pop-up window that quickly hides itself *behind* your browser windows. This usually happens too fast for your computer to render the window on your display, so you see nothing. You don't know when the ad will appear, and you won't see it until you close all of your browser windows. By then, you have opened a few more windows and browsed to other Web sites. This keeps you from knowing which Web site spawned the window in the first place. I only know about the above three corporations because I was lucky enough to catch the window popping up when I first opened my browser to these sites, or because it was the only site I went to. I caught a glimpse of "fastclick.net" in the status bar, and it all fell into place. The only solution is to turn JavaScript off completely. If you don't want to do this, then add the offending sites to your "Restricted Sites" list. I have sent a complaint to these corporations as well, letting them know that I don't appreciate this "sneaky" advertising, and have disabled these ads. ------------------------------ Date: Sun, 10 Jun 2001 09:46:49 -0700 (PDT) From: Lauren Weinstein <laurenat_private> Subject: ScanMail's "sophisticated" filtering blocks PRIVACY Forum Digest Greetings. The manufacturers of e-mail filtering and blocking systems continue to claim that their products have vastly improved over time --that the incidents of false negatives and false positives are greatly reduced from earlier versions. Much empirical evidence has continued in general to contradict these assertions, and here's yet another example of what happens in the real world as these systems are actually configured by users. My most recent PRIVACY Forum Digest was blocked by the popular "ScanMail" product as configured within at least one site. I only learned about this since the particular configuration was in a "quarantine for review" mode that sent out a warning. Other sites may be configured to simply delete flagged messages without such a reply to the sender. What was it about the PRIVACY Forum Digest that aroused ScanMail's ire? In the nine years since I originated the Digest, each issue has included a "quote of the day"--which usually is an interesting or amusing quote from a feature film. In the case of the most recent Digest (http://www.vortex.com/privacy/priv.10.04) I chose a quote from Peter Sellers' 1968 classic "I Love You, Alice B. Toklas!" Ah hah! The phrase "I Love You" appeared in the text of the message. It must be a virus! Or perhaps a spam? Indeed, the Digest was blocked via ScanMail's "ILOVEYOU" policy! This was done even though the message was not encoded in any way and was not an attachment. It was just simple, plain, ordinary, ASCII text, with the "offending" phrase well down within the message (not in the header). Presumably, ScanMail at various sites will be blocking *this* issue of RISKS because (horrors!) the forbidden phrase "I Love You" appears in this message as well! With such a level of "stone club" analysis at work, one can only imagine what other innocent e-mail is being injected, inspected, detected, infected, neglected, and selected by the "sophisticated" algorithms of filtering programs to be flagged, reviewed, dropped, banned, burned, or trashed. Lauren Weinstein <laurenat_private> laurenat_private laurenat_private Co-Founder, PFIR: People For Internet Responsibility - http://www.pfir.org Moderator, PRIVACY Forum - http://www.vortex.com ------------------------------ Date: Wed, 6 Jun 2001 18:04:36 -1000 From: Dan Birchall <djbat_private> Subject: Risks of heuristics and marketers For some years, I have been concurrently involved in countering spam and in designing, implementing and administering e-mail lists for marketing purposes. In both of these endeavors, as in much of life, heuristic (trial-and-error) methods are commonplace. Heuristic approaches to the development of spam filters tend to be somewhat effective. If one receives 100 pieces of spam over a reasonable period of time containing a given word or phrase, and no legitimate mail containing it, it is statistically probable that filtering mail based on that word or phrase will block at least some spam, and little or no legitimate mail, going forward. Of course, such simple heuristics are not without their risks. We recently sent an issue of our periodic customer newsletter which contained the phrase "sizzling summer." The marketers love their alliteration -- in fact, the exact same phrase appeared a few days earlier in a mailing by another company in our market segment! Unfortunately, a small number of sites using simple heuristic filtering like that I described above took offense at our use of the word "sizzling," which apparently now indicates pornographic material. A better method might combine heuristics with the scoring capability in some mail server software (I'm personally familiar with Exim), incrementing or decrementing a counter based on the occurrence of given words or phrases, with actions depending on the final value of the counter. Thus, if "sizzling" is a +1 word, "video" a +2 word, and "sex" a +3 word, a threshold of 3, 4 or 5 might be used for blocking. Dan Birchall - Palolo Valley - Honolulu HI - http://dan.scream.org/ Peruse my opinions, at http://dbirchall.epinions.com/user-dbirchall [Still too many false positives and false negatives. PGN] ------------------------------ Date: Thu, 7 Jun 2001 10:20:31 -0400 From: "Dinwiddie, George" <George.Dinwiddieat_private> Subject: Re: Dutch government and virtual child pornography (de Geus, R-21.45) How do you ascertain the age of a virtual individual in an electronically synthesized image? In the real world, you can ask for some identification. My sister was frequently carded in bars (when the legal drinking age was 18) until she was 26, because she looked young. My son told me a story of not being carded at 16 when the guy in front of him was carded at 20 (when the legal drinking age was 21). Obviously you cannot reliably determine age by appearances. Perhaps you could look at the creation date of the file? ;-) [That's not very reliable either. PGN] ------------------------------ Date: Wed, 6 Jun 2001 21:49:05 -0700 From: Matt Giger <mgigerat_private> Subject: Security notice for recent EarthBrowser purchasers (via Ben Laurie) My name is Matt Giger and I write the EarthBrowser software that you have recently purchased us. I am writing to inform you of about a recent scam being run on our customers. This first report was about 5 PM on 6/6/01 from a customer who purchased EarthBrowser just yesterday. Apparently some files with customer information on our server have been accessed. Let me assure you that your credit card information is safe since we never store that information on our server. Also we purge all customer information on a daily basis so the amount of information they obtained was minimal, just your name, address, e-mail address and EarthBrowser serial number. The reported scam e-mail looks something like this: Please confirm [its] registration. Correct Purchase Information You account: http://www.earthbrowser.by.ru/3004001065-010605214102678/index.htm This poorly written e-mail sends you to a Web site in Russia which is an exact copy of our purchase page and presumably sends the information you enter to the thief. If you enter your credit card number on this page, they will then have it so please do not enter any information. Hopefully the poorly worded e-mail and the suspicious Web address will alert most to the fact that this is bogus. If you have received an e-mail like this one, please let me know as soon as possible so I can trace exactly how long ago they gained access. I apologize for having to warn you of this, I am taking steps to insure that our customer information remains safe. I promise to let you know of any such scams in the future, but please help me out by letting me know if you get any strange contact trying to use our relationship with you to obtain any information. Matt Giger, Lunar Software, Inc. mgigerat_private ------------------------------ Date: Sun, 10 Jun 2001 07:33:20 -0700 (PDT) From: timeworkat_private (Tom Walker) Subject: Excel date munging: what a difference --four years and-- a day makes A couple of months ago I was replying to a expert-witness report in an arbitration and found that his years of service calculations were wrong by four years. Then last week I received an excel file from the other side's lawyers in the case and noticed that when I cut and paste a column of dates they all automatically went back four years and a day. The problem arises from incompatibility between the 1904 date system used by excel in mac and the 1900 date system used in windows. This is a known and documented feature of excel: http://support.microsoft.com/support/kb/articles/q180/1/62.asp However, a quick search on the Web and in the Risks Forum archives suggests the risk isn't that widely appreciated. Even if one knows about the anomaly and checks for date system compatibility before cutting and pasting dates, one still could receive files from a source that already had corrupted dates. There would be no way of knowing (other than common sense if the results are not credible). It seems to me that the errors introduced into spreadsheet calculations will tend to be systematic rather than random because: 1. they will often occur when two or more sets of data are being consolidated and thus the errors will apply to the population of one set but not to the other and 2. the direction of the error will be influenced by the prevalence of macs or pcs in different institutional settings and fields, e.g., macs in universities & design and pcs in businesses & finance. Thus, for example, dates systematically advance from businesses to universities and recede from design to finance. This makes collaborative work between institutions and professions especially vulnerable. The first time (that I know of) that I encountered the problem was a practical instance with a potentially significant economic impact on several thousand employees. The fact that the data was presented in the course of an adversarial process was probably crucial to the error having been detected. I am wondering why there aren't more reports out there of encounters with this problem. Is this bug flying under the radar? Tom Walker, Bowen Island, BC 1-604-947-2213 ------------------------------ Date: Fri, 8 Jun 2001 14:59:11 -0500 From: "Dankmyer, Kirt" <Kirt.Dankmyerat_private> Subject: Dead men produce no documentation I was recently assigned to take over a system that processes and sends data to a wide variety of scientific agencies that depend on said data. In particular, I've been asked to understand the system well enough to maintain and troubleshoot it. Naturally, the system, both software and hardware, was created "in-house" by contractors. Nothing like anything I'd experienced before. When I requested documentation, I was told there was none. The last person who had to work on the system had produced a draft of user documentation, but it was incomplete. So, I contacted the poor soul who had worked on this system before me, the one who had produced the incomplete documentation. (We'll call her Joan.) Joan was only familiar with the part of the system she had worked on (the user interface, really). So I asked her about the two people who had designed and implemented the system in the first place. I thought that they could perhaps help me with some of the questions I had. One of them had left the company that originally employed her, and wouldn't return phone calls. So I asked Joan about the other designer, who seemed to have done the bulk of the work anyway. "He's dead," Joan told me. "Heart attack." The risk? If you skimp on documentation while designing a custom system, you may find that you don't have time to go back and do it later, with serious consequences for those who follow you. This problem should be familiar to most readers of RISKS, but it bears repeating. As I write this, a problem has come up with the system and no one is even sure if it is hardware or software. When dealing with such a system, you cannot guarantee you will be able to talk to the original designer (and the only one who understands the system fully), and it might be because they've left more than just the company that originally produced the equipment. Sic transit gloria mundi... Kirt Dankmyer -- 757-824-2283 -- kirt.dankmyerat_private CSOC UNIX System Administrator -- Wallops Flight Facility [Of course, Wallops Island is where a lightning strike hit the missile launch platform when a missile was waiting to be launched to test the effects of lightning -- and resulted in the missile accidentally being launched. PGN] ------------------------------ Date: Mon, 11 Jun 2001 18:21:13 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Inside Internet Security", Jeff Crume BKININSC.RVW 20010511 "Inside Internet Security", Jeff Crume, 2000, 0-201-67516-1, U$29.95 %A Jeff Crume crumeat_private %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2000 %G 0-201-67516-1 %I Addison-Wesley Publishing Co. %O U$29.95 416-447-5101 fax: 416-443-0948 bkexpressat_private %P 270 p. %T "Inside Internet Security: What Hackers Don't Want You to Know" Recently I started teaching a new class. During the introductions, one student admitted that he wanted to learn how to break into systems since that would teach him how to protect them, right? In the first place, I don't believe him. In the second, his thesis is seriously flawed. Yet that is the type of argument Crume seems to be making in the introduction to this book: learning how to hack will teach you how to protect yourself. It doesn't work that way. Knowing how to exploit a buffer overflow in Microsoft's Internet Information Server doesn't teach you anything about the type of systems development practices that will keep you from leaving buffer overflow loopholes in your own programs. Crume does, however, present some good, if basic, security advice. After a bit of a rocky start. Chapter one says that there are weaknesses in the net. Big surprise. Chapter two says that the Net is possibly dangerous. About the only reliable information you'll get out of chapter three is that hackers differ. By chapter four, though, the book has settled down. Here we get a decent introduction to risk analysis, stressing that some risks are not worth protecting against. There is some solid advice about security policies in chapter five, most notably, have one. Chapter seven lists some good general points to keep in mind, which then become the titles of the remaining chapters. There is a clear, if not terribly detailed, explanation of what firewalls are and do, in chapter eight. We are warned to be wary of insiders in chapter nine, which also points out that not all "insiders" are actually inside. Chapter ten outlines some of the aspects of social engineering. A detailed discussion of passwords, in chapter eleven, even covers tokens and biometrics. Network and packet sniffing is explained in chapter twelve. Chapter thirteen is weak. Ironically, it is the first chapter to touch closely on the items Crume implied in the introduction, and looks at software vulnerabilities. But these loopholes are very difficult to deal with, and the material here isn't much help. Chapter fourteen is helpful in pointing out that factory set defaults can be dangerous. The title of chapter fifteen ("it takes a thief to catch a thief") seems to be suggesting that you hire hackers. Actually, it merely suggests that you learn the vulnerabilities that they know. However, it isn't very useful in pointing the reader in the right direction. Chapter sixteen offers a grab bag of anecdotal reports of recently exploited vulnerabilities. And, of course, I have to pay special attention to chapter seventeen, on viruses. Well, Crume makes mistakes, but he doesn't make any really important ones. The background is reasonable, and the advice is sound. Chapter nineteen provides a good overview of cryptology, but some of the more important points get buried in the stories. (There is more material provided in appendix A.) Backdoors and end runs are discussed in chapter twenty. Chapter twenty one points out that even "harmless" defacement of a Web site can have serious consequences, while twenty two says the information is valuable and a good defence. Chapter twenty three finishes off with a look at some emerging technologies that are bringing forward new security concerns. One note that I should make: the text doesn't have all that much to say about the Internet, as such. Most of the points deal with security on a general basis. Which doesn't necessarily make it any less useful. This book can be read completely in a day. And, for most managers and business people it would be a day very well spent. While some chapters are weak, roughly three quarters of the material is both reasonable and technically sound, a match that happens less often than one might wish. This is definitely a volume to get to pass around among all employees--and to provide to all newly hired managers. copyright Robert M. Slade, 2001 BKININSC.RVW 20010511 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 12 Feb 2001 (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 DIRECT E-MAIL REQUESTS to <risks-requestat_private> with one-line, SUBSCRIBE (or UNSUBSCRIBE) which now requires confirmation to majordomoat_private (not to risks-owner) [with option of E-mail address if not the same as FROM: on the same line, which requires PGN's intervention -- to block spamming subscriptions, etc.] or INFO [for unabridged version of RISKS information] .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 20" for volume 20] 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 21.47 ************************
This archive was generated by hypermail 2b30 : Wed Jun 13 2001 - 16:28:07 PDT