Text File

precedence: bulk Subject: Risks Digest 20.53

RISKS-LIST: Risks-Forum Digest Tuesday 10 August 1999 Volume 20 : Issue 53

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.53.html> and at ftp.sri.com/risks/ .

Contents: Cell Phones Become Instant Bugs! (Lauren Weinstein) Cell phone sends jet off-course (David Clark) Sharing files via Yahoo (Morten Welinder) Executive Order on Unlawful Conduct on the Internet (Bill Clinton via PGN) California's "shameful reputation"! (PGN) NCIC 2000 Begins Operations (Jack N. Fenner) Complexity and Safety in Medical Electronics (Dr D John Doyle) Re: Go FORTH (M. Simon) E-Trade and long passwords (Mark Harrison) Security sites vandalized (NewsScan) SPAM causes major ISP crash (Peter Leeson) Re: PCS, IMRSS, Mobile phones in airplanes (Peter Houppermans) Cell phones and aviation electronics (Glenn Carroll) REVIEW: "Kerberos: A Network Authentication System", Brian Tung (Rob Slade) UPCOMING EVENT- USENIX Security Symposium, 23-26 Aug 1999 in DC (Moun Chau) Abridged info on RISKS (comp.risks)

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

Date: Mon, 09 Aug 99 14:37:28 PDT From: Lauren Weinstein <lauren@vortex.com> Subject: Cell Phones Become Instant Bugs!

Greetings. A disturbing application for the new generations of digital cell phones appears to be developing -- many models can be easily used as remote-controlled clandestine listening devices ("bugs"), often with little or no modification.

It turns out that many current cell phone models can be set into modes where they are completely silent (no "boops" or "beeps") and will answer incoming calls automatically. This latter mode is designed for use in hands-free (headset) situations. A cell phone left in a strategic location set in such modes may be silently interrogated from virtually anywhere on the planet with a simple phone call, and will happily transmit the room conversations back to the caller. When the caller hangs up, the cell phone resets, ready for the next call.

In some cases, phones can be placed into this "automatic answer" mode without any accessories being required. For some models, a headset connector needs to be plugged into the phone, which may be modified to allow the phone to continue using its built-in microphone when in its "bugging" mode, or could trivially have a remote microphone wired via a very thin cable to the actual cell phone some distance away.

Even without an outside source of power, many modern digital cell phones can have standby times of a week or more, and be able to transmit conversations for a number of hours. With an outside power source, they could perform their bugging functions indefinitely.

Since various commercial firms are now planning to offer a wide variety of location-based services using cell phone location tracking capabilities, (which were originally mandated for 911 use), it seems likely that planted cell phones may soon be usable to track the location of persons or moving vehicles as well. Just picture a cell phone hidden in a car trunk with a tiny microphone wired up behind the rear seat, for example. The car wiring would also provide an ideal source of continuing power for both bugging and tracking via the cell phone. Simple, cheap, and accessible from practically anywhere!

Cell phones can also of course act as communications platforms for a variety of other add-on devices, such as tiny cameras, small Global Positioning System (GPS) units (for highly accurate location tracking that works *today*), and so on. While the current generations of cell phones have fairly limited data rates, and there are a variety of technical analog vs. digital issues involved, many cell phones can still be used for such "enhanced" applications even in the existing limited data bandwidth environment. It must also be pointed out that a hidden cell phone could also be used to remotely control or trigger apparatus connected to the phone, under the command of the caller.

With cell phones becoming smaller and the associated networks ever more ubiquitous, this whole area has a great deal of potential for serious privacy-invasive and other abuses. Lauren Weinstein <lauren@vortex.com> Moderator, PRIVACY Forum --- http://www.vortex.com; Host, "Vortex Daily Reality Report & Unreality Trivia Quiz" --- http://www.vortex.com/reality

