Text File

precedence: bulk Subject: Risks Digest 20.41

RISKS-LIST: Risks-Forum Digest Sunday 23 May 1999 Volume 20 : Issue 41

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 <URL:http://catless.ncl.ac.uk/Risks/20.41.html> and at ftp.sri.com/risks/ .

Contents: Re: Biometric risks (Dan Wallach, Fred Herr, Dan Wallach reponding to James L. Cambier, Paul Lewis Gittins) Costly fight about party software (Debora Weber-Wulff) Embedded NT ... (Jeremy Epstein) Vulnerability in Windows SSL server and common browsers (Chris Cowley) Buggier than thou ... Wiretapping (Mike Williams) Y1.K9 (Mark Brader) JAVA language definition (Craig DeForest) Documentation for vapor (Seth Gordon) Risks of aliasing webservers (Tim Panton) May you live in interesting times, or What excites bankers (Mark Brader) REVIEW: "Digital Democracy", Cynthia J. Alexander/Leslie A. Pal (Rob Slade) Abridged info on RISKS (comp.risks)

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

Date: Wed, 19 May 1999 20:01:11 -0500 From: Dan Wallach <dwallach@cs.rice.edu> Subject: Re: Biometric risks (RISKS-20.40)

A few clarifications on my last post.

- I mixed up iris and retina scans. The iris is the thing in front of your eye with the pretty colors. The retina is the thing in the back with the photoreceptors. Both are useful for identification, but the iris is somewhat less difficult to scan. Bank United of Texas intends to do iris scans.

- Two companies who are apparently big into eye-dentification are Sensar [1] and IriScan [2]. The latter site has more depth in its description of the technology. One private e-mail I received described that modern ATM machines from Diebold and NCR run Windows NT (*sigh*) and allow third parties to integrate their own security measures.

- As biometrics go, iris scans seem to be pretty good. I'm willing to believe vendor claims of high discrimination and low error rates. In particular, [3] claims that the system can be designed to have an error rate of approximately 1 in a million (both false accepts and rejects). There is a tradeoff where the designer can choose to decrease the odds of a false accept in exchange for increasing the odds of a false reject. One such stated data point would have one in 22700 customers falsely rejected in return for a one in 10^11 false accept rate. "Authentication failed. Please try again."

- Claims that iris biometrics cannot be copied or spoofed seem less believable. Once I've got a good photograph of your iris, I should be able to (with some expense) construct an artificial eye that matches the original. Vendors claim recognition times of 2-4 seconds. That's how long you hold your styrofoam head in front of the machine. [3] mentions various other spectral scans (i.e., infrared light) that might distinguish a styrofoam dummy from an actual head and a glass eye from a real eye. I'm sure this stuff works great, but again will be broken in due course.

- I've received some interesting private e-mail on this subject. There are some people who don't have irises (300 children born this way per year in the U.S., says one person preferring to remain anonymous). One issue with pure biometric authentication is dealing with the non-zero number of people who don't happen to *have* your preferred biometric.

- Both companies seem to be marketing their products as the only form of authentication you need. This is my strongest complaint. I could support the use of a smartcard as the primary identification and the biometric as a replacement for PINs or passwords. That would be sensible for banking applications and would help quash any desires for evil-doers to try beating the system. Also, for the biometrically-challenged, their cards could be coded in such a way as to indicate the customer is a special case for the system. Indeed, I find it hard to imagine my bank not wanting to keep a piece of plastic in my wallet with their name on it.

- Lastly, we haven't even begun to discuss the risks that occur when an industrious bank officer physically hacks the ATM. If the ATM hacker need only intercept the video camera wires, a quite nasty attack could be developed which nicely generates perfect "evidence" that a transaction occurred. Conversely, a crypto smartcard could go great distances in eliminating the ease of such an insider attack. (Not that smartcards don't have their own problems, for example, differential power analysis [4].)

Dan Wallach, Rice University

[1] http://www.sensar.com/products/products.stm [2] http://www.iriscan.com/technology.htm [3] http://www.iriscan.com/basis.htm [4] http://www.cryptography.com/dpa/

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

