precedence: bulk Subject: Risks Digest 20.91 RISKS-LIST: Risks-Forum Digest Thursday 8 June 2000 Volume 20 : Issue 91 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 and by anonymous ftp at ftp.sri.com, cd risks . Contents: White House admits over one year of VP's e-mail lost forever (Doneel Edelson) Julia Roberts wins control of her net name (NewsScan) Dot-Com nightmare -- domain-name hijacking (NewsScan) Cyber pirates (NewsScan) UPS kills power (Daniel Norton) Ford Explorers recalled due to "lock-up" (Alex Wiebe) Re: "Incompatible software" blamed for phone-book fiasco (Malcolm Pack, Kevin Parker) Bloat Dissections II (R.A. Downes) Re: How not to distribute white papers (Ian Goldberg, Stanley Chow, Paul Wallich) Re: Trash Compactor (Bernard W. Joseph, Robert Alberti, Bob Dubery) Re: India piggybacking on railway controls (Ramjee, Douglas W. Jones) Bcc: filtering vs spam - almost risk-free (Charles Arthur, Bob Jewett, Fredrik Staxaeng) Re: Blocking e-mail on headers (William Colburn) Y2K bug still manages to bite after five months (Paul van Keep) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 8 Jun 2000 15:45:35 -0400 From: "Edelson, Doneel" Subject: White House admits over one year of VP's e-mail lost forever The details are that when a contractor migrated the server for the Office of the Vice President (OVP) to NT 4, a new partition was created, an E: drive, in order to have the standard IS&T configuration (Information Systems and Technology division of the Office of Administration), and this drive was not added to the OVP backup schedule. This drive contained the OVP e-mail files. The migration was done in April 1998 and the problem was discovered by IS&T staff in May 1999. The full document is at: http://www.house.gov/reform/letters/00.06.07.wh.pdf ------------------------------ Date: Thu, 01 Jun 2000 07:33:01 -0700 From: "NewsScan" Subject: Julia Roberts wins control of her net name Actress Julia Roberts has won control of the Internet name www.juliaroberts.com, after an international arbitration panel ruled that an accused cybersquatter had no legitimate interest in that name and registered it in bad faith. The World Intellectual Property Organization, which is one of four designated arbitrators of Internet domain name disputes, cited evidence that the defendant, Russell Boyd, had registered names of several famous movie and sports celebrities, and had even tried to auction the Roberts address on eBay. In reaching its quick decision, the panel is demonstrating its willingness to extend protection to famous individuals, even if they haven't formally registered their names as trademarks. [*Wall Street Journal*, 1 Jun 2000; NewsScan Daily, 1 June 2000: http://interactive.wsj.com/articles/SB959810376180166493.htm] [NewsScan Daily is underwritten by IEEE Computer Society and Arthur Andersen, world-class organizations making significant and sustained contributions to the effective management and appropriate use of information technology. NSD is written by John Gehl and Suzanne Douglas, editors@NewsScan.com. NewsScan items are reproduced in RISKS with permission. PGN] ------------------------------ Date: Fri, 02 Jun 2000 08:12:05 -0700 From: "NewsScan" Subject: Dot-Com nightmare -- domain-name hijacking At least two Internet companies recently suffered a dot-com's worst nightmare -- their domain names were reregistered without their knowledge, and all traces of their legal ownership were erased. Web.net, based in Toronto, and Bali.com of Hong Kong both have suffered crippling losses from the hijacking, which occurred last weekend. Sleuthing by Web.net's owners found that someone in Jakarta, Indonesia had sent a forged e-mail to Network Solutions, asking them to redirect all the site's e-mail and Web site information to a new location. He then requested that the registration, which had been recorded with Network Solutions in 1993, be transferred to a Toronto registrar, and asked them to switch the ownership to someone living in Hong Kong. In Bali.com's case, an investigation shows that the name now belongs to someone living in Madrid, Spain. "These are what I call A-class domain names," says Toronto Star columnist K.K. Campbell. "If the person collected 50 of these, they'd have $5 million in assets they could afford to sit on for a little while until they're laundered and then resold." [*Toronto Star 1 Jun 2000; NewsScan Daily, 2 June 2000: http:www.torontostar.com/editorial/updates/top/20000601NEW01d_CI-DOMAIN1.html] ------------------------------ Date: Mon, 05 Jun 2000 09:01:10 -0700 From: "NewsScan" Subject: Cyber pirates A company called Havenco has built what it calls a "data haven" on an abandoned military platform in the sea, six miles off Britain's coast, in order to offer communications services to clients who want to avoid monitoring by governmental authorities. Declaring his small fortress a sovereign country beyond the reach of British law, Havenco co-founder and chief executive Sean Hastings, a 32-year-old U.S. citizen, says, "Technology has made it easier to move information and hide information. Soon it will be impossible to trace where money is and who has money, and that will eventually force governments to move away from income taxes and toward consumption taxes." [*The New York Times*, 4 Jun 2000; NewsScan Daily, 5 June 2000: http://partners.nytimes.com/library/tech/00/06/biztech/articles/04have.html] ------------------------------ Date: Wed, 07 Jun 2000 09:20:39 -0400 From: Daniel Norton Subject: UPS Kills Power I received this over the weekend: >Sunday, June 04, 2000 - 9:51:44 AM >[We] would like to apologize for any inconvenience caused by our brief >outage on Sunday, June 4. A UPS backup system burned out, cutting off >power to some of our systems. Ironically, it is the UPS's job to make sure >that our systems HAVE a constant power supply, so this problem was >unexpected, and something we would not normally anticipate. Thankfully, >one of our systems administrators who was on call noticed the problem and >went onsite to rectify the situation. >Thank you for your patience As it turned out, my own systems automatically paged me within 20 minutes of the failure. Why did they need someone to "notice" the problem? Daniel Norton ------------------------------ Date: Tue, 6 Jun 2000 08:46:18 -0500 From: "Wiebe, Alex" Subject: Ford Explorers recalled due to "lock-up" Here's the link: http://cbc.ca/consumers/market/recalls/reclfull/2000/06jun2000b.html The title is shocking: Ford recalls Explorer due to air bag problems The body is mildly humorous for those who can envision the slap stick comedy routine that could result from "An inoperative front windshield wiper system could adversely affect driver visibility." Looks like a bit of electrical noise can cause some central computer to lock up, the result is anything ON will stay ON, anything OFF will stay OFF. The risks are: There is no mention of the air bag in the article. Was this an eye catching hook? or was some critical detail left out of the article. Electrical noise locking up a computer? This is a problem as old as transistors - maybe older. A vehicle is a very noisy place, hopefully the [engin]eers who let this slip get their hands slapped. Alex Wiebe, Online Business Systems - (204) 982.0200 Voice: (204) - 982.0322 awiebe@online-can.com ------------------------------ Date: Mon, 05 Jun 2000 23:06:34 +0100 From: Malcolm Pack Subject: Re: "Incompatible software" blamed for phone-book fiasco (RISKS-20.90) I received this from a San Diego resident. I'll post it verbatim, because it will hopefully raise a smile, even if it doesn't add to your knowledge of the matter... | BTW, have you hoid about the fiasco/brouhaha here in sunny Southern | California? The fruits and nutz are alive and well. Picture this... | Sicily, 1945... no wait! | | Cox Communications, the local cable TV monopoly ain't making enuff money | on cable TV, so dey spread out ( SPREAD OUT! ) into being an ISP. Dat's | nice. Are they happy having money raining down on them faster then they | cam count it? | | OF COURSE NOT! So, what better idea then to SPREAD OUT! into providing | phone service too! | | So far, so good. Now the fiasco... | | It seems CoxPhone needs to send in their phone subscribers' | names/addresses/phone numbers to Pacific Bell aka PacBell. | | Well, it seems Cox sent in *all* their phone subscribers' n/a/#s, | including the folks paying extra for unlisted numbers. PacBell prints | the phone books and starts distributing them. 400k of 1.3 mil phone | books were distributed before someone, like a Cox phone subscriber hits | the roof when s/he finds out their 'unlisted' number is listed. | | Quick like a bunny, Cox calls PacBell to STOP DA PRESSES! | PacBell sez, no problem. Now it seems they can't get together to figure | out what to do. Junk the phone books they have left, retrieve the 400k | they distributed, who pays for what, etc. PacBell is going to | distribute the rest of the phone books as they don't want to lose | advertising dollars and it wasn't their problem that they didn't | notice Cox's database of names include unlisted numbers. | | Anyways, we'll have everyone suing each other while Cox and PacBell | claim a 'computer error' for the problem. So it wasn't their fault. | Everyone is nuts here! Must be sunstroke or the bottled water, IMO. Malc, Southend-on-Sea, UK ------------------------------ Date: Mon, 05 Jun 2000 15:02:57 -0700 From: Kevin Parker Subject: Re: "Incompatible software" blamed for phone-book fiasco (RISKS-20.90) An interesting story concerning the Cox/Pac Bell unlisted phone number fiasco. When I got the new phone book a few weeks ago from Pac Bell, I thought I'd look up an old acquaintance from high school to see if he was listed. Not only was he listed, but he lived in our housing development, two doors down from friends of mine. The next time I went to visit the friends, I stopped by to see if John was home. A woman and some kids were out front, so I asked her if John C. lived here. "Why do you want to know," she said. I knew him in high school, I replied. "What's your name?," she wanted to know. I told her. She then asked me how I got their address. I told her that it was in the new Pac Bell phone book. Impossible, she said, since ours is an unlisted number. Well, I told her, not only is your phone number printed, but so is your address. She became really concerned and said, "This is not good. John and I are both police officers, and John works undercover. He can't have his name published." A few weeks later the *LA Times* mentioned the snafu. [The risks of this episode run deep. PGN] ------------------------------ Date: Mon, 05 Jun 2000 15:01:05 +0000 From: root@radsoft.net (R.A. Downes) Subject: Bloat Dissections II (Re: RISKS-20.35) The bloat dissections continue. One remaining question in the article cited above and its follow ups is: "would dissecting such an application as RegClean at source level really reduce its bloat?" Curious coincidence then, that I should happen upon the source code to another Microsoft Registry cleaner - RegMaid, from 1993 - 95 (btw, this application might very well be the basis of the later RegClean project as well, judging from the embedded resources). Fact: the distributed executable to RegMaid is 153,600 bytes. Fact: it is distributed with its source code. Fact: after less than ten minutes work I got it down to 69,632 bytes. This is a savings of 83,968 bytes, or well over half the original image size. This is a new image only 45% the size of the original. And in less than ten minutes. I got 83,968 bytes of bloat off my disk that fast. Not to beat the dead horse but - just think about it. Ten minutes, 55% savings of 83,968 - and I had never seen this code before in my life. If this doesn't prove that bloat is inexcusable, I'll just have to send more examples. Cutting the bloat in that application, and attempting to estimate the cost of doing so, really misses the point too: the code itself is rather intricate, and this Rome was not built in a day. Barring the author's getting the architecture completely right from the beginning, the ten minutes it took to shave the EXE by 55% represent: 1. Half of only one coffee break. 2. A late arrival into the Thursday night Quake game. 3. One final tweak in the evening before dinner is really served. 4. Something to do on the laptop while commuting to work in the morning. It's *trivial*. Avoiding bloat has never been an effort, despite what the defenders of latter-day commercial software like to claim. Things can be done right from the beginning, or even if not, corrected in a negligible envelope of time. As for really astounding comparisons, try: http://radsoft.net/bloatbusters/sw_dns.htm Where we got a monster down from 3.5MB to just 7KB (seven kilobytes) in a single hour! It's professional pride on the one side -- and "who cares?" on the other. RA Downes http://radsoft.net ------------------------------ Date: Mon, 5 Jun 2000 14:44:45 -0700 From: Ian Goldberg Subject: Re: How not to distribute white papers (Re: Rubin, RISKS-20.90) Actually, the "unzip" program available for Linux (as well as, I assume, the equivalent unzip programs for Windows) is able to decompress these self-expanding archive programs. So there's no need to actually run the .exe file (which is good, since I don't *have* a Windows box on which to do so, anyway). Of course, once we do that, we discover that it expands into a Microsoft Word file... - Ian "Yes, I know about wvWare." [Similar comments from several others. TNX! PGN] ------------------------------ Date: Tue, 06 Jun 2000 14:48:32 -0400 From: Stanley Chow Subject: Re: How not to distribute white papers (Re: Rubin, RISKS-20.90) Avi Rubin (RISKS-20.90) talked about the difficulty of using "sacrificial" machines for quarantining potential malware. The latest release of VMWare (see http://www.vmware.com) has some useful features for this purpose. One can set up a virtual machine to have the desired O/S, patches, products, etc, then take a snap shot. You can then just copy a new virtual machine and throw it out after. (There are some path settings that have to be done, but I wrote a perl script). They also allow the disk to roll back, very cool. Note that my relationship to VMware is purely as a customer. Stanley Chow VP Engineering stanley.chow@cloakware.com Cloakware Corp (613) 271-9446 x 223 ------------------------------ Date: Tue, 6 Jun 2000 09:33:33 -0400 From: Paul Wallich Subject: Re: How not to distribute white papers (Re: Rubin, RISKS-20.90) Microsoft is more likely doing this to restrict distribution of the text file as it sees fit. The same savings of space could be achieved simply by delivering a zipped file and letting the user's software recognize the MIME type for decompression. Bundling the file into an executable, however, arguably meets the requirements of the Digital Millennium Copyright Act for a technological copy-protection mechanism, which makes unauthorized redistribution of the text a serious crime (where "serious" means "you could go to jail for more than a year"). I don't know if that particular white paper (or the page from which it was downloaded) contained a license agreement restricting redistribution of the text, but if it did, that would certainly appear to meet the DMCA requirements. (This kind of thing has already bitten other ostensibly open MSFT documents.) Indeed, depending on the state from which you accessed the document (or in which the server was located) UCITA might apply as well, in which case you could have to check the download page for links to any agreement governing use of the document, and recheck at regular intervals should MSFT decide to restrict the text in the future... > I could not believe that this is how Microsoft > distributes its white papers. It is beyond comprehension. If you view control, rather than dissemination, as the goal of putting documents on a web site, it's easy to comprehend. Paul Wallich ------------------------------ Date: Thu, 08 Jun 2000 09:40:26 -0400 From: bjoseph@mail1.industrynet.net Subject: Re: Trash Compactor (RISKS-20.90) In RISKS-20.90, Robotech_master wrote about a thief jumping into a weight-activated trash compactor. I live here where it happened and attest that the story was the first one that went over the wire services. As the story developed, new facts indicated that it was a garbage truck into which she jumped, and that the workers manually activated the compactor. That didn't make the wire services. In his book Fables for Modern Times, James Thurber said, "He who hesitates is sometimes saved." The news services probably should not have been so eager to publish before all the facts were known; Robotech_master probably should not have jumped on the story as a risk; I probably should not have answered. Bernard W. Joseph http://bbs.industrynet.net/html/bjoseph [Also noted by Vincent Dovydaitis, in http://dailynews.yahoo.com/h/ap/20000601/us/brf_compactor_death_3.html Hesitates? The object of the media is to sell their wares. *The New York Times* meticulously publishes corrections on Page A2 each day. Not everyone else is as careful. But RISKS tries very hard to correct the record, although if we waited for verification on such items, the wait would be very long... Incidentally, the risk of a hyperactive automated compactor still remains a risk. PGN] ------------------------------ Date: Wed, 7 Jun 2000 11:25:27 -0500 From: Robert.Alberti@born.com Subject: Re: Trash Compactor (RISKS-20.90) Two AP follow-up articles state that the compactor was not automatic, but was started by employees while the woman was inside. Unfortunately for her, the employees were apparently deaf... http://detnews.com/2000/metro/0006/01/d02-66693.htm http://www.detroitfreepress.com/news/statewire/sw13442_20000531.htm Robert Alberti, BORN Security Practice Lead ------------------------------ Date: Tue, 6 Jun 2000 08:31:05 +0200 From: "Bob Dubery" Subject: Re: Trash compactor kills shoplifter (RISKS-20.90) Surely when designing such a device, one is entitled to not have to cater for the fact that people may use the device for something that it is not designed for? I recently had someone tell me that a light fitting on the external wall of my house was a risk because somebody could get a shock from it. I replied that yes, somebody could, but only if they were trying to remove it - in which case they probably deserved the shock. Everyday I see indications that people are less and less inclined to take responsibility for their own stupidity or, in some cases, dishonesty. The risks to society of that attitude far outweigh the risks posed by automated hardware that doesn't cater for the whims of every turkey that walks down the street. ------------------------------ Date: Wed, 7 Jun 2000 17:33:44 +0530 From: sramjee@hss.hns.com Subject: Re: India piggybacking on railway controls (Bakowski, RISKS-20.90) Actually the guy called Ashok Jhunjhunwallah who is spearheading the efforts is a respected professor from IIT Madras and is working for the promotion of indigenization of technologies. He has been working with WILL and DSL on Cu for a while now... He has been reasonably successful so far. Moreover, the fact is that the railway stations are interconnected for normal voice traffic thru quad Cu cable. As a matter of building in a possible onfail crossover and to control the trains in future by some means, there is also a spare cable (running parallel to the whole system) which is *not at all* used. Ashok and friends want to make use of this spare, to start with, to operate a railway based Internet backbone n/w. And later, they are planning to factor in the spare capacity of the railway's fibre optic n/w as also by laying fresh cables. The spare cable will be used for high bit rate data link and WILL will / could be used in hubs at railway stations etc. Actually it looks like an elegant and pragmatic solution, political will permitting... This much said, I don't think there is a risk associated with this as the trans modes are not at all going to interfere with the existing comm systems for the management of Indian railways... But don't you think, it will be easier to "train" our guys to use the Internet this way? ;-) --ramjee ------------------------------ Date: 5 Jun 2000 22:13:08 GMT From: jones@cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: India piggybacking on railway controls (Bakowski, RISKS-20.90) No, this looks exactly like the way the Sprint long distance carrier got its service. Consider the expansion of the acronym: Southern Pacific Railroad INternal Telecommunication (recalled from memory, so it may only be approximately correct.) This company was founded to sell exactly the kind of excess bandwidth that the Indian railways are interested in exploiting, and there's no evidence that use of surplus capacity in lineside cables leads to trouble. Doug Jones ------------------------------ Date: Tue, 6 Jun 2000 10:36:55 +0100 From: "Charles Arthur, The Independent" Subject: Bcc: filtering vs spam - almost risk-free (Bean, RISKS-20.90) > My log files showed that 96% of the spam was being deleted by the Bcc: > filter and not even getting to the "clever" ones. That has been exactly my experience (I had 95%). I can't understand why Microsoft introduced content-based filtering. This is sure to be (1) slower (2) less accurate. The unique thing about spam is not its content, which can be just about anything, but the fact that it's, well, spam, and hence not aimed at you. Some spam programs do do individual addressing: these are the annoying 5% which elude the Bcc filter. For anyone who may expect to receive e-mail from people they've never met (such as journalists like myself) though, you can't just trash stuff on that basis. From being a major annoyance though, spam has become a minor irritation via Bcc filtering. It is now the only spam filter I use. (After other filters looking for stuff from mailing lists have done their work.) Maybe MS couldn't copyright Bcc filtering? ------------------------------ Date: Mon, 5 Jun 2000 21:08:07 -0700 (PDT) From: Bob Jewett Subject: Bcc: filtering vs spam - almost risk-free (Bean, RISKS-20.90) In RISKS-20.90 Ron Bean remarks that his Bcc: filter had few false positives. That filter is also used by many here, but that may have to change. There is now circulating a "Use BCC or be assaulted" hoax. The summary from http://www.snopes.com/horrors/mayhem/bcc.htm is: "Woman is stalked by on-line acquaintance; use the "blind carbon copy" feature in e-mail to prevent this from happening to you!" I am seeing increasing numbers of mailing list submissions which have no valid To: or Cc: address. Is it just ignorant users who have stumbled onto mailer features? I fear that they fear the above. I got the hoax in e-mail from the usual (fearful) person who sends me hoaxes. Did a spamster start the hoax? Bob Jewett ------------------------------ Date: Wed, 7 Jun 2000 18:46:08 +0200 (CEST) From: Fredrik Staxaeng Subject: Bcc: filtering vs spam - almost risk-free (Bean, RISKS-20.90) Any junk-mail filter made by Microsoft will soon have a 100% false positive rate. The spammers will check that their message passes the filter. Fredrik Stax\"ang | fstx@algorithmica.se | (+46) 8 678 09 94 ------------------------------ Date: Mon, 5 Jun 2000 21:24:01 -0600 From: Schlake (William Colburn) Subject: Re: Blocking e-mail on headers (RISKS-20.90) I define a lot of anti-spam here for my users without them ever being aware of it. I am always very careful about what I block, and I get e-mail summaries of the messages every day (which I actually look at every weekday). In addition to my own anti-spam, I also include pieces of Eric Allman's anti-spam from the knecht.mc file. Eric uses a rule that blocks "friend@" and "@public.com" in the "To:" field. If Eric Allman uses it, then it is good enough for me, or so I thought. Turns out that there is someone out there with a real last name of "Friend". His e-mail address was "friend@.edu", and mail from us to him was being blocked. I modified the rules to check for the specific case of "friend@public.com" in the "To:" line instead of "friend@anywhere" and "anyone@public.com". Then I contacted the guy whose e-mail I had blocked, and told him all about why his e-mail had been blocked. He was most grateful to me, and said that he had a lot of e-mail disappear all the time, and then he changed his account name. The risk here, is that automated processes can chug along for years without anyone ever noticing that they are broken. Poor Mr. Friend may have been silently losing e-mail for years, and could still have been losing e-mail today if it hadn't been noticed at my end. There is also a risk in someone trying to plug in someone elses solution. Eric Allman's personal machine is a lot different than my mail server with 3000 users on it. http://www.nmt.edu/~schlake/ ------------------------------ Date: Thu, 08 Jun 2000 17:28:40 +0200 From: Paul van Keep Subject: Y2K bug still manages to bite after five months To my amazement I was hit by a Y2K bug last week. Last Wednesday I was in Chalon-sur-Saone at a pickup point from La Redoute, a french mail order company. I was there to collect an order and pay for it. And that's where things went wrong. The clerk tried to enter my credit card into their computer system, but it kept refusing it, claiming the account was blocked (not the card.) Of course it took her a couple of tries before she realized that the problem wouldn't disappear by itself. So she called their head office in Roubaix to ask them to unlock the account. It took two long phone calls but in the end my card was accepted and I could pay for the goods. When I asked her why my card was rejected she said it was caused by a Y2K problem. Their computer system stores a maximum of two credit cards in an account profile. This is, as we all know, a big risk in itself. It simply means that my card information is available to anyone at La Redoute who has access to their customer system. In my case, two card numbers were stored, both my wife's and mine. But when they converted their system to be Y2K compliant the process erased a number of expiration dates including that of my wife's card and probably mine too, both being 06/00. When I tried to pay with my card, the correct expiration date was entered into the system again, but my wife's card number still had a blank date connected to it. So the system decided to block the account. There are two extra risks besides the obvious one of storing credit card information: wiping valid data while trying to clean up a database for a Y2K conversion and being overprotective when checking account information. Paul van Keep ------------------------------ Date: 13 Dec 1999 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact (Dennis Rears). .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. http://the.wiretapped.net/security/textfiles/risks-digest/ . ==> PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks . ------------------------------ End of RISKS-FORUM Digest 20.91 ************************