[An earlier version of this appeared in Lauren's PRIVACY Forum Digest, (http://www.vortex.com/privacy/priv.08.11) Saturday, 7 August 1999 Volume 08 : Issue 11, which he has augmented for RISKS. PGN]

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

Date: Mon, 9 Aug 1999 12:28:45 -0700 From: "Clark, David" <Dave.Clark@BCHydro.bc.ca> Subject: Cell phone sends jet off-course

>From: "Telecom News - August 6-9, 1999" News Summary

> "CELL PHONE SENDS JET OFF-COURSE", *Ottawa Citizen*, 7 Aug 1999 > > "A Chinese plane drifted 30 degrees off course because a passenger failed > to switch off his mobile telephone. A crash was narrowly avoided after the > cabin crew found the phone during a desperate search while approaching > Beijing airport. Mobile phones are banned on planes worldwide but a direct > link with instrument failure has never been proved. The Beijing incident > is likely to provoke new air safely fears in Asia where at least one crash > is attributed to on-board phone use."

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

Date: Mon, 9 Aug 1999 21:02:59 +0200 (METDST) From: Morten Welinder <terra@diku.dk> Subject: Sharing files via Yahoo

I just met this ad on Yahoo:

Share all your important files with friends and co-workers with Yahoo! Briefcase

I am tempted to upload a few years' worth of comp.risks archives. Risks (familiar to faithful readers):

* Yahoo knows your secrets.

* Anyone who snoops their traffic knows them too.

* Anyone who asks Yahoo for your secrets knows them too. (Yahoo has a bad reputation for just handing over stuff in order to avoid trouble.)

* When your boss finds out who knows his secrets, he probably will not remain your boss.

* "Make telecommuting even easier!" Convenience for security.

* "Access and share files, documents and photos from anywhere." Your files or anyone else's, that is.

* "You'll be registered with all of Yahoo!'s services." Just in case you don't get enough e-mail as it is.

The only thing missing seems to be a small sign saying "Just kidding -- gotcha!".

Morten

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

Date: Mon, 09 Aug 99 20:50:48 PDT From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Executive Order on Unlawful Conduct on the Internet

THE WHITE HOUSE

Office of the Press Secretary (Little Rock, Arkansas)

For Immediate Release August 6, 1999

EXECUTIVE ORDER - - - - - - -

WORKING GROUP ON UNLAWFUL CONDUCT ON THE INTERNET

By the authority vested in me as President by the Constitution and the laws of the United States of America, and in order to address unlawful conduct that involves the use of the Internet, it is hereby ordered as follows:

Section 1. Establishment and Purpose. (a) There is hereby established a working group to address unlawful conduct that involves the use of the Internet ("Working Group"). The purpose of the Working Group shall be to prepare a report and recommendations concerning:

(1) The extent to which existing Federal laws provide a sufficient basis for effective investigation and prosecution of unlawful conduct that involves the use of the Internet, such as the illegal sale of guns, explosives, controlled substances, and prescription drugs, as well as fraud and child pornography.

(2) The extent to which new technology tools, capabilities, or legal authorities may be required for effective investigation and prosecution of unlawful conduct that involves the use of the Internet; and

(3) The potential for new or existing tools and capabilities to educate and empower parents, teachers, and others to prevent or to minimize the risks from unlawful conduct that involves the use of the Internet.

(b) The Working Group shall undertake this review in the context of current Administration Internet policy, which includes support for industry self-regulation where possible, technology-neutral laws and regulations, and an appreciation of the Internet as an important medium both domestically and internationally for commerce and free speech.

Sec. 2. Schedule. The Working Group shall complete its work to the greatest extent possible and present its report and recommendations to the President and Vice President within 120 days of the date of this order. Prior to such presentation, the report and recommendations shall be circulated through the Office of Management and Budget for review and comment by all appropriate Federal agencies.

Sec. 3. Membership.

(a) The Working Group shall be composed of the following members:

(1) The Attorney General (who shall serve as Chair of the Working Group).

(2) The Director of the Office of Management and Budget.

(3) The Secretary of the Treasury.

(4) The Secretary of Commerce.

(5) The Secretary of Education.

(6) The Director of the Federal Bureau of Investigation.

(7) The Director of the Bureau of Alcohol, Tobacco and Firearms.

(8) The Administrator of the Drug Enforcement Administration.

(9) The Chair of the Federal Trade Commission.

(10) The Commissioner of the Food and Drug Administration; and

(11) Other Federal officials deemed appropriate by the Chair of the Working Group.

(b) The co-chairs of the Interagency Working Group on Electronic Commerce shall serve as liaison to and attend meetings of the Working Group. Members of the Working Group may serve on the Working Group through designees.

WILLIAM J. CLINTON

THE WHITE HOUSE, August 5, 1999.

<http://www.pub.whitehouse.gov/uri-res/I2R?urn:pdi://oma.eop.gov.us/1999/8/9/11.text.1>

[For those of you whose systems lose the line overflow, that is http://www.pub.whitehouse.gov/uri-res/I2R concatenated with ?urn:pdi://oma.eop.gov.us/1999/8/9/11.text.1]

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

Date: Sun, 8 Aug 99 13:32:01 PDT From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: California's "shameful reputation"!

In the *Sunday Examiner and Chronicle*, 8 Aug 1999, the *Chronicle's* editorial ("Sunday" section, p.6) is titled "Silicon Valley Expertise Stops at Capitol Steps"; it begins with this statement:

In a cruel irony, the state that gave birth to Silicon Valley is also the state with one of the worst reputations for high-tech know-how at the government level. And it is a well-deserved, if shameful reputation.

This is prompted by the latest fiasco, the demise of

* A system supposedly linking county welfare offices (scrapped, $18M lost)

The editorial notes the earlier failures familiar to long-time RISKS readers:

* Deadbeat parents' system ($111M, abandoned) [RISKS-19.12, .43, .73, .82] * DMV upgrade ($51M, abandoned) [RISKS-15.80, .82, RISKS-16.01, .07] * California Lottery agreement to improve Scratcher game (contract cancelled, $52M lost after both sides sued) [not previously reported, although premonitions are noted in RISKS-14.18 and 14.20]

The editorial suggests that the new governor (Gray Davis) appears to recognize "that he has a critical role" to play, while asserting that the previous governor (Pete Wilson) "lacked sufficient interest".. The charge to improve matters rests with Elias Cortez, Davis' head of the Department of Information Technology (nicknamed ``DO IT''), who has put all new procurements on hold until Y2K is sorted out.

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

Date: Fri, 6 Aug 1999 14:21:32 -0700 (PDT) From: "Jack N." <jnf@pcisys.net> Subject: NCIC 2000 Begins Operations

The FBI has announced that the National Crime Information Center 2000 began operations on July 11. According to the FBI announcement (http://www.fbi.gov/pressrm/pressrel/ncic2000.htm), this is a major upgrade of the NCIC system which provides police officers nationwide with the ability to view mugshots, and perform fingerprint searches from their patrol vehicles. It also adds additional persons to the NCIC database, including persons on probation, on parole, in federal prison or with records as sexual offenders.

There are any number of risks associated with this system. Here are a few:

1) False positive matches on the fingerprint search. According to http://www.civic.com/pubs/1998/september/civ-techside1-9-14-98.html, the NCIC 2000 fingerprint scan has an accuracy rate of 92 percent. (The original contract called for 100% accurate positive matches and 98% negative matches.) If false positives are a significant element of the 8% error rate, lots of people will be hauled to police stations and at least inconvenienced based on incorrect NCIC matches.

2) Lots more people in the database. The accuracy and timeliness of the information in this database must be questioned.

3) According to the same www.civic.com article noted above, no probable cause is needed for an officer to require a fingerprint image. In fact, the system is intended to be used to establish probable cause. If a match is indicated, the suspect is then to be taken in to a police station and the larger IAFIS fingerprint scan system used to confirm identification. (IAFIS automates the entire FBI fingerprint database, is not yet online, has an unknown accuracy rate, and takes 2 hours to perform searches.)