Date: Wed, 19 May 1999 14:38:42 -0400 From: "Herr, Fred K" <Fred.Herr@unisys.com> Subject: Re: Biometric Risks (Wallach, RISKS-20.40)

[Fred's first 4 points were more or less covered by Dan's message, which he send before I had sent him Fred's. I have removed them. PGN]

5. The same technology recently completed a pilot with ATMs in Swindon, UK, where it apparently generated high levels of satisfaction and enthusiasm.

Biometrics are pretty well established by now, as most anyone who attended the CardTech/SecurTech show in Chicago last week can testify. Most people who understand it are not afraid of the technology itself.

The legitimate Risk is how well will the biometric user, Bank United in this case, protect the biometric data. As a bank, I would expect them to provide the same level of protection they give to their customers' names, account numbers, balances, transaction histories, etc.

Movies that show bad guys cutting out eyeballs to defeat "biometric" security systems may provide cheap thrills and grist for the alarmists, but they bear little relation to the realities of biometrics today. My great grandmother may have been afraid to have her house wired for electricity, but I suspect Dan knows enough about that technology not to panic. I hope he, and others with equivalent understanding of biometrics, will spend a little time investigating. www.biometrics.org is a great place to start.

Privacy! You want privacy?! How about the medical testing company that uses biometrics to insure their clients' COMPLETE anonymity. They don't even take your name and address. Just your biometric. Only you can get your test results because the key you use to get them is that same biometric.

Yes, biometrics can be part of systems that threaten privacy, but they have the potential to do more good than harm. Check out www.ibia.org.

Fred Herr

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

Date: Thu, 20 May 1999 15:28:11 -0500 From: Dan Wallach <dwallach@cs.rice.edu> Subject: Re: Biometric Risks (Wallach, RISKS-20.40)

Wow, my post really touched a nerve! Here's a note from IriScan's VP of Technology.

P.S. Geez, if I knew I was going to stir up this much mud... Dan

Date: Thu, 20 May 1999 15:35:14 -0400 To: Dan Wallach <dwallach@cs.rice.edu> >From: "James L. Cambier" <jcambier@iriscan.com> Subject: Re: Biometric Risks

Dear Mr. Wallach:

I am writing in response to your "Biometric Risks" article in RISKS-20.40, 18 May 1999.

First, to relieve some confusion. The biometric technology being evaluated by Bank United is IRIS recognition, not RETINA scanning. The iris recognition equipment used in the Diebold ATM machines (and those of several other ATM manufacturers) is supplied by Sensar (www.sensar.com), which in turn is a licensee of IriScan, Inc. (www.iriscan.com), which developed and holds worldwide rights to the core iris recognition technology. The significant differences between the capabilities, performance, and user friendliness of iris vs. retina imaging are detailed in our website, www.iriscan.com.

I would offer several counters to the assertions in your article. Relying on a single authentication factor, "something you are", is NOT a disaster if the biometric used is based on the human iris, which offers profoundly higher information content and, with appropriate algorithms, several orders of magnitude lower false accept and false reject rates than any other biometric. This is attested by numerous independent studies and widely accepted within the biometrics industry. Iris recognition equipment manufactured by IriScan has been in use in government, industrial, corrections, banking, and other facilities for at least five years with resounding success. And unlike other biometrics, iris recognition has sufficiently low error rates that it can be used in large scale identification (as opposed to verification) applications successfully. Hence there is no need for usernames, passwords, tokens, etc. Identity is determined solely from the iris template. And in the millions of iris recognitions that have been conducted by evaluators and customers over the last ten years, we have NEVER experienced a false accept event.

The iris recognition system used by Bank United does not transmit images or maintain them in any archival storage. Each captured image is immediately processed to generate a proprietary, highly unique 512-byte IrisCode(TM) template then the image is deleted. The template is encrypted (using industry standard encryption algorithms) before it is transmitted to the bank for authentication.

Needless to say, the iris recognition technology includes countermeasures to guard against attempts to deceive the system with photographs or other devices. And, finally, the postscript at the end of your article about "potential eye damage from miscalibrated units" is unfounded and irresponsible. The illumination used by this and other iris recognition devices is extremely low level, near-infrared illumination that is incapable of producing energy levels greater than several orders of magnitude below commonly accepted damage thresholds for the eye.

[Yes, I was thinking of the Therac 25, where it was falsely believed that the system could not harm the patient. I realize that well implemented iris scanning might not have that risk, but for long-time readers of RISKS, believing in such certainties is often itself a huge risk. PGN]

Please feel free to contact me if you have any questions or comments.

James L. Cambier, Ph.D., VP Technology Development, Chief Technology Officer IriScan, Inc. 9 East Stow Road, Suite F Marlton, NJ 08053-3159 609-797-6890

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

Date: Fri, 21 May 1999 23:52:05 +0100 From: Paul Lewis Gittins <plg101@york.ac.uk> Subject: Re: Risks Digest 20.40, Iris Scanning ATMs

RE: Iris Scanning ATM'S

Further to the recent article, I hope that any bank implementing the iris scanning systems will not be relying on this as the sole authentication method. There is an inherent problem, in that this further disadvantages some people with visual disabilities. Visually impaired users who wish to use atms have little enough thought from interface designers as it is, without further problems in hampering the UI. Suppose the user has no iris that can be scanned, will a pin number still suffice? OK, it may be a small number of users, but the user group does still exist. With banks pushing more and more services out to atms and remote access, it must only be a consideration that users must not have further hamperings in using the system....

I remember a quote from my old tutor, regarding Dexel (sp?) University saying that all undergraduates should buy a Mac to do their courses - what they were implying was that blind users need not apply.....

Paul

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

Date: Thu, 13 May 1999 10:31:41 +0200 From: Debora Weber-Wulff <weberwu@tfh-berlin.de> Subject: Costly fight about party software

[excerpted and translated from "Der Tagesspiegel", 1999-05-12, p. 5]

The central administration of the SPD party, the major coalition partner in Germany, has no idea who belongs to the party or if they are up to date with their dues. The problem is software that was delivered by the large German software company SAP, says the SPD, who employed a company in Hamburg to document the problems in September 1998. This company notes: "Not one of the larger batch runs has been free from problems, programming errors, unexpected terminations or needed corrections."

SAP retorts: "The SPD ordered a VW Beetle but expects us to deliver a Daimler [Meredes-Benz]". The SPD bites back: "We would be happy to have software that runs like the Beetle, but we have had to correct disastrous errors ourselves". [No word on what the cause of the problems is.]

While the fight, purported to be about the 35 million DM price for the software (about 19 million $), rages, the SPD has no way of knowing exactly how many members it has [or if there are enough DM coming in from outstanding dues to pay the lawyers!]. -- Prof. Dr. Debora Weber-Wulff TFH Berlin, FB Informatik Luxemburger Str. 10, 13353 Berlin, Germany weberwu@tfh-berlin.de http://www.tfh-berlin.de/~weberwu

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

Date: Fri, 21 May 1999 07:29:45 -0700 From: "Epstein, Jeremy" <Jeremy_Epstein@NAI.com> Subject: Embedded NT... (in case you don't have enough to worry about already)

One of the articles about the well-reported link between Xerox and Microsoft (in which Xerox will use "embedded NT" in its copiers and Microsoft will license certain Xerox web technologies) had an interesting comment. John Markoff reports in _The New York Times_ May 19th edition that "although the reliability of Windows NT has been questioned in so-called mission-critical industrial applications, the company has succeeded in persuading hardware developers to use it in a wide variety of devices, ranging from point-of-sale systems to computer routers and airline avionics." The article also mentions the infamous 1997 incident where the USS Yorktown was left dead in the water due to a failure related to NT (although it's still unclear whether it was a flaw in NT itself).

Makes me wish for the good old days of the early Airbus fly-by-wire systems.....

--Jeremy

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

Date: Fri, 21 May 1999 14:39:00 GMT From: ccowley@grok.co.uk (Chris Cowley) Subject: Vulnerability in Windows SSL server and common browsers

Some time ago, I downloaded a trial version of an SSL web server product for Windows NT called 'Alibaba 2.0' for evaluation as a possible SSL solution. I eventually made a decision to use another product, but I ended up using an RSA key pair generated by Alibaba's 'genkey' utility (which is based on the popular SSLeay toolkit).

Whilst recently examining the keys generated by 'genkey' using tools shipped as part of the SSLeay distribution, I discovered what I believe to be a serious flaw:-

The 'genkey' utility erroneously generates a private key with an exponent of '1'. This results in null security since the RSA public key associated with a private exponent of '1' is also '1', with the effect that the session key for each SSL session to a server running 'Alibaba' is sent in the clear.

The result of this vulnerability is that 'secure' web sites that use keys generated by the 'genkey' utility provided with Alibaba 2.0 do not provide any security. Such sites are susceptible to having their transactions snooped by a third party, or falsified by man-in-the-middle attacks.

A further interesting discovery is that both Netscape Navigator and Internet Explorer will happily let the user interact with SSL web sites which have an RSA public key exponent of '1' without bringing the user's attention to the fact that such transactions are, in fact, entirely insecure.

Chris Cowley, Grok Developments Ltd http://www.grok.co.uk/

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

Date: Fri, 21 May 1999 09:20:47 -0400 From: Mike <John.Michael.Williams@Computer.org> Subject: Buggier than thou ... Wiretapping

Electronic Wiretaps on Wireless Devices Outnumber Those On Wireline Phones

An annual report by the Administrative Office of the U.S. Courts reveals the number of electronic wiretaps on wireless phones and other wireless devices has more than tripled in the past year. (USA Today http://www.usatoday.com/life/cyber/tech/ctf213.htm )

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

Date: Tue, 18 May 1999 15:47:42 -0400 (EDT) From: msbrader@interlog.com (Mark Brader) Subject: Y1.9K

[From Mark after forwarding to him from David M. Sherman. PGN]

> J.J. McVeigh wrote: > > > > ]]]]]] EMPEROR HIROHITO'S DEATH CAUSES SOFTWARE PROBLEMS [[[[[[ > > (1/18/1989) > > [From Pavan Sahgal, ``Automation at the "Big Four" Securities > > Firms'', Wall Street Computer Review, January 1989, p. 23] > > > > [Kindly uploaded by Freeman 10602PANC] > > > > Under Japanese custom, when a new emperor is crowned, his > > reign or era is marked by a title that appears on all records in > > the country. [Hirohito's era was called Showa, or peace.] > > [E]xecutives at Tokyo's leading securities firms were > > chagrined to discover that the computer programmers who wrote > > accounting, recordkeeping and customer billing systems software > > in recent years created inflexible systems. They did not > > envisage that someday Japan would have a new emperor, and his > > reign would mark the start of a new era requiring records and > > statements to reflect that. > > The dilemma is comparable to having a system that won't change > > from 1988 to 1989. The programmers had overlooked an essential > > detail that obviously has widespread fundamental implications. > > Even worse, a new generation was sadly out of touch with custom > > and the saying, Koin ya no-goto she [acute accent over e] (A > > lifetime goes like an arrow). > > > > * * * > > http://www.powerup.com.au/~dominion/ff/k14.htm > > David M. Sherman, LLB, LLM, Tax Author & Consultant > ds@davidsherman.ca http://www.davidsherman.ca

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

