Text File

Subject: RISKS DIGEST 18.68

RISKS-LIST: Risks-Forum Digest Monday 16 December 1996 Volume 18 : Issue 68

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: California tax-form attacks: a new tax on businesses (PGN) Communications errors delay response to San Francisco fire (Brian Slesinsky) Power surges in Third World countries (Frank Conlon via Don Wagner) Re: repetitive strain injury suit (Joshua Goodman) November, 1996 CACM article on InfoWar Defense - highly critical (Fred Cohen) You can't rewrite history in Internet Explorer 3 (Tim Nott) *Java Security* by Gary McGraw and Edward W. Felten (PGN) When is an upgrade not an upgrade? (Ian Barker) Beware of Year2000 Sharks: A Story for Non-Believers (Year2000InfoNet) Re: .pdf files, RISKS of using Adobe Acrobat Reader (Kenneth Albanowski, Gene Wirchenko) Re: Combatting cookies (Hal Lewis, Frank Stuart, Pete Kaiser) Women into Computing Conference 1997, last call for papers (Richard Nealon) Privacy Digests (PGN) Abridged info on RISKS (comp.risks)

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

Date: Mon, 16 Dec 96 8:50:42 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: California tax-form attacks: a new tax on businesses

A California Franchise Tax Board computer apparently went berserk, resulting in thousands of extra copies of 1996 tax forms being sent to California businesses -- including a San Diego dentist who reportedly received about 16,000 copies of the 1996 forms. [Source: An AP item in the *San Francisco Chronicle*, 14 Dec 1996, A16.]

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

Date: Sat, 14 Dec 1996 17:22:19 -0800 From: bslesins@hotwired.com (Brian Slesinsky) Subject: Communications errors delay response to San Francisco fire

>From Saturday's San Francisco Chronicle (Dec 14, page A20, also available online: http://www.sfgate.com/wais/search/chron-pro.html):

San Francisco fire officials acknowledged yesterday that communications errors delayed the arrival of vital equipment at last month's huge fire at Pier 48 -- the second time this year that the department has had problems getting firefighters to major blazes." [...] According to [Deputy Chief] Gamble, a dispatcher -- alerted to the waterfront fire at 2:48 p.m. -- initially sent only four pieces of equipment by computerized message when he should have sent seven. Gamble said the dispatcher mistakenly entered into the computer that the alarm had come from a street box, triggering a relatively minimal first response. The second error occurred when the first units at the scene immediately called for help. At that point, Gamble said, the dispatcher told the computer to send the next wave -- only to discover six minutes later that the units never got the message. Gamble explained that because the dispatcher gave the computer the wrong message on the first alarm, the computer wouldn't accept the second." [...]

The RISK seems to be a user interface that makes it too easy to make mistakes entering data, and "business rules" that assume that whatever was previously entered into the computer is correct. Brian Slesinsky bslesins@hotwired.com http://www.hotwired.com/staff/bslesins/

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

Date: Sat, 14 Dec 1996 06:13:14 -0500 From: D B Wagner <106026.3213@compuserve.com> Subject: Power surges in Third World countries

Don Wagner, Reverdilsgade 3, 1.th., DK-1701 Copenhagen V DENMARK [Don sent in another item too, but this one seemed appropriate here. PGN]

>--------------- Forwarded Message ---------------

From: Frank Conlon, INTERNET:conlon@u.washington.edu To: D B Wagner, 106026,3213 Date: Fri, Dec 13, 1996, 2:31

RE: H-ASIA: Using laptop in the PRC

Date: Thu, 12 Dec 1996 17:14:10 -0800 Reply-To: Frank Conlon <conlon@u.washington.edu> Sender: H-Net list for Asian History and Culture <H-ASIA@h-net.msu.edu> From: Frank Conlon <conlon@u.washington.edu> Subject: H-ASIA: Using laptop in the PRC To: Multiple recipients of list H-ASIA <H-ASIA@h-net.msu.edu>

