precedence: bulk Subject: RISKS DIGEST 19.58 RISKS-LIST: Risks-Forum Digest Friday 30 January 1998 Volume 19 : Issue 58 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. ***** Contents: Man jailed because of computer glitch (Bear Giles) False identification of child support deadbeats (Epstein Family) Y2K bug at major bank? (Andrew Walduck) Dangerous handling of null variables in programs (Mike Jeays) Internet Explorer flaw (Joseph Bergin) Location tracing service of handy phones starts in Tokyo (Kenji Rikitake) EuroParl Rpt on NSA, Trade, & Crypto Controls (Vin McLellan) Crash of A-320, Strasbourg (Alexandre Siniakov) Re: TCAS near-miss (Nancy Leveson) Re: robots.txt (Bertrand Meyer) 4-Letter words, Re: CyberSitter (Devon McCormick) Re: Possible Netscape source code risks (Dale Martin) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 28 Jan 98 16:45:42 MST From: Bear Giles Subject: Man jailed because of computer glitch >From "Glitches of the Week", http://www.currents.net/newstoday/98/01/27/news1.html >Man Jailed Because of Computer Glitch > Tony Ninness of Agnes Waters, Australia, was jailed for six hours for > failing to pay a traffic fine, even though it turned out he had paid the > fine five years ago. Last month, police came to Ninness' residence with > outstanding warrants for his arrest. He was held in custody at the Agnes > Waters police station until the friend paid the police $1350. The next > day, courthouse staff confirmed that Ninness had indeed paid off the fine > long ago, and issued him a refund check. But then the police contacted > him and said they had issued too large a refund, and said he would be > jailed again unless he returned $114.60. "It sounds like a load of > rubbish to me," Ninness told the Sunday Mail newspaper. "Why should I pay > it? It's not my fault." Police officials blamed computer glitches for > the problems. Unfortunately, the article doesn't make it clear if the "excess amount" was on top of what the friend paid in "outstanding" fines, or if the check was for $1350 and the police demanded incarceration charges similar to those becoming common in the United States. Bear Giles bear@coyotesong.com ------------------------------ Date: Thu, 29 Jan 1998 21:12:12 -0500 From: Epstein Family Subject: False identification of child support deadbeats *The Washington Post* (29 Jan 1998) reports that the state of Virginia has been cracking down on noncustodial parents who have fallen behind on child support payments. About 15,000 people have paid $15 million. But 2300 other people were incorrectly identified as delinquent and were sent notices revoking any hunting and fishing licenses they have. The incorrect notices were caused by "a computer programming error". The state official responsible for child support apologized and said that safeguards have been put in place to avoid it happening again. ------------------------------ Date: 27 Jan 1998 17:48 EST From: "Andrew Walduck" Subject: Y2K bug at major bank? I'm having an interesting encounter with one of the major Canadian banks right now over RRSP (registered retirement savings plan) receipts. It smells vaguely Y2K-ish. Here's the scenario. In August of 1997, I purchased 11 $1000 GICs (guaranteed investment certificates) laddered at 4 months increments with the farthest out one coming due in 5 years (or 2002-09), the earliest would come due in 1 year, 8 months (1999-05) (the actual maturities are 1999 5, 1999 9, 2000 1, 2000 5, 2000 9, 2001 1, 2001 5, 2001 9, 2002 1, 2002 5, 2002 9). In December, I received a receipt for $2000. The bank usually accumulates up all of your contributions for the year and then sends one receipt. In my case, I should have received a receipt for $11,000. I thought this strange, so I phoned their call center and was told that a receipt for the rest of the amount would be coming. So I made a note in my daytimer, and let it sleep. So today (end of January, 1998) I phoned my branch and talked to a rep I know there about my account. She checks the records and they show that I was to receive only a $2000 receipt (not $11,000), although, there are 11 different GICs in my account all purchased in August! Fortunately, I still have the temporary, no good for taxes, receipt. So now she's investigating and I did some thinking. Of the 11 GICs I purchased, 2 came due before 2000, (in 1999 5 and 1999 9), the rest came due in (2000 1, 2000 5, 2000 9, 2001 1, 2001 5, 2001 9, 2002 1, 2002 5, 2002 9). Hmm... $2000 receipt... for the ones maturing before 2000? Where did the receipt for the rest go?? ;-) The hypothesis: If you buy a GIC that matures after 2000-1-1, the receipt program breaks, and ignores the amount. You don't get a receipt mailed to you. Has anyone else had this experience with a Canadian bank? Andrew Walduck ------------------------------ Date: Wed, 28 Jan 1998 09:26:00 -0500 From: "Jeays, Mike" Subject: Dangerous handling of null variables in programs The treatment of null values is arguably reasonable once it is understood - null values simply fail all comparisons with non-null variables. This means that if you ask if x(null) < y(non-null), you will be told "no". The same thing will happen if you change the operator to ">". Not too bad so far. However - I found the result of "<>" deceptive. It fooled me into writing a statement that did the exact opposite of what I expected. Behaviour like this in a language is dangerous, because many people will fall into the trap, and some of them will bring down national telephone systems. The following code snippets are NOT equivalent: if x=b then print "Equal" else print "Not equal" endif and if x<>b then print "Not equal" else print "Equal" endif The latter is perverse and non-intuitive. It says the two variables are equal when one of them is null and the other isn't. Think very carefully when you use the "<>" operator! ------------------------------ Date: Wed, 28 Jan 1998 07:32:02 -0800 (PST) From: "Joseph Bergin" Subject: Internet Explorer flaw It seems MS/IE makes it easy to steal private keys: Microsoft Product Flaws Make Net Dangerous, Experts Say By Douglas Hayward, TechWeb (23 Jan 1998) Joseph Bergin, Professor, Pace University, Computer Science, One Pace Plaza, NY NY 10038 berginf@pace.edu http://csis.pace.edu/~bergin/ [The beginning of the text is excerpted below by PGN Stark Abstracting:] Flaws in the security of Microsoft's Internet products allow malicious hackers to steal users' private encryption keys and impersonate their victims, security experts said. [...] A security advisory note circulated this week by Peter Gutmann, a security expert in New Zealand, said that private encryption keys can easily be stolen from the hard disks of machines whose users are surfing the Web, thanks to flaws in several Microsoft products, including the Internet Explorer browser and the Internet Information Server package. "I would say it was a fairly important security flaw," Gutmann told TechWeb. "At the moment there is no defense against the problem." ------------------------------ Date: Thu, 29 Jan 1998 20:38:20 +0900 (JST) From: Kenji Rikitake Subject: Location tracing service of handy phones starts in Tokyo On 20 Jan 1998, NTT Central Personal Communication Network Inc. announced an experimental service of providing the estimated location of a PHS (Personal Handy-phone System) terminal through a FAX machine. The service will be provided in Tokyo from February to April. The location information is accessible by any FAX machine with the phone number and the access PIN of the PHS terminal. The information is given by a circle on a map, with the radius of 100 to 500 meters (or 328 to 1640 feet) range. The company has been field-testing the service since July 1997, and will provide the same kind of experimental service for The coming Nagano Olympic Games too. The risk is quite obvious; anyone who has a PHS terminal is technically traceable, without the consent or knowledge of the owner. I found a similar service was being developed by British Telecom too[1]. PHS is quite popular in Japan. The number of PHS service subscriber in Japan was 6,992,000 as of December 31, 1997, according to the report of Telecommunications Carriers Association[2]. References: [1] "Spy phones trace cheating husbands -- and employees", RISKS Forum 19:35. [2] http://www.teleserve.co.jp/tca/whatn/whatn_e.html Kenji Rikitake ------------------------------ Date: Wed, 28 Jan 1998 03:30:35 -0500 From: Vin McLellan < Subject: EuroParl Rpt on NSA, Trade, & Crypto Controls A draft ("consultation version") of a report by the European Parliament's Office for Scientific and Technological Option Assessment (STOA) entitled "AN APPRAISAL OF TECHNOLOGIES OF POLITICAL CONTROL" has been submitted to the EuroParl's Civil Liberties and Interior Committee. Several IT-relevant excerpts are now available at John Young's widely respected crypto-politics website: < (STOA regs apparently require a document to be distributed only on paper while it is a "working document." Quaint, huh? A hardcopy can be ordered by e-mail from the office of British MEP Glyn Ford < or with a fax to STOA in Luxembourg.) According to Mr. Young's correspondents, the report covers: - The Role & Function of Political Control Technologies - Recent Trends and Innovations - Developments in Surveillance Technologies - Innovations in Crowd Control Weapons - New Prison Control Systems - Interrogation, Torture Techniques and Technologies - Regulation of Horizontal Proliferation - Further Research As expected, a portion of the report highlights the NSA's Echelon surveillance system, developed and managed in conjunction with its sister SigIntel agencies from the UK, Australia, New Zealand, and Canada. Snippets quoted give the flavor, capturing the tenor of fear common in European media references to the NSA: "[...] unlike many of the electronic spy systems developed during the cold war, ECHELON is designed for primarily non- military targets: governments, organizations and businesses in virtually every country. The ECHELON system works by indiscriminately intercepting very large quantities of communications and then siphoning out what is valuable using artificial intelligence aids like Memex to find key words." "[...] Within Europe, all e-mail, telephone and fax communications are routinely intercepted by the United States National Security Agency, transferring all target information from the European mainland via the strategic hub of London then by satellite to Fort Meade in Maryland via the crucial hub at Menwith Hill in the North York Moors of the UK." The priority targets of this surveillance system are selected by the participating intelligence agencies -- only one of which is European -- on the basis of their individual military and political interests, notes STOA. "Whilst there is much information gathered about potential terrorists, there is a lot of economic intelligence, notably intensive monitoring of all the countries participating in the GATT negotiations...." The report seems to briefly summarize a wealth of earlier reports on the Echelon network, notably from Bamford and Hager, but offers no apparent evidence of an independent inquiry. The report nevertheless suggests that these intelligence agencies have become a law unto themselves, and operate in a context where most presumably-private communications are effectively transparent and accessible to them. "With no system of accountability, it is difficult to discover what criteria determine who is not a target," the STOA adds in a dry summary. STOA recommends a new European Parliament study of the "constitutional issues" raised by the American eavesdropping practices, and of the impact of Echelon upon (a) the "constitutional safeguards" of the individual European states, and (b) "the political, cultural and economic autonomy" of EU's nation states. The report also recommends that the European Parliament should address and explicitly reject "proposals from the United States for making private messages via the global communications network (Internet) accessible to US Intelligence Agencies. "Nor," warns STOA, "should the Parliament agree to new expensive encryption controls without a wide ranging debate within the EU on the implications of such measures." The "implications" of these proposed controls over free access to strong cryptography, declares STOA, "encompass the civil and human rights of European citizens and the commercial rights of companies to operate within the law, without unwarranted surveillance by intelligence agencies operating in conjunction with multinational competitors..." That last phrase -- with its explicit reference to the commercial intelligence which can be gleaned from electronic surveillance (and the value of such data to "multinational" corporations aligned with each of the intelligence agencies cooperating in Echelon) -- lies in the dense gray text of the report like an unlit fuse. One of the inevitable problems for a nation which fosters both intelligence prowess and commercial prowess is that success in the former can undermine the legitimacy of whatever success it achieves in commerce and industry. International finance and trade rely, in some measure, upon a general acceptance that the terms of such trade are overt, if not necessarily "fair." Without that minimal trust, the successful competitor is viewed not with respect, or even jealousy; but with scorn and bitterness. Commercial failures will inevitably attribute their losses not to the skill or ingenuity of their international competitors, but rather to the competence and bias of the mysterious cyberspooks who, all acknowledge, probably watched the deal unfold. The MEPs wouldn't be European if they didn't consider the possibility of that sort of frustration fueling a backlash against the European Union and EU governments which appear either unable or unwilling to protect the integrity of their economic infrastructure. Americans worry about future InfoWar: the corruption of the American economic infrastructure by tech-savvy foreigners. A Presidential Commission studies the threat today, and generates headlines by the ream. Europeans might fairly ask if they are not already the victims of such malevolent prowess. And what guarantees could they be offered that this is not the case? "Cryptography is like literacy in the Dark Ages. Infinitely potent, for good and ill... yet basically an intellectual construct, an idea, which by its nature will resist efforts to restrict it to bureaucrats and others who deem only themselves worthy of such Privilege." _ A thinking man's Creed for Crypto/ vbm. Vin McLellan + The Privacy Guild + < 53 Nichols St., Chelsea, MA 02150 USA <<617> 884-5548 ------------------------------ Date: Fri, 23 Jan 1998 20:38:24 +0300 From: "SINIAKOV ALEXANDRE" Subject: Crash of A-320, Strasbourg About the cause of air accidents and crashes of * Boeing-747, Flight 826, 28 Dec 1997 (Tokyo-Honolulu) * A-320, 20 Jan 1992 (Mont Saint-Odile, France) * A-310, 22 Mar 1994 (Novokuznetsk, Russia) * Tu-154, 6 Dec 1995 (Habarovsk, Russia) Computer researches show,that Local Geophysical Resonance was primary cause of these air accidents (B-747) and crashes (A-320, A-310, Tu-154). This is a previously unrecognized natural phenomenon, connected with the resonance characteristics of both the solar system and outer space. LGR arises from the interaction of the planets of the solar system and is a cause of an excitement of space-local sones. In such cases natural and technical catastrophes take place. Specifically, under certain conditions at a moment of LGR, aircraft flight-safety-critical whirlwinds (tornados) arise. The whirlwinds are the common cause of these incidents. ------------------------------ Date: Wed, 28 Jan 1998 06:11:30 -0800 From: Nancy Leveson Subject: Re: TCAS near-miss (Bellovin, RISKS-19.55) > ... Someone on the ground switched on a transponder; the TCAS system on > the plane overhead decided that an aircraft had suddenly appeared 3000 > below it, and suggested that the pilot climb. This didn't make any sense to me. TCAS recognizes transponders on the ground and ignores them. It also only issues alerts near the ground when an aircraft is within 750 feet (not 3000) and even at high altitudes the max is 950. As usual, what you see on the net has been garbled. The FAA is still investigating, but apparently the radar data shows that the actual separation between the two aircraft was much greater than reported by the media (in fact, the media has exaggerated the whole event). What seems to have happened is that a maintenance shop on the ground was testing the altitude reporting capability of the transponder and the transponder was reporting an altitude above ground level. The FAA has guidance to perform such tests with the transponder antenna shielded so that these events will not occur. They are still investigating why the shielding did not occur. Where the media got the number "3000 feet below it" is unknown but was probably a garbling of the Southwest Airlines plane's climb rate of 3000 feet per minute. [It would indeed be helpful if would-be RISKS contributions gave specific sources of information. To satisfy that desideratum in this case, I note that Nancy's information comes from the head of the TCAS program at the FAA and the AIRINC investigation report of the incident. PGN] ------------------------------ Date: Fri, 30 Jan 98 00:23:26 PST From: bertrand@eiffel.com (Bertrand Meyer) Subject: Re: robots.txt (Meyer, RISKS-19.57) I have received a flurry of responses to my article describing the risks associated with the `robots.txt' convention for excluding search engines from indexing parts of a Web site. I apologize for not responding individually to all the people who wrote to me. I have put, however, all the answers in a Web page, for the benefit of anyone who cares to consult them: http://www.eiffel.com/private/meyer/robots.html (available Saturday, Jan 31st, 18:00 California time). The common theme of the answers can be summarized as follows: I was wrong to criticize the robots.txt design because it is not meant to protect pages, simply to keep search engines away from pages that are not *worth* indexing, e.g. because they are of temporary values. To quote one correspondent, Osma Ahvenlampi : > Robots.txt is a way to protect your web server from being overloaded by a > dumb robot in a cgi loop, not a security tool. This much should be obvious > to anyone capable to be in charge of web site administration. or, according to Chris Cheyney : > Anyone stupid enough to leave a network open and count on the optional > robots.txt robot exclusion de-facto standard for security gets (and should > get) what he deserves. Among the people making similar points: Thomas Andrews , Nelson Minar , John R. Levine , Jeremy Nelson , Barry Margolin , Laurentiu Badea , Klaus Johannes Rusch . Again, see the Web page for the details of their comments. I stand by my original assessment: 1. If every facility was always used as its designers intended, the RISKS archives would be noticeably slimmer. Here the possibility of misuse seems rather considerable. If you are just a bit absent-minded, isn't it natural to use this mechanism to exclude stuff from being indexed and hence believe no one will find it? "Stupid", maybe -- but not unlikely. After all, the designers of the Mercedes A-Class car could also say "anyone stupid enough to swerve violently when an elk crosses the road gets (and should get) what he deserves". Unfortunately for them, and probably fortunately for most of us, that doesn't pass muster. 2. For anyone who thinks this is just a hypothetical possibility, here is the robots.txt file of the site of a major communications company: robots.txt User-agent: * Disallow: /bug-navigator # Bug Data Disallow: /warp/customer # Registered Users Disallow: /kobayashi # Navigation for registered Disallow: /cgi-bin # no programs Disallow: /pcgi-bin # no programs Disallow: /univ-src/ccden # will get content through /univercd Disallow: /cpropub/univercd # obsolete The first two lines at least suggest to me that this is stuff that the company doesn't want publicized -- for security reasons, not because it is of temporary value. Were I a "hacker" in the bad sense of the term, I would revel in such information, as it would direct my efforts to the really juicy bits. Here is an extract from another page -- I'll let you guess the URL: # o Created this file to prevent indexing of one # SME directory. User-agent: * Disallow: /sparc/SPARCengineUltraAX/oem/ Disallow: /microelectronics/SPARCengineUltraAX/oem/ Disallow: /javachip/SPARCengineUltraAX/oem/ Disallow: /javachips/SPARCengineUltraAX/oem/ Disallow: /sparc/SPARCengineUltraAX/download/ Disallow: /microelectronics/SPARCengineUltraAX/download/ Disallow: /javachip/SPARCengineUltraAX/download/ Disallow: /javachips/SPARCengineUltraAX/download/ I can't say for sure, but doesn't some of this look a tad like proprietary information? 3. So even if the respondents are right that it is "stupid" to use robots.txt in that way, my posting at least draws attention to the risk. If it succeeds in making just one Webmaster a bit more careful, it will not have been useless. 4. Of course designers cannot always be blamed for misuses of their mechanisms. But they should minimize the possibility of misuses. In the robots.txt case it seems to me rather wrong to have a conspicuous world-readable file that draws attention to *excluded* information. (Reminds me of programming languages which implement information hiding by making the author of each module list conspicuously, as the first thing you read in the module's text, those features which are *not* exported!) This draws attention to what should not attract attention. I think that a more effective convention would have been to include a special marker (META tag?) in HTML files that shouldn't be indexed, and a special file (exclude.txt?) in the directories that should not be explored at all. Then you would only be able to find that information if you already knew where to look. The robots.txt mechanism is a godsend for Peeping Toms in search of possible secrets. (Thanks too to Marc Horowitz and Rik Moonen for their comments.) Bertrand Meyer, Interactive Software Engineering, makers of ISE Eiffel , http://www.eiffel.com ------------------------------ Date: 27 Jan 1998 13:43:51 -0500 From: Devon McCormick Subject: 4-Letter words, re: CyberSitter [I wrote an article on the ramifications of binary data as "bad words" for our local New York APL (A Programming Language) newsletter. I think you can get the gist of it without the special font you need to read the APL code properly. Devon] I was thinking about the CDA (Communications Decency Act) the other day, about how much more important it is to protect our children from bad words than from bad laws, and I wondered what I could do to help make the 'net as bland and harmless as television. One danger no one has pointed out has to do with another fine U.S. government initiative, the Clipper chip (or whatever name it's disguised under right now). It occurred to me that any good encryption routine, and the NSA promises that Clipper is real good, effectively turns its input into an output that appears random. This raises the dismaying possibility, in fact certainty, that an encrypted datastream will contain dirty words! At first glance this seems to be simple enough to remedy: we can scan the encrypted stream for dirty words and replace them with some equivalent string then convert them back at decryption time; in fact, someone has already written software to do this using names of U.S. senators as the dirty word equivalents. However, this is not as simple as it seems. Consider that a dirty word may be written in upper-case letters, lower-case, or a combination of the two. Also, there is the concern of performance degradation. Pondering these difficulties, I realized that since most dirty words are 4 letters (bytes) long, and that most computers do well with 4-byte (integer) conversions and comparisons, there is a good solution: consider only the equivalent "dirty" numbers! Once I had had this insight I leapt to my keyboard to answer the question that must now be burning in your mind the way it was then in mine: just what are these dirty numbers and what can we do with them? The following Dyalog APL session explores some of the possibilities. One advantage dirty numbers have over dirty words is that you can do things like find the "average" dirty word: this could lead to a whole new class of forbidden words (albeit largely unpronounceable ones). ½BADWORDS 7 4 Apologies to George Carlin. BADWORDS[;0],'*','*',BADWORDS[;,3] F**K S**T Q**M C**T F**T D**N P**S © Or, for the more squeamish: BADWORDS[;,0],7 3½'*' F*** S*** Q*** C*** F*** D*** P*** ALPNUMAV OK, let's see what the all-upper-case dirty numbers look like: (½ALPNUM)³ALPNUM¼BADWORDS 302078184196 357695050756 349323218180 289194005508 301743625220 293153361412 344827581188 Account for all possible upper- and lower- case combinations by expanding the upper-case versions with all 4 digit boolean combinations (so "1 1 1 1" maps all-upper to all-lower, "1 0 0 0" maps all-upper to initial upper-case letter only). VARBW(-/AV¼'Aa')×(³(4½2)¼16) © Assumes upper and lower alphabets are each contiguous. ½¨ALLBW¨(VARBW)+¨¨ALPNUM¼BADWORDS 16 4 16 4 16 4 16 4 16 4 16 4 16 4 BADWORDS-ALPNUM[¨¨ALLBW] © Check that we have what we think we do 1 ½BADVARIANTS(½ALPNUM)¨³¨ALLBW 7 16 BADVARIANTS 1179992907 1179992955 1180005195 1180005243 1183138635 ... 1397246292 1397246340 1397258580 1397258628 1400392020 ... 1364543821 1364543869 1364556109 1364556157 1367689549 ... 1129664084 1129664132 1129676372 1129676420 1132809812 ... 1178686036 1178686084 1178698324 1178698372 1181831764 ... 1145130318 1145130366 1145142606 1145142654 1148276046 ... 1346982739 1346982787 1346995027 1346995075 1350128467 ... © So, the average of each bad word variant is: ALPNUM[³(4½½ALPNUM).5+(+/BADVARIANTS)÷16] .Ò $à ÏÁÐ ÍÒÁÈ $ÒÊÐ .YÎÐ %YÈÊ ÌÁÏÏ © And the average variant bad words are: ALPNUM[³(4½½ALPNUM).5+(+BADVARIANTS)÷7] JÕêñ JÕêµ JÕ"ñ JÕ"µ J<êñ J<êµ J<"ñ J<"µ õÕêñ õÕêµ õÕ"ñ õÕ"µ õ<êñ õ<êµ õ<"ñ õ<"µ © And the overall average bad word is: ALPNUM[,(4½½ALPNUM).5+(+/,BADVARIANTS)÷½,BADVARIANTS] ÂÖ¹¼ © So, ÂÖ¹¼ the CDA! ------------------------------ Date: 28 Jan 1998 16:32:38 -0500 From: Dale Martin Subject: Re: Possible Netscape source code risks (Wilson, RISKS-19.57) This possibility exists with ANY software project. Personally, I feel better about source code that's being looked at by thousands of developers rather than a few in a company, at least with regards to "slipping nasty things in so-called bugfixes". Dale E. Martin | University of Cincinnati Savant Research Laboratory dmartin@ececs.uc.edu http://www.ececs.uc.edu/~dmartin ------------------------------ Date: 1 Apr 1997 (LAST-MODIFIED) From: RISKS-request@csl.sri.com 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. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, 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 risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 19.58 ************************