Date: Wed, 19 May 1999 10:33:20 -0700 From: craig@deforest.org Subject: JAVA language definition (Was Re: C Compilers vs editors)

Roy Wright and Daniel Graifer have pointed out that MS Visual J++ sometimes uses a single return carriage to end a line, breaking some compilers. Roy suggested that the problem is either "an attempt to lock a developer into one set of tools or very sloppy design".

I forwarded the note on to my friend Josh Engel, who just finished writing a large monograph on Java. He sent me the following snippet:

>From the Java language specification: > >>3.4 Line Terminators >> ... >>LineTerminator: >> >> the ASCII LF character, also known as "newline" >> the ASCII CR character, also known as "return" >> the ASCII CR character followed by the ASCII LF character >> >>Lines are terminated by the ASCII characters CR, or LF, or CR LF. The two >>characters CR immediately followed by LF are counted as one line >>terminator, not two. The result is a sequence of line terminators and input >>characters, which are the terminal symbols for the third step in the >>tokenization process. >> >******************************************************** >As I read this, Visual J++ is correct. A CR by itself is a line terminator. > >If Cafe and the JDK fail to recognize CR by itself as a line terminator, >then they are not in compliance with the spec and must be corrected.

So M$ may indeed be trying to "embrace and break", but for once they're staying wholly within their allowed spec. (The Java spec in this case is the document co-authored by GLS, not some Redmond-spawned variant.)