H-ASIA, December 12, 1996

Response to query on laptop usage in PRC from a non-Sinologist

>From Frank Conlon <conlon@u.washington.edu>

With reference to Susan Blum's query, I cannot say anything at all about the PRC, but will mention the strategy I followed whilst in India in 1990-91 using a laptop.

It may be too late or to unwieldy to use my approach, but what I did was buy several extra storage batteries and a charger. Except in Bombay city which had a relatively stable power system, I never, that is NEVER, plugged my computer directly into an electric source. During my previous visit we had purchased a top of the line, industrial strength surge protector made in the U.S.A. It lasted 6 days before the Delhi Electric Supply Undertaking sent a spike through the line and blew the little hummer into the next world, if there is a next world for surge protectors and transformers.

Instead, in 1990-91, since I had a computer that used batteries which could be replaced and charged in a separate charging device, I just kept cycling batteries through the charger and replacing them as needed. Because I was going to be there for almost a year, I purchased a substantial surge protector in India--the sort folks there buy for their televisions and refrigerators there. Being manufactured in India meant that they were engineered with a realistic grasp of the vagaries of most Indian power supplies. As the power surges came it buzzed and spat, but the battery charger blissfully escaped unscathed.

Now if you are travelling around a lot, that might be inconvenient, and perhaps such devices are not readily and cheaply available in China, but my computer and data reached home safely, and the surge protector made a handsome gift to one of the many folks who had done favors for me during my stay.

Bon voyage, bon chance.

Frank Conlon, University of Washington

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

Date: Fri, 13 Dec 1996 20:23:40 -0500 From: Joshua Goodman <goodman@eecs.harvard.edu> Subject: Re: repetitive strain injury suit (PGN, RISKS-18.68)

Repetitive Strain Injuries are a very common risk from computing; they can easily lead to disabling injuries. The fact that these people sustained million dollar injuries give you an idea of how bad it can be... However, RSIs can be avoided with proper typing technique, ergonomics, stretching, etc. For instance, simpler than installing foot-pedals is to train oneself to hit ctrl, shift, etc. with the index finger of the opposite hand. For tips about typing technique, and other information about RSIs, see http://www.eecs.harvard.edu/RSI, which is pretty good (OK, as the author I'm biased) although a bit Harvard specific. Another good page (OK, maybe better) is http://www.engr.unl.edu/eeshop/rsi.html.

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

Date: Mon, 16 Dec 1996 09:42:54 -0800 (PST) From: fc@ca.sandia.gov Subject: November, 1996 CACM article on InfoWar Defense - highly critical

***** FLAME ON *****

Dateline: Livermore - Dec. 16 9:02AM

CACM AIMS RIGHT BUT MISSES INFO-WARFARE TARGET

Yes, Neil Munroe aimed right, but as usual, he missed the Info-Warfare target.

He correctly identifies the problem - disruption (a.k.a., corruption and denial of services) - but he misses the target by talking about privacy, privacy, and more privacy.

The phone system could be brought down... but we have to protect privacy The power grid could go down... but we have to protect privacy Planes could crash... but we have to protect privacy

Questions: Suppose we had absolute and perfect privacy but still had the current inadequate level of information assurance.

Could the phone system still be brought down? Yes Could the power grid still be brought down? Yes Could air traffic still be brought down? Yes Does privacy protection solve the information assurance problem? NO!

Question: Suppose we had absolute and perfect information assurance.

Could we still have perfect privacy? Probably

So what is the relevance of the "... but we have to protect privacy" when the issue is not privacy but assurance (integrity and availability)?

If we aim at information assurance and we keep hitting privacy, we will never achieve our goal.

The target is NOT privacy! This issue is NOT ABOUT PRIVACY!! PRIVACY IS THE WRONG TARGET!!!

The right target is integrity and availability - a.k.a. information assurance.

How many times have I heard this misdirection? Hundreds at least. What's the cause? I don't know.

It could be that people think of computers as infallible and that for that reason integrity and availability cannot be of concern.

