RISKS-LIST: Risks-Forum Digest Friday 14 December 2001 Volume 21 : Issue 82 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.82.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Cisco accountant's fraud (David Weitzel) "The Missile Defense Hoax" (Lauren Weinstein) Military intelligence at its best? (Terry Labach via Alan Wexelblat) Office XP, Windows XP may send sensitive documents to Microsoft (David Farber) MS Word XP "autocorrects" my name (Arnold Weissberg) P3P, IE6 and Legal Liability (Ben Wright) SMS phone crash exploit a risk for older Nokias (Monty Solomon) Identity theft without prior knowledge of social security number (Identity withheld by request) FBI may not appreciate the risks with Carnivore sniffing E-Mail (Fredric L. Rice) Number takes prime position (technews) Radio-synchronised alarm clocks (Jonathan D. Amery) Computer will drives 820 passengers at 68 mph (Daniel Norton) Re: "Late-night" Internet-porno-ban (Debora Weber-Wulff) Re: Risks of various characters in Unix filenames (Duncan MacGregor, Bennet S. Yee) NetSOL vs. PGP: Risks of a crypto company owning a registrar? (R. A. Hettinga) Swedish police reportedly doctor video evidence, admit it (Michael Walsh) Followup to: Savings Bank software upgrade goes awry (Jonathan Kamens) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 13 Dec 2001 17:35:39 -0500 From: david weitzel <dweitzelat_private> Subject: Cisco accountant's fraud www.cybercrime.gov: Former Cisco Systems, Inc. Accountants Sentenced for Unauthorized Access to Computer Systems to Illegally Issue Almost $8 Million in Cisco Stock to Themselves (November 26, 2001) <http://www.cybercrime.gov/Osowski_TangSent.htm> Press release excerpt: Judge Whyte sentenced the defendants each to 34 months in federal prison, restitution of $7,868,637, and a three year period of supervised release. The defendants will begin serving their sentences on January 8, 2002. David S. Weitzel, M.S., J.D., Senior Principal, Mitretek Systems dweitzelat_private 1-703-610-2970 ------------------------------ Date: Thu, 13 Dec 2001 12:33:37 -0800 (PST) From: Lauren Weinstein <laurenat_private> Subject: "The Missile Defense Hoax" Greetings. The latest short "Fact Squad Radio" audio piece addresses the risks related to the U.S. withdrawal from the 1972 ABM treaty. It's called "The Missile Defense Hoax" and can be accessed via: http://www.factsquad.org/radio Lauren Weinstein Tel: +1 (818) 225-2800 laurenat_private or laurenat_private or laurenat_private ------------------------------ Date: Tue, 11 Dec 2001 05:55:06 -0500 From: quotationoftheday_requestat_private Subject: Military intelligence at its best? (Retitled) Quote of the day for December 11, 2001: "As a pilot, I can do everything perfectly with a perfect weapon system, and still cannot account for every weapon going exactly where it's supposed to go." U.S. Rear Admiral John Stufflebeem redefines the word "perfect". Stufflebeem was responding to the deaths of three U.S. soldiers in Afghanistan after yet another bomb went astray. Submitted by: Terry Labach, Dec. 6, 2001 [Submitted to RISKS by Alan Wexelblat <wexat_private>. PGN ] ------------------------------ Date: Fri, 07 Dec 2001 07:59:49 -0500 From: David Farber <daveat_private> Subject: Office XP, Windows XP may send sensitive documents to Microsoft PROBLEM: Microsoft Office XP and Internet Explorer version 5 and later are configured to request to send debugging information to Microsoft in the event of a program crash. The debugging information includes a memory dump which may contain all or part of the document being viewed or edited. This debug message potentially could contain sensitive, private information. PLATFORM: * Microsoft Office XP * Microsoft Internet Explorer 5.0 and later * Windows XP * Microsoft has indicated that this will be a feature of all new Microsoft products DAMAGE: Sensitive or private information could inadvertently be sent to Microsoft. Some simple testing of the feature found document information in one message out of three. SOLUTION: Apply the registry changes listed in this bulletin to disable the automatic sending of debugging information. If you are working with sensitive information and a program asks to send debugging information to Microsoft, you should click Don't Send. http://www.ciac.org/ciac/bulletins/m-005.shtml ------------------------------ Date: Thu, 06 Dec 2001 19:39:48 -0500 From: Arnold Weissberg <aweissbergat_private> Subject: MS Word XP "autocorrects" my name I typed my last name into a document. I thought something funny had happened because it came out with one "s." I never misspell my last name. There was a line under the "W". Holding the mouse on this line I got the following choices: 1. Change back to "Weissberg" 2. Stop Automatically Correcting "Weissberg" 3. Control AutoCorrect Options Now this is, as my grandmother would have said, real chutzpah. Telling me how to spell my own name! Talk about arrogance--what's next, "anglicizing" it? Like, auto correcting it to "Whitehill?" And if I try to change it back will it say, "I'm sorry, Arnold, I can't do that"? I think in this little example we can learn a lot about Microsoft's corporate attitudes toward the rest of the world--that is, no one is smart enough even to be trusted to spell their own name right. Much less choose what software they'd like to use. [Not much new, but just one more instance -- which is so often the case in the RISKS archives. PGN] ------------------------------ Date: Mon, 10 Dec 2001 10:07:12 -0500 From: Ben Wright <Ben_Wrightat_private> Subject: P3P, IE6 and Legal Liability Privacy filters in Microsoft's new Internet Explorer 6 pose for Web administrators an unexpected legal predicament. The filters force administrators to post new privacy policies for their Web sites, coded in a technical language called P3P. The filters punish administrators who fail to publish properly coded P3P privacy policies by blocking or impeding their cookies. The P3P coding language raises, for any corporation, government agency or other institution that uses it, a lawsuit danger. A privacy policy written in it exposes the organization to liability, with little or no escape. A privacy policy, even one written in computer codes, can be legally enforceable like a contract. In lawsuits filed in 1999, plaintiffs forced US Bancorp to pay $7.5 million for misstatements in a privacy policy posted on its Web site. Web administrators face a dilemma. They want to satisfy IE 6's technical requirement for P3P codes, but they also want to sidestep liability. See Webserver Online Magazine article: http://webserver.cpg.com/news/6.12/n5.shtml One solution is to deploy dummy P3P codes, with an extra legal code that disavows any liability for the codes, as explained at http://www.disavowp3p.com. P3P is the Platform for Privacy Preferences, developed under the sponsorship of a non-profit organization named the World Wide Web Consortium (also called W3C) http://www.w3.org/p3p, a coalition of industry and non-profit groups. --Ben Wright ben_wrightat_private ------------------------------ Date: Fri, 7 Dec 2001 14:25:15 -0500 From: "monty solomon" <montyat_private> Subject: SMS phone crash exploit a risk for older Nokias SMS phone crash exploit a risk for older Nokias, by John Leyden, 12 Jun 2001 Nokia has upgraded its phone software to guard against a security glitch that might allow a cracker to render a phone inoperable by sending a text message. However, older phones may still be vulnerable. http://www.theregister.co.uk/content/55/23232.html ------------------------------ Date: 13 Dec 2001 From: (Identity withheld by request) Subject: Identity theft without prior knowledge of social security number A while back I had few occasions when I was asked for my social-security number by organizations I felt have no business knowing it (such as libraries, etc.). Following advice from the Usenet SSN FAQ, I asked why they wanted my SSN, quoted appropriate legislation, and was allowed to give "a different number" (which these organizations presumably want as a primary key for their databases or for similar procedural reasons). Needless to say, I used a meaningless word for mother's maiden name and a made up birth date, one per organization. When I have later requested my credit report, I discovered that these silly made up numbers appear on the report as "Other social security numbers used." Along with their respective mother maiden names and birth dates. Apparently, credit-reporting agencies aggressively merge records in their databases. A risk? Surely. Consider the following scenario: 1. Identify target for identity theft by name (common names could work). Use the phone book to learn the address of the person in question. This is all the information you need to know. 2. Apply for a credit card in the name of that person, using a made up SSN, mother's maiden name, and birth date. (It doesn't matter if the request for credit is approved; the information you submit will get reported to credit agencies and they will merge it into the database entry of the target person based on matching name and address. You now have information that's sufficient to ask for a credit report.) 3. Ask a credit reporting agency for "your" credit report. You should be able to do it through a Web interface. (If you had to give them a mailing address, you could have asked for the report to be mailed to a temporary Mail Boxes, Etc address or to somebody else's street address where the mailbox is accessible and you can get to it before the rightful owner does--for example, because you know the owner's work schedule.) 4. Examine the credit report. It has the target's actual ("primary") social security number and other information. 5. Having that, proceed with identity theft in any number of well-known ways. I have a fairly uncommon name. Maybe the record merging algorithm will not actually work with common names. Does anybody know more about their actual merging algorithm? ------------------------------ Date: Wed, 05 Dec 2001 11:57:43 From: "Fredric L. Rice" <friceat_private> Subject: FBI may not appreciate the risks with Carnivore sniffing E-Mail Probably everyone who reads RISKS has read about the United States' law enforcement agencies wish to implement anti-terrorism measures which adversely impact people's privacy. As reported in Yahoo Magazine, November 2001, the FBI has been pushing to get its Carnivore package installed at major Internet Service Providers like AOL and EarthLink so that subscriber's inbound and outbound E-mail can be flagged and read by the FBI. Before the terrorist attacks on New York, activists had been trying to disrupt Carnivore and like-minded software packages by stuffing their Web sites, E-Mail messages, Usenet postings, and mailing list messages with likely terms and phrases that would trigger collection by Carnivore so that some hapless FBI stooge has to spend half a minute apiece looking through tens out thousands of messages. By now, I'd expect, the FBI has tailored its implementations of Carnivore to detect such repeated, invariant attempts to choke off their software's usefulness but did the FBI really consider all of the risks of using Carnivore? I doubt that they did. You know what happens next, humans being ornery and downright stupid. What happens next is that activists and idiots both will start farming AOL and EarthLink E-Mail addresses and software will be written to start spamming those hundreds of thousands of addresses with variant message texts containing all the likely terrorism-related keywords inserted Mad-Lib fashion. Tens of thousands of people will get E-Mail messages with forged return addresses containing Mad-Lib-like generated terrorist plans and Carnivore will flag on them. Then when the subscriber who gets the spam forwards it to both uceat_private and Norfolkat_private, Carnivore gets two more hits. If the subscriber is stupid enough to reply to the E-Mail (and let's face it: They're using AOL or EarthLink so you know they're not very bright) and now Carnivore sees a bi-directional link. The risks are plenty. How many people will the FBI take off of real criminal investigations and put onto the project to monitor and review bogus Carnivore hits? If they hire new people, who's going to pay for them? How many people are going to be visited by the FBI because some idiot keeps sending them terrorist attack plans? The biggest risk is obvious and I have to wonder why nobody in the FBI seems worried about it: Real terrorists will slip through Carnivores' filtration criteria simply because you damn well know that activists and idiots will be the ones who get to decide what Carnivore filters and what it hits on. How will activists get to drive Carnivore? Every time someone gets questioned by the FBI or finds out from their neighbors that they've been investigated, the victim will report the fact on the Internet maybe even posting the E-Mail they received that triggered the software, prompting activists and idiots to adopt the terms and methodologies which worked, prompting the FBI to tailor Carnivores' filtration until the next time. I can't see anything coming out of the struggle besides a pile of useless software running on ISP's servers fingering innocent people and failing to point at a single bad guy. ------------------------------ Date: Mon, 10 Dec 2001 16:28:41 -0500 From: technews <technewsat_private> Subject: Number takes prime position The largest prime number yet to be documented has been discovered by Michael Cameron, a participant in the Great Internet Mersenne Prime Search (GIMPS). The project, founded in 1996 by George Woltman, aims to uncover new Mersenne primes through distributed computing. ... 4,053,946 digits: 2^(12,466,917) - 1. ... 130,000 volunteer participants ... ACM TechNews - Monday, December 10, 2001 http://www.acm.org/technews/articles/2001-3/1210m.html#item13 [See that site for subscriptions. PGN] ------------------------------ Date: Mon, 10 Dec 2001 00:38:21 +0000 (GMT) From: "Jonathan D. Amery" <jdameryat_private> Subject: Radio-synchronised alarm clocks I own a radio synchronised alarm clock (a friend of mine also has one that displays the same symptom). When the batteries are running low it will display the time just fine, but when it tries to sound the alarm there is insufficient power and it resets itself. Since it is radio synchronised it then starts showing the correct time after a minute or two. As a result I oversleep and get to work late, but since I often don't notice the clock going off and wake up a few minutes later I don't know that this has happened, and it carries on like this for many days until I notice. If this was a normal battery operated clock I would be able to tell because the time had reset. ------------------------------ Date: Mon, 10 Dec 2001 14:10:20 -0500 From: Daniel Norton <danortonat_private> Subject: Computer will drive 820 passengers at 68 mph Here are some technical specification on the planned JFK Airport AirTrain: >From http://www.kennedyairport.com/airtrain/projectframe.htm ... Train Consist 1- to 4-car trainsets ... Train Control Fully automated, 24 hour per day operation ... Maximum Design Speed 110 km/h 68 mph ... Capacity per Car, 71 standees + 26 seated = 97 total Passengers with Luggage ... Capacity per Car, 179 standees + 26 seated = 205 total Passengers without Luggage So that's up to 820 passengers at up to 68 mph (110 kmh) under automated control. That's per train and multiple trains are likely to be operating at the same time. I think the RISKS are obvious to readers here, but I'd like to know if there are similar automated passenger systems elsewhere and what actual problems, if any, they have faced. Daniel Norton, NYC ------------------------------ Date: Mon, 10 Dec 2001 10:57:39 +0100 From: Debora Weber-Wulff <weberwu@fhtw-berlin.de> Subject: Re: "Late-night" Internet-porno-ban (RISKS-21.81) Debora wrote: > >all such content is banned from 11 p.m. until 6 a.m. Nick Brown responded: > Don't you mean "banned except from 11 p.m. to 6a.m."? > Papier zufolge duerften nicht jugendfreie Inhalte "nur zwischen 23 Uhr und > 6 Uhr verbreitet". Presumably that gives people the choice: a drink in an > Autobahnraststatte (which is banned between 2300 and 0600, I think), or a > porno session on the Net. > Either way it's very funny. We've been here before though, when Germany > tried to take xs4all.nl offline because one page which it hosted had > pro-Nazi propaganda. They never learn, do they? Prof. Dr. Debora Weber-Wulff, FHTW Berlin, 10313 Berlin +49-30-5019-2320 weberwu@fhtw-berlin.de http://www.f4.fhtw-berlin.de/people/weberwu/ ------------------------------ Date: Sat, 1 Dec 2001 19:46:33 -0500 (EST) From: aa735at_private (Duncan MacGregor) Subject: Re: Risks of various characters in Unix filenames (O'Keefe, R 21 80) Unfortunately, there are two assumptions that fail when shifting from the old Mac OS to a UNIX-based system. One of these is the meaning of the word "quote." Unfortunately, different dialects of English give it a different meaning. In British English, it means the single quote, but in North American English, it means the *double* quote-mark. Fortunately, the phrase 'quotation mark' is often understood to refer to the North American rather than the British convention, though I may be wrong on that point. [And yes, I deliberately alternated between single and double quotes just to drive the point home.] The other assumption that fails, however, is much harder to catch. In UNIX, the single and double quote mark apply different meanings to the string that is contained in it. The single quote means that the string is to be taken *strictly* as is, with no translation of substrings that might match shell or environment variables. Use of the double quote, however, means that such a substitution should be done. This means that, if you have a literal string that includes reversed (single) quotes or dollar [currency] signs, you had better use single quotes or apostrophes [inverted commas?] to demarcate it, or get a shell variable interpolated inside it. Contrarily, double-quotes are needed if you do want such a substitution [though you should use braces or "curly brackets" (i.e., {}) to contain the variable name itself, just in case]. As for languages such as Perl and Tcl, that's an even messier tangle, with yet other methods for quoting ... (where's that Excedrin bottle? :-). Hoping I'm not misquoted ... Duncan MacGregor | aa735at_private Also at: "http://www.ncf.carleton.ca/~aa735/" ------------------------------ Date: 11 Dec 2001 01:46:29 -0800 From: bsyat_private (Bennet S. Yee) Subject: Re: Risks of various characters in Unix filenames (Spinellis, R 21 79) There are several problems with this approach. first, a newline is also a valid character in a filename, not just spaces. so if i create a file named "foo\nbar" in a directory that also contains files "foo" and "bar", this script will not process "foo\nbar" and process both "foo" and "bar" twice. next, if the subtree rooted at "." contains many files, this command could cause the shell to fail in trying to run the "wc" command, since more than ARG_MAX number of bytes in the arglist will cause execve(2) to fail with errno set to E2BIG. Of course, the gnu find utils authors provided a way handled this properly: $ find . -type f -print0 | xargs -0 wc -l This relies on the fact that on all unix filesystems thus far, the null character is not a legal character in a filename component. While I'm nit picking, earlier in the article, a recommendation was made for doing sh/bash/ksh loops as for arg in "$@" do ... done which is fine in modern shells but once upon a time failed in older shells when there are no arguments. the simpler way of for arg do ... done Works just fine in the special case of "for" loops and is shorter besides. in older scripts you'll see ${1+"$@"} instead of just "$@" in non-"for" loop contexts, since it handles the no-arguments case properly. of course, most modern shells (such as bash) handles the no-arguments case for '"$@"' "properly", i.e., the commonly desired interpretation of expanding to nothing instead of a single zero-length argument. The Risks: * not knowing the existing / known methods to solve various shell quoting problems lead to reinvention of the wheel; * trying to outwit shell quoting rules without fully understanding them leads to ever subtler bugs which, because they probably occur with a lower frequency, will be harder to find again; * incompletely considered reinventions can cause harm, esp if eagerly adopted by other non-wheel-reinventors when published in fora like comp.risks. Oh, while kernighan and pike may have commented on "$@", the reference read like a misattribution. s.r.bourne had it in his unix 7th edition shell. i have no idea whether s.r.bourne came up with the notation -- after realizing the need for something like it -- himself or had it suggested to him by others, but its invention significantly predates the K&P book. perhaps this is just the Risk of my reading the article too quickly the first time. Bennet S. Yee, Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114 +1 858 534 4614 http://www-cse.ucsd.edu/users/bsy/ ------------------------------ Date: Mon, 10 Dec 2001 12:19:05 -0500 From: "R. A. Hettinga" <rahettingaat_private> Subject: NetSOL vs. PGP: Risks of a crypto company owning a registrar? Last week, IBUC and Shipwright's upstream provider, kc-inc.net, changed its own upstream access to the net, using Network Solutions' PGP interface to change the DNS server IPs after the wires were pulled and the lights went on. After a week of NetSOL saying that every thing was okay, to repeatedly retry the changes, and wait for the system to catch up, they came back today saying that, in fact, PGP authentication to their domain name registration system was broken, it might be broken for a while, and could kc-inc.net please send a *fax* authorizing the change, and they would walk it, by hand, it through the configuration process. Of course, authentication methods were put in place to avoid manual processing, so this is rather amusing. NetSOL, of course, is owned by Verisign these days, and Verisign is an offspring of RSA, so, given the extant bad blood between RSA and the various iterations of PGP development, it's a pretty fair assumption that there's no real desire to use the SAIC-installed PGP domain-control request system at NetSOL anymore... My question is, would DNSSec fix this mess? R. A. Hettinga, The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA http://www.ibuc.com/ (Reply to rahat_private, of course, as shipwright.com is *still* down, because I can't change my InterNIC handle via email to fix it :-)...) ------------------------------ Date: Mon, 10 Dec 2001 08:59:16 +0200 From: Walsh Michael <michael.walshat_private> Subject: Swedish police reportedly doctor video evidence, admit it (R 21 81) Both RISKS correspondents seem in their own ways to have seen this program in a different way to myself. For me the key difference between the Police video used by the prosecutor and the amateur video used mainly (there were a couple of other sources) by Swedish TV in the Granskning program was that the amateur video was running the entire time and from above (corner building; third? floor). Thus you could see that whereas initially a few police were being chased by a large group of stick-wielding, stone-hurling "demonstrators" (also shown on the police video), by the time the person in question had been shot a large number of police reinforcements had arrived and the large group of demonstrators had mostly fled. In other words whereas the police video showed a few police running away from a mob and in the end defending themselves with a few bullets; the amateur video supported by a couple of other sources showed that at the time of the shooting of the demonstrator the police had the upper hand. The amateur video did however also seem to show that the demonstrator who was shot had been throwing paving stones at the police throughout the entire action from close by and had treated the whole thing as a huge joke. If this is so (it "seemed" to be the same demonstrator), I suspect this finally got to them. Mike Walsh, Helsinki, Finland ------------------------------ Date: Tue, 11 Dec 2001 15:31:04 -0500 From: Jonathan Kamens <jikat_private> Subject: Followup to: Savings Bank software upgrade goes awry (RISKS-21.53) Some of you might recall the tale I told in RISKS-21.53 (published 19 Jul 2001) of problems with my bank's upgrade of their computer systems in June. Unfortunately, although it's almost five months later, the situation still hasn't improved. The bank still hasn't acknowledged that most of the problems I reported haven't been fixed. Most significantly, they still haven't admitted that they miscalculated interest on some accounts during the month of June, explained how the error occurred, explained how many accounts were affected, or fixed the error in the affected accounts. I finally gave up on waiting for them to do the right thing as a result of only my inquiries. I've therefore contacted the local newspapers, the Massachusetts Division of Banks, and the FDIC and asked them to investigate. I've also put the whole story on-line at <URL:http://www.mit.edu/~jik/pfsb_problem/>. If you are interested in continuing to follow this story, please periodically check the above URL for updates (or you can let me know you're interested and I'll send you E-mail when there's new news). I will refrain from submitting any further articles to RISKS about this unless either (a) the bank actually does something substantive to address the interest miscalculation or (b) they prove that I'm wrong about it, in which case I'll submit a retraction :-). Jonathan Kamens ------------------------------ 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 e-mail requests to <risks-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_private . [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 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.82 ************************
This archive was generated by hypermail 2b30 : Fri Dec 14 2001 - 16:36:34 PST