Text File

Subject: RISKS DIGEST 18.04

RISKS-LIST: Risks-Forum Digest Monday 15 April 1996 Volume 18 : Issue 04

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: OS/2 Warp TCP/IP misfeature (Pete Bentley) Data entry omission extends prisoner's sentence (James K. Huggins) Has the net reached a critical size? (Frederick Roeber) Single names and identification (Colin Eric Johnson) The joys of FAX machines (Drew Dean) Real "Natural" language design isn't easy either (Peter Van Eynde) Another Daylight Saving Time problem: Netscape 2.* reload (John F. Whitehead, Prentiss Riddle) Another Daylight Savings Time risk: billing (Lorne Beaton) Abuse of statistics about computer crime (Dan Barrett) Phone-sex users on web index accidentally [Name withheld by request] Re: The weakest link (Paul Robinson) Re: X-Confirm-Reading-To: Pegasus woes ... (David Woolley, Peter Yamamoto) Re: A note on e-mail (David Milun, Jiri Baum) ABRIDGED info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Thu, 11 Apr 1996 12:44:22 +0100 From: Pete Bentley <pete@mimir.com> Subject: OS/2 Warp TCP/IP misfeature

[ I was recently reminded of this one by a thread in a newsgroup I frequent ]

It seems that in the OS/2 (2.1 and Warp) TCP/IP stack socket descriptors are system-wide. That is, they aren't per-process file descriptors, so if you can discover the number of some other process's socket (and netstat -s will helpfully list all the open sockets on the system) you can send(), recv(), shutdown() or do many other fun things with it.

Risks include the fact that anyone with telnet access to the machine (and OS/2 telnet security is a risk in itself) can write a program to subvert any TCP/IP server running on it.

A shame, because otherwise it's one of the better non-Unix implementations of the BSD socket API.

Pete

------------------------------

Date: Thu, 11 Apr 1996 10:30:12 -0400 (EDT) From: "James K. Huggins" <huggins@eecs.umich.edu> Subject: Data entry omission extends prisoner's sentence

Summarized from the *Detroit Free Press*, 11 April 1996, p. 4B.