4) The NCIC 2000 project was twice as expensive (US$183M vs US$80M) and a took twice as long (7 years vs 3 years) as originally projected. Also, at least one of the original requirements (accuracy) was relaxed. Thus it shows the cost increases, schedule delay, and requirements fade often associated with large, ambitious projects.

5) One wonders how long it will be until this system will be used as a method of collecting and storing fingerprints on citizens not convicted--or even charged with--any crime.

Jack Fenner

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

Date: Thu, 5 Aug 1999 22:34:26 -0400 From: "Dr D John Doyle" <djdoyle@home.com> Subject: Complexity and Safety in Medical Electronics

Some technologies, like scissors and chop sticks, are inherently simple.

Others, like nuclear reactors or life support electronics, are inherently complex. By nature, the safety issues associated with complex systems are more involved than those associated with simple systems. There are always added cost requirements in complexity, such as special requirements for ensuring the safe operation of the system. But the very subsystems added to increase safety necessarily add to complexity, and, ironically, enrich the number of possible failure modes in the overall system. Thus there is the concern that the failure of any addon safety system may sometimes actually lead to new system failure modes that would not have otherwise occurred.

Consider the following hypothetical example:

A sensor failure or algorithm failure in a patient monitoring system results in a false "asystole" alarm in a patient monitored during general anesthesia. (This alarm indicates that the patient is in cardiac arrest, an obviously grave situation. However, every single unexpected asystole alarm I have witnessed to date has been false.) In a panic from seeing this unexpected alarm, an inexperienced physician taking care of the patient forgets to check for the absence of a pulse to confirm that there is indeed a problem. Instead, the doctor calls for the crash cart and immediately administers a full ampoule (1000 micrograms) of adrenaline to restart the heart.