The RISK? If you break enough specs, eventually people will assume that all software incompatibility is your fault.

[I'm guessing that Craig's last name might be DeForest. If not, I am guilty of DeForestation by adding two extra lines. PGN]

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

Date: Wed, 19 May 1999 13:32:07 -0400 From: "Seth Gordon" <sgordon@kenan.com> Subject: Documentation for vapor

A few weeks back, our company upgraded all of our PCs to use the latest version of Microsoft Office. Aside from experimenting with Outlook, I ignored the upgrade, since our group uses FrameMaker for all of the documentation we write. Now, I have to produce templates in Microsoft Word, so that people in our company who have Word and not FrameMaker can produce a document that is formatted like our standard documentation.

The upgrade had not come with a manual, so I went down to the local nerd bookstore in search of books on Word, and one of the items on the shelf was _Running Microsoft Word 2000_ (Microsoft Press). I dimly recalled people referring to my version of Office as "Office 97", but I figured that the "Office 2000" label might be a marketing gimmick and not a distinct version. The windows in the screen shots looked like the windows I had seen using the program, so I bought the book.

After a couple days wrestling with the program, the manual, and Microsoft's Web pages, I discovered that:

(1) Word 97 SR-2 is not, in fact, Word 2000. (2) Word 2000 hasn't been released yet.

