Subject: RISKS DIGEST 17.94 RISKS-LIST: Risks-Forum Digest Monday 25 March 1996 Volume 17 : Issue 94 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. ***** Contents: Technology "deterioration" (Lauren Weinstein) Someone may steal your life! (Ka-Ping Yee) The risks of misquoting/mispointing on the Web (Thomas H. Slone) The risks of too-smart printers (Dwight Brown) An uncertainty principle for risks (Dick Mills) Lemmings -- Re: Java/JavaScript woes (A. Padgett Peterson) Comments on Netscape, list-bombing, another attack (Fred Cohen) Re: More on list-bombing (A. Padgett Peterson, Frederick Roeber, Leonard Erickson) Free spam-cancelling shell scripts (Fred Cohen) Re: Jury duty (Shannon Nelson, Paul Franklin, Dorothy Klein) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sun, 24 Mar 96 16:49 PST From: lauren@vortex.com (Lauren Weinstein) Subject: Technology "deterioration" The example of answering machines that can be easily "talked-off" by speech is but one case of a broader category -- which I'll call "technology deterioration". It's not that the proper techniques for avoiding DTMF (Touch-Tone) talk-off haven't been designed (when's the last time you talked-off a dialtone on a central-office switch?), but rather that many inexpensive devices don't bother implementing all of the specs for proper performance. Many answering machines also provide a wide selection of other implementation deficiencies as well, including the frequent use of two-digit security codes, and often a total lack of incorrect entry lockouts, making "exhaustive" search trivial. The same sorts of problems can be found in a wide spectrum of devices, from computer keyboards to automobiles. In many (perhaps most) cases, the root cause is simply the desire to cut production costs. But there is evidence that in a significant number of cases the designers simply didn't know better. To the extent that the NIH ("Not Invented Here") philosophy prevails around the world, this is an easily observed phenomenon. What's of particular concern is how the results of these attitudes can impact devices and systems with significant RISKs associated with their use. --Lauren-- http://www.vortex.com ------------------------------ Date: Fri, 22 Mar 1996 20:13:30 -0500 From: Ka-Ping Yee Subject: Someone may steal your life! A possible RISK of placing your own personal information on the WWW? Today, I received a message from a concerned person (anonymized through the anonymous forwarding service in Finland). > Are you member of Waterloo's three-person team > took first place at the East-Central Regionals [1995] > in ACM Programming Contest? [...] > If so, I think you may be feel a little bit upset after looking at this: > http://www.undergrad.math.uwaterloo.ca/~ecstsui/resume.html [...] > I noticed his resume was like this since early February; > the first time it was copied verbatim; now, about 2 months later, it's > not, but it's even more misleading than the first one, since he mixed > his own information with your information. If you dare to compare, the original is at: http://www.csclub.uwaterloo.ca/~kryee/resume.html I had posted my resume on the WWW hoping to be able to provide convenient information for interested people and potential employers; while I imagined it feasible for someone else to imitate the style I used, I had no idea that someone would be so brazen as to copy the entire thing. It shocked me that this had actually been happening on my very own site for over a month! Occasionally I use the search engines to check for my name to find other people's references to me, but since there is no mention of my name in ecstsui's document, it never showed up. Beware -- someone may steal your life! (I did not previously have explicit copyright notices on my pages, but I added them today. While they may make little legal difference because copyright is automatic, they may help to deter this sort of incident.) Ping (Ka-Ping Yee): 3A Computer Engineering, University of Waterloo, Canada CWSF 89 90 92; LIYSF 90 91; Shad Valley 92; DOE 93; IMO 91 93; ACMICPC 94 96 ------------------------------ Date: 25 Mar 1996 21:33:57 GMT From: tom@potency.berkeley.edu (Thomas H. Slone) Subject: The risks of misquoting/mispointing on the Web Greg Campbell wrote a cover story for the Boulder (Colorado) Weekly on the city's sale of its sewage sludge as fertilizer (http://www.earthnet.net/~altnews/012596/cover.html). The article quotes EPA toxicologist Suzanne Wuerthele: "We don't understand fully at what point individual people will be at risk," she says. "Theoretically, for any carcinogen, there are no safe limits. ... One or two asbestos fibers could do it (cause cancer)." [ellipsis is Campbell's] The word "carcinogen" in the above quote is a link to our Web site, The Carcinogenic Potency Database Project (http://potency.berkeley.edu/cpdb.html); we are unaffiliated with Suzanne Wuerthele. The information at our site, if anything, would cause one to doubt the veracity of her statement. Misquoting or misattribution is not unusual in newspapers. The widespread availability of newspapers on the Web potentially facilitates the ability to see where one is being quoted and how it's being done (a risk for the reporter). Those who are not versed in the technology or who are not diligently Web browsing can be misquoted without their knowledge. This is true for hard-copy too -- people don't always know where they're being (mis)quoted unless it's in a periodical that they happen to read. The fact that our Web site was being pointed to by the Boulder Weekly was discovered using an AltaVista advanced query (http://www.altavista.digital.com/cgi-bin/query?pg=aq&what=web) on the following: link:potency.berkeley.edu and not url:potency.berkeley.edu tom@potency.berkeley.edu ------------------------------ Date: Thu, 21 Mar 1996 21:35:37 -0600 From: stainles@bga.com (Dwight Brown) Subject: The risks of too-smart printers My organization has to print and mail several thousand postcards every working day, so we want to get the best postage rates we can. This means not only sorting by zip code, but adding a full ZIP+4 whenever possible, and printing postal barcodes (Delivery Point Bar Code, or DPBC, as the post office calls it) on the cards. The program that generates the postcards is custom written by an outside group, but we use standard software (Postware Presort) to do zip code presorting and get the ZIP+4 information on the cards, and a standard printer (Mannesman Tally MT691) to print the cards (including the barcodes). We've been doing this for quite a while, without major problems, until one day a few weeks ago when the Post Office rejected our outgoing postcards because "the barcode had too many bars". This caused us a great deal of concern. (Several thousand postcards a day, with us paying about $.02 extra postage per card, can really add up.) So, for the past few weeks, our outside group has been working with us to try and figure out what the problem was. Yesterday, everything clicked. The standard for DPBC is one start bar, then five bars per digit, and one stop bar. The digits in a DPBC are: the ZIP+4 (9 digits), two digits from the street address, and a "correction digit" (for a total of 62 bars). We had configured our zip code package to automatically figure out the "correction digit", and were inserting the correction digit on the postcards after the street address and zip code data. The MT691 printer has POSTNET barcoding (for DPBC) built-in. All you have to do is send it a control code to turn on POSTNET barcoding, send it the data you want barcoded, and a control code to turn off POSTNET barcoding, and it will print nice POSTNET barcodes on your forms. Which is what we were doing. It turns out that the MT691 has a nice feature: in POSTNET barcode mode, it *automatically* calculates the correction digit for you. So we were sending it data that included an already calculated correction digit, and the printer was calculating a correction digit based on the data it was being sent...and adding an extra spurious correction digit. It also turns out that this behavior is documented *nowhere* in the manual. The moral? As Tom Clancy said, "You can't even trust the manual." (Or, for that matter, the Post Office, which took a year and half to notice this problem.) Dwight Brown, Texas Automobile Insurance Plan Association ------------------------------ Date: Thu, 21 Mar 1996 06:02:44 -0500 From: rj.mills@pti-us.com (Dick Mills) Subject: An uncertainty principle for risks The radio in my car displays either time of day or the tuned frequency. After changing channels, it automatically shows the frequency for 10 seconds, then reverts to time. There is also a button to manually toggle display modes. Yesterday I happened to press the button to view time precisely 10 seconds after changing channels. My action canceled the automatic action thus causing a result opposite to my intention. Unfortunate timing deprived me of visual feedback of what happened. Most people would blame the radio for misbehaving. I tried to think of a way to redesign the toggle and automatic functions to be infallible. I couldn't. This made me despair. If we can't make such a mundane device behave perfectly, what can we achieve? Soon thereafter, I read Mr. Cross' article in CPD 17.91. He discussed inadvertent activation of a machine and continued to say: >It is possible to say that we have advanced to such a point in so >many areas that seemingly innocuous things in one (such as a track of >music on a CD) can trigger *very* unexpected results in another. This made me wonder where the *real* complexity limit lies. The boundary between reliable expected behavior and the risk of unexpected behavior. I concluded that it lies somewhere between a simple inanimate object like a knife, and a folding knife. A simple knife doesn't *do* anything, we do things to it. It has no behavior. A folding knife will, some day, fold unexpectedly and someone will blame the knife. This leads to the seemingly obvious result: Any object, capable of any behavior, is capable of unexpected behavior. Disregard of this simple principle is the root cause of all other risks. It could be an alternative way to define the *meaning* of the word risk. Dick Mills +1(518)395-5154 O- http://www.pti-us.com AKA dmills@albany.net http://www.albany.net/~dmills ------------------------------ Date: Sun, 24 Mar 96 20:24:11 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Lemmings -- Re: Java/JavaScript woes I keep seeing all of these scary postings about netscape, but few point out that Netscape 2.0 and 2.01 do not support Java on Windows 3.x and Macintosh platforms at all. Further with 2.01, in addition to curing the two problems, you can turn JavaScript off (Options/Security). Do you suppose that in the future, when warnings are posted for such cross-platform applications that the poster could specify *which* platforms are affected? Padgett [Excellent idea. Thanks. PGN] ------------------------------ Date: Sun, 24 Mar 1996 17:25:22 -0500 (EST) From: fc@all.net (Fred Cohen) Subject: Comments on Netscape, list-bombing, another attack (RISKS-17.93) >Java/Netscape security flaw (Ed Felten): Indeed there is a more basic flaw in the URLs used in the Internet that appears to make firewalls very weak prey for attackers and enables Web sites to launch highly distributed and hard-to-trace attacks. The basic flaw was published some weeks ago (e.g., gopher://localhost:79/0 for example) and extensions have now been used to launch probes and attacks by the thousands from sites all over the net. For more details, see: http://all.net/ -> Incident at all.net > More on list-bombing (Phil Agre): A discussion of list spams has been started on the LACC@suburbia.net mailing list. The ideas presented to date include: * E-mail spams can be eliminated by refusing large-volume e-mail from unknown senders. Whenever e-mail arrives from a new sender, the user is told about it, and further e-mail from the same sender is refused until and unless the recipient signals the system to allow ongoing e-mail from that source. (At least one such mailer exists today.) * E-mail receivers can be rigged to refuse e-mail from known lists unless specifically configured to allow it by the user (or in the alternative, configured to allow mail unless specified to not be received from a list of sites/users). The problem with this is maintaining a good list of lists. (I know of one mailer that does this as well.) * Automated e-mail spams can also be prevented by sending back a "user ID" to the sender of e-mail which must be used in subsequent communications. (This is unlikely to be effective.) * Mailing lists could eliminate their use in signup spams rather easily. Instead of the single signon protocol they use now, they could send a confirmation e-mail containing a unique identifying string to the proposed list member. The new member would have to reply before being added to this list. This would be a simple and effective method of limiting e-mail spams to one notification per list. (This would work, but would require fixes for the common mailing list handlers.) * For the techies among us, there is always the extensive use of digital signatures. If every e-mail were signed, we could authenticate sources before allowing them to post to lists, and trace them back to their sources. (Unlikely to happen soon.) Then there is the moderated list. Notice that the RISKS list has never been spammed. (Although perhaps a few users have been spammed by getting signed up, I doubt if they have been negatively impacted.) [Fred, the USENET readers of comp.risks were spammed recently, along with many other USENET groups, but our direct-mail subscribers never saw it, and I know about it only because several folks forwarded it to me! PGN] All lists should include details on how to sign off the list in each mailing. Finally, an optional X-Mailing-List header for mail to allow lists to be easily differentiated and identified. (Again requires participation by all list owners but could work.) -> See: Info-Sec Heaven at URL http://all.net/ Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236 [Fred's fourth bulleted item was also suggested by Rick Russell , hien@ncddenver.ncd.com (Hien D. Ngo), and przemek@rrdjazz.nist.gov (Przemek Klosowski). Rick added a little more discussion (but not markedly different from others), and Przemek suggested checking out an item by Don Libes, (http://www.cme.nist.gov/pub/msid/pubs/libes96b.ps). PGN] ------------------------------ Date: Sun, 24 Mar 96 19:45:03 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: More on list-bombing (Agre, RISKS-17.93) A couple of years ago I posted some information on forged e-mail and the fact that the header almost always contains sufficient information to determine if the message is bogus. For instance examination of the "Received: from" lines in the header is generally sufficient to raise doubts. The problem is that e-mail is essentially sent "blind" and unlike interactive sessions encourages "fire and forget". Further RFC821 makes it clear that the information sent by the mailer such as the "Reply" entry was intentionally made user configurable ("isn't a bug, it's a feature"). In normal messaging this is not a problem however I have seen several newsgroups which routinely generate over a hundred messages a day. To me, the simplest possible mechanism would be to require confirmation with a unique message. I suspect that few will be willing to go to this length so have a fallback: if the subscribing message was "Received: from" a domain other than that of the apparent requestor, then require confirmation. Padgett ------------------------------ Date: Mon, 25 Mar 1996 09:58:27 GMT From: roeber@iea.com (Frederick Roeber) Subject: Re: More on list-bombing (Re: RISKS-17.93 and RISKS-17.83) Perhaps the simple solutions of a simpler world just aren't applicable in the new, now-massively-popular internet. Many protocols on the net -- from e-mail to usenet to more basic routing issues, all familiar to RISKS -- are based in trust. When the net was small, trust worked; now, I have my doubts. A couple years ago I proposed a new system to the team at CERN that created the WWW. I won't bore everyone with the details, but basically 1) discussion forums existed on an invisibly sliding scale between a single-host web-annotations to a network-wide usenet group; and 2) user access varied on a scale between completely-user-initiated "browsing" through user-merely-notified "newsreading" to sent-to-the-user "mailing lists." However, the user interaction was with the local newshost, which then if necessary dealt with remote servers. All articles, digests, summaries, etc. that are mailed to a user are sent by that users' local newshost -- which incidentally gives the user one central control point. (It also completely automates mirroring and caching, which was my original aim.) This certainly won't stop anyone from sending bogus mail. But it would be more difficult to illicitly subscribe someone to a mailing list, and it would be much easier for the user to clean up the problem. Frederick Roeber roeber@iea.com | roeber@cern.ch ------------------------------ Date: Mon, 25 Mar 96 02:15:34 PST From: shadow@krypton.rain.com (Leonard Erickson) Subject: Re: More on list-bombing Fidonet suffered *massive* list-bombing attacks on dislike administrators a couple of months back. What made this worse than the usually list-bombing is that once the mail entered the Fidonet,org domain, it was transported via dial-up Fidonet connections, not via the Internet. This resulted in effective denial of service attacks, as as some of the systems couldn't handle the traffic levels, and even where they could, trying to find legitimate mail was difficult when it was mixed into the list traffic. This was aggravated due to a couple of design "features" of Fidonet. Most Fidonet nets (the .nxxx level in the addresses) don't have a local fidonet<>Internet gateway system. So traffic for user@f111.n222.z1.fidonet.org all went to the default gateway. That system then stuck it into the low-priority routed mail system rather than wasting his money dialing direct all over North America. The routing system is hierarchical, so lots of nodes got *really* jammed by this. Even nets with local gateways still had that poor gateway system trying to make phone calls to the recipients. This sort of thing wasn't anticipated, except that policy was that the gateways were *not* to be used for mailing lists. The end result was that on March 1st, the default gateway was discontinued. Now, only fidonet nets with explicit MX records are reachable. Gateway operators are *still* getting huge amounts of list traffic, much of it aimed at addresses that have *never* existed. This has apparently been an organized attack by some party, and it is at least successful to the extent that it annoys the gate-ops. My advice to list maintainers is to lock out *all* addresses in the fidonet.org domain, and if you get complaints, check to see which system the MX record points at and ask the postmaster there if he allows list traffic through his system. Nine times out of ten the answer will be along the lines of "Hell, no!". And you can then report to the complainer that he is violating the rules under which the gateway operates. If you get a yes response from a gate-op, great. Just remember to check occasionally to see that the gateway system hasn't changed. It's a pity that things are like this, but too many people are abusing what was meant to be a conduit for low-volume *personal* mail. Leonard Erickson (aka Shadow) shadow@krypton.rain.com leonard@qiclab.scn.rain.com <--last resort ------------------------------ Date: Mon, 25 Mar 1996 16:54:02 -0600 (CST) From: Rick Russell Subject: Re: More on list-bombing (Agre, RISKS 17.93) It's just as easy to forge e-mail from a mainframe as from a personal computer (*). The basic problem is not simply on the client side; it's on both sides. The mail client and mail server must implement a system that confirms and records the identity (insofar as it can be determined) of the mail sender, and _rejects e-mail for which the identity cannot be confirmed_. Further, the system would have to have wide implementation, or the malicious e-mail sender could just find a non-authenticating server to his or her e-mail. As usual, the price of security is convenience; such a system would be substantially more complex than the common SMTP protocol we have now, and would require software changes on both the client and server sides. For safety in a lab or office environment, it might also require that users enter a confirmation password each and every time they send e-mail, although Kerberos-style authentication tickets can be used to get around that problem to a limited extent. (*) Admittedly, using a password-authenticated system for the forgery provides a better record of what transpired, leaving the miscreant open to capture. But what if the miscreant were to send e-mail via an open SMTP server in, say, Singapore? I would imagine that getting a sysadmin in a distant country to give you his or her system logs would be awfully difficult. Rick R. ------------------------------ Date: Mon, 25 Mar 1996 10:31:04 -0500 (EST) From: fc@all.net (Fred Cohen) Subject: Free spam-cancelling shell scripts To assist in those who need to cancel spams, we have set up a free (donations accepted) spam-cancelling capability on the all.net Web site. We considered handing out a convenient shell script along with the list of over 10,000 mailing lists we are now able to cancel subscriptions to, but we decided this might add to spams instead of eliminating them. Instead, we opted to have the user provide the site name and we provide a shell script to unsubscribe from the lists coming from that site. For full details, use: http://all.net/ and look under CanSpam. -> See: Info-Sec Heaven at URL http://all.net/ Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236 [Can spam attacks be stopped? Canned spam controls would be of interest to Monty Python. PGN] ------------------------------ Date: Fri, 22 Mar 1996 13:30:13 -0800 From: Shannon Nelson Subject: Re: Jury duty (RISKS-17.91,92) Another pool used in Oregon is the list of registered car owners. This, combined with a zip code that overlaps two counties, got me a Jury Duty summons for Multnomah county while I live in Washington county. Of course, the Department of Motor Vehicles representative had trouble fixing our record because the computer "knew" that our zip code was a Mult. Co. zip. As it turns out, probably everyone in our zip code in Wash Co. has this problem but doesn't know it yet. And no, the DMV would not change us all - they told us that each person has to call in individually. They didn't want to hear from a Wash. Co. official requesting a blanket change. Risks (in any order): 1. Computers that can't deal with humanity's political deviances (zip boundary not matching county boundary) 2. Stubborn bureaucratic clones that won't take the 'risk' to fix the system 3. Bad information propagating from one system to another 4. Licensing tax money going to the wrong county 5. probably more... Shannon Nelson Portland Technology Development, Intel Corp. snelson@ptd.intel.com (503) 642-8149 ------------------------------ Date: 23 Mar 1996 15:06:06 -0800 From: Paul Franklin Subject: Re: Jury duty (RISKS-17.91,92) In most (all?) states, whatever agency issues drivers' licenses also issues official ID cards for people who aren't eligible to drive or don't wish to. For people who don't wish to drive, or for children who look several years older/younger than they are, these cards are a necessity for things such as writing checks, watching movies with their peers, etc. If Emily had a state-issued ID card, it doesn't take much imagination to figure out why she got called. One might try to fault a computer. But the real risks are nothing new: * politicians (or others) not thinking through what they do * people trying to blame the computer --Paul ------------------------------ Date: Sun, 24 Mar 1996 13:02:23 -0500 (EST) From: Dorothy Klein Subject: Re: Jury duty Jury summoning and selection procedures are set by New Jersey state law. New Jersey has recently greatly expanded the lists from which jury duty lists may be composed. Three were concerns about non-representative juries in some urban counties, and claims that the expanded lists would add 30% more bodies to the jury pool. The new state law also ended the exemption for police officers and other professions. (Like a cop wouldn't be challenged right off a jury -- what a waste of time!) The youthful juror problem is occurring because just about any official contact with the state government now gets you onto the jury list. Little Emily's case is only one of several, but hers came to public attention because her parents are lawyers and pointed out the idiocy publicly. It seems Emily had to file a state income tax return, probably for interest income, and got onto the massive jury list that way. [Above info as I remember it being reported in the Star-Ledger last Sunday -- any errors are mine.] One wonders how well the new expanded jury lists have been winnowed. I can see an active citizen, who drives, owns property, files taxes, has wages reported, votes, etc., being present on the list many times. It seems to me that this would lead to a non-representative jury pool, biased toward people with multiple jobs and owning property. While a NJ juror is now exempt for three years after actually serving, certain counties in NJ are notorious for summoning large pools, then excusing most of them because the court-load is not what was expected. I for one am sick of turning my planned work schedule upside-down, then calling the juror tape on the morning of my first day and finding I'm excused, then 9-12 months later, going through the whole process again because I haven't actually _served_. I had the honor of receiving two jury summonses in the same month, so I am already unimpressed with Middlesex county's juror data handling skills, and that was _before_ the new law, when only voter and driver registrations were used. The juror questionnaire asks for SSN, but utterly lacks a privacy act statement, showing just how "up" on data issues this county is. I'm betting that Emily's parents will be making more "Please excuse my child from jury duty" calls to the courthouse before she's 18. After all, every year she'll file a tax return, and get back onto the jury summons list. Aside from pointing out the problems of using data collected for one purpose for an unrelated purpose, the new juror selection lists and criteria risk further annoying citizens of this state. Dorothy Klein dklein@pluto.njcc.com [If you wonder why all these messages made it into RISKS, it might be once again to illustrate how difficult it is for bureaucracies to deal with regulations and procedures -- let alone computers! PGN] ------------------------------ Date: 18 March 1996 (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 unabridged version of RISKS 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, nonrepetitious, and without caveats on distribution. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Particularly relevant contributions may be adapted for the RISKS sections of issues of ACM SIGSOFT Software Engineering Notes or SIGSAC Review. * Submissions: By submitting an item that is accepted for publication in RISKS, the author grants permission for unlimited public distribution and redistribution in electronic or other form. * Reuse: Blanket permission is hereby granted for reuse of all materials in RISKS, under the following conditions. All redistributed items must include the Risks-Forum masthead line. All reuse must be accompanied by the following statement: Reused without explicit authorization under blanket permission granted for all Risks-Forum Digest materials. The author(s), the RISKS moderator, and the ACM have no connection with this reuse. As a courtesy, reusers of individual items (as opposed to forwardings of entire issues) should notify the authors, and should pay particular attention to any subsequent corrections. 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://ftp.sri.com/risks The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest, see the unabridged INFO file at RISKS-Request (send one-line message INFO to risks-request@CSL.sri.com as noted above). ------------------------------ End of RISKS-FORUM Digest 17.94 ************************