RISKS-LIST: Risks-Forum Digest Monday 19 August 2002 Volume 22 : Issue 19 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/22.19.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: [Back from long trip. PGN] Name filtering affects police officer (Fuzzy Gorilla) Massive ATM fraud after security problems due to Sept 11 (Tom Van Vleck) A universal Turin machine? (PGN) Win32 API utterly and irredeemably broken (Monty Solomon) Microsoft EULA asks for root rights -- again (Monty Solomon) FTC Stamps Microsoft's Passport (Monty Solomon) Keystone SpamKops (Edward W. Felten) Re: Listen to TCAS, not the controller (Peter B. Ladkin) An automation-related AIRPROX incident (Peter B. Ladkin) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 15 Aug 2002 18:41:31 -0400 From: "Fuzzy Gorilla" <fuzzygorillaat_private> Subject: Name filtering affects police officer It is not clear that we will ever solve the problem of computerized filtering based on "lewd" names when even humans can't get it right. The badge of El Paso police officer Christine Lynn O'Kane (and her e-mail address) identified her as C. O'KANE (which unfortunately looks like 'cocaine'). After leaving the force for personal reasons and later reapplying, she was denied reinstatement on the grounds that her name was inappropriate -- despite her good service record that included an explicit recommendation her work file supporting her reinstatement. Although her appeal to the Civil Service Commission resulted in her being rehired, she has now reverted to her maiden name (Whitaker). [Source: Cop In Trouble Over Name, AP, 12 Aug 2002; PGN-ed] http://dailynews.yahoo.com/news?u=/ap/20020812/ap_on_fe_st/c__o_kane_1 ------------------------------ Date: Mon, 5 Aug 2002 20:18:08 -0400 From: Tom Van Vleck <thvvat_private> Subject: Massive ATM fraud after security problems due to Sept 11 http://fr.news.yahoo.com/020805/5/2pe9c.html [This is in French, but not yet reported in English. Translation with the help of Babelfish. thvv] 4000 people are suspected of taking a total of $15 million in ATM overdrafts from the NY Municipal Credit Union, whose computer system was damaged by 9/11 attacks and the phone and electric outages that followed. The CU chose to allow withdrawals of up to $500/day without checking. Word got around. One person withdrew over $18,000 in 54 transactions. ------------------------------ Date: Mon, 19 Aug 2002 15:06:53 PDT From: "Peter G. Neumann" <neumannat_private> Subject: A universal Turin machine? Seeing the number 4000 in the foregoing message from Tom Van Vleck reminded me of an article I read 12 days ago in *The Herald Tribune* Italian edition supplemental highlights from *Corriere della Sera* in English, 7 Aug 2002: Police probe credit card scam. Turin police obtained a cigarette-pack-sized machine that been used by an up-scale restaurant to make about 4000 perfect-copy credit cards from cards used by customers, including mag stripes. The Clone Arranger Strikes Again. (The Shrewd of Turin?) ------------------------------ Date: Mon, 19 Aug 2002 12:44:53 -0400 From: "monty solomon" <montyat_private> Subject: Win32 API utterly and irredeemably broken Thomas C Greene in Washington, 7 Aug 2002 Windows might possibly be the most insecure piece of viral code ever to infect a computer, according to Chris Paget who's found a fascinating hole in the Win32 Messaging System which he believes is irreparable, and which he posted to the BugTraq security mailing list. The research leading to this discovery was inspired by MS Veep Jim Allchin, who testified to the effect that if flaws in the Windows Messaging System were sufficiently understood, national security would be deeply compromised, CRUISE missiles would be launched remotely, and /bin/laden would most likely find some novel way of raping your daughter with his big bad mou Paget has brought at least some of Allchin's fears to fruition ... http://www.theregus.com/content/55/25883.html ------------------------------ Date: Sun, 4 Aug 2002 23:03:51 -0400 From: Monty Solomon <montyat_private> Subject: Microsoft EULA asks for root rights -- again Andrew Orlowski in *The Register*, London, 2 Aug 2002 An addition to Microsoft's End User Licensing Agreement has alarmed *Register* readers. Windows XP Service Pack 1 and Windows 2000 Service Pack 3 contain a new condition which asks you to allow Windows to go and install future updates. "You acknowledge and agree that Microsoft may automatically check the version of the OS Product and/or its components that you are utilizing and may provide upgrades or fixes to the OS Product that will be automatically downloaded to your computer," is the new bit you'll be interested in. ... http://www.theregister.co.uk/content/4/26517.html ------------------------------ Date: Fri, 9 Aug 2002 18:05:42 -0400 From: Monty Solomon <montyat_private> Subject: FTC Stamps Microsoft's Passport FTC Stamps Microsoft's Passport Yesterday Microsoft settled a complaint by the Federal Trade Commission that its Passport user-ID service had violated its own privacy policy and was insufficiently secure. Almost every outlet featured the story prominently, and the Wall Street Journal e-mailed one of its infrequent Technology Alerts yesterday after the FTC/Microsoft conference call. ... http://newsletter.mediaunspun.com/index000018770.cfm#a86817 ------------------------------ Date: Fri, 16 Aug 2002 09:45:06 -0400 From: "Edward W. Felten" <feltenat_private> Subject: Keystone SpamKops I recently set up a web site at www.freedom-to-tinker.com. It's a weblog containing my commentary on various issues. Earlier this week, my ISP shut off the site, because the site had appeared on a list of "spammers" published by an outfit called SpamCop. Apparently, this happened because one person, whose identity I was not allowed to learn, had sent SpamCop an accusation saying that he had received an unwanted e-mail message, which I was not allowed to see, that did not come from me but that did mention my web site. On that "evidence" SpamCop declared me guilty of spamming and decreed that my site should be shut down. Never mind that I had never sent a single e-mail message from the site. Never mind that my site was not selling anything. Naturally, I was not allowed to see the accusation, or to learn who had submitted it, or to rebut it, or even to communicate with an actual human being at SpamCop. You see, they're not interested in listening to complaints from spammers. With help from my ISP, I eventually learned that the offending message was sent on a legitimate mailing list, and that the person who had complained was indeed subscribed to that list, and had erroneously reported the message as unsolicited. Ironically, the offending message was sent by someone who liked my site and wanted to recommend it to others. Everybody involved (me, my ISP, the person who filed the complaint, and the author of the message) agreed that the report was an error, and we all told this to SpamCop. Naturally, SpamCop failed to respond and continued to block the site. Why did my ISP shut me down? According to the ISP, SpamCop's policy is to put all of the ISP's accounts on the block list if the ISP does not shut down the accused party's site. Note the similarities to the worst type of Stalinist "justice" system: conviction is based on a single anonymous complaint; conviction is based not on anything the accused did but on favorable comments about him by the "wrong" people; the evidence is withheld from the accused; there is no procedure for challenging erroneous or malicious accusations; and others are punished based on mere proximity to the accused (leading to shunning of the accused, even if he is clearly innocent). Note also that the "evidence" against me consisted only of a single unsigned e-mail message which would have been trivial for anyone to forge. Thus SpamCop provides an easy denial of service attack against a web site. The only bright spot in this picture is that our real justice system allows lawsuits to be filed against guys like SpamCop for libel and/or defamation. My guess is that eventually somebody will do that and put SpamCop out of business. [By the way, there is more discussion of this incident on my blog site at http://www.freedom-to-tinker.com EWF] ------------------------------ Date: Thu, 15 Aug 2002 11:38:00 +0200 From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de> Subject: Re: Listen to TCAS, not the controller (Morell, Risks 22.18) In RISKS-22.13, Bob Morell discusses the midair collision on 1 Jul 2002 over Southern Germany, in which a Bakshirian Airlines Tupolov 154, operating as BTC 2937, collided with a DHL Boeing 757-200, operating as DHX 611, although both were using ACAS II-compliant collision-avoidance systems, namely Honeywell TCAS II Version 7 systems [1] (TCAS is "kit"; ACAS II is the international designation for a requirement which TCAS II Version 7 fulfills). Morell is right in saying that more comment is due on this accident. However, his comment is misleading, particularly because of its superficial plausibility. Most misleading of all is the title suggestion that the crew of BTC 2397 (BTC CRW) should have listened to TCAS rather than the controller. To the contrary, their cognitive model may well have been such that prioritising the controller's advisory over the Resolution Advisory (RA) from TCAS would have been the most rational decision to make, as I note below. An extended version of my comment is available as "ACAS and the South German Midair", RVS-Occ-02-02, on http://www.rvs.uni-bielefeld.de First, a brief explanation of how TCAS II avionics operates [2,3]. TCAS II broadcasts signals on the radar-interrogation frequency, and receives responses from other aircraft's transponders. A Mode C transponder is a device which responds to radar beams of a certain frequency with information on the aircraft's identity and its "pressure altitude" - the altitude at which it would be flying in an "international standard atmosphere" at the measured outside air pressure. Additionally, the Mode S transponder used with TCAS II may receive and transmit messages, a facility used essentially in TCAS II. TCAS II gives two types of advisories, Traffic Advisories (TAs) and Resolution Advisories (RAs). It displays the approximate relative position and separation of conflicting traffic visually on a display screen, and announces the advisory via simulated voice. TAs alert a crew to the presence of a potentially conflicting aircraft (determined by presence within a specified volume of surrounding airspace), and attempts to predict time-to-go to collision (TTG). When TTG reaches a certain threshold, a TA is generated; when TTG reaches a lower threshold, an RA is generated upon negotiation with the other aircraft's TCAS II, if it is so equipped. A TA is just a warning; pilots are not expected to manoeuvre in response to a TA. An RA is an advisory to climb, or to descend. An algorithmic negotiation between the TCAS II avionics on both aircraft ensures that one aircraft of a TCAS-II-equipped conflicting pair receives a climb RA and the other a descend RA. Morell speculates whether BTC CRW made a "mistake" or not, and suggests that the descent decision and action "if the reports on the Russian training are correct, was not, technically speaking, a mistake on the pilot's part...." It is not clear to me what Morell's concept of a "mistake" is. First, any pro forma operational suitability of BTC CRW's actions is determined by German aviation law and associated approved procedures in German airspace, not by any "Russian training". Second, in private correspondence, Morell suggested that the RTC CRW action was "obviously" a mistake, since the two aircraft collided. I don't know what it would mean for the action to be a mistake, but at the same time not to be "technically speaking" a mistake. Besides, the criterion offered is clearly insufficient: DHX CRW action led just as inexorably to the collision, but it would be anachronistic to refer to this action as a "mistake". I feel such speculation about possible pilot error without a careful analysis of the interactions in the cockpits, as contained on the cockpit voice recorder (CVR), is unwarranted. The CVR often provides the only means of assessing the quality of CRW decision making, and in this menage a trois equipes in which four of the five participants are dead, I think such analysis is essential. Morell says, astoundingly, that "TCAS is a highly tested system with a flawless record", apparently not counting this midair as a failure. On the contrary, the TCAS avionics were a causal factor in this accident: had neither aircraft been so equipped, the accident would not have happened (DHX CRW would have maintained altitude as cleared; BTC CRW would have descended as cleared and as they did; the aircraft would have missed each other by 600ft). The TCAS system, like most complex systems which depend essentially on human action, does not have a "flawless record", even previous to this accident. There are significant operational issues with previous TCAS versions (such as 6.02 and 6.04a), which remain (while reduced) with TCAS II Version 7. Eurocontrol training materials say that TCAS "... cannot eliminate all risks of collision. Additionally, as in any predictive system, it might itself induce a risk of collision" [4, p17]. The Eurocontrol ACAS Operational Evaluation indicates a substantial history of false positives ("unnecessary RAs") [5]; the latest version, Version 7, shows a "40% reduction in unnecessary RAs" [6]. False positive RAs are not merely a nuisance; in dense traffic areas, which is where RAs are most likely to be generated, manoeuvres in accordance with RAs disrupt ATC planning and generate immediately an unanticipated higher workload for a controller, which can be a safety risk when a controller is operating near the limits of higher capacities. There has been a significant rate of "nuisance" advisories, and one can anticipate pilots' reactions to the system crying "wolf" too often. Lincoln Labs apparently reported that that over 50% of RAs occurring in U.S: airspace are ignored [5, Section 5.3, p19]. Such operational issues arise with, for example, "stacks" of aircraft queuing for approach to an airport in instrument meteorological conditions, and in the European Reduced Vertical Separation Minimum airspace, introduced this year between Flight Levels 290 and 410 (between 29,000 ft and 41,000 ft in an "international standard atmosphere"). In both of these cases, aircraft are operating as cleared with only one thousand feet of nominal vertical separation. Altitude measuring equipment is allowed to be up to +/- 64 ft deviant in RVSM airspace, and altitude reporting equipment reports in either 25ft or 100ft increments. Two TCAS-equipped aircraft operating as cleared may well "see" each other separated by less than 850 ft, sufficient to generate a "nuisance" TA. Add effects of turbulence, or of a non-perfectly executed levelling off manoeuvre at a new cleared altitude ("bump up" or "bump down") and a "nuisance" RA can easily be generated [7]. One should not identify an ACAS II-compliant system with the TCAS II Version 7 avionics alone. The avionics influence an aircraft's flight path only through the crew's decisions and actions. The procedures which crew are advised to follow, and their understanding of the situation (their "cognitive model") are essential components of the ACAS system. Not only that, but it is possible for misleading controller advisories to alter the cognitive model of one or more of the crew involved, indicating that the controller's role must be considered in any safety analysis of ACAS operation. Facts already available concerning the July 1 midair collision highlight certain difficulties with ACAS operation, namely that ACAS does not handle some three-aircraft conflicts well. Consider the situation engendered by the circumstances on July 1. We may assume that BTC CRW and DHX CRW knew that there were only two ACAS-equipped aircraft involved in the conflict. This information would be displayed; BTC CRW would see DHX at their 10 o'clock position (60 degrees left of straight ahead). However, at 23:25:03, 7 seconds after the first RA, BTC CRW were informed by air traffic control that there was conflicting traffic at their 2 o'clock position (60 degrees right of straight ahead) [1]. This aircraft was not on their display - indeed was not there; the controller's advisory was a cognitive mistake. BTC CRW is now faced with the following situation: there is a conflict with traffic painted by TCAS at their 10 o'clock position and also with non-painted traffic at their 2 o'clock position. Their cognitive model poses a three-aircraft conflict situation. (One of these aircraft is a "ghost" but they do not know it.) The importance of this scenario does not depend on what did or did not happen in the accident on July 1. We may find out from CVR and other evidence, or we may not, what BTC CRW's cognitive model actually was. The importance lies in that it is an ACAS scenario whose components have actually occurred, and therefore it must be analysed as part of a safety assessment of ACAS. Let me use "Aircraft A" for the DHX-similar aircraft, "Aircraft B" for the BTC-similar aircraft, and "Aircraft C" for the aircraft at Aircraft B's 2 o'clock position. Since TCAS is not painting Aircraft C, Aircraft B CRW can suppose that Aircraft C will not be involved in any RAs. It is hard to say what cognitive model Aircraft A CRW have, since they might not have heard or assimilated the controller's mistaken advisory to Aircraft B CRW. So I shall not consider their cognitive model. Aircraft B CRW do not know whether the controller is in contact with Aircraft C or not, although it might be reasonable to suppose so. ATC has issued a descent instruction to Aircraft B to take Aircraft B out of conflict with Aircraft C. Further, Aircraft B have received an RA to climb. They can conclude that the RA was negotiated with Aircraft A, since their TCAS display is painting Aircraft A as the "intruder", and that Aircraft A has received a descent RA. There is a clear strategy for Aircraft B CRW to follow when both controller's advisory and RA agree. They follow it. They then come to be in further trouble only if Aircraft A manoeuvres in the reverse sense to their presumed RA. However, a dilemma is directly posed if the controller's advisory and the RA do not agree in sense. One rational strategy could be termed "better the devil you know". Aircraft B CRW can follow the controller's advisory to avoid Aircraft C, and attempt to use the TCAS display information to acquire Aircraft A visually and avoid it. They could also attempt to reduce speed to give greater TTG until conflict with Aircraft A. Risky as this is, I see no more rational strategy available to Aircraft B CRW. Not even this meagre strategy is available if they are in Instrument Meteorological Conditions. The manoeuvres of BTC CRW on July 1 are consistent with this strategy, which violates the oft-repeated advice to pilots not to manoeuvre contrary to an RA. I suggest on the basis of this scenario that this advice is not universally applicable. Indeed, the benefit of ACAS in this situation to Aircraft B is in knowing roughly where Aircraft A is - a benefit provided equally well by TCAS I, which does not generate RAs at all. I believe this scenario shows that it is illusory to imagine that better or more uniform training will resolve ACAS operability problems. Before solutions can be trained, we first need a solution, and I doubt there is one for this scenario based on ACAS technology. I refer to my extended note for other cases, involving three ACAS-II equipped aircraft, for which it is also unclear to me that a solution exists. Peter B. Ladkin, University of Bielefeld, http://www.rvs.uni-bielefeld.de References [1] Bundesstelle fuer Flugunfalluntersuchung, Presseinformation, Zusamme nstoss am Bodensee (available also in English), reviewed July 28th, 2002, http://www.bfu-web.de/aktuinfo-d28.htm [2] Mitre Corporation, Center for Advanced Aviation System Development (CAASD), Traffic Alert and Collision Avoidance System, http://www.caasd.org/proj/tcas/ [3] Honeywell, Inc. Advanced Collision Avoidance Systems, at http://www.honeywelltcas.com [4] Eurocontrol, ACAS II Training Manual, Version 2, available from http://www.eurocontrol.int -> Projects -> ACAS -> Training Materials -> Training Manual Version 2, May 2000. [5] Eurocontrol Experimental Center, European ACAS Operational Evaluation, Final Report, Eurocontrol Experimental Centar Report No. 316, July 1997, available at http://www.eurocontrol.fr -> Documents -> (Search) Final Report 316 -> Reports for the Year 1997 -> 316. [6] Mitre Corporation, Center for Advanced Aviation System Development (CAASD), Traffic Alert and Collision Avoidance System, http://www.caasd.org/proj/tcas/ [7] Eurocontrol, ACAS II Operations in the European RVSM Environment, Project ACTOR, available from http://www.eurocontrol.int -> Projects -> ACAS -> Training Materials -> Brochure f11, 2 August 2001. ------------------------------ Date: Thu, 15 Aug 2002 16:07:31 +0200 From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de> Subject: An automation-related AIRPROX incident On 2 Oct 2000, there was a loss of separation (an AIRPROX incident in jargon) on the North Atlantic Track E from Europe to North America between an Airbus A330 and an Airbus A340 aircraft. The aircraft were operating under Reduced Vertical Separation Minima (RVSM), in which high-altitude aircraft may use a nominal vertical separation of 1,000 ft from each other for their operations instead of 2,000 ft, which has been standard. RVSM had been introduced for trials on the North Atlantic track system, and was introduced in European airspace in January 2002. RVSM depends essentially on participating aircraft using Airborne Collision Avoidance System (ACAS) equipment. Both incident aircraft were using Traffic alert and Collision Avoidance System (TCAS) Version 6.04 avionics. I shall describe the incident briefly, omitting some salient observations made in the report. Since the report is about eleven A4 pages of prose and data, I recommend reading it in full [1]. The A340 was cleared at Flight Level (FL) 360 (the altitude at which the air pressure is the same as that at 36,000 ft in an International Standard Atmosphere), and the A330 at FL 370. The A330 was roughly abeam and slowly overtaking the A340, when the aircraft encountered clear air turbulence, described by the A340 captain as severe. The A340 entered a "zoom climb", and went up to FL384, some 2,400 ft above its assigned FL and 1,400 ft above the FL assigned to the A330. Both aircraft had been receiving Traffic Advisories (TAs) on each other for some minutes before the incident, and during the incident received TCAS Resolution Advisories (RAs); the A340 was advised to descend and the A330 to climb. The A330 captain said that the A340 passed through his FL, some 200-300ft to his left, before he had time to react to the RA. The maximum rate of climb of the A340 during the incident was recorded to be some 6,000 ft/min. At the time the first RAs were issued, the aircraft were likely separated by some 800 ft, and the RAs were "nuisance" RAs due to the turbulence, as described in [2]. The A340 had not begun its zoom climb. About ten seconds later, though, the A340s flight control system captured "alpha prot", and the A340 commenced its climb. "Alpha prot" is a value of a flight parameter known as the "phase-advanced angle of attack" which triggered a change from the "normal" flight control law in the Airbus fly-by-wire control system to the "angle of attack protection" law, or AoA law. When both control sidesticks remain neutral, AoA law attempts to maintain the angle of attack (inclination of the aircraft's wing to the air it is flying through; the major parameter used in controlling lift in flight) at the value it has at the point of reversion. One may presume that the turbulence encountered had momentarily increased the angle of attack to a high value at the time that alpha prot was captured. Right before alpha prot was captured, the A340's airspeed briefly rose above its "limiting value" of 0.86 Mach (0.86 times the speed of sound at that altitude), due to the turbulence encounter. This triggered a Master Warning, and also disconnected the autopilot. The Fault Warning Computer prioritises warnings, and the autopilot disconnect warning was suppressed for about six seconds in favor of the Master Warning. It is surmised that the crew may not have registered the TCAS RA because of the interference of the other warnings. The crew responded right away (within five seconds) to the Master Warning by reducing thrust. The investigation suggests that, because of the fluctuations caused by the turbulence, the reversion from normal law to AoA law would likely not have been sensorily detected. Furthermore, this reversion is not possible under autopilot control. It is likely that the crew then had, for up to six seconds, no obvious reason to judge that the aircraft was operating in AoA law. The investigators say that "Such was the vigor of the A340's climb in AoA law, the aircraft could well have climbed through FL 363 (thus provoking a TCAS RA with revised software version 7.0) in a very short time, even if the crew had applied nose-down sidestick as soon as they heard the (delayed) autopilot disconnect warning. The climb to FL 363 would have been sufficient to generate a TCAS RA in any adjacent aircraft at FL 370 but, if the intruder aircraft continues its climb, there can be no guarantee that an aircraft directly above it could respond in sufficient time to avoid a collision." The incident raises the issue of operations under RVSM. The investigators recommended suggested that such an incident is relevant to the safety case being made at that time for the introduction of RVSM in Europe. The incident shows that that a combination of a turbulence encounter, automated flight control, and RVSM could prove deadly, with or without improved versions of TCAS. Peter B. Ladkin, University of Bielefeld, http://www.rvs.uni-bielefeld.de References [1] U.K. Air Accidents Investigation Branch, AAIB Bulletin 6/2001, Ref. EW/C2000/10/2, <A HREF="http://www.aaib.dft.gov.uk/bulletin/jun01/cggwd.htm"> http://www.aaib.dft.gov.uk/bulletin/jun01/cggwd.htm> [2] Eurocontrol, ACAS II Operations in the European RVSM Environment, Project ACTOR, available from <A HREF="http://www.eurocontrol.int">http://www.eurocontrol.int> -> Projects -> ACAS -> Training Materials -> Brochure f11, 2 August 2001. ------------------------------ Date: 29 Mar 2002 (LAST-MODIFIED) From: RISKS-requestat_private Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, send e-mail requests to <risks-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_private . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 21" for volume 21] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 22.19 ************************
This archive was generated by hypermail 2b30 : Mon Aug 19 2002 - 16:50:18 PDT