It could be that people just don't understand.

It could be that the media attention and publicity is all aimed at privacy. I've even seen media stories of computer viruses causing computer crashes and heard the media people comment on how privacy problems have to be addressed in order to solve this.

Get a clue!

How come the editors at the ACM couldn't figure this one out and tell the author to hit the right target?

They must not have a clue!

How come the author calls the privacy advocates to find out about information assurance?

He must not have a clue!

How come the FBI seems to think they need to tap phones to protect NII integrity?

They certainly don't have a clue!

How come the president puts people without a clue in charge?

The president doesn't have a clue either!

As clueless Louis once said: "If you want to make sure your phone works, make sure your number isn't in the yellow pages."

***** FLAME OFF *****

This article was sponsored by the "get a clue" foundation: - people with clue trying to get it to you.

[Extensive disclaimers omitted.]

Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225

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

Date: Mon, 16 Dec 96 14:02 GMT0 From: timn@cix.compulink.co.uk (Tim Nott) Subject: You can't rewrite history in Internet Explorer 3

Microsoft Internet Explorer 3 for Windows 95 maintains two special folders. One, the 'Temporary Internet Files' folder, actually contains four MS-DOS directories, used to cache HTML documents, GIFs, JPEGs and other files downloaded from the Web. The other is the 'History' folder, which does a similar caching task, but for URLs. Although each URL appears as a separate entity in the folder they are actually stored in two .DAT files.

Clearing the History folder removes the entries visible in the Explorer folder, but does not delete, or reinitialise the DAT files. These are still visible using File Manager, and can be opened with a text editor to show all the 'deleted' URLs. The files cannot be deleted by normal means including first resetting attributes) from within File Manager or Explorer. Presumably they are overwriten 'as needed' by new URLs. Risks? We know where you've been today...

Tim Nott Figeac France

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

Date: Mon, 16 Dec 96 13:44:57 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: *Java Security* by Gary McGraw and Edward W. Felten

Gary McGraw and Edward W. Felten Java Security: Hostile Applets, Holes, and Antidotes -- What Every Netscape and Internet Explorer User Needs to Know John Wiley & Sons, New York, New York, 1997 ISBN 0-471-17842-X

This book is mandatory reading for every user and developer of Webware. It considerably extends what readers of RISKS have already learned, and puts the entire topic into a coherent and readily accessible form.

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

Date: Mon, 16 Dec 1996 10:22:08 GMT From: ian@pumptt.powernet.co.uk (Ian Barker) Subject: When is an upgrade not an upgrade?

A few days ago a non-technical neighbour of mine asked me to pop over and check out the new Pentium PC she had bought for her family and herself. She is not particularly familiar with computers and this was her first PC. Her main concern was that the computer dealer was going to "come back in a few days" to upgrade the Pentium Chip from a 133Mhz to 166Mhz and she wanted to make sure she wasn't wasting her time installing any new software if the upgrade was going to trash her hard disk.

The new machine was running Microsoft Windows '95 and the dealer had helpfully renamed the "My Computer" icon on the desktop to say "Pentium 133" - presumably as part of their standard installation process. Fair enough.

My neighbour told me the dealer had told her that the machine was "running at 95 percent full power" and that he would return in a few days to "switch it to 166Mhz". She *knew* it had 16MB of memory because the machine counted it as part of the boot-up process when the machine is switched on.

When the dealer's technical guy arrived (1 week later) he didn't have any parts or boards with him and he proceeded to rename the "My Computer" icon from "Pentium 133" to "Pentium 166". He fiddled around with the CD ROM (my neighbour had asked him to fix an unhealthy vibration). I hadn't told the technical guy that I was computer literate (I have my own software company) and he - wrongly - assumed that my neighbour's lack of knowledge was typical of all in the house.

The dealer's employee completed his inspection of the CD ROM and put on his coat ready to go. My neighbour's inquiries of "Is the PC running OK now?" were answered with assurances that all the work was completed and he was ready to leave - all this without once opening the PC case.

