RISKS-LIST: Risks-Forum Digest Monday 10 June 2002 Volume 22 : Issue 12 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.12.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Is there a law that says you have to watch commercials? (NewsScan) Dim STARS (Peter B. Ladkin) Questions about new STARS air-traffic computer system (Ian Macky) COTS versus Bespoke ATC Systems (Peter B. Ladkin, Nancy Leveson) Re: Swanwick (Peter B. Ladkin) *NY Times* new zero-security password system (Martin Ward) Tracking subway users by electronic fare card (Ngiam Shih Tung) Kazaa users inadvertently share their private files (Nathan Good) Web glitch exposed Fidelity accounts (Monty Solomon) Hacker threat posed by Excel spreadsheets (Patrick O'Beirne) Re: More on typos and homographs (Martin Wheatman, Scott Nicol) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Fri, 07 Jun 2002 09:31:29 -0700 From: "NewsScan" <newsscanat_private> Subject: Is there a law that says you have to watch commercials? Surely there isn't -- says Rep. Rick Boucher (D-Va.) in his support for a consumer lawsuit seeking to confirm that users of Sonicblue's ReplayTV system have the lawful right to skip commercials when they record TV programs for later viewing. The suit has been filed in the same federal court in Los Angeles that is hearing a complaint from movie and television studios that ReplayTV allows customers to violate their copyrights, arguing that skipping commercials amounts to stealing. Sonicblue's position is: "Basically we believe that consumers have 'fair-use' rights, and everything consumers do with a ReplayTV is covered with 'fair use'." [Reuters/*USA Today*, 6 Jun 2002, http://www.usatoday.com; NewsScan Daily, 7 June 2002] ------------------------------ Date: Fri, 07 Jun 2002 19:15:36 +0200 From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de> Subject: Dim STARS The US gave up on its Advanced Automation System (AAS) for air-traffic control in the mid-90's, for the "usual" reasons: large cost overruns and schedule slippages. The UK, however, whose 2MLoC [million lines of code] NERC system was approximately half (1MLoC) AAS code, decided to continue with development. The US instead went for a series of targeted solutions, starting with the Display Replacement System (DRS) for its en-route centers (those dealing with traffic en-route) in the late 90's, and continuing with new hardware for its HOST system, which drives the en-route displays. Among the major systems still under development is the Standard Terminal Automation Replacement System (STARS), which was to be installed at some 170+ (now 160+) locations, for departing and arriving traffic at TRACONS (Terminal Area Control facilities, controlling airspace around major airports), to replace the aged ARTS systems. A full list of FAA ATC systems under development may be found in [1]. STARS was contracted in 1996 to be delivered in 1998. The full software is now scheduled to be delivered in 2002. STARS is described as a "commercial off-the-shelf" (COTS) system (see [2]), quite the buzzword nowadays, and was the type of thing the US wanted to try instead of the "bespoke" AAS that was canceled in 1994. STARS was budgeted at $940m, including installation costs at some 170+ TRACONs. John Mica, Chair of the House Aviation Subcommittee, said in March 2001 [2] that the cancellation of the AAS "[cast] aside 11 years of development work and, according to GAO, [wasted] more that $1.5 billion of taxpayer money." This supposedly COTS system was restructured by the FAA and the supplier, Raytheon, into a "major redevelopment program" in 1998, because the COTS system "proved to be inadequate", being "[unable to] handle the high volumes of traffic required", with a corresponding $1.4b price tag (Mica [2]). STARS is about 960 KLOC of core system i.e., that part of the software that is common to other STARS installations, such as in Germany and elsewhere (Marchilena, Executive VP of Raytheon, [2]) and about 400KLOC of "bespoke" code (Mead, DOT Inspector General, [2]). In February 2002, Kenneth Mead, Inspector General of the US Department of Transportation, said that STARS "is already 4 years late and is now estimated to cost $600 million over the original estimate of about $1 billion. [...] Delays with STARS causes FAA to take stopgap measures for some facilities. FAA spent $85 million to purchase and install Common ARTS systems [developed by Raytheon rivals Lockheed Martin Air Traffic Systems, formerly Loral, formerly IBM Federal Systems. PBL] at large facilities to replace aging equipment. FAA has spent about $660 million on the STARS program but has only two Early Display Configuration systems in operation, which provide new controller displays, but rely on older software. The Early Display Configuration should not be confused with Full Service STARS (Full STARS), which includes both new equipment and a complete replacement of older software." [1] Inspector General Mead has recently reported that STARS will cost at least $1.7 billion, "an 80 percent increase over the initial estimate" [3]. Mead had testified before the Transportation Subcommittee of the House Appropriations Committee on March 13, 2002 that there were 258 open critical trouble reports for STARS, having grown from 171 in September 2001. The FAA indicated, however, that there were only 50 open critical trouble reports. Mead reviewed FAA documentation (the STARS Biweekly Report for March 7, 2002) and concluded that the figure of 258 was correct [3]. (A trouble report is open until closed, meaning a fix has been identified, documented, verified and validated. "Critical" open trouble reports are "those that would prevent or preclude the performance of a mission, jeopardize safety or security, or adversely affect a mission-essential capability." [3]) The FAA is aiming for the first installation of Full STARS at Philadelphia in November 2002. They are aiming for a product that is "not perfect, but acceptable", that is, to fix the "potential show-stoppers". As of May 2, there were 221 open critical trouble reports. The FAA now distinguishes between "critical" otr's and "truly critical" otr's. Mead calls the distinction "not self-defining and [..] vague" [3, p3]. Apparently, to stay on schedule for November 2002 deployment in Philadelphia, the FAA has deferred independent testing. They were going to conduct the tests on Full STARS in Memphis in August 2002 to identify and correct glitches before installation in Philadelphia. But because of delays in development, Full STARS has not been installed in Memphis and independent testing will be performed after (!) Full STARS installation in Philadelpia [3]. Further, "in order to stay on schedule for Philadelphia, the contractor increased monthly spending (the "burn rate") in fiscal year 2002 to an unsustainable level [....] [to] about $10 million per month on average this year [...] an increase from a monthly average of $8 million to $9 million in the 3 prior fiscal years." [3] Mead concludes "We have little doubt that STARS hardware and software can be "installed" by November, but, in our opinion, it is doubtful that it will be operationally suitable by November to control live air traffic in Philadelphia and replace ARTS." [3] One might compare also the news reports by Bruce Nordwall in Aviation Week in March 2002 [4], and the AP brief in the International Herald Tribune on June 6, 2002 [5]. However, the IHT thinks that Mead said 71 open critical trouble reports, rather than the 258 that Mead says he said [3], and Nordwall says Mead said 175. Caveat lector. References [1] Status on the Federal Aviation Administration's Major Acquisitions, Memorandum from the DoT Inspector General, February 22, 2002. http://www.oig.dot.gov/item_details.php?item=701 [2] Minutes of the House Aviation Subcommittee Meeting of March 14, 2001, at www.house.gov/transportation/aviation/ 03-14-01/03-14-01memo.html [3] Follow-up Memo to FAA on STARS Acquisition, Memorandum from the DoT Inspector General, June 3, 2002. http://www.oig.dot.gov/item_details.php?item=806 [4] FAA Faulted for Slow Progress In ATC Modernization, Bruce D. Nordwall, Aviation Week and Space Technology, 18 March 2002, available to subscribers at www.awstonline.com [5] New air traffic system under fire, Association Press, International Herald Tribune, Thursday June 6, 2002, available at www.iht.com Peter B. Ladkin, University of Bielefeld http://www.rvs.uni-bielefeld.de ------------------------------ Date: Wed, 5 Jun 2002 14:10:15 -0700 (PDT) From: Ian Macky <ian.mackyat_private> Subject: Questions about new air-traffic computer system There are some highly scary quotes in this article regarding the new STARS (Standard Terminal Automation Replacement System) which is supposed to replace the hodge-podge of old air-traffic control systems: http://www.cnn.com/2002/TRAVEL/NEWS/06/05/faa.airtraffic.ap/index.html Players are the FAA Union (representing the flight controllers), the FAA technicians who are trying to roll out the new system, the equipment builder, Raytheon Co., and the DOT (Department of Transportation). [...] "DOT Inspector General Kenneth Mead ... said there were 71 specific software problems that could prevent the system from operating as designed, or could threaten safety or security. " "Mead said controllers in El Paso had to track airplanes manually because the computer system didn't properly display the flights." Union vice president Tom Brantley: "They don't believe it's operationally suitable," Brantley said. "It's failing. It has a lot of errors. They can't verify that it works because it fails a lot of the tests." FAA spokesman Scott Brenner said the only problems are the normal bugs (!) that accompany any new technology. [Ship it!] "When the [FAA] technicians refused to certify the system in Syracuse, New York, the FAA invoked a never-before-used [emergency] clause in its contract with its employees and ordered them to approve the equipment. The Syracuse system was turned on Monday night." Brantley: "The emergency clause was never intended for something like this. That was intended if there were an actual emergency." Blanche Necessary (!), a spokeswoman for the equipment builder, Raytheon Co., said the system was working well in El Paso and Syracuse. etc., etc. The RISKS are painfully familiar. Feel safer flying? ------------------------------ Date: Fri, 07 Jun 2002 19:17:18 +0200 From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de> Subject: COTS versus Bespoke ATC Systems I have noticed that people talking about air-traffic control system software like to make a distinction between "commercial off-the-shelf" (COTS) systems, and bespoke systems (for example, [1]). I have long found this distinction unimportant in this domain, because of the amount of bespoke tailoring required for any ATC installation. But its usage seems to me to be increasingly prevalent. So I'd like to quantify my view with two examples. The UK NERC system is an en-route system with 2MLoC software, which is about half common software (well, common with the now-defunct US AAS) and half bespoke. Development was budgeted at roughly GBP 500M (roughly $750M) in the time frame 1992-1996. It finally came on-line in January 2002, with significant cost overruns. (How expensive the development effort really was depends on how one does the accounting. My estimates of 1998 turn out to have been fairly accurate. [2]) Schedule slippage was 6 years on 4 years planned. The US STARS system was bought as a "COTS" system. STARS has undergone $660m of development work to date and a schedule slippage of 4 years (to an original schedule of 2 years until first installation in 1998), and is about two thirds code in common with other installations (e.g. in Germany), that is, 960 KLOC, and one third bespoke, 400+ KLOC. Full STARS software is thus two thirds as large as NERC software. Development has cost $660 million so far, for a November 2002 first (full) deployment. So the difference between "COTS" and "bespoke" appears to be one-sixth (the difference between two thirds and one half), and buying "COTS" systems does not necessarily save one from comparable cost overruns or schedule slippages. The LOC count for STARS is about two thirds that for the NERC software; the development costs to first deployment seem also to be comparable (NERC has only one installation, compared with STARS's planned 160+, so total program costs for STARS are higher than for NERC). And schedule slippages are roughly the same magnitude (if strict proportionality is your thing, total:planned time yields 9:4 for NERC and 6:2 for STARS). I conclude that "COTS" and "bespoke" is not a helpful predictive distinction for ease and comparative cost of development and deployment of ATC systems. References [1] Minutes of the House Aviation Subcommittee Meeting of March 14, 2001, at www.house.gov/transportation/aviation/ 03-14-01/03-14-01memo.html [2] Memorandum to the Transport Sub-Committee on the Costing of NERC, 26 November 1998, Memorandum FN 12 in (UK) House of Commons, Session 1998-99, Environment, Transport and Regional Affairs Committee, Third Report, The Future of National Air Traffic Services, pp52-55. Also available as RVS-S-98-02 of 26 November 1998, at www.rvs.uni-bielefeld.de -> Publications -> Special Reports Peter B. Ladkin, University of Bielefeld http://www.rvs.uni-bielefeld.de ------------------------------ Date: Fri, 07 Jun 2002 19:16:26 +0200 From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de> Subject: Re: Swanwick (Brady, RISKS-22.09) Chris Brady notes that the UK's New En-Route Center (NERC) at Swanwick, which came on-line in January 2002, crashed "yet again" on May 17th. Well, it did, but that's the first time, to my knowledge. Other recent outages, including one on March 27 in which I was caught, reported in RISKS-21.98 by Alistair Macdonald and Simon Waters, involved the National Airspace System (NAS) in West Drayton, which processes flight plan data which is fed to the NERC (Martyn Thomas, RISKS-22.02). When this data is generated and manipulated by hand, as during a NAS failure, many fewer aircraft are allowed into the system. The NERC is an airspace management aid. It is essentially a display system for data which comes from other systems (radar feeds, NAS, and so forth). The worst kind of outage is one in which the system fails in use. As far as I know, this has not happened. The BBC reported that engineers failed to bring the system fully back up after a system upgrade. A number of controller workstations were inoperative ( http://news.bbc.co.uk and search for "Swanwick") and service was restored fairly quickly (a matter of hours). As failures go, that is technically relatively benign, and completely benign as concerns safety. Of course, one would prefer not to have any. Brady says that the upgrade rendered "half the air traffic controllers' computer screens inoperable". The BBC reported that six out of twenty displays did not come up. Brady wonders how much all this outage is costing the airlines. The answer is: more than one might think, for the airlines also own and manage NATS. In a second note concerning difficulties some controllers are having in reading data on the screens at the NERC, Brady says "Obviously no-one thought to ask the controllers if they could actually read the screens clearly". On the contrary, controllers were evaluating and training on the system for at least two years before it went live in January, and it is public knowledge that they were very active with their feedback. NATS recognised in 1998 the need for a transition period more extended than the originally planned six months (I suspect they knew it well before that, but there would have been constraints on their replanning). Brady says that the NERC is "a disaster waiting to happen". It is unclear to me how he reaches this conclusion. He seems to think that one outage portends disaster. The record could equally well be taken as evidence for a well-managed and well-functioning system: one glitch in a system build in four months, and no live crashes. Reader's choice (along with any position in between). That all said, it is appropriate to wonder, as Brady does, why there is now a cluster of system slowdowns and outages, after years of successful NATS systems operation, including times when various systems have been strained to and even over what was thought to be their capacity and have proved much more resilient than most people had imagined. John Stuart Mill's Method of Differences would lead us to look for causal factors around what has recently changed, and the most obvious recent large change is the introduction of the NERC in January into the live airspace management system. In so far as there is a risk obvious to everybody, that was it. The management of this change will have affected other subsystems of the national airspace management, including NAS of course. One should not underestimate the technical challenge involved in switching to this new system. ATC systems are built in an environment in which requirements constantly change; they are safety-related and hard-real-time; and every one has components adapted from other systems and components unique to itself. All the system-engineering bad apples in one basket, except one: ATC system design has traditional employed "graceful degradation" in the guise of a radio-only reversion mode (which will sometime no longer pertain when traffic is allowed to become sufficiently dense, whereupon the ATC system will become safety-critical rather than safety-related). The airspace NERC covers includes some of the busiest in the world, and it is to my knowledge the largest live ATC system anywhere (2MLoC), though not the most expensive (that honor belongs to the deployment of STARS in the US, as far as I know). I imagine management of this enterprise has been learning by doing. And unavoidably so. For what it's worth, the NERC is a system Brits made work after America gave up. In the last few years, I have found myself puckishly drawn to two images. One is Dr. Johnson's "... dog walking upon his hind legs. It is not done well; but you are surprised to find it done at all." The other is that of old American cars in Cuba (the NERC uses a token ring architecture, after all). However, the US got its replacement systems (the 1.3 MLoC STARS, inter alia) no more quickly, by no means less expensively, and apparently with no less trouble (see [1] and [2]). Again, reader's choice. References [1] Dim STARS, Peter B. Ladkin, 7 June 2002. [RISKS-22.12] [2] COTS versus bespoke ATC systems, Peter B. Ladkin, 7 June 2002. [RISKS-22.12] Peter B. Ladkin, University of Bielefeld, Germany http://www.rvs.uni-bielefeld.de [Incidentally, Nancy Leveson reports that she was told STARS has 5MLoC, although that may represent different code boundaries from the smaller numbers. PGN] ------------------------------ Date: Fri, 07 Jun 2002 14:16:12 -0400 From: Nancy Leveson <levesonat_private> Subject: COTS versus Bespoke ATC Systems (Re: Ladkin, RISKS-22.12) > NERC has only one installation, compared with STARS's planned 160+ This is an important point... In the U.S., every ATC facility does things differently, often significantly differently. The problem of trying to develop and install 160 different systems with each different than the others is orders of magnitude more difficult from both a software engineering and installation standpoint. I was involved with a software tool that simply assisted TRACON controllers with arrival traffic. That software (about 500 KLOC of C code) contained 50,000 KLOC of what was called "adaptation data" that was needed for the Dallas/Ft. Worth installation with which I was involved. The experimental software was designed originally for DFW, with the intention of changing the adaptation data for other TRACON facilities. That has proven to be more difficult (and expensive!) than expected. ------------------------------ Date: Wed, 5 Jun 2002 11:33:05 +0100 (BST) From: Martin.Wardat_private (Martin Ward) Subject: *NY Times* new-zero security password system *The New York Times* has recently switched their paid user accounts from a reportedly hard to use and unreliable password system called Qpass to a new system. They then sent an e-mail message to all account holders: Now enter the following Member ID and password which we have created for you and click the "Log In" button. You will need to use this Member ID and Password to access your NYTimes.com premium products in the future. Member ID: ZZZZ Password: Your password is your Qpass User Name. The member id (ZZZZ above) is in the form firstname_lastname and Qpass user names are easily guessable, often repeated across many sites, and often not kept as secrets (for instance, message board posts are often tagged by username). *The New York Times* response to complaints about this system was that you could always change your password if you found yourself concerned about security. See http://www.oreillynet.com/cs/weblog/view/wlg/1482 for the full story. Martin.Wardat_private http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4 [An item by Marc Hedlund on this problem was noted by Peter Tonoli: http://www.nytimes.com/ref/membercenter/help/qpass_redir.html PGN] ------------------------------ Date: Tue, 28 May 2002 22:01:19 +0800 From: Ngiam Shih Tung <stngiamat_private> Subject: Tracking subway users by electronic fare card *The New York Times* (2 Apr 2002) recently reported that investigators trying to determine how a New York woman had contracted Anthrax during last year's bioterrorist attack had used subway computer records and her fare card to trace her movements in the city prior to her death. Admittedly, the victim was dead and privacy rights are generally recognised to be extinguished on death, but if a dead person's subway rides can be tracked, so can a live person's. Does anyone know what is the legal position on fare card records in New York and elsewhere ? Is there any legal barrier or policy that would prevent a transit authority from releasing fare card records to any law enforcement agency, or to anyone ? None of the media reports mentioned how far back in time the investigators were able to trace Nguyen's movements. Can anyone hazard a guess on how long New York's MTA keeps fare card data ? ------------------------------ Date: Wed, 5 Jun 2002 17:10:02 -0700 From: Nathan Good <ngoodat_private> Subject: Kazaa users inadvertently share their private files We have just finished a study that shows how user interface design flaws allow users on Kazaa to share their personal files without their knowledge. In a laboratory user study, only 2 out of 12 subjects were able to correctly determine that Kazaa was sharing their entire hard drive. We looked at the current Kazaa network and discovered that many users are sharing personal information such as email and data for financial programs such as Microsoft Money. To see if other users on Kazaa were aware of this and taking advantage of users ignorance, we ran a Kazaa client for 24 hours with dummy personal files. During this time, files named "Inbox.dbx" and "Credit Cards.xls" where downloaded from our client by several unique users. The tech report can be accessed here: http://www.hpl.hp.com/shl/papers/kazaa/KazaaUsability.pdf or from our lab web page at http://www.hpl.hp.com/shl/ Nathan Good, Information Dynamics Lab, HP Laboratories ngood @hpl.hp.com 1501 Page Mill Road, Palo Alto, CA 94306, USA 1-650-236-4437 ------------------------------ Date: Mon, 3 Jun 2002 01:57:08 -0400 From: Monty Solomon <montyat_private> Subject: Web glitch exposed Fidelity accounts Canadian account holders information was accessible, AP, 29 May 2002 A design flaw at a Fidelity Investments online service accessible to 300,000 people allowed Canadian account holders to view other customers' account activity. The problem was discovered over the weekend by Ian Allen, a computer studies professor at Algonquin College in Ottawa. Fidelity said it had fixed the problem and was offering customers the option of changing account numbers. http://www.msnbc.com/news/758979.asp ------------------------------ Date: Wed, 29 May 2002 15:56:36 +0100 From: "Patrick O'Beirne" <yg02at_private> Subject: Hacker threat posed by Excel spreadsheets http://www.silicon.com/a53624 Tuesday 28th May 2002 11:20am A security hole in Excel XP spreadsheets which could lead to a hack attack has been exposed. The discovery was made by independent security expert Georgi Guninski, who said on his Web site: "Excel XP tries to play with new technologies like XML and XSLT. Unfortunately the Excel seem so flawed that if the user opens a .xls file and chooses to view it with xml stylesheet arbitrary code may be executed. As script kiddies know this may lead to taking full control over a user's computer." Guninski, who has posted a sample of the code in his site, said users should not use XML stylesheets. ------------------------------ Date: Fri, 7 Jun 2002 09:44:20 +0100 From: Martin Wheatman <martin.wheatmanat_private> Subject: Re: More on typos and homographs (RISKS-22.11) I have been informed by Malcolm Pack that I was wrong about the protection of the .co.uk domain, which involves no checks whatsoever. The protected ones with stringent requirements are .ltd.uk and .plc.uk (which are private and publicly listed companies in the UK) and .sch.uk for schools and .ac.uk for academic institutions. <http://www.nic.uk/rules/rup1.html> [This message is a combination of Martin's and Malcolm's items. PGN-ed] ------------------------------ Date: Thu, 06 Jun 2002 22:04:38 -0400 From: Scott Nicol <snicolat_private> Subject: Re: More on typos and homographs (Wheatman, RISKS-22.11) Are you sure [about llyodstsb.com]? You may want to change your password: whois lloydstsb.com gives Registrant: Lloyds Bank Plc (LLOYDSTSB2-DOM) Network Services 64 Hopton Street, London SE1 9JQ United Kingdom whois llyodstsb.com gives Registrant Contact: FastNet Corporation Kwai Wei Suh (fastnet22at_private) 852-4326-7127 339 Huan Shi Dong Road Guangzhou, AL 510098 CN ------------------------------ 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.12 ************************
This archive was generated by hypermail 2b30 : Mon Jun 10 2002 - 16:01:48 PDT