Subject: RISKS DIGEST 17.32 REPLY-TO: risks@csl.sri.com RISKS-LIST: Risks-Forum Digest Weds 6 September 1995 Volume 17 : Issue 32 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, etc. ***** Contents: Mispelcorekters (Thiomir Glowatzky via Martin Virtel) Bogus check for $95,093.35 deposited and retained! (Alan Wexelblat) Voting by Phone in the Netherlands (Alex van Es via Clive D.W. Feather) Automated bridge risk (Erkka Sutinen) Another "Units" crash... (David Lesher) Mass Pike Electronic Toll Collection Update (Rich Lethin) MS-Word "Find File" feature scales poorly with MAE/NFS (Jeff Anderson-Lee) 10 Arguments Against Commercial Key Escrow (CKE) (Marc Rotenberg) Pittsburgh HOV Follow-up (Chuck Weinstock) White house "hack" (Martin Virtel) US White House Hacked? sendmail or SMTP? (Matt Bishop) Re: newspaper risks (Dan Gillmor) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 6 Sep 95 8:01:30 PDT From: "Peter G. Neumann" Subject: Mispelcorekters Martin Virtel wrote a wonderful article "Fehler, Fehler, Feler" in Die Zeit (Nr. 33, 11 Aug 1995, page 49) observing the 10th anniversary of RISKS. The following item came to him as a response from a German teacher, Thiomir Glowatzky, of Bamberg. I include the German, with "u umlaut" being represented as "|", but the essence of it is simply that the spelling corrector wanted to replace Kafka, Musil and Schnitzler with Kaffee, M|sli, and Schnitzel. It must have been from Hungery. PGN >From: M.VIRTEL@bionic.zerberus.de (Martin Virtel, tel/fax +49-8421-80995) "Die auf dem PC getippte Arbeit setzte mein Sch|ler einem Rechtschreibprogramm aus, ohne die darin vorkommmenden Schriftstellernamen Kafka, Musil und Schnitzler ins Programm aufzunehmen. Er wunderte sich, als beim Ausdruck 'Kaffee', 'M|sli' und 'Schnitzel' auftauchten." ------------------------------ Date: Wed, 6 Sep 95 10:39:51 -0400 From: Graystreak Subject: Bogus check for $95,093.35 deposited and retained! RISKS readers may be interested in the story to be found on the web at http://www.dnai.com/g-think/$$tablecontents.html It tells of a man (Patrick Combs) who, according to himself, deposited into an ATM a "check" for $95,000. This "check" was one of the authentic-looking come-on gimmicks that we so often receive in our junk mail. In this case, it was a solicitation for a get-rich-quick scheme and the "check" was purportedly an "example of the kind of money" one could earn using this scheme. The "check" bore a valid signature and account number as well as a realistic amount ($95,093.35). The only indication that it was not a valid document was the phrase "not negotiable for cash" inconspicuously placed in a corner. More interestingly, the "check" met all nine of the legal criteria for a valid bearer document. Apparently, the warning message was not seen and the amount was credited to Mr Combs' account. The amount remained in his account for several weeks and, after repeated inquiries to the bank Combs withdrew the money in the form of a cashier's check, which he then placed in a safe-deposit box. Throughout the story, Combs maintains that he had/has no fraudulent intent. The fact that he has not spent a cent of the money despite ample opportunity to do so lends credence to his claim. Eventually, of course, the bank detected the error and demanded its money back. Its method of treating Mr Combs will be familiar to many of us who have had to deal with inflexible financial institutions. However, the story is complicated by the fact that (by both law and many legal precedents) Mr Combs is now legally entitled to keep the money. Banks must refuse payment within a fixed time period and must serve notice in a specific manner, both of which Combs' bank has failed to do. The story details his research into the legal side of it, as well as his negotiations with the bank. In reading this story, a number of RISKS-related issues came to my mind: - Combs apparently ascertained that none of the bank tellers would be held liable for the fault, since the "check" was deposited into an ATM. But *someone* had to open those envelopes and verify the data. - Combs comments that he was under the impression that checks of greater than a certain amount were subject to additional verification. That clearly did not happen here. Why? No information is given in the story as to what part of this process is manual and what is automatic. - Through a bit of social engineering, Combs claims to have traced the flow of the money: apparently his bank got the money from the clearinghouse bank in Chicago (which also missed the non-negotiable warning). It was not until the "check" was sent to the Federal Reserve bank that it was rejected; the money was then retrieved by the Chicago bank from Combs' bank which no doubt assumed it could get the money back from Combs. However, they waited 16 days from the time they received notice of their error and by that time the money was gone from Combs' account. Who was responsible for generating notice to Combs? How did they fail to take action? Again, it is unclear how much, if any, of the bank's procedures are automated. - There is also a social RISK in that the bank's treatment of Combs has clearly exacerbated the problem and generated a good deal of cost and negative publicity for the bank (as well as the obvious monetary loss). Banks, despite being in a customer service business, have gained a widespread reputation for inflexibility and for gouging customers for ever-increasing charges and fees. Combs asks readers to suggest what he should do, and opinion is clearly against the bank. As new digital technologies make cash and location less important, banks RISK putting themselves out of business altogether if they are not seen to be serving their customers. It seems clear that a large number of procedures must have broken down in this story. It is also interesting that the Federal Reserve, which deals with a much larger volume of paper, was able to catch an error that two local banks did not catch. I confess that I voted for Combs to keep the money or give it to charity, in large part because of my reaction to the way the bank treated him and how I have been treated by banks in the past. I hope RISKS readers find the story interesting and worth their time to investigate. Alan Wexelblat, Cyberspace Bard, MIT Media Lab - Intelligent Agents Group 617-253-9833 wex@media.mit.edu http://wex.www.media.mit.edu/people/wex/ ------------------------------ Date: Wed, 6 Sep 1995 09:49:57 +0100 (BST) From: "Clive D.W. Feather" Subject: Voting by Phone in the Netherlands Seen in Telecom Digest (aka comp.dcom.telecom): > Date: Mon, 4 Sep 1995 16:36:54 +0200 > From: alex@worldaccess.nl (Alex van Es) > Subject: Voting by Phone in the Netherlands > > Every four year there are elections in the Netherlands, and because of > different reasons (bad weather or having to work) many people never > even bother to go to the polling booth. In order to make voting easier > the Dutch government made it possible last year for people who live in > the city of Utrecht to vote at the railway station, so they would be > able to do it on their way to work. Yet, many people don't travel by > train to work, and even if they do, they might not have the time at > the railway station to stand in line. Therefor the government is > currently considering the option of voting by phone. People who decide > to vote by phone will have to call a special access number. The > number will be one of a 06 (900 type) kind, leading to the call > factory in Rotterdam. The call factory is a special exchange for > handling up to 1,6 million phone calls an hour. At this moment most > time is invested in making sure the system is safe, and fraud will not > be possible. If this system is going to be used in the future, the > Netherlands will be the first country to make televoting for > parliamentary elections possible. > > Alex van Es Alex@Worldaccess.NL, Apeldoorn, The Netherlands +31-55-421184 > > [TELECOM Digest Editor's Note: Suggestions -- and for that matter, full- > bodied, substantial proposals -- regarding 'vote by phone' have been > made here in the USA also, but nothing has come of it. All the usual > excuses ('there would be too much fraud', etc) have been tossed out as > reasons it would not work, even though fraud prevention techniques have > been provided. Then there were the privacy freaks who insisted that > the tighter the fraud controls, the more likely there would be massive > invasions of privacy in the 'voting booth' if controls were established > identifying the phone number being used and some other personal identifier > such as social security number, etc. They can't seem to understand that > there *are* ways to identify the user and validate his *right to vote* > without necessarily examining the vote being cast. Nor can they seem to > understand that there are competent programmers who share a love for > their country and a sense of patriotism which would develop the needed > software in an instant -- as fraud-proof and fool-proof as the present > manual system if not more so -- if it meant that more Americans would > participate in the process. They would do so with a sense of integrity > and ethics which would *never* willfully violate anyone's privacy. > > Even starting on a small scale for 'beta testing' purposes seems to be > out of the question. The Chicago Board of Election Commissioners (an > independent government agency responsible for administering elections of > all sorts within the city) has been shown how telephone voting, either > with modem and computer or by touch tone buttons alone) would work quite > well. They have been shown how, with the cooperation of the banking > network, voting could be done at any ATM machine. Of course *not everyone* > has an ATM card, and of course *not everyone* has a computer and modem, > but these would be two additional ways of 'getting out the vote'. They > have been shown how even in conventional voting booth arrangements, a > terminal hooked to their central computer could be used to eliminate a > huge amount of manual tabulating required, and the fraud that can accompany > same, to say nothing of being able to eliminate many of the 'middle-man' > election judges found at each polling place. > > They'll hear none of it ... which is odd, considering how desperate they > are getting to find voters these days. They do registrations now at all > sorts of places -- even at the Cook County Jail where they always get > *thousands* of voters each year for selected candidates -- just to round > up anyone they can who is willing and wants to bother to vote. They keep > harping on the fraud problem using phone voting, but believe me you, > nothing compares to the fraud we have here now with the crooked election > judges and the low-level Democratic politicians who hang around the > polling places on election day, bringing in voters by the bus load from > old-people's homes, etc. We could have had tele-voting here years ago had > they wanted it. As they say in Chicago, 'vote early and often!' PAT] Clive D.W. Feather, Demon Internet Ltd, 322 Regents Park Road, Finchley, London N3 2QQ clive@demon.net Tel: +44 181 371 1000 ------------------------------ Date: Thu, 31 Aug 1995 21:26:34 +0300 (EET DST) From: Erkka Sutinen Subject: Automated bridge risk (I was absent of the town at the time of this event, so there may be some errors, but the core is solid.) This week Kuopio, a small town in Finland faced sudden problem with automated bridges. The town is located in the middle of a lake district, wonderful transportation method during past centuries but a problem if you use cars instead of boats. The only way from the town to north (to airport among other places) is through one bridge, which has one (small) openable bridge for boats. Suddenly one morning the bridge, which (as you may have guessed) is computer-controlled, opened without any reason in the middle of the morning rush. No-one going to work could get anywhere in the north side of the town. The bridge was not manned (since it was not in use at that moment) and it took some time to get anyone there. The bridge computer didn't do anything and there was no manual button to force closing of the bridge(!!!!!). The bridge had to be closed by hand, using crank, by several strong men turning the wheels. Interviewed representative said that the situation occurred due to "unpredicted combination of events" (what else :-}) if my memory does not fail me. (What events they were, I haven't heard of.) The risk is old and well-known on this list: Automation of something without leaving backup-system. The good side is that the automatic lights and fences connected to the bridge-system worked well and warned people that the bridge is raising, so there was no risk to people. Erkka Pietari Sutinen University of Oulu, Finland Dept. of Information Processing Science eps@rieska.oulu.fi / sutinen@csc.fi ------------------------------ Date: Thu, 31 Aug 1995 10:19:55 -0400 (EDT) From: wb8foz@netcom.com (David Lesher) Subject: Another "Units" crash... The NTSB ruled that human error augmented by fatigue probably caused the crash of a DC-8 cargo plane Feb. 16 at Kansas City International Airport, killing all three crew members. [...] The NTSB found the pilot lost control of the DC-8 on takeoff, mainly because the flight engineer used the wrong calculations to determine how fast to supply power to the engines. The engineer based his calculations on Fahrenheit temperatures instead of centigrade as he should have. [Excerpts from AP reports] RISKS readers will recall the Gimli incident in Canada where another metric conversion error led to a shorter-than-expected flight. As often pointed out by my EE prof's, calculators let you get the wrong answer 10 times as fast.... ------------------------------ Date: Thu, 31 Aug 95 13:45:38 EDT From: lethin@ai.mit.edu (Rich Lethin) Subject: Mass Pike Electronic Toll Collection Update I was listening to Boston rock-and-roll station last week when I heard an advertisement criticizing the Mass Pike's RFP for an electronic toll collection system. I called the company, ATCOMM, based in Marblehead, Massachusetts and spoke with Mike Greenstein to get details: Recently, the Mass legislature passed a law requiring the Pike to develop standards for electronic toll collection. The Pike responded with a Request for Proposals (RFP) which substantially narrowed the allowable technical solutions. The Pike's RFP specifically wants to have a centralized accounting mainframe. As the driver approaches, an electronic tag (about the size of a pack of cards) is polled and this is used to debit his account. The user's balance is displayed by the tool booth as the driver goes through. Information about the user's movements are entered immediately to the centralized database. ATCOMM sells a technology which adds a keypad, microprocessor, and an LCD display to the tag. The keypad allows the user to ask questions about his balance at any time, and the LCD displays the remaining balance. ATCOMM's technology was specifically excluded by the narrow RFP and so the decided to go to the radio campaign to make their case, alert the drivers and other stakeholders that this is an issue. I asked Mr. Greenstein about the motivation for the Pike's RFP and he was unwilling or unable to speculate. The Mass Pike is a quasi-independent agency by virtue of its bond contracts and independent of governmental oversight. The Pike has been a source of patronage jobs with mutual backscratching between the Democratic party government officials and the Pike's authorities. However, recently, Gov. Weld has moved to bring the Pike under government control and this will take place Summer next year. According to Mr. Greenstein, there's no concern for privacy of drivers, and this does not appear to have been the Pike's motivation for issuing the RFP calling for a centralized database. ATCOMM could be programmed to ensure privacy, but currently it is not. There's some small benefit to ATCOMM's technology, because the information about the movements of specific cars through the tolls is not centralized, but kept at the toll facility. However, this can be collected periodically so there's little difference from the centralized scheme. Probably, privacy is not a big selling point for companies making proposals to governmental RFPs. Concurrent VLSI Arch. Group 545 Technology Sq., Rm. 610 MIT AI Lab Cambridge, MA 02139 (617)-253-0972 ------------------------------ Date: Thu, 31 Aug 1995 14:40:54 -0700 From: Jeff Anderson-Lee Subject: MS-Word "Find File" feature scales poorly with MAE/NFS Macintosh Application Environment (MAE) is a product that runs on Sun and Hewlett-Packard workstations, emulating a Macintosh computer under X-Windows. It allows 680x0 based Macintosh applications to run on the workstation accessing the Unix filesystem (including NFS partitions) as if they were folders and files on the Mac. Recently, a secretary who was new to the Mac environment tried to access a file she had saved from her mailer in Unix from MS-Word under MAE. She knew what the name of it was, but wasn't sure *where* it was, so, when she saw the "Find File" feature in the "Open File" dialog box thought that she would try it... Unfortunately, the workstation was connected to a 256GB NFS fileserver which MS-Word under MAE dutifully began to search. Furthermore, neither MAE nor MS-Word made it apparent how to cancel the request once it was set into motion. (Alt-'.', which often works in a Mac environment did nothing.) Even stranger, the X11 window manager ceased to respond to requests to pop-up the window's menu to close it. Fortunately, there were still some Unix windows around to "kill" the MAE process--but at a loss of any unsaved information created previously in the MAE session. The RISK? Perhaps that scale factors were not considered in the design of the "Find File" feature. The Mac Style Guide states that all applications must confirm operations that are either not "undoable" or which may perform extensive changes. Perhaps a similar rule should apply: all operations which may take an extensive amount of time to complete should include a status window with a cancel operation. Or perhaps, the cancel operation *does* exist, but by the time I got there the X display server was not refreshing the "exposed" regions on the MAE window (after having been covered and uncovered) so that only a rapidly changing filename was visible in the middle of an otherwise blank region of the screen... In that case, the RISK may be in reliance of X-Windows or other software emulation to reliably reproduce the emulated hardware environment. Jeff Anderson-Lee jonah@eecs.berkeley.edu ------------------------------ Date: 31 Aug 1995 17:26:59 U From: "Marc Rotenberg" Subject: 10 ARGUMENTS AGAINST COMMERCIAL KEY ESCROW (CKE) 1. Increased network vulnerability. The key escrow configuration necessarily increases the likelihood of communications compromise and improper interception by third parties. Computer crime will skyrocket. 2. Policy incoherence. The key management needs of business differ sharply from the real-time intercept plans of law enforcement. The latter has little to do with the former. 3. Emergency circumstances taps. The current wiretap law permits the initiation of a wiretap *without court order* upon a certification that emergency circumstances exist. If this procedure is built into the CKE procedure, then there will be *no judicial review* prior to the disclosure of keys. 4. Complexity. Has anyone really given thought to how many communications will be encrypted in 20 years and what the key management requirements will be to develop a unitary key escrow system to satisfy the government's concerns? Its staggering. 5. Cost-benefit. The Bush White House rejected the original digital telephony bill for this reason. As time has passed, the argument has strengthened. The cost to match each new technology with an intercept capability is rising rapidly. The benefits of wiretap are falling. 6. Intrusiveness. How will the government monitor compliance by escrow agents and crypto users with statutory requirements? Will separate penalties exist for escrow agents and key holders who negligently fail to comply with procedures even though there is no evidence of criminal conduct? If so, law enforcement could "pull over" anyway on the info highway who is using crypto (the broken tail light problem). 7. The future of PGP. Will PGP and other non-escrow schemes be permitted if CKE is adopted? What will be the implications for developers and companies in the communications industry? The 8. Ability to Defeat. It will be trivial to send non-interpretable communications in a key escrow network -- foreign dialect, bury text in graphics, speak in code! The bad guys know all about this. They've assumed their phones were tapped for years. 9. The Long Term. Where does the CKE policy take us in 20 years? A secure network where crime is more difficult or a platform for surveillance of private communications and compromise of business information? 10. Oklahoma City. For more than a year, the White House warned that if Clipper was not adopted terrible terrorist incidents on US soil similar to the World Trade Center could not be prevented. Guess what? It happened and Clipper, CALEA and all these other dumb ideas didn't prevent the deaths of 170 innocent people. The FBI hadn't even bothered to request a wiretap warrant for this type of threat (arson, weapons, explosives) since the late 1980s. Marc Rotenberg Electronic Privacy Information Center (www.epic.org) ------------------------------ Date: Wed, 30 Aug 95 11:30:58 EDT From: Chuck Weinstock Subject: Pittsburgh HOV Follow-up A couple of follow-up items regarding the recent head-on crash on Pittsburgh's HOV lane. A Pennsylvania Department of Transportation worker has admitted that he made a mistake and opened the northbound gate before closing the south- bound gates. There is no interlock of any sort to prevent this. The worker in question has been fired. There apparently is still some question as to whether this led to the accident or not. I mentioned some dual-use ramps downtown. One of the ramps in question (near Three Rivers Stadium) actually is a single ramp with an exit and an entrance. When the entrance is officially closed there is a barrier across it. To enter erroneously (if the barrier is in place) one has to make an extremely acute right hand turn onto the exit ramp (or be traveling the wrong way on the major street surrounding the stadium.) I view this as no different than the arrangements on many such lanes around the country (e.g., the express lanes on the Kennedy Expressway in Chicago.) The other downtown ramp in question is at Anderson Street, and as best I can tell from the photos is a true dual use ramp. There is no possibility of a barrier at this location. Chuck Weinstock ------------------------------ Date: Thu, 31 Aug 1995 06:12:00 +0200 From: M.VIRTEL@bionic.zerberus.de (Martin Virtel) Subject: White house "hack" (Re: RISKS-17.31) Just to clarify: the attack method reproduced on page 185 of the September 1995 issue of C'T (which allegedly lead to forged mail From: ) is the telnet-to-sendmail-type mail forgery attack described many times, i.e. in alt.2600.faq available from mail-server@RTFM.mit.edu among others. In my eyes, using the old sendmail on one hand and banning the export of software capable of message authentification (this is, PGP) on the other makes up to a pretty bad (this is, risky) policy regarding electronic exchange of information. One more thing: does anybody around have a CCopy for me (m.virtel@bionic.zerberus.de) of a newsgroup posting send through the white house mail server? Martin Virtel tel/fax +49-8421-80995 ------------------------------ Date: Thu, 31 Aug 1995 14:08:45 -0700 From: Matt Bishop Subject: US White House Hacked? sendmail or SMTP? (Kennedy, RISKS-17.31) The article "US White House Hacked?" describes a series of forged messages sent to computer users; the sender was supposedly Bill Clinton. It then describes the reaction to it, including a dispute about whether the White House computer was broken into and the forgeries sent from it. What surprised me the most was the assumption that sendmail had been used or even that a break-in had occurred. Why? In 1985, we forged a letter from Opus the Penguin at whitehouse.arpa (which didn't exist) to our office staff asking for more kippered herring heads at our weekly meetings. (Those meetings were in the bloomin' county ...) All it takes is knowing the SMTP protocol, and being able to access port 25. So, given the information in the article, I'd go with Occam's Razor and assume someone did it that way. ['Occam dead, Matt!] In particular, this part: He claimed the White House uses an old version of software for electronic mail handling which is obsolete. This program makes it possible to falsify mail. Many other System Administrators also use this older version, leaving the network vulnerable to similar attacks. was somewhat depressing; I would think the editor of a computer magazine would know better than to assert mail forgery is due to an "old version of software" and not due to the nature of the underlying protocols. Matt [And Malte Borcherding sent me a message From: Bill Clinton just to remind us that one does not have to hack the White House. PGN] ------------------------------ Date: Wed, 30 Aug 1995 14:17:49 -0700 (PDT) From: Dan Gillmor Subject: Re: newspaper risks Misdirected stories and headlines are, of course, not new. The Boston Globe is famous for its headline, over an editorial about then-President Carter's economic policies, which said: "Mush from the Wimp." Dan Gillmor, Computing Editor, San Jose Mercury News, 750 Ridder Park Drive San Jose, CA 95190 dgillmor@sjmercury.com 408-920-5016 Fax: 408-920-5917 ------------------------------ Date: 5 September 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from 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. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to the newly automated , with first text line SUBSCRIBE or UNSUBSCRIBE [with option of E-mail address if not the same as FROM: on the same line]. HELP gives instructions on using the Majordomo listserver in other ways, although not all are implemented for RISKS. ** UNSUBSCRIBE is not yet automated for early subscribers, as Majordomo is not yet fully installed. 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. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [yes, VL = volume, IS= issue] (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk .) RISKS ARCHIVES: ftp://unix.sri.com/risks if your browser accepts URLs, or ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP; Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.32 ************************