OK, I erred by not looking up my version number before going on this shopping trip, but ... what's the point of selling a nine-hundred-page manual for a program that hasn't been released yet?

seth gordon == documentation group, kenan systems corp.

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

Date: Thu, 20 May 1999 16:15:59 +0100 From: Tim Panton <thp@westhawk.co.uk> Subject: Risks of aliasing webservers

I've just been browsing the Trustwise web site - they sell Verisign certificates for us UK users.

They seem to be owned by BT, which has resulted in an entertaining problem When I opened https://www.trustwise.bt.com/ServerIdCentre.html I get a message from IE saying:

<QUOTE> A secure connection with this site can not be verified. Would you still like to proceed ?

The certificate you are viewing does not match the name of the site you are trying to view. </QUOTE>

Wiewing the certificate shows that it was assigned to www.trustwise.com . When I altered the URL, I got a correct page.

Looking in the DNS, I see that they have the same IP address(es).

www.trustwise.com internet address = 193.113.157.254 www.trustwise.com internet address = 193.113.157.253

www.trustwise.bt.com internet address = 193.113.157.254 www.trustwise.bt.com internet address = 193.113.157.253

If a company selling certificates can't get it right - what hope have the rest of us.

Tim Panton <thp@westhawk.co.uk>, Java consultant/implementor Westhawk Ltd Westhawk Ltd, Albion Wharf, Albion St, Manchester M1 5LN +44 1612370660

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

Date: Tue, 18 May 1999 16:38:01 -0400 (EDT) From: msbrader@interlog.com Subject: May you live in interesting times, or What excites bankers

In a brochure on their Y2K readiness, the Bank of Montreal writes:

Seeing the calendar change to the Year 2000 will be an exciting event.

I certainly hope it doesn't prove "exciting"!

Mark Brader, Toronto Carpe pecuniam! msbrader@interlog.com --Roger L. Smith

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

Date: Tue, 18 May 1999 08:40:11 -0800 From: Rob Slade <rslade@sprint.ca> Subject: REVIEW: "Digital Democracy", Cynthia J. Alexander/Leslie A. Pal

BKDGTLDM.RVW 990326

"Digital Democracy", Cynthia J. Alexander/Leslie A. Pal, 1998, 0-19-541359-8, U$26.50 %E Cynthia J. Alexander %E Leslie A. Pal %C 70 Wynford Drive, Don Mills, Ontario M3C 1J9 %D 1998 %G 0-19-541359-8 %I Oxford University Press %O U$26.50 212-679-7300 %P 237 p. %T "Digital Democracy: Policy and Politics in the Wired World"