One assumes that either the dealer has been charging customers for Pentium 166 chipped PCs and installing the cheaper processors or the dealer's employee has been up to no good himself. Either way, my neighbour would have been no wiser - as far as she would have been able to tell the upgrade had been carried out as agreed. Technology is so advanced in her opinion that she thought it possible to upgrade the PC merely by sitting at the keyboard and typing. The processor inside the machine was actually a true Intel Pentium 133 (I checked!) but it could have been a Pentium 90, Cyrix or indeed just about anything else and a non-technical user would have had very little obvious way of checking.

The risks?

Just because a PC says it has a Pentium 133 inside it doesn't actually mean that it has. Just because someone says with authority that everything is as it should be it doesn't actually mean that it is. And always get a second opinion if you are about to spend a lot of money on something you don't really understand.

Needless to say my neighbour (and her rather large and incensed husband) took the PC back to the dealer and demanded her money back (which was finally paid by cheque even though she paid cash).

Ian Barker ian@pumptt.powernet.co.uk http://users.powernet.co.uk/pumptt

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

Date: Sat, 14 Dec 1996 07:32:01 -0500 From: Year2000InfoNet <mbsprog@idirect.com> Subject: Beware of Year2000 Sharks: A Story for Non-Believers

BEWARE OF YEAR2000 SHARKS: A STORY FOR NON-BELIEVERS

I offer the following story as a different slant on the effect Year2000 may have on companies. The Year2000 Shark may be after your customers too...

I was sitting in the waiting room of a tire-repair shop. The room was dingy, and the owner/manager behind the counter was covered in tire carbon from head to foot. Into this scene walked a well-dressed arrogant-looking fellow with a meek assistant. He walked up to the counter and assertively asked the manager if he knew whether his credit-card authorization system was Year2000-compliant. Needless to say, the manager was clueless.

The salesman offered to test the store's CC unit with a test card. No sooner had the manager given the slightest nod of agreement, the salesman was swiping his card through the unit and pointing triumphantly at the message that popped up saying the card was invalid. "This card," he said, "has an expiration date of January 30, 2000. This system is not Year2000-compliant. May I ask where you got this system and how much you paid for it..."

That manager was helplessly snowed by the circumstances. If there was some way for him to require that salesman to legitimize himself (and his test card), it didn't occur to him. I thought about stepping in, but wanted to see where things went first. The manager succeeded in fending off the salesman's push for an immediate sale, so I figured he'd be OK.

THE MORAL: Even companies who have dealt with the Year2000 problem effectively need to ensure that their customers do not fall prey to such sharks or wily competitors who may seize the opportunity caused by the lack of information. I'm not a marketing person, but I imagine marketing staffs around the business world will be "strategizing" on this very soon, if they haven't already started...

The Year2000 Information Report thanks Jud Williford, Manager, Application Architectures/Technology Architecture Planning, Information Technology Division, Federal Express Corporation for submitting this article for publication. Jud can be reached at jlwillif@fedex.com, Tel: (901) 922-2349, Fax: (901) 397-4494. This article appears in the latest issue of the Year2000 Information Report.

mbsprog@idirect.com http://web.idirect.com/~mbsprog (416) 650-9475

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

Date: Fri, 13 Dec 1996 21:21:06 -0500 (EST) From: Kenneth Albanowski <kjahds@kjahds.com> Subject: Re: .pdf files, RISKS of using Adobe Acrobat Reader (Ehrich, R-18.67)

[It is] even harder to read on monitors with 80x8 pixel resolution, or 2x8 pixel resolution (Braille readers) or without a monitor at all (Speech synthesis). Not to mention simply difficult to read if your monitor doesn't match the aspect ratio of the original page.

As far as I can see, the risks are monumental. From my viewpoint, a format like HTML (which was designed to be accessible to everyone and every piece of software) is far, _far_, superior to a system which hands you dressed up photographs of each page in turn.