Trouble is, the heart was doing just fine until then. There was no asystole, no cardiac arrest, just an algorithm failure that occurred from a normal but low-amplitude electrocardiogram, possibly due to electrode misplacement.

Now the patient really is in trouble from a massive cardiac stimulant overdose!

Of course, this failure mode would not have occurred if no asystole monitor was used.

An interesting book which discusses these and other issues is: Robert Pool. Beyond Engineering: How Society Shapes Technology. Oxford University Press. New York. 1997. 358 p. $30. (Reviewed in IEEE Spectrum May 1998).

D. John Doyle MD PhD FRCPC University of Toronto and Toronto General Hospital djdoyle@home.com http://doyle.ibme.utoronto.ca

APPENDIX While 1000 micrograms (mcg) is a good starting dose in a full cardiac arrest setting, in the normal intact heart it is a massive amount. Only a 10 mcg dose of adrenaline is needed to "rev up" a normal heart. With a 100 mcg the heart operates well beyond its safety region, at least in the elderly or the sedentary. With 1000 mcg doses of adrenaline most healthy hearts are at least moderately damaged, even when aggressive attempts at correction with other (also dangerous) drugs is attempted (as many published clinical reports of such drug error accidents will attest to).

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

Date: Fri, 06 Aug 1999 17:57:01 -0700 From: "M. Simon" <mlsimon@mail.rkd.snds.com> Subject: Re: Go FORTH

Elizabeth Rather might disagree with you about large FORTH projects (President of FORTH Inc). FED-EX has 1500 programmers doing mostly FORTH. They claim it is at least 6X to 10X as productive as C.

Let's suppose FORTH does not scale well with more than 10 programmers. If you get a 10:1 productivity improvement you might handle projects up to 100 ordinary programmers/coder/testers. The product will be better designed and likely better debugged.

Very few projects require more than 100 software people.

I have found that testing each module as it is designed (easy in FORTH) eliminates the need for type checking. Generally the quality of the code is better because of this as well.

A 10-fold improvement in software engineering productivity is nothing to sneeze at.

PS. Every place I have been allowed to use FORTH, it has been a magic bullet. Perhaps I am unique.

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

Date: Sun, 8 Aug 1999 22:31:13 +0800 From: "Mark Harrison" <markh@usai.asiainfo.com> Subject: E-Trade and long passwords

I recently filled in an account application at etrade.com. I selected a RISKS-aware password, submitted the form, and received the following error message:

>Please correct the following information: > > Your Password must be 6 characters or less.

Yikes!

Mark Harrison, AsiaInfo Computer Networks, Beijing, China / Santa Clara, CA markh@usai.asiainfo.com http://usai.asiainfo.com:8080/

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