As a techie, I more comfortable with the "hard" sciences with provable outcomes, such as the "running code" (1) of the Internet. However, as one interested in the social aspects of the net, I have to respect the softer sciences, since without "rough consensus" (2) there would be neither protocol standards, nor the real heart of the communications that goes on. As Dimwiddy and Bunkum state (3), though, PoliSci is so soft as to be positively mushy.

Right from the beginning (4) the text is heavily larded with footnotes, which sometimes threaten to overpower the essays they are supposed to support (5). Oddly, though, these footnotes do not give any impression of the strength of the material in the book, quite the contrary. Instead, they tend to lend credence to the statement that 94.3% of all statistics are made up on the spot (6). The content of the book tends to be strangely unformed, with statements ranging between unsupported bombast that we are simply assumed to accept, to citations of studies without much discussion of relevance or validity.

After an introduction, there is a piece on "social forces in the hypermedia environment" that seems to want to talk about economics, a discussion of national security, and something looking at the national or global information infrastructure. None of these pieces, and, indeed, nothing in the book, seems to have any real idea of the technology involved, or the implications of the technology. A look at women on the net states that "Few will argue the impact of written language or--many centuries later--the printing press in shaping new societies" (7) while blithely ignoring the fact that we have very little idea of what those impacts might have been. Leslie Pal's own contribution, examining the outcry over the Communications Decency Act, seems to have the greatest understanding of modern communications systems, but even there (8) does not comprehend that the technical aspects of "flooding" algorithms and dynamic rerouting were what forced commercial services to lobby against the bill.

The paper on teledemocracy bemoans the fact that lack of a touch tone phone disenfranchises a massive 5% of the population (9), while ignoring as insignificant a 12% disparity in polling results (10). His lauding of Ted White's telephone polling (11) was of particular interest to me, since I live in White's riding and a) didn't get a pin, b) could have reproduced White's polling system using local technology at far lower cost to both constituents and the government (12).

There is a pedestrian piece on intellectual property. Then there is the mandatory article on pornography. (Can we have a Rimm shot? Thank you.) The Rimm "study" (13), and another equally suspect, categorize a bunch of feelthy peechers, and we are then told that there is a clear benefit for regulation of pornography (14).

The essay on privacy takes for granted that you cannot have freedom without privacy (15), ignoring items like David Brin's "The Transparent Society" which proposes a remarkably free environment almost completely devoid of privacy (16). The article also decries identification numbers of all types, and then goes on (17) to laud public key encryption, seemingly unaware that a public key is a number.

Neither the discussion of health care nor that of indigenous people really looks at social aspects of the technology.

This seems to be my week for dumping on compatriots (18). However, my rabid nationalism does not extend so far as to defend those resident in my country when they don't know what they are talking about, and this book seems to be almost completely devoid of experience of the technology under examination.

(1) Dave Clark (of MIT), IETF Conference, 1992 (2) ibid (3) I made them up, of course. (4) Well, I suppose not; there are no footnotes in the acknowledgement; but the first one comes in the second paragraph of the preface on page xii. (5) They never actually do. (6) This figure is embedded in one of my brother's sigblocks: I think he made it up. (7) p. 88 (8) p. 111 (9) p. 140 (10) p. 135 (11) p. 136 (12) White used Maritime T&T, had to spend $11,000 setting up a single poll, and it cost people $1.95 per time to vote. A PC based system could have, at the time, been established for about $5,000 altogether, and could have been reused at any time for further polling. (13) lucky, eh? (14) p. 176. I'm not exactly on the side of pornography, but there are a few steps missing in the proof, here. (15) p. 181 (16) cf. BKTRASOC.RVW (17) p. 187 (18) See also "Roadkill on the Information Highway" (BKRKOTIH.RVW)

copyright Robert M. Slade, 1999 BKDGTLDM.RVW 990326 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade

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

Date: 23 Sep 1998 (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 <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] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => 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.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

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

End of RISKS-FORUM Digest 20.41 ************************