It may be simple for companies to produce .pdf documentation, but by doing so they sharply curtail the usefulness of the information.

Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

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

Date: Sat, 14 Dec 1996 04:49:47 GMT From: genew@mindlink.bc.ca (Gene Wirchenko) Subject: Re: .pdf files, RISKS of using Adobe Acrobat Reader (Ehrich, R-18.67)

I'm sure glad I don't use a user-hostile system like a Mac. Instead, I use a user-hostile IBM compatible. My fun has been with Microsoft Visual FoxPro 5.0.

The Language Reference manual supposedly is a language reference manual, but it isn't. It has information on the syntax of the command, what the arguments are, BUT LITTLE TO NOTHING ABOUT THE SEMANTICS.

Fortunately, that is available in the on-line documentation. Needing a language reference manual, you might want to print all of the on-line docs. So you print it out. (Cost?) Then you find that the heading isn't printed. With most of the commands, the syntax diagram just down from the top has the item name, but with some retained for backward compatibility, they are only documented with something like "This feature retained for backward compatability. Use <something else> instead." and nothing else.

Did you want to print the topics more than one at a time? To do that, you put the topics you want into the on-line docs notepad (where they are listed in reverse order), print them (and find they print in reverse order (A nice match!)), and then delete them from the notepad (ONE at a time).

Are you finding this confusing? Try the on-line help for the on-line documentation. I got lost. It's the worst on-line help I've ever read.

