precedence: bulk Subject: Risks Digest 22.68 RISKS-LIST: Risks-Forum Digest Saturday 12 April 2003 Volume 22 : Issue 68 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 http://catless.ncl.ac.uk/Risks/22.68.html and by anonymous ftp at ftp.sri.com, cd risks . Contents: IBM's DB2 blamed for Danish banking crisis (Fuzzy Gorilla) Man Gets $12,000 Electric Bill (Fuzzy Gorilla) Missile-defense test failure linked to a single chip (Fuzzy Gorilla) Millennium trains taken off the tracks (John Colville) Stupid Security Awards for 2003 (Simon Davies) Radio stations unable to play copy protected CDs (Jeffrey Sunseri) Net fraud complaints triple in 2002 (Keith Rhodes) Credit-card theft (sergioch) Re: Friendly Fire (Peter B. Ladkin, Rod Van Meter, David Guaspari) Re: The reality behind these laws (Stanislav Shalunov) Re: POW Social Security numbers revealed (Jaanus Kase, Crispin Cowan) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sun, 06 Apr 2003 11:54:03 -0400 From: "Fuzzy Gorilla" Subject: IBM's DB2 blamed for Danish banking crisis Danske Bank is pointing fingers at IBM's DB2 database as the culprit for a massive outage that caused the Danish bank's trading desks, currency exchange and communications with other banks to shut down. The problems began on 10 Mar 2003, when a defective power unit was replaced in an IBM Ramac Virtual Array (RVA) storage system. An electrical outage occurred during the repairs, which caused operations at one of the bank's two operating centers to come to a halt. When operations were finally resumed, extensive data inconsistencies were discovered throughout a week-long process of trying to recover data. Apparently, a flaw had existed in DB2 in comparable installations since 1997, although it had not been detected prior to this event. IBM has issued a fix. [Source: Ashlee Vance, The Register, 4 Apr 2003; PGN-ed] http://www.theregister.co.uk/content/53/30095.html ------------------------------ Date: Fri, 04 Apr 2003 16:31:11 -0500 From: "Fuzzy Gorilla" Subject: Man Gets $12,000 Electric Bill On April Fools' Day, Randy Carrol in North Platte, Nebraska, received an electric bill of $12,344.16 for 33 days' service. But it was not a joke -- except that the amount was generated by new billing software, showing use of 310,421 kilowatts (instead of the usual 300). The correct amount due later turned out to be $26.26. [Source: AP item, 4 Apr 2003; PGN-ed] http://story.news.yahoo.com/news ?tmpl=story2&u=/ap/20030404/ap_on_fe_st/electric_bill ------------------------------ Date: Fri, 11 Apr 2003 20:39:09 -0400 From: "Fuzzy Gorilla" Subject: Missile-defense test failure linked to a single chip According to Jack Kelble, president of Raytheon Space and Airborne Systems, the failure of a U.S. missile-defense test on 11 Dec 2002 was caused by the malfunction of a single chip that failed to signal an exo-atmospheric kill vehicle to separate from its booster rocket. Coming just five days before Presidential directive on speeding deployment of missile defenses, the test included the use of Navy Aegis cruisers and a Boeing 747 modified as the Airborne Laser Lab. Both were used as trackers for the Minuteman II ICBM launched from Vandenberg Air Force Base, California, as a target missile. Each flight test costs an average of $100 million. [Source: Loring Wirbel, EE Times, 11 Apr 2003; PGN-ed] http://www.eetimes.com/sys/news/OEG20030410S0066 ------------------------------ Date: Fri, 11 Apr 2003 13:47:26 +1000 From: John Colville Subject: Millennium trains taken off the tracks The Millennium trains (so-called because of when they were supposed to start running, although that was delayed until ten months ago in mid-2002) have been taken out of service indefinitely, due to electrical problems that were having a "flow-on effect across the Sydney network." Train signals interfering with the frequency of the underground signalling system resulted in turning lights red for following trains. Only four 8-car trains have been delivered thus far (out of the contracted 81, with a total cost of 232 million Australian dollars). Transport Services Minister Michael Costa said, "This is the most complex train that's ever run on a rail system. It is a piece of equipment that would, in the normal course of events, have some teething problems." Other problems were also cited: passenger doors occasionally refusing to close; loss of the public address system; and loss of air-conditioning in some units. [Source: Joseph Kerr and Darren Goodsir, *Sydney Morning Herald*, 10 Apr 2003; PGN-ed from JC's excerpting] http://www.smh.com.au/articles/2003/04/10/1049567807326.html John Colville, Dept of Computer Systems, University of Technology, Sydney Broadway NSW Australia 2007 colville@it.uts.edu.au +61-2-9514-1854 ------------------------------ Date: Tue, 8 Apr 2003 20:20:30 +0100 From: Simon Davies Subject: Stupid Security Awards for 2003 Privacy Watchdog announces winners of competition to find the world's most stupid security measures; Global quest has identified absurd and pointless security requirements Privacy International today announced the results of its competition to find the worlds most pointless, intrusive and egregious security measures. The competition, launched in February, attracted almost 5,000 nominations from 35 countries. While the air security sector dominated the competition, nominations arose from almost all areas of private and public sector activity. The winners include JFK Airport, T-Mobile (UK), Michigan Correctional facilities and the Australian Government. The "Stupid Security" award was judged by a distinguished international panel of security and privacy experts and is intended to highlight the absurdities of the security industry. Privacy International's director, Simon Davies, said his group took the initiative because of "innumerable" security initiatives around the world that had absolutely no genuine security benefit. "The extraordinary number of nominations indicates that the situation has become ridiculous" said Mr Davies. "Security has become the smokescreen for incompetent and robotic managers the world over. The situation has become more than an irritation to the public. It has become an outright danger". The winners are: Most Egregiously Stupid Award * Winner: The Australian Government for a litany of pointless, irritating and self-serving security measures * Runner-Up: Moscow Mayor Yury Luzhkov for the 'Propiska' Identity Papers Most Inexplicably Stupid Award * Winner: Philadelphia International Airport for over-reaction to a bottle of cologne * Runner-Up: Heathrow Airport for quarantining a quantity of green tea Most Annoyingly Stupid Award * Winner: T-Mobile (UK) for pointless and idiotic financial security measures * Runner-Up: Bay Area Rapid Transport (Bart) for closing its restrooms. Most Flagrantly Intrusive Award * Winner: Delta Terminal at JFK Airport for forcing a nursing mother to drink still-warm bottles of her own breast milk * Runner-Up: Carson City Correctional Facility, Michigan for forcing women visitors to wear bras. Most Stupidly Counter Productive Award * Winner: San Francisco General Hospital for blind idiocy in its identity checking procedures * Runner-Up: San Francisco International Airport for endangering the public * Dishonourable Mention: The New Yorker Hotel, New York for aggressive, unnecessary and meaningless security measures. Full details at http://www.privacyinternational.org/activities/stupidsecurity/ Simon Davies can be reached at simon@privacy.org Phone (+44) 7958 466 552 [Note 1: Privacy International (PI) http://www.privacyinternational.org is a human rights group formed in 1990 as a watchdog on surveillance by governments and corporations, including wiretapping and national security activities, ID cards, video surveillance, data matching, police information systems, and medical privacy.] [Note 2: (Disclaimer) PGN was one of the judges.] ------------------------------ Date: Mon, 07 Apr 2003 15:09:20 -0400 From: "Jeffrey Sunseri" Subject: Radio stations unable to play copy protected CDs Music companies which use copy protection may be denying the artists under contract to them legitimate play time on radio stations, if the happenings at one outfit are any indication. [First sentence on Declan's Politech] [Some radio stations with desktop PCs rather than standalone CD players are unable to play the free CDs they get from EMI because of disc copy protection. PGN-ed of the article] http://www.theage.com.au/articles/2003/04/03/1048962867084.html ------------------------------ Date: Fri, 11 Apr 2003 04:59:58 -0700 (PDT) From: Keith Rhodes Subject: Net fraud complaints triple in 2002 The FBI's Net fraud unit says it referred 48,000 complaints to law enforcement last year, with both the number of fraud cases and the dollar loss associated with them more than tripling. [Source: Paul Festa, CNET News.com, 10 Apr 2003] http://zdnet.com.com/2100-1105-996270.html?tag=sas_email ------------------------------ Date: Sat, 12 Apr 2003 11:42:37 +0200 From: sergioch@ciaoweb.it Subject: Credit-card theft A mailman in Settimo Torinese (a small town in northwestern Italy) has robbed several credit cards and the relative letters with the PIN. His theft was found after one of the owners of the cards discovered that 3000 euros were missing from her account due to shopping made with her card, which she had never received. The police searched the home of the thief. It found more than 100 (a hundred) letters communicating the PIN code to the owners of the cards, plus for an amount of about 5000 euros in bought arcticles (mainly in sportswear, we are told). "The "Servizi Interbancari" (interbanking services), Italian leader in credit card management, told that it is the first time that such event occurs in Italy and that <> are followed in the dispatch of cards and PINs." Sarcasm is left to the reader as an exercise. Sources (in Italian): La Stampa, 11/04/2003, cronaca di Torino (page 41). http://www.lastampa.it/search/albicerca/ng_articolo.asp?IDarticolo=782728 Google Translation (not great): http://translate.google.com/translate?u=http%3A%2F%2Fwww.lastampa.it %2Fsearch%2Falbicerca%2Fng_articolo.asp%3FIDarticolo%3D782728&langpair=it %7Cen&hl=it&ie=ISO-8859-1&prev=%2Flanguage_tools ------------------------------ Date: Mon, 07 Apr 2003 11:22:55 +0200 From: "Peter B. Ladkin" Subject: Re: Friendly Fire (RISKS-22.65 to 22.67) Recent "friendly fire" incidents (known in the military as fratricide) were introduced in RISKS-22.65 by Paul, and discussed in RISKS-22.66 by Tyson and RISKS-22.67 by Eachus, Russ, and Youngman. Chris Johnson of the Accident Analysis Group at the University of Glasgow has an review article on the subject [1]. He recently quoted the following percentages of all reported casualties sustained, from FM100-14, US Army, 1998: World War II Korea Vietnam Desert Storm/Shield (1942-45) (1950-53) (1965-72) (1990-1991) Accidents 56% 44% 54% 75% Friendly Fire 1% 1% 1% 5% [archive-corrected] Enemy Actions 43% 55% 45% 20% As Russ pointed out, it is important not just to view percentages but also to know the absolute numbers, as asserted by 100% of the people typing this note, who doesn't have those numbers available. A particularly noteworthy fratricide incident occurred in 1994 during Operation Provide Comfort, which intended to protect certain Kurdish areas in Northern Iraq. Two F-15s patrolling the no-fly zone shot down two Black Hawk helicopters ferrying officials and locals within the no-fly zone. This incident has been analysed by (in temporal order) a USAF Aircraft Accident Investigation Board, by a US General Accounting Office review of that report [2], by U.S. military academician Scott Snook [3], by Joan Piper, the mother of one of the officers killed [4], and by Nancy Leveson, Polly Allen and Margaret-Anne Storey [5]. During the incident, the major technologies involved were a controlling AWACS aircraft, and the Air-to-Air Interrogation/Identification Friend or Foe (AAI/IFF) systems on board the F-15s and the Black Hawks, systems which send radio interrogation signals (AAI) and elicit responses (IFF) from friendly aircraft. These systems are similar in function to that of the combination of Primary Air Traffic Control Radar and on-board transponders in civil aviation, although I expect the military security design is far more sophisticated. During this incident, the technology apparently functioned more or less as intended, although there was some question as to why certain AAI/IFF transactions did not occur, which has not been answered. (Although the F-15s were interrogating on a different band from that on which the Black Hawks were responding, at least one performed interrogation should have elicited a response. No reason for this was identified.) When the F15 pilots failed to get suitable responses from AAI/IFF transactions, they performed a visual intercept, mistakenly identified the Black Hawks as Iraqi Hind helicopters, and shot them down. The reports focused on procedural irregularities (problems in the chain of command during the intercept), on coordination on board the AWACS, and the apparent haste, inaccuracy, and lack of procedural care with which the F15s performed the visual identification and shootdown. The GAO also investigated mission discipline issues with the squadron to which the interceptors belonged. According to the GAO, the USAF report "focused on, among other things, command and control problems, including individuals' lack of knowledge of specific procedures." The GAO report pointed out that the USAF report did not discuss the F-15 pilots' responsibility to report to the Airborne Command Element (ACE, the chief of the AWACS operation staff) when they encountered unknown aircraft in the no-fly zone; that it failed to note that the ACE had authority to stop the intercept (especially significant given that his staff had been dealing with those same helicopters a short while before); and that it erroneously concluded that use of an incorrect "squawk" code by the Black Hawks resulted in the F15s not receiving an IFF response (the F15s should have seen a response in any case on at least one of their required interrogation modes). These seem to me to be problems largely concerning organisational behavior rather than the technology itself, although this behavior is of course conditioned by that technology. One could expect this to be so in general for fratricide incidents, since, except for intentional incidents such as "fragging", they are cases of mistaken identity and are thus likely to contravene the rather elaborate procedures that have evolved for avoiding it. Another case, investigated by the organisational behavior researcher Gene Rochlin [6], was the shootdown of a commercial aircraft, an Iran Air Airbus Flight 655, over the Persian Gulf by an Aegis cruiser, the USS Vincennes, who was engaged in a firefight at the time with small Iranian patrol boats. The aircraft was initially misidentified as an F14, and its subsequent behavior was misinterpreted as threatening, despite the wealth of electronic information available to the Aegis crew which showed otherwise - a case of seeing what one expects (or fears) to see, it seems. Again, organisational behavior, conditioned by the available technology. The recent Patriot shootdown of a RAF Tornado may be different, in that it may have been initiated by technological misfunction. According to Flight International [7], "the aircraft was approaching the Kuwaiti border as number two in a two-ship formation when it was identified by the Patriot as an anti-radiation missile. An operator then initiated the engagement, before realising that other sensor data did not corroborate the target classification. ..... Initial indications are that the Tornado was in the "safe-lane" at the right speed and height when it was hit. If it had an IFF problem, even not functioning or broadcasting the wrong identification tag, it would probably still have been spotted by the airborne control post." The report continues: "Further doubts were raised about Patriot's IFF system when a day later a second SAM battery, 55km (35 miles) south of An Najaf, locked on to a US Air Force .... F-16. The fighter fired a [anti-radiation missile], destroying the battery's radar without killing anyone. References [1] Chris Johnson, Risk and Decision-Making in Military Accident and Incident Reporting Systems, available at http://www.dcs.gla.ac.uk/~johnson/papers/Military.pdf [2] General Accounting Office, USG, Operation Provide Comfort: Review of U.S. Air Force Investigation of Black Hawk Fratricide Incident, Report to Congressional Requestors, Report GAO/OSI-98-4, November 1997, available through search from http://www.gao.gov [3] Scott A. Snook, Friendly Fire: The Accidental Shootdown of U.S. Black Hawks over Northern Iraq, Princeton University Press, 2000. Details at http://pup.princeton.edu/titles/6847.html [4] Joan L. Piper, A Chain of Events: The Government Cover-Up of the Black Hawk Incident and the Friendly-Fire Death of Lt. Laura Piper, Brassey's Inc, 2001. [5] Nancy G. Leveson, Polly Allen, Margaret-Annd Storey, The Analysis of a Friendly Fire Accident using a Systems Model of Accidents, available from http://sunnyday.mit.edu/accidents/ [6] Gene I. Rochlin, Iran Air Flight 655: Complex, Large-Scale Military Systems and the Failure of Control. In Responding to Large Technical Systems: Control or Anticipation, Renate Mayntz and Todd R. La Porte, eds., Kluwer, 1991. A version is also to be found as Chapter 9 of Rochlin, Trapped in the Net, Princeton University Press, 1997, which chapter is available at http://pup.princeton.edu/books/rochlin/chapter_09.html [7] Accidents Take Their Toll, Flight International, 1-7 April 2003, p6. Peter B. Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany +49 (0)521 880 7319 http://www.rvs.uni-bielefeld.de ------------------------------ Date: 04 Apr 2003 14:55:01 -0800 From: Rod Van Meter Subject: Re: Friendly Fire ... (Russ, RISKS-22.67) I'm not certain where Mr. Russ got his data, but as of 14:30 PST on 4 Apr, http://www.cnn.com/SPECIALS/2003/iraq/forces/casualties/index.html lists 84 coalition deaths and another couple of dozen POW/MIAs. It also seems unlikely that we have already killed a full four tenths of a percent of the population of Iraq. I don't see numbers for injured at a glance. The problem likely stems from confusion over the term "casualty". It actually refers to persons killed OR INJURED, although many people seem to believe it refers to deaths. The same issue has caused over fifty years of misinformation about the atomic bombing of Japan and the planned Operation Olympic invasion of Japan's home islands, due to confusion over casualties on Okinawa and Iwo Jima. ------------------------------ Date: Mon, 7 Apr 2003 16:21:48 -0400 From: David Guaspari Subject: Re: Friendly fire ... (PGN, RISKS-22.65) It would take some hard work to decide whether [a high friendly fire rate] is astounding or is a simple statistical necessity. If side A so overmatches side B that B can do A no damage at all, then 100% of A's casualties will be the result of friendly fire (or self-inflicted by other kinds of accident). David Guaspari, ATC-NY, 33 Thornwood Drive, Suite 500, Ithaca NY 14850-1250 voice: (607) 266-7114 davidg@atc-nycorp.com ------------------------------ Date: 04 Apr 2003 15:30:20 -0500 From: stanislav shalunov Subject: Re: The reality behind these laws (Re: Cohen, RISKS-22.67) > Nothing in these bills in any way prevents firewalling, encryption, > etc. UNLESS it is being used to defraud. I certainly hope that this was the intent. However, the law says: > Sec. 540c (1) A person shall not [...] assemble, > develop, manufacture, possess, deliver, offer to > deliver, or advertise a telecommunications device > intending to use those devices or to allow the devices > to be used to do any of the following or knowing or > having reason to know that the devices are intended to > be used to do any of the following: [...] > (b) Conceal the existence or place of origin or > destination of any telecommunications service. A NAT box is a telecommunications device. Some common home WiFi access points can *only* be used in NAT mode, such as a few Linksys boxes. A NAT box is intended to conceal the actual origin of IP traffic. IP traffic seems to fit their definition of a telecommunications service. It would seem that the possession of a NAT box is made a felony in Michigan, punishable by up to four years in prison and/or up to $2000 fine per device. Please explain where you are reading this ``intent to defraud'' stuff? (Sec 219a does use ``with the intent to defraud'' language carefully, but we're talking about a different section here. Are we reading different texts? I'm talking about .) My reading of this is that it outlaws (both sale and possession) of NAT and VPN boxes and perhaps more (steganography?). Note that there does not need to be any malicious intent in order for the possession to be illegal. In addition, the item (c) that immediately follows is written quite vaguely (it was probably meant to outlaw cable descramblers), but it written -- probably unintentionally -- so that it might be interpreted as outlawing (the decryption side of) any use of encryption without prior permission from the service provider (all of them on the path, I guess?). Stanislav Shalunov http://www.internet2.edu/~shalunov/ ------------------------------ Date: Sat, 5 Apr 2003 01:45:07 +0300 From: "Jaanus Kase" Subject: Re: POW Social Security numbers revealed (Hirose, RISKS-22.67) Foreign readers, like myself, are well aware of America's problems with SSN. To my view, the problem is very simple: identification and authentication are two very different issues, but SSN is used for both. Let's face it: to have efficient public services and efficient means of communications in current Internet age and information society, it is vital to have a sort of universal "national identity number", whatever it is called - ID code, SSN, "medical insurance code" or whatever. They are often used in medical or social insurance, but not necessarily always - it can be used when providing any service or just wanting to talk to someone to be sure of his identity. I myself live in Estonia and I think we have a good national ID code system in place. Every person has a unique code - for example, mine is 38006270262. I can tell it to you freely, because it is available online anyway in a lot of places. It is widely accepted here that the ID code is public data. Think of it as your middle name. It is even helpful in daily electronic communications - if you have two persons with the same name, you can distinguish them by the code. It is also obvious that all sorts of electronic registers are easy to construct using the code. In itself, the ID code also encodes some key personal data, like your birth date and sex, but nothing else. A direct result of the above is that the code must NOT be used for authentication purposes. If I know someone's name and ID code, I should NOT be able to impersonate as that person. Indeed, all services in Estonia, public or private, consider this and knowing only someone else's name and/or ID code gets you nowhere - additional authentication is always used. As I view it, the core of US problems with SSN is very simple - it is used widely as a unique identifier as it is very easy to do so (as, I understand, it is the only numeric identifier that all US residents can be assumed to have). And then, you play hide-and-seek and say, "okay, the number is everywhere all over the place anyway, but now let's play it's secret and start authenticating people using it." I of course understand that the US system is in its current state due to its historic legacy, but in the long run, some changes will probably need to be made, although I wouldn't want to imagine the costs. You may say that there are valid arguments against having a universal public national ID code, but so far, I have not seen any, either in talk or in practice, that I would take seriously. ------------------------------ Date: Fri, 04 Apr 2003 19:32:26 -0800 From: Subject: Re: POW Social Security numbers revealed (Hirose, RISKS-22.67) It is often suggested that disclosure of SSN's is a great risk. In the current climate, where SSN's are used to *authenticate* an individual ("tell us your SSN so we know it is you") that certainly is true. However, I suggest an alternate approach to solving the problem of identity theft. SSN's are hopelessly easy to obtain; attempting to curtail the broadcast of these numbers (e.g. hoping the Iraqi state television will control the release) is futile. Instead, I suggest that the US Government *prohibit* the use of SSN's as authenticators. If all of the US organizations that currently authenticate with SSN's were forced to use something else (anything else) the state of the identity theft crisis would improve drastically. The "*anything* else" part is important to this proposal. It is tempting to propose something prescriptive, specifying how organizations should authenticate people. However, I suspect that such prescriptions would make the law founder on impracticality, as organizations find high quality authentication difficult to implement for one reason or anther. In contrast, simply forcing organizations to choose something else at least has the scattershot effect that they are unlikely to choose all the same attributes, making wholesale identity theft much more difficult. Just me proposing this idea here and getting a few folks to agree that it would be beneficial is fun & all :-) but won't actually change anything. More constructive would be if those who do agree with the idea, and have more influence in the financial regulation space than I do, would take up the idea and start spreading it around. Crispin Cowan, Chief Scientist, WireX http://wirex.com/~crispin/ http://wirex.com http://h18000.www1.hp.com/products/servers/solutions/iis/ ------------------------------ Date: 29 Mar 2002 (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. Alternatively, via majordomo, send e-mail requests to with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomo@CSL.sri.com . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address " ; 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. .UK users should contact . => 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 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 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.68 ************************