Date: Fri, 06 Aug 1999 07:41:58 -0700 From: "NewsScan" <newsscan@newsscan.com> Subject: Security sites vandalized

Just days after the Symantec site was attacked, vandals intruded upon AntiOnline, another Internet site devoted to computer security. The intruder never directly infiltrated AntiOnline's own computers, but managed to redirect visitors to a Web page with the image of an unblinking eye and the message ``expensive security systems do not protect from stupidity.'' AntiOnline's manager said the attack was "clever" but not "sophisticated." One security expert said, "All you can do is try to keep ahead of the game. For anybody to claim they're totally secure, it's not true." [Source: AP/*San Jose Mercury News*, 6 Aug 1999, http://www.sjmercury.com/svtech/news/breaking/ap/docs/727614l.htm]

[NewsScan Daily, 6 August 1999, with permission. NewsScan is underwritten by Arthur Anderson and the IEEE Computer Society. To subscribe to NewsScan Daily, send an e-mail message to NewsScan@NewsScan.com with 'subscribe' or 'unsubscribe' in the subject line.]

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

Date: Fri, 6 Aug 1999 09:21:34 +0100 From: "Peter Leeson" <Peter.Leeson@ispi.co.uk> Subject: SPAM causes major ISP crash

Globalnet, one of the main ISP in the UK had their e-mail severely handicapped by a massive SPAM mailing from a Florida-based ISP. Mail was delayed by up to a day while the spam was cleared on 5 Aug 1999, slowly and painfully...

Peter Leeson

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

Date: Fri, 6 Aug 1999 03:31:36 +0100 From: Peter Houppermans <Peter.Houppermans@pa-consulting.com> Subject: Re: PCS, IMRSS, Mobile phones in airplanes (RISKS-20.52)

I'd like to comment on three articles in RISKS-20.52:

1) Re: Can You Trust AT&T Wireless PCS Text Messaging?

There are generic issues of dependency with mobile phone services. I have experienced several times that messages left for me on voicemail (as I was on the phone at the time) did not trigger the alarms on the voicebox to alert me until fully 8 hours later (causing the ones that were urgent to be mildly out of date). This was on UK Vodaphone, and it occurred with both the 'call-back' service -it rings you and plays back the message- and the SMS service (it leaves an SMS alert message). Queries to the operator didn't yield a satisfying result, but to be fair, they didn't give me an SLA on performance and timeliness, I was getting used to it being quite immediate prompting an assumption on my part.

Another issue with voiceboxes is that they generally do not offer a method to play back a message you've just left, so if the line is bad you won't know the message (and return number) is next to useless for the recipient.

The RISK: don't rely on external facilities if the message is urgent, keep trying.

Note: the SMS services, however, give good feedback on message receipt. This could mean a small risk: someone can tell my phone has been switched on and is within range of the system ;-)

2) Re: IMRSS and Open Mail Relay Scanning

Question: if IMRSS enters a company mail server into their list as 'open' and other companies use this as 'spam relay block' source, what is the exposure RISK to IMRSS for creating in effect a partial denial-of-service? To leave a corporate mail server open for abuse is of course not a terribly good idea, but entering a server in the list of doom without the target companies' knowledge could IMO have legal consequences. The planned postmaster notification (maybe a with some time in between) is therefore a good thing.

Leads to another question: how is the company going to communicate with IMRSS? I presume it won't be by e-mail unless IMRSS don't they use their own list ;-).

3) Re: risk of using mobile phones in airplanes.

I've read this morning in the Hong Kong Standard of a plane that was found 30 degrees off course when they were about to land (I have to claim lack of knowledge here: wouldn't this show up earlier?). When researching they found a mobile had been inadvertently left on by a passenger who was too preoccupied with a family member being ill (the reason he was on that flight) to check that his phone was off. The passenger has been charged, which must adds nicely to his worries.

The RISK: dependency on passengers to check their electronic gadgets/phones to be switched off. I would much rather see some form of detector being developed, at least that would start a flight with all mobiles off. It would then only leave deliberate actions like the individual who continued to use his phone despite requests to switch it off.

Peter A B Houppermans, PA Consulting Group +44 (0)207 730 9000

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

Date: Sun, 8 Aug 1999 11:52:13 -0700 (PDT) From: Glenn Carroll <gcarroll@lmi.net> Subject: Cell phones and aviation electronics (re: Fear of Flying)

Both the original "Fear of Flying" post and the follow-up have glided over another RISK: the airlines have no effective way of controlling or checking the state of cell phones or other portable electronics. As a sometime cellular user, I often forget that I have the thing with me, and I do enough flying that I tend to doze through the safety announcements, including the one which reminds passengers to "please turn off all cell phones, portable electronics, etc". Thus it isn't hard for a well-intentioned but forgetful person to create this risk-y situation. Lacking the means to find active portable electronics, the airline can't do much about this, nor can they prevent quietly malicious persons from deliberately doing the same.

Even non-forgetful people can inadvertently and unknowingly have their portable electronics on: CD players generally have their buttons placed in such a way that squeezing the case the right way will turn them on. Mine has a "lock" slider to prevent this from happening, but of course that's one more thing has to remember, and not all CD players come so equipped.

If cell phones or other p.e.s were as dangerous as some people claim, one might have expected a terrorist attack via this channel by now. After all, this would solve one of the difficult problems for the terrorist, which is how to get the Harmful Device on board the aircraft. Either there have been no such attacks, or they have been so ineffective as to go unnoticed...

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

Date: Mon, 9 Aug 1999 08:54:34 -0800 From: Rob Slade <rslade@sprint.ca> Subject: REVIEW: "Kerberos: A Network Authentication System", Brian Tung

BKKRBROS.RVW 990715

"Kerberos: A Network Authentication System", Brian Tung, 1999, 0-201-37924-4, U$19.95/C$29.95 %A Brian Tung %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 1999 %G 0-201-37924-4 %I Addison-Wesley Publishing Co. %O U$19.95/C$29.95 416-447-5101 fax: 416-443-0948 bkexpress@aw.com %P 164 p. %T "Kerberos: A Network Authentication System"

Part one is a user guide to the Kerberos security tool, user being defined as both end user and administrator. Chapter one presents a rather weak justification for Kerberos (based on the insecurity of e-mail) and some quick contact information for obtaining it. End user operations for Kerberos are described, but not always clearly, and some questions are left open. (Does the user have any control over ticket expiry times?) The administrative functions, in chapter three, are weak in regard to installation, but reasonable in terms of maintenance operations. Chapter four contains quick listings of the Kerberos API (Application Programming Interface) calls, for those who want to build Kerberized programs.

Part two provides some background. Chapter five is a good tutorial on the concepts: if you are having trouble with chapters two and three, a review of five will probably help a lot. Differences in versions of Kerberos are listed in chapter six. A look at various related issues in chapter seven includes a very decent discussion of public key encryption.

For quick coverage of Kerberos, this makes a neat and handy package.

copyright Robert M. Slade, 1999 BKKRBROS.RVW 990715 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: Tue, 10 Aug 1999 00:27:34 GMT From: moun@usenix.ORG (Moun Chau) Subject: UPCOMING EVENT- USENIX SECURITY SYMPOSIUM, 23-26 Aug 1999 in DC

8TH USENIX SECURITY SYMPOSIUM 23-26 August 1999 JW Marriott Hotel, Washington, D.C. Sponsored by USENIX in Cooperation with the CERT Coordination Center

See the Program and register online at http://www.usenix.org/events/sec99

* Exchange ideas with the industry's top security insiders. * Gain command of leading-edge tools and techniques at specifics-driven tutorials. * Explore the latest advances in Internet security, intrusion detection, distributed systems, and applications of cryptography.

USENIX, the Advanced Computing Systems Association, is the international, not-for-profit society made up of scientists, engineers, and system administrators working on the cutting edge of systems and software. For 25 years USENIX conferences and workshops have emphasized quality exchange of technical ideas unfettered by stodginess or commercialism.

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

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.53 ************************