RISKS-LIST: Risks-Forum Digest Tuesday 5 March 2002 Volume 21 : Issue 93 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.93.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Malfunction shuts down computer-controlled amusement park ride (Chuck Hardin) A$ 22,000 in fines for missing car-toll transponder (Peter Trei) Air Transat emergency landing (John Johnson) Nick Petreley: Identity theft (Anthony W. Youngman) Metro: Time runs out for Domesday discs (Chris Leeson) RISKS to computers from society (Arthur J. Byrnes) Corporate Web sites leave cold steely feeling (Dan Jacobson) Tunneling too close to the person you're trying to protect: SafeWeb (David Martin) Privacy risk in Netscape 6 (Sim IJskes) Electronic Voting in Ireland (Peter Thornton) Re: Miami-Dade OKs touchscreen voting (Les Barstow, Mark Nelson) Re: The homograph problem (Partha) Re: Dangerous Characters (Dick Botting, Darrell Fuhriman, Bill McGonigle) REVIEW: "Security Fundamentals for E-Commerce", Vesna Hassler (Rob Slade) Abridged info on RISKS (comp.risks) --------------------------------------------------------------------- Date: Sat, 02 Mar 2002 08:57:38 -0600 From: Chuck Hardin <chardinat_private> Subject: Malfunction shuts down computer-controlled amusement park ride http://news.bbc.co.uk/hi/english/uk/england/newsid_1850000/1850592.stm It was a perfect day in the capital for viewing the skyline from the giant London Eye. But a computer problem made the 450-ft-high structure rotate too fast, and it was halted amid safety fears. Engineers have been brought in to get the attraction, officially known as the British Airways London Eye, up and running again. This calls to mind Ben Morphett's narrative in RISKS-21.50 about a carnival ride which gave him a bad moment by displaying a blue screen of death just before it began its (planned?) rapid descent. The difference is that in his case, the computer was merely providing some graphical effects and was not apparently responsible for controlling the ride. Not so in this case. Four hundred and fifty feet is a long way to fall, or to be hurled, due to an ill-considered RISK. ------------------------------ Date: Tue, 26 Feb 2002 15:20:10 -0500 From: "Trei, Peter" <ptreiat_private> Subject: A$ 22,000 in fines for missing car-toll transponder A man used City Link more than 220 times without an e-tag, attracting at least $22,000 in fines, because he did not know it had become a toll road, the Melbourne Magistrates Court was told yesterday. [...] http://theage.com.au/articles/2002/02/26/1014704951335.html Some highways in Australia cannot be legally used without a radio tag. This poor soul hadn't updated his address with the DMV. The RISK lies in building systems which automatically rack up charges without limit, and no backup notification system. A big flashing sign saying 'E-Tag missing!' might have helped. Peter Trei ------------------------------ Date: Mon, 4 Mar 2002 15:36:27 -0500 From: john.johnsonat_private Subject: Air Transat emergency landing I thought RISKS readers would be interested in a developing story in the news about a computer problem on the Canadian Air Transat flight that made an emergency landing in the Azores last summer. Apparently, as early reports describe, a "computer program" incorrectly reported a fuel leak as an "imbalance". To correct the "imbalance" the "computer program" diverted fuel from a good tank to the tank that was leaking thus both tanks were emptied. Inflight. The skill of the pilot and the availability of an island with an airport in the Atlantic Ocean averted a disaster. Source: Canadian Press, *Toronto Globe and Mail*, *Toronto Star*, & other Canadian newspapers ------------------------------ Date: Thu, 21 Feb 2002 13:05:11 -0000 From: "Anthony W. Youngman" <Anthony.Youngman@ECA-International.com> Subject: Nick Petreley: Identity theft http://www.computerworld.com/cwi/story/0,1199,NAV47-74_STO68446,00.html Nick Petreley's *Computerworld* column (18 Feb 2002) describes how some unknown person hijacked his phone account and made loads of long-distance calls "at his expense". The saga goes from bad to worse as poor security and company incompetence frustrates his attempts to stop the fraud. [After noticing the frequent calls to Germany, Nick canceled his calling card and switched his long-distance carrier. The person who had been piggybacking on his old card then managed to switch his new account back to the old carrier and make more calls. It turns out that person had created a Web account for him, so that he no longer received statements. The entire saga is a real horror story, and very well worth reading. Lots of lessons to be learned. PGN] ------------------------------ Date: Mon, 4 Mar 2002 09:51:50 -0000 From: "LEESON, Chris" <CHRIS.LEESONat_private> Subject: Metro: Time runs out for Domesday discs The BBC's 1986 Domesday Project (a time capsule containing sound, images, video and data defining life in Britain) is now unreadable. The data was stored on 12-inch video discs that were only readable by the BBC Micro, of which only a handful still exist. The time capsule contains "250,000 place names, 25,000 maps, 50,000 pictures, 3,000 data sets and 60 minutes of moving pictures.". The article notes that the original Domesday Book (compiled in 1086 for tax purposes) is still in "mint condition". [Source: London *Metro*, 01 Mar 2002] Additional comments of my own: The BBC Micro, along with the original Sinclair Computers, was the computer that sparked off the "computer revolution" in the UK. The BBC Micro was especially popular in schools, whereas the Sinclair computers were more popular in the home. To be fair, the 1986 Domesday Project was in the days before the really rapid changes in technology came into force - the BBC Micro was not a bad choice of platform then, especially when you consider that there were very few other choices available (50,000 pictures alone take up a lot of space). Moral/Risk: If you are wanting long-term data storage, the format is just as important as the materials. This is not a new problem - It has appeared in Risks before (RISKS-21.56: 'NASA data from 1970s lost due to "forgotten" file format' for one...), but is worth keeping in mind. I still have an old Commodore 64/128 disk with my (very) old account details on it - not that I have a C64/128 any more. My permanent records, however, are the printouts. PS: "Domed... We are all Doomed..." ------------------------------ Date: Sat, 23 Feb 2002 20:53:21 -0500 From: "Arthur J. Byrnes" <arthurat_private> Subject: RISKS to computers from society Reading the various articles about buffer overflow and WiFi security problems, makes you think that Society has to worry about risks from computers. Then I have two incidents in one week that remind me that computers are the ones at risk. First a I get a misdirected plain-text e-mail from a major insurance company with login IDs, passwords, and usage instructions, (that seemed to come from one of those "Dummies" books). As much as my curiosity wanted to try them out, my ethics stopped me. A note to the company got an auto reply, no thanks, or inquiry about how/why I ended up with this seemingly important e-mail. Then later in the week I added a new Web site to my Microsoft Central account. The welcome plain-text e-mail contained my login name and password, which is also my .Net login. They made clients sign up for .Net in order to continue using their service. (I'm glad I don't use it for anything else!) Two major companies that should have known better, put Society's computers at Risk, with a practice that is unpardonable. Never send login IDs and passwords together... Arthur J. Byrnes http://www.ajb.com ------------------------------ Date: 28 Feb 2002 03:56:16 +0800 From: Dan Jacobson <jidanniat_private> Subject: Corporate Web sites leave cold steely feeling Now that I have traded my corporate life for "back to nature", every once in a while there is a long term bond from my past life or something that is about to expire, hence I must log on to some corporate site, wherein right off the bat: Browser Upgrade Thank you for visiting Jackson National Life Insurance Company's Web site. We have noticed you are using an earlier version of null. Also, aren't those little lock symbols supposed to lock when asking for SS#, passwd, etc.? And don't you hate those Web sites that after filling in a long form, you are to pick which of the 50 states you live in... I get stuck here. I would have used the toll free phone # but it is not toll free for me. OK, now turning to the AT&T Universal card site... Ah, AT&T, equal opportunity employer... OK, but still, cant use the Lynx browser... what if I was vision impaired? And, why after establishing that I am not spam, cannot I have an e-mail conversation with these corporate giants about compatibility issues with their Web sites without having to "login to send/receive secure e-mail"... takes half of my modem session. http://www.geocities.com/jidanni/ Taiwan(04)25854780 ------------------------------ Date: Thu, 14 Feb 2002 16:50:52 -0500 From: "David Martin" <dmat_private> Subject: Tunneling too close to the person you're trying to protect: SafeWeb A tunnel is the prototypical example of a security mechanism that doesn't compose well: it creates an end-to-end connection that can bypass intermediate scrutiny. SafeWeb, the Web anonymizing service, fell into this trap by attaching the browser end of its tunnel too closely to the user and thereby bypassing meaningful browser protections. The result is that users of the service are at higher risk of some types of privacy attacks than those who refrain from using the service. Note that SafeWeb's anonymizing service was shut down in December for business reasons. However, its technology was licensed to In-Q-Tel (the venture capital firm funded by the CIA) and PrivaSec LLC. PrivaSec is currently offering a public beta test of its service based on SafeWeb's technology at its Web site http://www.privasec.com. For simplicity, we'll pretend the system is still running at safeweb.com in the rest of this article. First a quick SafeWeb overview: a SafeWeb user types in a URL. It goes to safeweb.com within an SSL connection; SafeWeb sanitizes the requested content and delivers it back to the browser. The origin server Web site only sees a connection from safeweb.com, and eavesdroppers near the user only see an encrypted connection to safeweb.com On-screen, SafeWeb uses frames to separate the SafeWeb controls from the requested content. Let's call them the "control" and "content" frames. Now let's meet the protections: (1) simultaneously open windows or frames can only communicate with each other if they're from the same domain, (2) scripts stop running when a new page is displayed, and (3) cookies are available only to the domain that set them. The problem is that both of SafeWeb's frames are served from the same tunnel (https://www.safeweb.com/) even though their content comes from radically different sources: the trusted SafeWeb site on the one hand, and the untrusted third party site on the other. Since both frames come from the same domain, the Web browser exposes each Document Object Model to the other: protection #1 is gone. Since the control frame is basically static, it's a great place for an attacker to tuck away any code that needs to persist throughout the browsing session -- like spyware. So protection #2 is gone too. SafeWeb also wanted to support pseudonymous persistent cookies. Since the content frame is always associated with a single privacy domain, they aggregated all of the pseudonymous cookies from sites a user might visit through SafeWeb into one "master cookie" associated with the fixed domain safeweb.com. That way, the individual cookies all get stored on the user's computer in a slightly different form, and SafeWeb doesn't have to maintain any persistent state on their servers (and users don't have to log in to SafeWeb, etc.). But this approach discards protection #3 as well. To exploit these lost protections, an attacker has to take control of one of the frames: the content frame is the obvious choice. That turns out to be not too hard. SafeWeb *requires* that JavaScript be enabled in the browser. Recognizing the risk, SafeWeb tried to sanitize scripts delivered to the content frame, but they didn't go nearly far enough. The result? By choosing to use this privacy enhancing system, users become vulnerable to having their IP address revealed, *all* of their cookies stolen, and the remainder of their privacy-"enhanced" browsing session silently transmitted to an attacker in spite of the layer of SSL protection. This is not speculation; we have tested several effective exploits against the system. Discarding protection mechanisms is only justified if those protections are replaced by something stronger, or by something more valuable to the end users. SafeWeb's system did keep its users' identities out of routinely gathered Web server logs. But the cost was increased vulnerability to targeted attacks, and it's hard to say whether the system's users would consider this a good tradeoff. There's no reason to think they would be aware of the tradeoff at all. Adding to the weirdness, we are told that this privacy enhancing service was subjected to a "stringent" technological review by the CIA. Details (24 pages, PDF) are available at http://www.cs.bu.edu/techreports/pdf/2002-003-deanonymizing-safeweb.pdf. In response to our observations, SafeWeb points out that their own service is no longer in operation, that their new products didn't inherit these problems, that the system was effective at resisting passive attacks, and that the adversaries they had in mind wouldn't have been willing to use attacks such as ours for fear of bad publicity. They have also announced that they are developing a fix for their licensees, In-Q-Tel and PrivaSec. David Martin -- dmat_private Andrew Schulman -- undocat_private ------------------------------ Date: Thu, 21 Feb 2002 21:05:43 +0100 From: Sim IJskes <simat_private> Subject: Privacy risk in Netscape 6 I just installed the Netscape browser version 6.2. I changed 'Internet search' options so that Netscape performed searches through Google instead of the Netscape search engine. Some browsing in the files that were installed led me to this line: action="http://info.netscape.com/fwd/lksidus_gg/http://www.google.com/search" in a file "SBWeb_02.src". It looked as if Google directed search requests are first sent to info.netscape.com. A quick look in the proxy server log on the server confirmed my suspicion. I guess that Netscape allows you to search other search engines than their own, but still wants to know what you are searching.... P.S. a similar mechanism was also used in the 'SmartDownload manager' some years ago, as i seem to remember (maybe still is). Sim IJskes, Leiderdorp, The Netherlands | simat_private ------------------------------ Date: Mon, 25 Feb 2002 14:48:22 -0000 From: "Peter Thornton" <Peter.Thornton@emr-radio.ie> Subject: Electronic Voting in Ireland Further to recent contributions on electronic voting, this is from the Web site of the Irish department of the environment: http://www.environ.ie/press/electvote02.html The "forthcoming general election" they refer to will be taking place in the next three months. I note that they will be using "an industry standard PC system". I presume that this means a Wintel box. Green Light For Electronic Voting In Dublin North, Dublin West And Meath Mr Noel Dempsey TD, Minister for the Environment and Local Government has announced today (19 February) that the constituencies of Dublin North, Dublin West and Meath have been chosen as the pilot constituencies for the introduction of electronic voting. "Subject to final testing of software, my intention is that the voters in Dublin North, Dublin West and Meath will be the first in the country to cast their ballots electronically. Thus, the forthcoming General Election should usher in a new age of efficiency in the voting process," said Minister Dempsey. "Electronic voting will dramatically speed up the counting process with results for the constituencies likely to be available within a half an hour of the final module, on which the cast votes are stored, being delivered to the counting centres." The electronic voting system to be used has been developed by the Dutch/UK company, Nedap/Powervote. The Nedap/Powervote solution will provide a 'fullface' (large screen) machine which is successfully used in the Netherlands and in the German cities of Cologne and Dusseldorf. Election preparation will be run from an industry-standard PC system and the completion of the count will also be carried out on a standard PC and programming unit. In the run up to the introduction of electronic voting, there will be an intensive public information campaign in the constituencies concerned to ensure that all voters will be familiar with the new method of voting. Peter Thornton, EMR Radio & Telemetry, Unit 11 Dunboyne Business Park Dunboyne Co. Meath Tel: +353-1-8013161 ------------------------------ Date: Thu, 21 Feb 2002 07:03:28 -0700 From: Les Barstow <lbarstowat_private> Subject: Re: Miami-Dade OKs touchscreen voting (Price/PGN, RISKS-21.90) With physical access to voting machines and/or the software used to control them, the only sure way to provide security is a paper record. Especially with OpenSource software, it becomes possible to recompile (and hence alter) any electronic-only record. Closed Source software isn't any better - it lacks public accountability and scrutiny. Someone could always create a new ROM, OS, or software image if given sufficient knowledge, bypassing any security system that has been put in place. So: Print an OCR paper record when the voter finishes his vote. He gets to check the paper copy and put it in a standard secured voting box. The best parts are: (a) Since it's printed on demand, only the voter's candidate appears on the printout - the voter sees only who or what he voted for, or that he made no vote, and can easily check the paper before dropping it in the box. (b) Using OCR, independent auditing becomes easy. The auditor needs little in the way of custom hardware or software to do the job; they only need to tweak their OCR readers. Auditors could be chosen by mutual agreement of the candidates after the vote is completed (and only if a candidate determines he wants to have a recount), removing any temptation to bribe the auditing firm. Les Barstow, System Administrator, VR1, Inc. http://www.vr1.com lbarstowat_private [We've been talking about such schemes before here. See Rebecca Mercuri's PhD thesis for a detailed analysis: http://www.notablesoftware.com/~evote noted in RISKS-21.10,13,14,61. PGN] ------------------------------ Date: Fri, 22 Feb 2002 15:56:57 -0500 From: Mark Nelson <mcnels1at_private> Subject: Re: Miami-Dade OKs touchscreen voting (Brain, RISKS-21.92) > The risks for vote-rigging on COTS systems [include]: e) Someone tweaks the compiler of the compiler of the compiler of the... See Ken Thompson's "Reflections on Trusting Trust" http://www.acm.org/classics/sep95/ ------------------------------ Date: Thu, 28 Feb 2002 19:16:12 +0530 From: Partha <algologat_private> Subject: Re: The homograph problem (RISKS-21.91 and 92) I am a victim of one such problem. Our Indian bureaucrats in the Govt. owned ISP called VSNL decided to create domain names using a mixture of alphas and Arabic numerals. Resultant: I have an e-mail address containing a "one". It is impossible to make out the "one" from "lower case L", and as result of which I lose many many e-mails destined for me. I have mitigated the problem to a certain extent, by adding a descriptive note in my signature box, but it is impossible to print such things on my visiting cards. Notice that there is also a "lower case L" in the second field of my domain name "v-s-n-L". We (Indians) are perhaps the only ones in the world to have such confusing combinations of alphas and numerals in their domain names. When will we ever learn? PS: VSNL has now been "privatised". They changed the owners but they kept the brilliant employees who created this mad domain name. Dr. S. Parthasarathy, Algologic Research & Solutions, 78 Sancharpuri Colony, Bowenpally, Secunderabad 500 011 - INDIA Phone: + 91 - 40 - 775 1650 ------------------------------ Date: Thu, 21 Feb 2002 13:41:31 -0800 From: Dick Botting <rbottingat_private> Subject: Re: Dangerous Characters (Lomas, RISKS-21.92) This looks like the "sanitization" procedures for user supplied data that is recommended for the Perl language. Perl is used by many Webmeisters. Typically, it has to call other programs and uses a "shell escape" to do so. On UNIX boxes it does this in such a way that the shell interprets the passed data as a command. An apostrophe is a string delimiter and so a stray blip can play havoc with string data... A smart user can easily make the server execute any command. Hence User data is sanitized by removing certain characters. Another solution is to avoid Perl. Scripts written in Bourne/Korn/Born Again SHell do not have this problem. Care is still needed, but the removal of the usual suspect characters is not necessary. ------------------------------ Date: 21 Feb 2002 13:49:09 -0800 From: Darrell Fuhriman <darrellat_private> Subject: Re: Dangerous characters (Lomas, RISKS-21.92) I regularly have perfectly valid e-mail addresses rejected by Web forms because they contain a '+' sign. Most Web sites seem to assume that anything not in the set [A-Za-z1-9_-] is invalid, even though the valid set defined in RFC 2822 is much larger than that. I wonder what's going to happen when, inevitably, e-mail addresses are allowed to be in Unicode. I fully suspect that we'll suddenly find a large portion of the population unable to use their nifty new language appropriate addresses. ------------------------------ Date: Thu, 21 Feb 2002 11:46:48 -0500 From: Bill McGonigle <mcgonigleat_private> Subject: Re: Dangerous characters (Lomas, RISKS-21.92) Probably Waitrose is storing their orders in a SQL database. In most SQL statements, apostrophes need to be escaped, typically as '' (that's two single quotes). I've met so-called Web-site programmers to whom the notion of an escape character suggests something out of a prison-break movie. Often they notice a problem, with the database of course, when trying to store text with an apostrophe, so they put some 'error checking' code in to prevent those errors. ------------------------------ Date: Mon, 4 Mar 2002 07:44:27 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Security Fundamentals for E-Commerce", Vesna Hassler BKSCFUEC.RVW 20020108 "Security Fundamentals for E-Commerce", Vesna Hassler, 2001, 1-58053-108-3, U$83.00 %A Vesna Hassler hasslerat_private %C 685 Canton St., Norwood, MA 02062 %D 2001 %G 1-58053-108-3 %I Artech House/Horizon %O U$83.00 800-225-9977 fax: 617-769-6334 artech@artech-house.com %P 409 p. %T "Security Fundamentals for E-Commerce" "The purpose of this book is to give an in-depth overview of all the basic security problems and solutions that can be relevant for an e-commerce application." I'm sorry, but "in-depth overview" sounds a bit like "jumbo shrimp": it's an oxymoron. And "all the basic security problems and solutions that can be relevant for an e-commerce application" covers a lot of ground. (Which is, I suppose, why this text has twenty two chapters.) Part one explains the basics of information security. Chapter one defines some of the basic jargon, but misses a number of the important fundamental terms. For example, the relationship between threats, vulnerabilities and exploits is fairly basic to security and risk analysis, and yet all security problems seem to be lumped together as threats. The examination of security mechanisms, in chapter two, is limited to cryptography. Key management is restricted to X.509 certificates and Diffie-Hellman in chapter three. Part two looks specifically at security of electronic payment systems. Chapter four briefly lists a wide variety of payment systems. A terse set of payment security problems is given in chapter five, while some seemingly random cryptographic solutions are given in six. A little bit of math for functions directed at electronic cash and cheques is presented in chapters seven and eight, respectively. Chapter nine describes the Internet Open Trading Protocol. Part three deals with communications security. Chapter ten is a general look at networking. Chapters eleven to fourteen examine different systems for security at different layers, but the depth of coverage is very inconsistent: extremely terse in some cases, with many gaps, and yet delving into minute detail in others. Part four examines Web security. Chapter fifteen details the HyperText Transfer Protocol (HTTP), which is good, since few texts bother to do. Random topics related to Web servers make up chapter sixteen. Web client security topics are dealt with somewhat better in chapter seventeen, although cookies aren't given any significant discussion. Active content does get its own chapter: eighteen concentrates almost exclusively on Java. Chapter nineteen contains miscellaneous topics. Part five covers some special issues for mobile or agent computing. Agent technology is described in chapter twenty, some cellular phone topics are reviewed in twenty one, and smart card security is discussed in twenty two. Well, overview it is. The book does cover a variety of topics, although there are a great many gaps and holes. However, "in-depth" can't be supported, except in a very few cases. There are some topics that are discussed in excruciating detail, but they are definitely in the minority. As a college text this undoubtedly has its uses, but professionals or businesspeople will find the inconsistent coverage problematic. copyright Robert M. Slade, 2002 BKSCFUEC.RVW 20020108 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 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.93 ************************
This archive was generated by hypermail 2b30 : Tue Mar 05 2002 - 17:07:50 PST