Subject: RISKS DIGEST 17.59 RISKS-LIST: Risks-Forum Digest Tuesday 2 January 1996 Volume 17 : Issue 59 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator [*** BEST WISHES FOR A RISK-REDUCED 1996! ***] ***** See last item for further information, disclaimers, etc. ***** Contents: A glitch in time shaves NIST (Ivars Peterson) Inside Microsoft is a floating crap game? (Peter J. Denning) Nearest-match alphabetic metrics (Henry G. Baker) Maine Yankee alleged to have deliberately run bad simulations (Daniel Smith) Bavarian Police Censors CompuServe (Klaus Brunnstein) 1st Net Wiretap (& CompuServe too) (David Kennedy) System modifications in grocery store (Michael Zehr) Dynamic IP mistakes (Bill Bereza) LoadDog - a risk reducer? (Julian Assange) Re: Timing cryptanalysis of RSA, DH, DSS (Saso Tomazic) TI e-mail snafu explained... (Bruce R Koball) Re: Colonels, bugs and spellcheckers (Jake Livni) Re: Robotic justice hoax! (Pete Mellor) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 02 Jan 96 13:22:11 From: ip@scisvc.org (Ivars Peterson) Subject: A glitch in time shaves NIST Did you hear about the problem that occurred when a leap second was added at midnight on New Year's Eve. Apparently, because of a mistake somewhere along the line, the leap second was added but the date was also inadvertently advanced to Jan. 2. I heard from a source at AP radio that the synchronization of their broadcast networks depends on the official time signal, and this glitch affected their operations for several hours until the problem was corrected. You can't even count on the national timekeepers to get it right all the time! And the year 2000 is coming up fast. Ivars Peterson, Math/Physics Editor, Science News, 1719 N Street, NW Washington, DC 20036-2888 ip@scisvc.org 202-785-2255 Fax: 202-659-0365 ------------------------------ Date: Sat, 30 Dec 95 08:29:16 EST From: pjd@cne.gmu.edu (Peter J. Denning) Subject: Inside Microsoft is a floating crap game? The Cobb Group publishes INSIDE MICROSOFT OFFICE, a monthly newsletter for users of Microsoft office products. In their January 1996 issue, they address a problem already discussed at some length in the Risks Forum --- floating point expressions in spreadsheets like Excel 5.0 that do not evaluate properly. They say the problem isn't an Excel bug, it's a consequence of the IEEE floating point standard 754. Many numbers with exact decimal representations do not have exact binary representations; arithmetic operations on the binary approximations may not give the same results as the same operations on the decimal numbers. They suggest a "workaround" -- wrap your floating point expressions in the ROUND() function -- e.g., ROUND(0.3-0.2-0.1,5) will yield 0 rather than -2.8E-17. This analysis, while helpful to spreadsheet users worried about the accuracy of calculations, is somewhat misleading. The IEEE 754 standard is an innocent bystander because the real problem, finite binary representations of decimal numbers, will happen with ANY binary floating point standard. The ROUND() function does not eliminate the problem, it only masks it behind a larger approximation error at the decimal level. Modern spreadsheets are so powerful that any user can set up numerically intensive computations and invoke all the problems that specialists have spent years to learn to avoid. For example, if you are doing a capacity study of a client-server system, you are likely to want to solve balance equations of the form x=Ax, where x is a vector of unknown numbers and A is a matrix. It is easy to set this up on a spreadsheet and utterly amazing how difficult it is to get the spreadsheet's iterative calculation algorithm to converge to a meaningful answer. This one can't be helped by the ROUND function. A far better answer would be for the makers of spreadsheets to offer numerical libraries that contain numerically stable algorithms for various problems, and urge users to select those packages rather than attempt their own, homegrown solutions. Peter Denning [What comes ROUND goes ROUND? PGN] ------------------------------ Date: Tue, 2 Jan 1996 09:02:22 -0800 (PST) From: hbaker@netcom.com (Henry G. Baker) Subject: Nearest-match alphabetic metrics I tried to finger someone at Carnegie Mellon University, and got the following reply: [cs.cmu.edu] finger: No names match "jwebb" , 1 nearest match is: Hooman Yaghoobi (hooman) This was not done on April 1st, and I don't think that I connected to the Monty Python server by mistake. I was quite impressed that the finger program considered this a 'match' at all, and am at a total loss as to what metric it could possibly be using. CMU CS department has a large number of people in it, so the chances of getting this match instead of some other would normally seem to be quite remote. (BTW, Jon Bentley did his thesis on best matches using a Euclidean metric at CMU if I recall correctly, although I doubt that CMU 'finger' is using his algorithm. :-) Henry Baker www/ftp directory: ftp.netcom.com:/pub/hb/hbaker/home.html Copyright (c) 1996 by Henry G. Baker. All rights reserved. [Well, at least "JWebb" and "Hooman Yaghoobi" have the letter "b" in common! Close enough for some purposes? PGN] ------------------------------ Date: Sat, 23 Dec 1995 18:28:45 +0001 (EST) From: "Daniel P. B. Smith" Subject: Maine Yankee alleged to have deliberately run bad simulations Peter Neumann's book "Computer-Related Risks" discusses some examples of problems with reproducibility and validation of computer simulations used to assess the safety of nuclear power plans. A story ("Maine reactor probe widens") in *The Boston Globe*, 23 Dec 1995, p. 17, adds some new twists. The story uses the phrase "it became clear that Maine Yankee had made widespread use of an allegedly inaccurate computer code to simulate accidents." The story gives me the impression that the charges are credible enough to have spurred action by the NRC. They are attributed to an anonymous whistleblower writing to Robert Pollard of the Union of Concerned Scientists, an organization to which I donate which can be vaguely characterized as "antinuclear." The whistleblower alleges that "in 1983, Maine Yankee officials developed a computer code that help predict the plant's emergency core cooling systems would be `grossly inadequate' in the vent of a pipe break. Maine Yankee `refused to even discuss the possibility' of upgrading the emergency safety system, and did not report the results. Instead... plant officials repeatedly modified the computer code over the next four years, but each `reasonable' computer-simulated accident had the same result: the fuel got too hot to meet NRC standards... finally in May 1989, Maine Yankee told the NRC that their new computer code, known as RELAP5YA, showed the plant could withstand a pipe break without a serious accident... Pollard said the NRC's [resulting] approval looks particularly bad because the agency had evidence in 1989 that RELAP5YA was not a reliable computer code." The RISK here is the popular presumption that anything that comes out of a computer is authoritative and objective, which made it easier for Maine Yankee, with the complicity of a lenient NRC official, to evade the purpose of the regulations requiring computer simulation. In addition, it appears from the story that Maine Yankee was in effect able to stall the NRC for at least five years by "claiming they were still working on the more sophisticated computer projection." When regulations are tied to the completion of a computer-related project it may be hard for officials to enforce deadlines because they recognize that big software projects are never completed on time. Daniel P. B. Smith dpbsmith@world.std.com ------------------------------ Date: Tue, 2 Jan 1996 15:26:25 +0100 From: Klaus Brunnstein Subject: Bavarian Police Censors CompuServe Last Friday (December 30,1995), a Bavarian State Attorney sent police to Germany's CompuServe offices to close down any German access to the Internet via CompuServe for services offering child pornography. The legal prosecution was based on paragraphs forbidding distribution of child pornography. As CompuServe felt (technically?) unable to close such access exclusively for its (about 200,000) German customers, they decided to close such services IN GENERAL, also affecting its 3,800,000 customers world-wide. No other German provider of Internet access (e.g. T-Online, a service of German Telekom) were NOT prosecuted (their headquarter is NOT in Munich). Following discussions in diverse newsmedia suffered from evidently missing knowledge about Internet in general and issues of responsibility of service providers. Though such aspects were internationally broadly discussed recently (e.g. the difference between responsibilities of a moderated group versus unmoderated ones), Bavarian police seemed rather unaware about such intricacies. Apart from the risk of living in a country with censorship-friendly bureaucrats, a UNIVERSAL RISK derives from the fact that NATIONAL LAW is applied in a way to influence the UNIVERSE. As countries with different cultural values and legal principles handle "freedom of information" (FOI) aspects differently, laws of countries with strongest restrictions in FOI may dominate more liberal ones :-). This may also apply to Germany itself, being a federal state with hardliners (such as Bavaria, which even did not sign the Federal Constitution 50 years ago :-) and more liberal countries (esp. those where some national service providers reside :-) Moreover, some lawyers doubt that the ancient paragraphs concerned with distribution of child pornography may apply to electronic distribution. Klaus Brunnstein (Jan.2,1996) ------------------------------ Date: 31 Dec 95 04:46:21 EST From: David Kennedy <76702.3557@compuserve.com> Subject: 1st Net Wiretap (& CompuServe too) Compiled from various wire services extracted from CompuServe's Executive News Service: Cyberspace wiretap leads to arrests UPI Northeastern US 29/12/95 14:46 By TRACEY L. MILLER > NEW YORK, Dec. 29 (UPI) -- The G-men have started bugging cyberspace. > The U.S. Secret Service announced Friday that a court-sanctioned > wiretap on the Internet has led to the arrests of three people who > allegedly advertised the sale of illegal electronic surveillance devices > through the on-line service, CompuServe. > "These arrests offer a glimpse into what crime and law enforcement > will look like in the 21st century," Brooklyn U.S. Attorney Zachary > Carter said at a Manhattan news conference. "Criminals are adjusting to > new means of communications in the same way we are." o Bernard Bowitz a German national, his estranged wife, Rachel, and Gregory Brooks of Seattle were arrested. o Seizures included a cellular phone cloning equipment: a "Lifetime Phone" capable of storing 99 stolen Mobile Identification Numbers (MIN) and Electronic Serial Number (ESN) combinations; a "Celltracker" that also allows the caller to eavesdrop on any nearby cellular conversation, and an "ESN Reader", which allows the user to steal the MIN/ESN combinations. Also seized laptop computers, scanners, covert transmitters and receivers hundreds of cellular phones and a satellite cellphone. Some covert transmitters were disguised as a three-pronged wall socket and a fountain pen. o AT&T Wireless Services Security noticed Bowitz's ads on CompuServe. They verified what he was offering and tipped the US Secret Service (USSS) and the Drug Enforcement Agency (DEA). Bowitz also advertised openly on a World Wide Web site. > The Department of Justice and the U.S. district court gave > investigators authorization to monitor the trio's outgoing and incoming > CompuServe E-mail messages, the first time permission for such a wiretap > over the Internet has ever been granted. > "This authorization was critical, since Bernhard and Rachel Bowitz, > and Gregory Brooks, perhaps believing that Internet communications were > immune from interception, spoke relatively openly in their E-mail > communications," said Brian Gimlett, who heads the Secret Service's New > York Field Office. o Operation has been ongoing for several months and ran from New York City to Seattle, Las Vegas and Hong Kong. o Bowitz communicated with an undercover DEA agent by e-mail and met him several times for buys. Bowitz also was laundering US$225K believed to have come from drug trafficking. > "The significance of this case should not be minimized," said > Gimlett. "This case has substantially impeded the spread of technology > that would undercut law enforcement's ability to conduct effective > electronic surveillance, endanger the telecommunications and > international business community and intrude upon the public's right to > privacy." o All three charged with wire fraud, the manufacture and sale of illegal intercepting devices, and conspiracy. Bernhard Bowitz, alone, was charged with money laundering. Bowitz is in the grey-bar hotel pending US$500K bail. His wife is out and about on bond in Las Vegas. Brooks was arrested in New York and is free pending his arraignment next month. o Joint investigation included AT&T and the New York Electronic Crime Task Force. The task force includes USSS, DEA and the New York Police Department. > "The Internet has become the new battleground for law > enforcement to fight crime," said Gimlett. Dave Kennedy [US Army MP] [CISSP] Volunteer SysOp National Computer Security Association Forum on CompuServe ------------------------------ Date: Wed, 27 Dec 95 10:16:28 -0500 From: tada@MIT.EDU Subject: System modifications in grocery store While not life-threatening, this situation is definitely sanity-threatening when one is in a hurry. I recently had to go to a local Star Market grocery store to purchase chicken stock. It turned out that the store was having a sale on chicken stock that day. Normally you might expect this would be a good thing from my point of view, but it added more than 5 minutes to my wait in the express checkout lane. Here's why: As with most large supermarkets, Star has UPC scanners connected to price databases to speed checkout. They also print weekly circulars with coupons. They recently started a program called Star Advantage which uses a scannable card instead of coupons. You present the card to the cashier, and when the bill is totalled the system automatically applies any of the weekly coupons for items you bought. [You're encouraged to present your card for all purchases, because you don't always know if something has a coupon or not. The subject of the store building up a database of what you buy, when, and how you pay for it is a privacy RISK for a separate article.] The checkout procedure has provisions for buying a large quantity of items at once. People often buy a case of something on sale, the cashier scans one item followed by "quantity 36" for example. People purchasing one or two cases of something often go through the express lane because the checkout is as fast as buying one or two single items. Coupons must always be entered and printed one at a time, however. Herein lies the problem. The two people ahead of me in the line both purchased two cases of the chicken stock, and both used Star Advantage cards. It took only a few seconds to scan one can of stock and hit quantity 72. When the purchase is totalled, the computer applies 72 coupons to the sale. But the software knows it has to print all the coupons individually, so it starts cranking out 72 or 144 lines (coupons might require two lines) on the receipt. The register printers are fast enough to keep up with items being scanned individually. But at a second or so per line of text, it's a long wait for the cashier, the customer, and everyone in line when it's printing the coupon information. This is an example of adding a feature without thinking through how it will be used. In the past, no one would pick up 36 circulars and tear out 36 coupons. Or if they did, they wouldn't consider going through the express line like that. Using systems for something other than what they were originally designed for is one of the stock RISKs we see here. What seemed like an idea that would help customers could end up leaving a fowl taste in their mouths if they wait too long in the express lane. I'm almost chicken to submit this for fear of seeing what commentary PGN will add to this "Case of the Delayed Customer." -michael j. zehr [Zehr gut, Michael, although if it were an Oriental chicken in Germany, my *stock* answer would be that you might have a Hahn Dynasty or Huhn-Nohs-Wat?, depending on its gender. We are Soupernuts? PGN] ------------------------------ Date: Sun, 24 Dec 95 13:05:03 -0500 From: Bill Bereza Subject: Dynamic IP mistakes At home I have a Unix workstation which I connect to the Internet using PPP from a service provider that gives me a dynamically assigned IP address. Yesterday when I connected I noticed that I was getting large amounts of incoming data over my low-bandwidth phone connection. I couldn't do anything through the connection. After checking some log files, I found out that my machine was receiving dozens of mail messages. All of the messages were addressed for a machine called XXXXX.org [I put X's in place of the real name]. I did a DNS lookup on this XXXXX.org and found that its IP address was the same as my assigned address. So my home machine was being sent mail messages from mail servers that thought my machine was XXXXX.org. To make it worse, since my machine knew it wasn't XXXXX.org, it would pass the mail onto a mail-relay host, but that mail-relay host would pass the mail right back since it still thought my machine was the right one. Each piece of mail that my machine received for XXXXX.org would be passed back and forth 18 times, and on a slow phone-line this essentially stopped me from doing anything else. The only thing I could do was drop the connection, reconnect with a new IP, and send some mail to a few sys admins. This problem could have gone unnoticed for a while, since most people connecting with dynamic IPs are probably not running mail server software, so their machines would just refuse the connection and the mail would just stay spooled on the mail servers waiting for a machine that will accept a mail connection. Another problem is that this could be used as a denial of service attack. You could send large amounts of mail to addresses you know are dynamic, and the next person to connect could be deluged. I think the biggest risk from this is that I was receiving dozens of possibly private messages intended for someone else. Mistakes in configuring name servers or assigning IP addresses could cause anyone's mail to be misdirected. ------------------------------ Date: Fri, 29 Dec 1995 05:16:47 +1100 (EST) From: Julian Assange Subject: LoadDog - a risk reducer? I have spent some time trying to maximise the ability of a of a unix system to self-diagnose impending or actual insanity. Not a risk (or is it? ;)) but I thought risk readers might be interested in this software. Julian Assange EMAIL: proff@suburbia.net FAX: +61-3-9819-9066 - - - - - - - - - - - - - - - - - - - - - - - - This is the first public release of LoadDog! Please read the man page below for implementation and archive location details. LOADDOG 0.90b(8) LOADDOG 0.90b(8) NAME loaddog - system crash detection dead man's switch SYNOPSIS loaddog [-d] [-l loadavg] [-m bytes] [-r retries] DESCRIPTION loaddog monitors system vital functions and if they repeatably fail shuts the system down (if possible with one minute warning) and reboots. Nearly all possible fail- ure points within loaddog itself due to serious system malfunction are handled, from file system unmounting and syncing requests hanging to loaddog suffering from segmen- tation violations. Currently the following vitals are tested every 60 seconds: system can create new processes system can execute new binary images (/bin/date is used as the test program) system can create new file descriptors system can create new tcp sockets system load average over the course of the last 15 minutes is within reason system is scheduling correctly system can allocate new virtual memory If running under Linux-1.3.51+ Loaddog also supports Alan Cox's in-kernel software deadman's switch /dev/watchdog which will perform a hard (nasty) reboot should the system become so unusable that even the Loaddog daemon can't run. OPTIONS -d Detach from the controlling tty. -l loadavg The highest acceptable 15 minute loadavg. Defaults to 10.0. -m bytes The minimum acceptable quantity of free virtual memory. Defaults to 2 Mb. -r retries Do not consider the system terminal until retries consecutive vital failures have occurred. Defaults to 3 - that is three consecutive failures over three minutes. EXAMPLE loaddog -d -l 6 -m 2097152 -r 2 Julian Assange (proff@suburbia.net) ARCHIVE The latest version of this program can be obtained from the Suburbia archives at ftp.suburbia.net or ftp://suburbia.net/pub/proff/original/loaddog.tgz. ------------------------------ Date: Tue, 26 Dec 1995 17:23:09 -0100 From: Saso Tomazic Subject: Re: Timing cryptanalysis of RSA, DH, DSS (Kocher, RISKS-17.53) The timing attack presented by Paul C. Kocher in his extended abstract of the paper "Cryptanalysis of Diffie-Helman, RSA, DSS, and Other Systems Using Timing Attacks" (ftp://ftp.cryptography.com/pub/kocher_timing_attack.ps) is really worth consideration, however I would like to stress there is no need for panic, mainly for two reasons: 1) Security of practical cryptosystems do not rest solely on security of crypt algorithm. In fact, cryptoanalysis attacks are rare, due to strong crypto algorithms that are presently known. More often cryptosystems are broken using other weak points of cryptosystems as insecurity of keys, bad key management, easy to guess passwords, computer screen radiation, monitoring the keystrokes of computer in network, ... The timing attack can be considered just as one of them, not the most dangerous one. For practical cryptosystem, it would be extremely difficult to measure exact timing of encryption process, at least much more difficult as to monitor keystrokes or to capture entire message from the screen. The intruder, who would be able to measure the exact timing of encryption in a multitasking environment, would probably also have access to everything else (i.e., secret message, secret key, passwords, ...) and thus no need to measure timing. 2.) It is not so difficult to rewrite algorithms to be resistant to timing attacks, i.e., to have execution time independent of secret key. For example, the algorithm to compute R = y^x mod n given in the Kocher paper can be simply rewritten as: Let R = 1. Let A = 1. Let z = y. For i=0 upto (bits_in_x-1): If (bit i of x) is 1 then Let A = (R*z) mod n Else Let B = (R*z) mod n Let y = y^2 mod n. Let R = A. End. to be resistant to timing attacks. ------------------------------ Date: Mon, 25 Dec 1995 12:53:40 -0800 From: Bruce R Koball Subject: TI e-mail snafu explained... (Koball, RISKS-17.58) ...and here's the explanation: > From ti_me@ti.com Fri Dec 22 23:18:47 1995 > Date: Sat, 23 Dec 1995 00:14:02 -0600 > To: (TI&ME users) > From: TI&ME Internet Information Service > Subject: E-mail on TI&ME Internet Information Service > > Last night, Texas Instruments sent out a short one-time announcement of > changes to the TI&ME Internet Information Service. The objective was to > simply inform you about service improvements. TI sent only one copy of > this e-mail to each user who had registered for this service. > > Unfortunately, a few users sent back an e-mail reply and also copied > the mail list address. We did not anticipate that anyone would do this > so we did not take the proper precautions to keep these replies from > being forwarded to the entire mail list. We deeply regret that this > caused you to receive extraneous e-mail as these responses were > forwarded. We were able to pull the plug on sendmail this morning and > stop the blizzard of e-mail. > > If you sent a reply requesting to be unsubscribed, we will honor that > request. The TI&ME announcement we sent last night also contained > instructions on how to do this yurself via http://www.ti.com. We wish > to provide information via e-mail only to customers who request it. > > We sincerely apologize for our mistake that allowed you to receive > multiple e-mail replies. We will take action to prevent this from > happening again. > > Sincerely, > Texas Instruments' Webmasters Bruce R. Koball, 2210 Sixth St, Berkeley, CA 94710 1-510-845-1350 bkoball@well.com (fax) 1-510 845-3946 ------------------------------ Date: Wed, 27 Dec 1995 18:28:13 -0500 From: jakel@eos.bony.com (Jake Livni) Subject: Re: Colonels, bugs and spellcheckers (Oram, RISKS-17.58) >Convoluting matters further, in the Canadian and British militaries, >lieutenant is pronounced 'lef-tenant' yet spelled the same. And the AF >equivalent of a captain is a colonel, which is also not pronounced as it >sounds because of a horrific entomological journey from Italian via French >to English. ^^^^^^^^^^^^^ I think the intended word was "etymological", the study of of historical linguistical change. "Entomological" relates to the study of insects. Should we call this a "bug" or should we blame it on an overenthusiastic spellchecker (and not a spell checker). :-) Jake Livni jakel@eos.bony.com [Yes, the error did seem quite suitable for RISKS. Correct spelling is a tough roach to haugh. PGN] ------------------------------ Date: Thu, 28 Dec 95 18:54:23 GMT From: Pete Mellor Subject: Re: Robotic justice hoax! (Matthews, RISKS-17.47) Sean Matthews writes:- > While this particular project may be a hoax, the inspiring idea is certainly > not. Prof. Robert Kowalski at Imperial college in London is/was closely > associated with a project to encode UK immigration law (so far as I > remember) as an expert system of logic program clauses. As a junior executive officer in the UK Civil Service (Home Office, Immigration Department) many years ago, my first wife had the job of responding to enquiries from abroad regarding immigration. Her work consisted of reading each letter, selecting from a set of trays one of around 50 standard pre-typed replies, clipping the reply to the letter, and placing it in the out-tray from where it was taken to be checked by a more senior officer before being signed and posted. It seems like *exactly* the sort of task that could be computerised, and would not even require a particularly "expert" system. In fact, any system with any real intelligence would probably do what my wife did after three days: crawl up the wall screaming and hand in her notice! Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422, Fax: +44 (171) 477-8585 E-mail: p.mellor@csr.city.ac.uk ------------------------------ Date: 6 September 1995 (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) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for further information] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks RISKS ARCHIVES: "ftp ftp.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://unix.sri.com/risks [if your browser accepts URLs.] ------------------------------ End of RISKS-FORUM Digest 17.59 ************************