The RISK? A customer (me) could refer to your manuals as "flingware" and raise hell with technical support. He might also switch to another product. (If the product itself wasn't reasonable, I might have.) VFP looks good, but if you can't get it going...

Gene Wirchenko

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

Date: Fri, 13 Dec 1996 19:51:01 -0800 From: hal lewis <hlewis@physics.ucsb.edu> Subject: Re: Combatting cookies (Schneier, RISKS-18.67)

I wish I knew why my solution---making the cookie file read-only---isn't just as good. Nobody ever writes to my cookie file, and nobody ever aborts a transmission (to my knowledge) just because they can't write to my cookie file. Am I missing something here?

Hal Lewis

[Also proposed by Michael Schuerig <uzs90z@ibm.rhrz.uni-bonn.de> and "Stirling Westrup" <sti@Hydro.CAM.ORG>. PGN]

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

Date: Fri, 13 Dec 1996 23:14:33 -0600 (CST) From: Frank Stuart <fstuart@vetmed.auburn.edu> Subject: Re: Combatting cookies

Making Netscape's cookies file a symbolic link to /dev/null is also an effective way to disable cookies under UNIX.

Frank Stuart fstuart@vetmed.auburn.edu

[Also proposed by Brian Clapper <bmc@n2k.com> and Rik Faith <faith@cs.unc.edu>. A much more elaborate scheme was proposed by Zygo Blaxell <zblaxell@myrus.com>, replacing the set-cookie string with an equal-length random string. Carl Maniscalco <caman@earthlink.net> suggested a freeware utility called "Cookie Monster". PGN]

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

Date: Mon, 16 Dec 96 08:07:56 +0100 From: kaiser@acm.org Subject: Re: Combatting cookies

I also have "alert me" to cookies turned on in my Netscape browser, and last Friday I brought up a page that attempted to set twenty-nine cookies.

Anyone who does this to me is running a risk: the risk that I won't return to that page.

Incidentally, so far I've encountered nothing anywhere to make me permit a cookie.

Pete kaiser@acm.org

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

Date: Mon, 16 Dec 1996 13:45:47 +0000 From: Richard Nealon <Richard.Nealon@ITD.boi.ie> Subject: Women into Computing Conference 1997, last call for papers

WOMEN INTO COMPUTING CONFERENCE 1997 IN ASSOCIATION WITH CENTRE FOR COMPUTING AND SOCIAL RESPONSIBILITY

To be held at De Montfort University, Milton Keynes, UK. 10th July - 12th July 1997

*** PAPER SUBMISSIONS DUE 6 January 1997 ***

PROGRESSION: FROM WHERE TO WHAT?

Computing and information technologies are now ubiquitous and of vital importance in the global society. Gender related issues in computing continue to be critical in realising the potential of these technologies. Computing as a discipline has a clear gender imbalance. Recent figures show recruitment of women into the discipline is continuing to decline.

To date, significant determinants of women's success in the computing field have been explored primarily in terms of societal, cultural and organisational work factors. The perspective of women computer technologists and engineers has often been overlooked. Tensions between the different groups exist but there has been insufficient dialogue between these different groups to date. This conference will address this situation and provide an opportunity for a greater understanding between all those working in and associated with computing.

Papers are invited within the broad area of Gender related computing research. This includes but is not limited to:-

1. Telematics -the field of computer mediated communication. 2. Women systems/software engineers - a contradiction in terms? 3. Professionalism, legislation and the role of women. 4. Women Returners 5. 'Man Machine' Interface to 'human Computer' Interface to what? 6. Feminist perspectives in computing research. 7. Education - computing education and the use of computers in education.

An underlying theme of the conference is to be social responsibility and therefore we wish to encourage papers emphasising this and ethical issues. Papers taking different cultural, national and societal aspects are particularly welcome as are globally oriented papers.

In addition, we are looking for sister organisations throughout Europe to participate in the conference. The aim is to report on European Women's Organisations, initiatives and relevant research. We will be maximising participation through the use of video conferencing services at De Montfort University.

For further details, or if you would like to register an intention to submit or participate in the conference, please email : wic97@dmu.ac.uk We will then add you to our mailing list for registration

Further information on Women into Computing can be found at: http://osiris.sund.ac.uk/wic/wic-home.htm

Further information on the Centre for Computing and Social Responsibility can be found at: http:///www.cms.dmu.ac.uk/CCSR

Centre for Computing and | Dept of Computer Science, Social Responsibility | De Montfort University, e-mail: ccsr@dmu.ac.uk | The Gateway WWW : www.cms.dmu.ac.uk/CCSR/ | LEICESTER, UK LE1 9BH

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

Date: 16 Dec 1996 From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Privacy Digests

Periodically I remind you of TWO useful digests related to privacy, both of which are siphoning off some of the material that would otherwise appear in RISKS, but which should be read by those of you vitally interested in privacy problems. RISKS will continue to carry general discussions in which risks to privacy are a concern.

* The PRIVACY Forum is run by Lauren Weinstein, with some support from the ACM Committee on Computers and Public Policy. He manages it as a rather selectively moderated digest, somewhat akin to RISKS; it spans the full range of both technological and non-technological privacy-related issues (with an emphasis on the former). For information regarding the PRIVACY Forum, please send the exact line:

information privacy

as the first text in the BODY of a message to:

privacy-request@vortex.com

You will receive a response from an automated listserv system. To submit contributions, send to "privacy@vortex.com".

Information and materials relating to the PRIVACY Forum may also be obtained from the PRIVACY Forum Archive via ftp to "ftp.vortex.com", gopher at "gopher.vortex.com", and World Wide Web via: "http://www.vortex.com". Full keyword searching of the PRIVACY Forum Archive is available through the World Wide Web access address.

* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is run by Leonard P. Levine. It is gatewayed to the USENET newsgroup comp.society.privacy. It is a relatively open (i.e., less tightly moderated) forum, and was established to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. Submissions should go to comp-privacy@uwm.edu and administrative requests to comp-privacy-request@uwm.edu.

There is clearly much potential for overlap between the two digests, although contributions tend not to appear in both places. If you are very short of time and can scan only one, you might want to try the former. If you are interested in ongoing discussions, try the latter. Otherwise, it may well be appropriate for you to read both, depending on the strength of your interests and time available. PGN

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

Date: 15 Aug 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) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, 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.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. 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

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

End of RISKS-FORUM Digest 18.68 ************************