John O'Valle was convicted in 1987 on charges of cocaine and weapons possession, and was expected to serve 20 years in prison. Later on, however, the sentencing judge reduced the sentence on technical grounds, making him eligible for release in 1992. The reduction was noted in O'Valle's written file, but not in the Department of Corrections' computer records. (Neither O'Valle nor his lawyer was notified of the change.)

In January 1996, prison officials reviewed his records and discovered the discrepancy. However, there is now a new problem. In 1995, O'Valle was convicted for possession of marijuana while in prison, a felony. Had he not been in prison at the time, he would have been guilty of a misdemeanor and not subject to jail time. So now O'Valle is serving time for a felony, which (presumably) never would have happened had he been released on time. State officials aren't sure what to do.

Officials aren't sure what happened. O'Valle's warden says that sentencing formulas are complicated, and the prison camp program and parole programs were in "transition" during the time O'Valle entered the system.

Perhaps a new story with an old moral: if you have replicated data sets, make sure that the data sets are consistent.

Jim Huggins, University of Michigan (huggins@umich.edu)

[The O'Valle course runs twistingly around. PGN]

------------------------------

Date: Sun, 14 Apr 1996 22:15:20 GMT From: roeber@iea.com (Frederick Roeber) Subject: Has the net reached a critical size?

I don't mean "critical" as in "film-at-eleven," but as in its size or penetration has reached a sufficient point for a process to occur.

In ten years on the net, I've only come across a couple other people with my last name. Websearches never revealed anything but links to my own data.

But within the past few weeks this has changed. RISKS had an article about www.switchboard.com, which lists some 350 Roebers. A new websearch finds a dozen Roebers. And suddenly the e-mail has started coming in-- "My name is <something> Roeber. Might we be related?" And this is all happening at once. It shouldn't be long before we have the whole family tree worked out.

I can't say there's a hard risk to this, other than the usual ones of privacy and how the net is making this an ever-smaller world. (But I do hope none of those 350 www.switchboard.com hits are actually federal witnesses in the American witness protection plan. Pretty soon they'll stick out like sore thumbs.)

Frederick Roeber roeber@iea.com - roeber@cern.ch - roeber@caltech.edu

[Frederick has gone from being a Roeber Baron to being a DisRoeber, in short order. This must be where the Roeber meets the load. PGN]

------------------------------

Date: Mon, 15 Apr 1996 14:50:55 -0600 (MDT) From: Colin Eric Johnson <colinj@unm.edu> Subject: Single names and identification

It seems that a friend's friend [name altered] decided that he wanted to only have a single name, Smith. When Smith had his name legally changed to just Smith one of the things that he had to do was get a new drivers license. So he headed on down to the local DMV.

It seems that the state of Oregon (at the time at least) had a computer system that required that both a first *AND* last name be entered for every persons license. Of course Smith only had one name (and the paper to prove it). So after struggling with the system for a while the diligent workers asked Smith to come back in a couple of days when they would have a license for him. And, sure enough, a couple of days later he returned to find a license with just the name Smith on it waiting for him, all seemed to be well.

While on a road trip, which Smith is prone to, he was pulled over for some sort of traffic violation. When he was offered up his license as per request the police officers were concerned with his lack of a second name (first or last? you decide). When they looked him up, he was not in Oregon at this time, they could not find any such person as "Smith" in the Oregon registry. At this point the police officers began to get suspicious. After much investigation, and a great deal of lost time and frustration on the part of Smith and the local constabulary, it was determined that the state of Oregon had done the following:

Failing to get the system to accept a single name for a drivers license they inserted a fictitious second name "Jay". They then simply altered the printing process so that only the name "Smith" actually appeared on the license. So to find Smith in the Oregon listing one would have to look under "Smith Jay".

The risks? Well, I believe trouble with the law would be obvious in this case. It might also cause problems in terms of employment where security and background checks are done as well as insurance. I believe that the least that could have been done would have been to explain to Smith what had been done to make this work. It might also be more appropriate to have a preset second name like "No Second Name" that could appear either in the list, on the license or both.

Colin Johnson | colinj@unm.edu | http://www.unm.edu/~colinj/

------------------------------

Date: Sat, 13 Apr 1996 19:18:28 -0400 From: Drew Dean <ddean@CS.Princeton.EDU> Subject: The joys of FAX machines

I was filling out an application for a summer job. Time was of the essence, so the company's normal employment application was FAXed to me. Printed in landscape mode, the bottom question, about whether I'd been convicted of a crime, got cut off by the FAX machine. Since various companies ask the question in different ways (some ask only about felonies, others include traffic citations, etc.), I decided that the best approach was to write in, "I have not been convicted of a felony" and to initial it. I then FAXed the application back.

I received a phone call within the hour asking if I was a felon. I had written the word "not" a little lower on the page, and _it_ got cut off on the return trip. The situation was resolved, but somewhat amusing. I've fought laser printers that can't print closer than 1/4" to the edge of the page before, so I should have known about the problem, but I forgot.

RISKS: You think of FAX as being WYSIWYG, but it isn't quite. And you can't (easily) see what the recipient will get.

Drew Dean <ddean@cs.princeton.edu> Department of Computer Science, Princeton University

------------------------------

Date: Thu, 11 Apr 1996 08:54:37 +0200 (MET DST) From: Peter Van Eynde <natst3@uia.ua.ac.be> Subject: Real "Natural" language design isn't easy either

The Netherlands and the Dutch-speaking region of Belgium have an organization to define the language (Dutch) spoken in the two counties. This organization reformed the Dutch language the last time in 1947-1954 by printing "Het groene boekje" (the little green book) _Woordenlijst Nederlandse Taal_. This book defines the rules and words used in the Dutch language.

In the last few years, there has been a feeling of unease with the spelling: it was felt that there were to many "illogical" words. So, a committee was formed to reform the language. But they proposed a radical change -- for example, the use of "c" sounding like "k" would be abolished. There was protest (and the grounding of a "We love the letter C" group) and the politicians told the committee to soften its proposal. It seems that they did this (in a very short time) by simply removing rules that were too radical, and then removing a bit more. (Nobody actually knows for sure: interviews with committee members result in a lot of finger pointing and "It works for me".)

So, version 2 came out, and is now law. It must be introduced in the schools, government and media. There is one snag: the rules are not "complete": the rules given don't even include the spelling of words given as examples, and there are cases without any rules.

Nobody uses the green book; people use dictionaries. But the major publishers found the rules and the words in argument, so introduced their own rules. Each publisher has different ones. Major newspapers also have an internal dictionary, and they did the same. One major encyclopedia publisher even found the new rules so bad that it refuses to use the new spelling.

The RISKS? I have to write my thesis *after* the new spelling becomes law, and I have to write it in Dutch. Now my only problem (and that of Microsoft, Lotus(oops IBM), Word-perfect (whoever owns them), etc), is *which* Dutch. This whole case is a textbook demonstration of the RISKS of language specifications and the influence of politics on "natural" or "logical" designs. 20.5 million people have to live with the consequences.

Peter Van Eynde [It's logic Jim, but not as we know it.]

------------------------------

Date: Thu, 11 Apr 1996 18:45:14 -0400 From: "John F. Whitehead" <jfw@wral-tv.com> Subject: Re: Daylight Savings Time problem: Netscape 2.* reload

There has been another side effect of the daylight savings time change, with the Netscape Navigator browser: caches have incorrect times and no longer work properly for documents that change frequently.

Netscape Navigator version 2.x for Windows and Unix platforms is an hour off in its cache-file handling. If a user tries to reload a page that has changed within the last hour, the browser still thinks its cached version is more up to date and won't retrieve the new version. (After an hour, this is no longer an issue.) This has been a problem with news organizations (such as ours), chat/bulletin boards, and java applets that need to be updated frequently.

Netscape's "force reload" procedure (shift key + reload button) doesn't always work either: the only solution is to flush the memory and disk caches before a reload, or to set them to size zero. Netscape has made no official statement, but apparently has said the bug won't be fixed in the next version of the software (2.1) but in the one after that (3.0 (Atlas)).

The Macintosh version does not suffer from this bug, nor do versions 1.x, or browsers from other manufacturer.

The risk (aside from the obvious one related to programming for time changes) is trusting that a market-leader software company is going to have bug-free software.

John F. Whitehead OnLine Technical Director 919-821-8605 jfw@wral-tv.com http://www.wral-tv.com

[This problem was also reported by CurtAkin@aol.com and Prentiss Riddle <riddle@is.rice.edu> -- next message. PGN]

------------------------------

Date: Mon, 15 Apr 1996 09:14:54 -0500 (CDT) From: Prentiss Riddle <riddle@is.rice.edu> Subject: Another Daylight Saving Time problem: Netscape 2.* reload

[...] One workaround is said to be to run Netscape in California time, e.g. under Unix:

setenv TZ PDT ; netscape &

Defying the RISKS tradition of intoning that "the risks are obvious", one could draw the following lessons:

-- Time-dependent functions should be tested using multiple time zones and both DST- and non-DST dates.

-- In networked applications, local time issues can cause more than just local problems.

Prentiss Riddle <riddle@rice.edu> http://is.rice.edu/~riddle RiceInfo Administrator, Rice University

------------------------------

Date: Thu, 11 Apr 1996 16:20:49 -0400 (EDT) From: beaton1@server.uwindsor.ca (Lorne Beaton) Subject: Another Daylight Savings Time risk: billing

My university recently (ca. January 1, after a testing period of about a month) instituted a new dialup service, for which students and faculty are charged 75 cents per hour peak and 60 cents off-peak. A couple of days ago I logged on and saw something like the following in my logon message:

> Charges THIS month to date 500 minutes for a cost of $ 49.59 > Charges LAST month (total) 2089 minutes for a cost of $ 24.76

(Note that these aren't the exact figures, but you get the idea.) Needless to say I was consternated. After complaining to the admins, I learned that the billing discrepancy arose from the change to Daylight time. Night owl that I am, I happened to be logged in at the exact moment that 2:00 a.m. EST became 3:00 a.m. EDT. Needless to say, this was the first time they had dealt with the changeover. Happily, the problem has since been fixed, but the risk is self-evident.

Lorne Beaton <beaton1@server.uwindsor.ca>

------------------------------

Date: Fri, 12 Apr 1996 12:52:50 -0400 From: barrett@liberation.cs.umass.edu Subject: Abuse of statistics about computer crime

The March 1996 issue of IEEE COMPUTER contains an article on the rise of computer crime ("Security and Privacy TC," by Deborah Cooper and Charles Pfleeger, pp. 118-119; TC = Technical Committee). Based on a table of statistics obtained from the CERT Coordination Center, the article claims that computer crime is undergoing a "dramatic escalation." Whether or not this is true, the article is seriously flawed, and it points out the risks of shoddy statistical reasoning.

Here is an excerpt from the table, which has the heading, "Computer Emergency Response Team (CERT) statistics show that computer attacks are on the rise."

YEAR INCIDENTS REPORTED ========================== 1988 6 1989 132 1990 252 1991 406 1992 773 1993 1334 1994 2341

On first glance, this certainly appears to be a "dramatic escalation" in computer crime... or does it? Let's look at how much information was not presented in the article.

The table heading discusses "attacks," but the table column says "incidents." So what exactly is an "incident?" Is it a report of an alleged attack? (Likely, given that CERT is usually the recipient of unsolicited reports.) Or is it a verified attack, meaning that erroneous reports were somehow weeded out? If it was verified, how was it verified? The article doesn't say.

I wrote to Pfleeger with this question, and he responded that "the source of these statistics is CERT" and I would "have to contact them for the interpretation of their data." In other words, Pfleeger, Cooper, and IEEE COMPUTER published a table of statistics that the authors did not not themselves understand. So I wrote to CERT, and their response indicated that an "incident" is a report, and that they "don't talk to law enforcement people at all" to verify that an attack is real "unless a site requests us to."

The abuse of statistics gets worse. While the number of incidents in the table is approximately doubling every year, so is the population of the Internet (source: The Economist, July 1995). In other words, the number of incidents grows linearly with the size of the population, which is completely unsurprising. This fact is not mentioned anywhere in the article. Pfleeger argued (by email) that "technical and physical security controls" have improved since 1988, and yet incidents have continued to increase "in spite of improved protection." That is an interesting hypothesis but hardly a reason to ignore the growth of the Net as a possible source of increased reports. The CERT representative reported that she didn't "know why the authors of the article didn't mention the relationship between the number of incidents and the number of Internet users."

Similarly, the visibility of CERT has grown greatly since 1988, and this could account for an increase in reported incidents. Again, this is not mentioned in the article. Both Pfleeger and CERT say that measuring CERT's visibility is a non-trivial task, and I agree. Still, the effect should have at least been mentioned in the article.

Footnote 1 of the table mentions that "some incidents have ongoing activity for long periods of time (i.e., more than a year)." I asked Pfleeger whether "ongoing activity" meant "ongoing penetration of a compromised system," or "ongoing interaction with CERT," since the phrase is ambiguous. Pfleeger DIDN'T KNOW and suggested I ask CERT. He also didn't know whether the phrase "some incidents" referred to a majority or a (possibly insignificant) minority. By highlighting the incidents with long ongoing activity, the table takes on a negative slant. After all, one could just as easily have focused on the opposite, saying that "some incidents lasted only a few minutes."

My intuition and experience tell me that security incidents are indeed increasing. In other words, I believe the basic premise of the article. Nevertheless, the article's reasoning is flawed and contributes only to the prevalent misinformation about computer crime and security.

Dan Barrett dbarrett@ora.com http://www.ora.com/item/bandits.html Author, "Bandits on the Information Superhighway" (O'Reilly & Associates)

------------------------------

Date: Wed, 10 Apr 96 From: [Name withheld by request] Subject: Phone-sex users on web index accidentally

To see if any of my personal WWW home pages have been indexed by web crawlers, I sometimes query the popular web search engines with my first and last names. Imagine my surprise when, amid the usual links, I found several that referred to caller-id files!

Upon visiting the links, I discovered many text files containing a column of phone numbers and a matching column of people's names. The files were broken up by month and year, and contained hundreds of listings each. Some of the names in the list were 'Pay Phone' and 'City of XXX' and 'State of XXX'. Often, a name and number would be repeated several times in a row, presumably denoting multiple calls from one number.

When I removed all but the fully qualified host name from the URL address, I was presented with the first HTML document that I'd found on this server. It was functional, yet spartan: clearly intended for the page-developer's use only. From it, I ascertained that the phone lines from which the caller -id's were taken were all named after different kinds of sexual activity.

Forgive me for jumping to conclusions, but I believe that these files were created by a phone-sex service. Perhaps they are used to identify satisfied customers, or to help direct incoming calls to the proper 'talent'.

The RISKS: too many! First, it is foolish to allow proprietary information be stored on a server connected to the internet. Second, any time that you dial the phone, unless you're calling from a Pay Phone or the State of XXX, the marketeers at the other end probably know who you are. Finally, free access to demographic data may be hazardous to your marriage, or job, or whatever.

------------------------------

Date: 15 Apr 96 09:49:00 -0700 From: ROBINSON_PAUL@Tandem.COM Subject: Re: The weakest link (Reifschneider, RISKS-18.02)

Sean Reifschneider reports that Social Security Administration employees sold SSNs and "mother's maiden name" info to a credit-card fraud ring. Many credit card issuers require "activation" of newly-issued cards, i.e. the recipient must call a toll-free number and give this kind of "identifying" information before they can use the new card.

Actually, the weakest link is "the clerk who's paid $12K/year" at the credit-card issuer. Recently I received a new card, called the number, and adamantly refused to give my SSN over the phone. The somewhat flustered clerk eventually activated my new card, having received only the credit-card number and the zipcode (postal code) printed on the accompanying letter. No SSN, no "mother's maiden name," NOTHING else.

If all I need is the card and the letter, why pay off SSA employees? I have written to the credit-card issuer, no response yet.

--paulr

------------------------------

Date: Sun, 14 Apr 96 12:58 BST From: David Woolley <david@djwhome.demon.co.uk> Subject: Re: X-Confirm-Reading-To: Pegasus woes ... (Yamamoto, R 18 02)

>The "problem" is due to a new release of Pegasus which added a directed >confirmation header field as well as keeping the old confirmation header

The new header was added precisely because the old version was causing problems with mailing list, but people have to upgrade the reading version not the sending version to gain the full benefit.

However, this whole thing shows the common risk that users will demand certain features of a product ("read" receipts are a very popular feature of Pegasus) without realising the full implications (namely they will get a reply from every Pegasus user on the mailing list, and possibly compromise the privacy of those subscribers).

There is, however, a very simple solution for MajorDomo and probably for listserv, just filter out the offending headers. The standard MajorDomo already filters out Return-Receipt-To:, a rather more common, non-standard header, with similar effects. Adding such filters to MajorDomo is a reasonable local customisation.

Although there are now safe standards for achieving these results, which shouldn't propagate through a properly configured list server, it will be many years, if ever (commercial factors, rather than good technical design are now controlling the e-mail market), before they are widely implemented, and more ad hoc methods of meeting the market demand for this feature will arrive first.

------------------------------

Date: Wed, 27 Mar 1996 00:47:51 -0500 (EST) From: Peter Yamamoto <pjyamamo@daisy.uwaterloo.ca> Subject: X-Confirm-Reading-To: Pegasus woes ... (Yamamoto, RISKS-18.02)

Two things about automatic e-mail confirmation, although the risk is nothing new to RISKS readers...

Recently, on a mailing list I maintain, a Pegasus (the name of a Mac/Windows e-mail reader) user posted a message with a line:

> X-Confirm-Reading-To: <e-mail address>

This would be fine if Pegasus respected the field value when acting on the presence of this field. But Pegasus programmers apparently took the RISK of assuming that they didn't have to. Now every list member using Pegasus is generating a confirmation message to the list.

Peter Yamamoto University of Waterloo Waterloo, Ontario, Canada N2L 3G1 519-888-4567 x3299 PJYamamoto@UWaterloo.CA http://daisy.uwaterloo.ca/~pjyamamo/

------------------------------

Date: Fri, 12 Apr 1996 10:46:24 -0400 (EDT) From: Davin Milun <milun@cs.Buffalo.EDU> Subject: Re: A note on e-mail ()

While I tend to disagree with your preference for "e-mail" over "email", that pales in comparison for my dislike of the use of "email" as other than a mass noun.

Sentences like "send me an email" or "I received an email today" bother me intensely. "Mail" is a mass noun --- no native English speaker would replace "an email" with "a mail" in the above sentences! But many casually do it with "email", even though "email" is just "electronic mail".

Listen everyone, it's "send me some email" or "send me an email message" or "send me a piece of email" etc..

(So, maybe PGN is correct after all. Maybe we do need the hyphen to remind people that "e-mail"/"email" is a modification of "mail".)

Davin Milun milun@cs.Buffalo.EDU http://www.cs.buffalo.edu/~milun/ Cory Search - Aquaria index: http://aquaria.cs.buffalo.edu/

[And PGN left all of Davin's "email"s intact. Am I ("Am I" = the French pronunciation for "email", sort of) Nice?]

------------------------------

Date: Sun, 14 Apr 1996 09:07:01 GMT From: jiri@baum.com.au (Jiri Baum) Subject: Re: Notes on e-mail (Sandee 18.01, Stolz 18.02)

>> [...] "co=F6perate", "na=EFf", and "Bront=EB.". [...] ... >> Usenet (at least NNTP) is generally 8-bit transparent, and any European >> soc.culture group will tell you that ISO 8859-1 usually works [...]

Nothing is so simple as it seems at first sight.

There is not only ISO 8859-1, but also ISO 8859-2, ISO 8859-3 etc. For a practical example of the difficulties, see soc.culture.esperanto. (Esperanto has the endearing feature that stripping supersigns tends to cause a lot more confusion than in say Czech.) Most people there have given up and are using the ugly method of a trailing x (which is human-readable yet machine-tractable).

[...]

Using multipart/mixed and separate charsets for each section? While that would be acceptable to people who have MIME, it would add to the bulk of the headers that one has to skip in a plain text reader.

Of course, that's assuming that each contributor only posts in one charset. Multi-charset contributions would be worse still... I guess it'll be a long time before I can put my name on my Esperanto postings properly (the r should be \v{r}, and the i should be \'{\i}).

Jiri Baum

------------------------------

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 <risks-request@csl.sri.com> (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.com<CR>login anonymous<CR>[YourNetAddress]<CR> cd risks<CR> or cwd risks<CR>, 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 18.04 ************************