RISKS-LIST: Risks-Forum Digest Tuesday 18 February 2003 Volume 22 : Issue 56 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.56.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Identity theft evidently based on spoofing AOL (Mike Hogsett) Credit-card hacking (David Wj Stringer-Calvert) 11-year-old boy charged with felony for computer tampering (David R. Throop) eBay Sting (D. Joseph Creighton) Edsger Dijkstra quote on Computer Science (Stan Mazor) MacOS 10.2.4 update & httpd.conf replacement (Lawrence Brenninkmeyer) Risks of Doing Homework (Rebecca Mercuri) Re: Hospital claims 8,500 people expired (Fredric L. Rice) Re: Artery errors cost over $1 billion (Jamie McCarthy) Re: Password complexity (Nick Brown) Questions Frequently Asked About Rob Slade's Innumerable Book Reviews (Rob Slade) REVIEW: "Honeypots: Tracking Hackers", Lance Spitzner (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 18 Feb 2003 15:49:02 -0800 From: Mike Hogsett <hogsettat_private> Subject: Identity theft evidently based on spoofing AOL A Web site, http://www.aol-billsite.com/, was recently brought to my attention. It has questionable content and most certainly a questionable intent. From my investigation, it appears that the intent is to purloin the information necessary for identity theft from unsuspecting AOL subscribers. In summary, the domain name www.aol-billsite.com serves a web page that uses a frame set to obscure the source of the real contents. The real contents contain a very official looking form for "customers" to enter new billing information for their AOL account. In addition to a credit-card number this form asks for social security number, mother's maiden name, and a second credit-card number. If some poor, unsuspecting person actually presses the submit button on this page, the information is sent in the clear to a CGI program on yet another web server which presumably sends this information via e-mail (also in the clear) to a hotmail.com e-mail account. I believe it is immediately evident that the intention is to steal the information necessary to perform identity theft. Why don't I believe that it is not an official AOL page? 1) Original frameset page not served via https 2) Obfuscation of true source of content 3) Content not served via https 4) Form contents not sent via https to form target 5) Form contents sent to form target on third web server in yet another domain 6) hotmail.com address given as argument to form target 7) Real page server via a residential broadband address 8) Form asks for home address, date of birth, SSN, mother's maiden name, and a second credit-card number 9) Form asks for AOL password 10) Two of the relevant domains registered by individuals 11) Domain/host information spans the US (WA to CA to NJ to FL) 12) Form contents e-mail is sent via a completely insecure CGI program (anyone can send e-mail anywhere with this script). [Update: The abuseat_private auto-responder rejected my report, for the following ERRONEOUS reason! (My e-mail has numerous references to hotmail.) Mike "Unfortunately, we cannot take action on the mail you sent us because it does not reference a Hotmail account. Please send us another message that contains the full Hotmail e-mail address and the full e-mail message to: abuseat_private " ] [If it this case is due to stupidity and ignorance rather than an outright scam, that would be even more startling -- although the opportunities for privacy violations would still be enormous. Furthermore, the recipient mailbox is reportedly saturated, which suggests perhaps that people are incredibly gullible and have already bitten for this scam! Also commented on by Fred Gilham. PGN] ------------------------------ Date: Tue, 18 Feb 2003 07:33:28 -0800 From: "David Wj Stringer-Calvert" <david.stringer-calvertat_private> Subject: Credit-card hacking More than five million Visa and MasterCard accounts throughout the U.S. were accessed after the computer system at an unidentified third-party merchants' processor was hacked into. It is currently believed that no fraudulent misuse has occurred. MasterCard began to notify its financial members during the week of 3 Feb that more than 2 million MasterCard accounts had been potentially compromised -- as did Visa for about 3.4 million of its accounts. [Source: Reuters item, 18 Feb 2003; PGN-ed] http://story.news.yahoo.com/news ?tmpl=story2&cid=581&ncid=581&e=10&u=/nm/20030218/tc_nm/ financial_visamastercard_dc ------------------------------ Date: 13 Feb 2003 23:01:58 -0600 From: throopat_private (David R. Throop) Subject: 11-year-old boy charged with felony for computer tampering A St. Lucie West Middle sixth-grader used the excuse of forgetting his lunch to return to his reading classroom and sat down at his teacher's computer to change five reading assignment grades, St. Lucie County sheriff's deputies said Tuesday. ... The 11-year-old student, who faces a 10-day suspension and a principal's recommendation that he be expelled, was arrested Monday on a felony charge of offense against intellectual property. ... The student was booked into the St. Lucie County jail, then released to his father. Mancini said he could face several years in a juvenile detention facility, if convicted. http://www.gopbi.com/partners/pbpost/epaper/editions/wednesday/ martin_stlucie_e394fc8032005260000b.html [With a little more imagination, he could have qualified for life imprisonment under the new anti-hacking law. PGN] ------------------------------ Date: Tue, 18 Feb 2003 14:54:19 -0600 From: "D. Joseph Creighton" <djcat_private> Subject: eBay Sting A computer technician in Winnipeg, Canada, had his Fluke inline network tester stolen (approx. value CDN$11,000) at the end of January. Later, he decided to check if the not-so-common device was being put up for sale on eBay and found two: one in Indianapolis and the other in Winnipeg. [First source: CBC Radio with an online article: <http://winnipeg.cbc.ca/template/servlet/View?filename=mb_ebay20030218>] After expressing interest and through correspondence with the seller, a serial number was obtained which confirmed that the network tester was the technician's. Police were contacted and a meeting was arranged at a local coffee shop where the seller/suspect was arrested. *The Winnipeg Free Press* for 18 Feb 2003 later mentioned that the meeting between seller and technician occurred with two plainclothes officers waiting at another table. [I presume the police were drinking Tester's Choice with their serial. PGN] It appears the CBC may have gotten their tip from the morning paper -- I don't get to my own copy until the end of the day -- and there's a bit of a difference between the radio and newspaper versions. Although the suspect may be innocent of the theft, the attempt to sell would seem to constitute a crime. The RISKS in not doing your on-line research before doing your on-line auction is -- for the seller -- one that might be costly and -- for the thief -- downright dumb. D. Joseph Creighton [ESTP] | Systems Analyst, Database Technologies, IST Joe_Creightonat_private | University of Manitoba Winnipeg, MB, Canada, eh? ------------------------------ Date: Mon, 10 Feb 2003 09:55:17 -0800 From: Stan Mazor <smazorat_private> Subject: Edsger Dijkstra quote on Computer Science [From asilomar-news, noted by Robert G. Kennedy III in Hackers newsgroup, sent to RISKS by Ken Knowlton. PGN] Edsger W. Dijkstra, *Communications of the ACM*, Mar 2001, Vol. 44, No. 3 In academia, in industry, and in the commercial world, there is a widespread belief that computing science as such has been all but completed and that, consequently, computing has matured from a theoretical topic for the scientists to a practical issue for the engineers, the managers, and the entrepreneurs. [...] I would therefore like to posit that computing's central challenge, "How not to make a mess of it," has not been met. On the contrary, most of our systems are much more complicated than can be considered healthy, and are too messy and chaotic to be used in comfort and confidence. The average customer of the computing industry has been served so poorly that he expects his system to crash all the time, and we witness a massive worldwide distribution of bug-ridden software for which we should be deeply ashamed. For us scientists it is very tempting to blame the lack of education of the average engineer, the shortsightedness of the managers, and the malice of the entrepreneurs for this sorry state of affairs, but that won't do. You see, while we all know that unmastered complexity is at the root of the misery, we do not know what degree of simplicity can be obtained, nor to what extent the intrinsic complexity of the whole design has to show up in the interfaces. We simply do not know yet the limits of disentanglement. We do not know yet whether intrinsic intricacy can be distinguished from accidental intricacy. To put it bluntly, we simply do not know yet what we should be talking about, ... The moral is that whether computing science is finished will primarily depend on our courage and our imagination. [Stanley Mazor, Director Customer Services, Numerical Technologies Inc. 70 West Plumeria Drive, San Jose, CA 95134-2134 1-408-273-4485] ------------------------------ Date: Fri, 14 Feb 2003 10:56:43 -0600 From: Lawrence Brenninkmeyer <ldbat_private> Subject: MacOS 10.2.4 update & httpd.conf replacement The Mac OS X operating system is a work in progress. Users are treated to small upgrades every one or two months that fix bugs, improve security, and occasionally provide increased functionality. Presumably in an effort to add functionality to the built-in Apache server, the latest update installs a brand new httpd.conf file. This is file that tells the Apache server how to configure itself (which modules to load, where the root directory is, etc.) The update kindly (and silently) saves the original httpd.conf as httpd.conf.applesaved. The risk is that replacing the original, not telling anyone, and then leaving the server active on restart can lead to a breach of security. One of the things that you can use the httpd.conf file for is to govern which directories are password protected and which are not [1]. This information is not retained in the new httpd.conf, so directories that were password protected are opened to the world after the update has been installed. The risks are obvious, and so are the solutions. At a minimum, they should have disabled Apache on startup and presented the user with a dialog box informing them of the change. [1] Apache httpd documentation: Basic Security <http://httpd.apache.org/docs/howto/auth.html#basic> <http://pubweb.northwestern.edu/~ldb371/> ------------------------------ Date: Thu, 13 Feb 2003 05:46:37 -0500 From: "Rebecca Mercuri" <notableat_private> Subject: Risks of Doing Homework At the faculty meeting at Bryn Mawr College on 12 Feb 2003, we were informed that a student at Haverford (our affiliated College) was arrested over the weekend when he was trying to do his homework assignment in Philadelphia. As part of the Cities project, he was taking photographs of SEPTA (our regional transit authority) facilities when he was arrested, detained for a few hours, and eventually released. Haverford administration is working to try to ensure that this event not be a part of the student's permanent police record. Apparently taking photographs at transit facilities is cause for arrest during "Code Orange" alert, the authorities explained. Faculty were advised to be careful about assigning "field trip" projects during such alerts. Rebecca Mercuri, Bryn Mawr Computer Science ------------------------------ Date: Thu, 13 Feb 2003 11:18:28 -0800 From: "Fredric L. Rice" <Quackat_private> Subject: Re: Hospital claims 8,500 people expired In RISKS-22.55, the coverage of the hospital in Grand Rapids, Michigan didn't mention the possibility of *deliberate* abuse of the system where simply changing a 01 into a 20 causes the system to inform insurance carriers, the IRS, and presumably other agencies that one's dead. Since a hospital is a credible source for agencies, someone trying to vanish in America to make another life for themselves -- either for honest reasons else for criminal reasons -- could hack or bribe their way to access to the system and, after going to St. Mary's Mercy for a broken finger, have the hospital send credible notices of their own death. Love it. Death and taxes aren't quite so final in the Information Age. ------------------------------ Date: Thu, 13 Feb 2003 13:22:02 -0500 From: Jamie McCarthy <jamieat_private> Subject: Re: Artery errors cost over $1 billion (RISKS-22.55) > Fleet Center arena ... was missing from the 1994 design drawings... > ...which (according to the headline) cost over $1 billion ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The RISK here is reading the headline instead of the article. The arena missing from the design drawings cost slightly under $1 million extra. The $1 billion figure is for all mistakes made by the Bechtel company resulting in cost overruns over the past decade. ------------------------------ Date: Thu, 13 Feb 2003 18:28:09 +0100 From: BROWN Nick <Nick.BROWNat_private> Subject: Re: Password complexity (Palme, RISKS-22.55) I have absolutely no training in probability theory, but it seems to me intuitive that adding a mechanism that effectively tells you if you're already half-right, is going to reduce the security of any password. Consider an eight-digit combination lock versus two four-digit locks, where the first four-digit lock goes "click" before you open it and move on to the next. Clearly you only have to go round the 10000 combinations of the second lock once, whereas in the 8-digit lock, you might have to do it 10000 times. Or to make it even clearer, consider eight one-digit locks. The calculation of the relative ease of cracking the combination only becomes non-trivial when the number of bits in the separate locks sums to more than the number of bits in the single lock. However, as long as the main limiting factor in determining the minimum length of a password for, say, an online banking system, is the marketing department ("Oh, no, we mustn't frighten the customer with a hard-to-remember code; let's use four digits like for the ATM card. But don't forget to insist on a 128-bit browser, because the user wants to feel safe."), the debate will remain academic anyway. :-( [Similar comments were received from Simon Waters and David Parnas. Of course, one of the CLASSIC password attacks was the old TENEX flaw in which passwords were checked one character at a time. By aligning the password presented in a program so that the NEXT character lay across a page boundary, you could detect whether or not a page fault had occurred on the previous character, and thus iteratively reduce an exhaustive search to a linear search. This was something like 30 years ago when it was realized that visibility of intermediate results is riskful, and that checking must be done in a single atomic transaction. PGN] ------------------------------ Date: Thu, 13 Feb 2003 16:38:22 -0800 From: Rob Slade <rsladeat_private> Subject: Questions Frequently Asked About Rob Slade's Innumerable Book Reviews OK, since I am now getting not only questions about the reviews every day, but multiple copies of the *same* questions, I suppose it is time for: Questions Frequently Asked About Rob Slade's Innumerable Book Reviews -- Now With Answers! Questions and answers 1) How do you find time to read all those books? Darned if I know. I've always read a lot, and quickly. No, I don't do speed reading: I find that I can't use those techniques. I read while waiting, I read while traveling: sometimes I just read. I read and review as much as I can spare time for. Those who have followed the series of reviews will notice that sometimes I produce more than others: a lot depends on what else I have to do at the time. Yes, I do read all of the books: every page (although, I admit, sometimes not every word). 2) Do you have an archive of the reviews? Yes, two, in fact. The "base" URLs are http://victoria.tc.ca/techrev, courtesy of the Victoria, BC, Canada TelecommunityNet (aka VTN), and http://sun.soci.niu.edu/~rslade, courtesy of Northern Illinois University (former home of the Computer Underground Digest and aka NIU). All the various pages and files are in those directories, so you can construct a full URL by simply appending the filename. Also, all files are mirrored at both sites. For example, a reference in one review, like "(cf.BKVR.RVW)," would mean that the filename (converted to lower case) could be appended to the base addresses, and you would find that both http://victoria.tc.ca/techrev/bkvr.rvw and http://sun.soci.niu.edu/~rslade/bkvr.rvw point to actual reviews. (If you use only the base URLs, you will find an index file that points you at some of the major pages.) For those looking for the reviews, probably the most useful addresses will be http://victoria.tc.ca/techrev/mnbk.htm or http://sun.soci.niu.edu/~rslade/mnbk.htm; the top level of the topical menus of book reviews (security is not the only topic); and http://victoria.tc.ca/techrev/review.htm or http://sun.soci.niu.edu/~rslade/review.htm; the main index to all reviews. Due to increasing numbers of questions, I guess I will be maintaining this FAQ at http://victoria.tc.ca/techrev/revfaq.htm and http://sun.soci.niu.edu/~rslade/revfaq.htm. 3) Where can I find the reviews? All kinds of places, apparently. There are, of course, the archives above, and the various topically related lists and groups to which I post messages. Others archive various subsets of the reviews to different sites, reprint the reviews in college or user group newsletters, and repost the reviews to other mailing lists. If you want to get on a mailing list for all the reviews, I have created a mailing list at Yahoo Groups. You can subscribe by sending an email message to techbooks- subscribeat_private, or visiting the Web site at http://groups.yahoo.com/list/techbooks/, where you can also find an archive of the more recent reviews. 4) Don't you like *any* books? OK, I'm a cruel reviewer. But fair! But, yes, I do like some. In the absence of a "Rob's Picks" page (which I may get around to some time) the closest alternative is probably the page of references by the CISSP domains, at http://victoria.tc.ca/techrev/mnbksccd.htm or http://sun.soci.niu.edu/~rslade/mnbksccd.htm. 5) Why don't you rate the books you review? Generally, the people who ask this question want me to assign a single numeric value, preferably on a scale of 1-5, to every book. Books are a little bit more complex than that. They are good or bad for different reasons for different groups. A book for a novice is useless to an expert. A book for an expert is useless to a novice. So I try to state who I would recommend the book to, and why. I think it's a bit more reasonable than just giving each book a number. If I'd wanted to do that, I could have skipped writing the reviews entirely. It'd sure save time. (See question 1 :-) However, a partial answer, for those who want a quick fix, is to look at the main review index. (See question 2 :-) I try to give a summary of my reaction to the book, in not more than one sentence. 6) Where can I find your reviews of all the CISSP guides? See http://victoria.tc.ca/techrev/mnbkscci.htm or http://sun.soci.niu.edu/~rslade/mnbkscci.htm. 7) What's all that stuff at the beginning? I was asked by the moderators of one newsgroup to use the standard UNIX addlib format for publication information. It seemed to be a good set of data, so I continued. The basic information is: %A Author's name (use a separate %A line for each) %C City (place of publication) %D Date of publication %E Editor (of book or series) %G Government order number (use this for ISBN) %I Issuer (publisher's name and imprint) %O Comments/etc. (use for format/price, ordering info) (also the links for purchase at online bookstores. Yes, I do get a commission: see question 8.) %P Page number(s) (use for page count) %T Title of article or book For more information, see the man page for the UNIX "refer" command. 8) How much money can you make reviewing books? I find it quite bizarre that almost everyone seems to assume that a) I buy all these books, or b) I get paid for doing these reviews. I get the books free from publishers. (See question 9.) I don't get paid for doing the reviews. Occasionally I use these reviews as the basis for review columns or "best of" articles for magazines, and get a few bucks. If people "click-through" the links on the reviews and buy books, I get a commission. (Eventually my account may build up to enough money that they'll actually send me a cheque.) I even get a bit of a tax break by getting a "gift in kind" tax receipt when all these dead trees go to the library. But this isn't exactly a business. Of course, if any large corporation was interested in sponsoring the reviews ... :-) 9) How can I get started reviewing books? In the immortal words of the advertising campaign, just do it. Grab some books, and review them. Post the reviews. Once you have built a body of work, you can start asking publishers for copies of books, especially if you have proven you are serious by sending them copies of the drafts of your reviews. (Before you post them on the net.) You don't even have to buy a ton of books to get started. Review the ones you've already got. If you use them, presumably you know why. If you want to review new ones, try the library. (If you live in Vancouver, the Vancouver Public Library has lots of recent technical books :-) Of course, why would you want to? (See question 8.) 10) Where can I find books on (topic)? Go to the main review index at http://victoria.tc.ca/techrev/review.htm or http://sun.soci.niu.edu/~rslade/review.htm. Use the search function on your browser (Ctrl-F for most Windows stuff, "/" for Lynx, etc). Search for terms you think would be in the title or the topic of the book. (For privacy you might want to search on "privacy," "private," or "confidential.") When you find a likely title, there will be a link to the review itself. ====================== rsladeat_private rsladeat_private sladeat_private p1at_private ============= for back issues: [Victoria Freenet] site http://victoria.tc.ca/int-grps/books/techrev/ or http://www.victoria.tc.ca/techrev or http://victoria.tc.ca/techrev an alternate site has been provided by CuD and NIU at: http://sun.soci.niu.edu/~rslade/ CISSP refs: [Victoria Freenet]mnbksccd.htm PC Security: [Victoria Freenet]mnvrrvsc.htm Security Dict.: [Victoria Freenet]secgloss.htm Security Educ.: [Victoria Freenet]comseced.htm Book reviews: [Victoria Freenet]mnbk.htm [Victoria Freenet]review.htm Partial/recent: http://groups.yahoo.com/group/techbooks/ Security Educ.: http://groups.yahoo.com/group/comseced/ Review mailing list: send mail to techbooks-subscribeat_private ------------------------------ Date: Mon, 10 Feb 2003 08:04:30 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Honeypots: Tracking Hackers", Lance Spitzner BKHNYPOT.RVW 20030126 "Honeypots: Tracking Hackers", Lance Spitzner, 2003, 0-321-10895-7, U$44.99/C$69.99 %A Lance Spitzner hostmaster@tracking-hackers.com %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2003 %G 0-321-10895-7 %I Addison-Wesley Publishing Co. %O U$44.99/C$69.99 800-822-6339 fax 617-944-7273 bkexpressat_private %O http://www.amazon.com/exec/obidos/ASIN/0321108957/robsladesinterne %P 452 p. + CD-ROM %T "Honeypots: Tracking Hackers" Chapter one is an introduction to the honeypot concepts, and the story of Spitzner's first attempt to run one. An overview of attackers and tools is given in chapter two. A history of honeypots is provided in chapter three, and a list of basic types. Chapter four looks at the benefits (and also the problems) of these types of programs. The types of honeypots are grouped into high, medium, and low interactivity, in chapter five. The explanations given, in this first section, are good and simple. Tables and figures provided, however, often require interpretation. Chapters six to eleven are reviews and descriptions of honeypots and related programs. There is a tutorial on the setup and use of Back Officer Friendly in chapter six. Specter, in chapter seven, gets a detailed review and a discussion of the program's options. Chapter eight discusses how honeyd emulates a network. Port monitoring, with netcat, and jails, using chroot, are covered in chapter nine. Mantrap cages are discussed in chapter ten. Chapter eleven reviews two generations of honeynets, with lots of details. Chapter twelve examines choosing and camouflaging honeypots. Maintaining and using a honeypot is in chapter thirteen. Chapter fourteen presents a couple of "case studies," integrating material from previous chapters. There is a reasonable discussion of legal issues in chapter fifteen. Future directions for honeypots are examined in chapter sixteen. "Know Your Enemy" (cf BKKNYREN.RVW) presented a fascinating glimpse into both honeypots and the blackhat community, but only a glimpse. This book provides much more detail into the inner workings, setup, and technologies involved in sensors for detecting and dissecting network intrusions. copyright, Robert M. Slade, 2003 BKHNYPOT.RVW 20030126 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ 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.56 ************************
This archive was generated by hypermail 2b30 : Tue Feb 18 2003 - 17:51:17 PST