Text File

precedence: bulk Subject: Risks Digest 20.28

RISKS-LIST: Risks-Forum Digest Thursday 1 April 1999 Volume 20 : Issue 28

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.28.html> and at ftp.sri.com/risks/ . *** [SORRY TO FLOOD YOU. JUST TRYING TO CATCH UP WITH THE BACKLOG. PGN] ***

Contents: Professor wants Y2K jokes banned on the Net (Edupage Editors) Daylight Savings Time cutover (Dave Stringer-Calvert) Y2K: Help for the Weary Programmer (Martin Minow) IE5 Risk (Lorne Beaton) The old Ethernet traffic jam in new form (Rob Slade) More e-mail risks (Silas S. Brown) Human input error on year causes $49-million error (Frank Carey) Baby death due to software-controlled air bag deactivation? (Stefan Leue) Hyperlinks, free accounts, and fraud (Mike Bell) Melissa beyond denials of service (David Lesher) Melissa macro virus author tracking (Joe Thompson) Y2K alert! (Rebecca Mercuri) Apple Y2K (Dave Stringer-Calvert) Re: Bringing Y2K fears to a new high -- or low (Gillian Richards) Re: Great moments in e-mail history? (Jerome H Saltzer, Tom Van Vleck, Jerome H Saltzer) Laughter causes loop with voice-recognition software (Don Mackie) Unusable backup power (Tim Kuehn) "kibibyte" is still ambiguous (D.V. Henkel-Wallace) Announcement - The Software Engineering Symposium '99 (Carol Biesecker) Abridged info on RISKS (comp.risks)

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

Date: Thu, 01 Apr 1999 11:25:58 -0500 From: Edupage Editors <edupage@franklin.oit.unc.edu> Subject: Professor wants Y2K jokes banned on the Net

Insisting that "there's nothing funny about things that aren't funny," Professor Wiley T. Langweile of the Palo Alto (CA.)-based Institute of Internet Reevaluation has written a searing letter to *The New York Times* (1 Apr 1999) protesting that the American media are so bored with the Year 2000 problem that they're mentioning it only once in every 94.5 sentences (by the professor's own hand-count). "Journalists are just not giving enough publicity to this impending crisis. They're either ignoring the problem entirely or making fun of it. Either way, they're acting unconscionably. Y2K irreverence needs to be banned, especially on the Internet." Dr. Langweile further charged in his letter that most reporters fail to include in their stories a detailed explanation of just what exactly the Y2K problem actually is and what it means to everyday people. "The low level of media competence on this issue is just tragic. Of course, there's Edupage. That's the big exception. Those Gehl and Douglas people really know how to get to the point of a story, without wasting words. They're the only ones I can think of who've successfully explained Y2K in terms of the big hand and the little hand. I say God bless them." (Edupage, 1 Apr 1999)

[Note to nonGermanophiles: "Langweile" relates to Boredom, not Coyotes. Definitely not the case here. PGN]

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

Date: Thu, 01 Apr 1999 09:43:11 -0800 From: Dave Stringer-Calvert <dave_sc@csl.sri.com> Subject: Daylight Savings Time cutover

Please note the following!

Washington DC (Reuters, 1 April 1999), Roger Tempus, News Staff

In a sweeping move to alleviate the problems generated by the switch to daylight savings time early on Sunday morning, Congress voted today to move the switch to Monday.

There has been a long history of confusion surrounding the switch to daylight savings time, and in a landslide vote this morning members of the house made a decisive move to make daylight savings a more attractive option. This was given wide support amongst the religious groups, concerned that people would be confused as to the timings of church services this Easter Sunday.

Congresswoman April Jester (R, CA) confirmed the news this morning and announced that the changeover will now take place at 10am on Monday morning. In a dramatic turnabout, the state of Arizona decided that in light of this decision they too will adopt daylight savings time for 1999.

Wall Street reacted angrily to the news, claiming that the lost hour of trading may drop the country back into recession. President Clinton is expected to sign the order confirming the change this afternoon, claiming that bedtime is just as, if not more, important than work time.

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

Date: Wed, 31 Mar 1999 23:02:39 -0800 From: Martin Minow <minow@apple.com> Subject: Y2K: Help for the Weary Programmer

While reading several articles on the Y2K problem in the 1 April 1999 issue of RISKS-20-26, I noticed that none addressed the actual problem facing working programmers: there isn't enough time to finish the job before December 31. As we all know from The Mythical Man Month, we can't add more people to the project: the project will just take longer. What we need is another month.

I propose Caligua. To honor Roman tradition, this would be added after August. This extra month should give us enough time to fix -- and test -- our changes. While it will cause minor disruption to calendar makers and astronomers, they, along with all other citizens, will reap the rewards when the airplanes keep flying on 1 Jan 2000.

And, if we need more time, we can always declare a Saturnalia.

Martin Minow, minow@pobox.com

[Martin drives a Saturnalias for Caligula. PGN]

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

Date: Thu, 25 Mar 1999 00:19:49 -0500 From: Lorne Beaton <lbeaton@MNSi.Net> Subject: IE5 Risk

Browsing the Web this evening (Thursday, March 24, 1999) using the new IE5 under Windows 98, I click a Favourite to load a well-known tech news site (http://www.slashdot.org/), then, with the site still loading, immediately press Control-N to open a new window so that I can load another site as well. A moment later, I'm a bit puzzled to notice that Slashdot hasn't been updated since Sunday the 21st. This is particularly puzzling since I had checked it earlier that day, using my work account, and it was up to date.

My confusion is relieved a moment later, when I notice the site loading up in the background window (the one that was already open). I have been looking at the newly-opened window, which appears to have inherited one piece of state from the previous one (i.e., the URL being displayed) but not another (i.e., the crucially important fact that the site needs to be updated, not just redisplayed from the cache).

Contrast this with the behaviour of other web browsers (e.g., Netscape Communicator 4.51). In a desultory test, Communicator acted correctly (i.e., displayed up-to-date information in a new client window, even as the previous window was still reloading the site). This was done with Communicator set to load "Last page visited" when opening new client windows. It appears that Communicator 4.51 checks this setting each time a new client window is opened, whereas IE5 checks this setting only once, when launched. There also appears to be no way to change this behaviour.

Possible risk (which I have not noticed in previous versions of IE, although it may be present there as well) is that a less-observant or more naive user might assume the outdated information is actually up-to-date and correct.

Lorne Beaton <lbeaton@mnsi.net>

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

Date: Tue, 23 Mar 1999 14:35:48 -0800 From: Rob Slade <rslade@sprint.ca> Subject: The old Ethernet traffic jam in new form

I am currently trying to download something from Microsoft--for the eleventh and twelfth time in the past five days.

The problem, of course, is probably the recent announcement of IE5. Everybody and his or her dog is trying to download the latest and buggiest browser. (Bob Frankston's problem with his bank is only one of many: Visual Studio 6 and Eudora Pro both have problems with it, and then there is the AutoComplete function ...)

However, I am inescapably reminded of the old problem with Ethernet, and Carrier Sense Multiple Access with Collision Detect. As traffic rises collisions grow more common. Therefore, there are more retries on the net, and therefore traffic rises and ... (Anyone who has to commute over a busy bridge knows why network traffic analysis is called "traffic" analysis.) Same thing is probably happening here. More people are trying to download the files from Microsoft. Therefore, more downloads fail, therefore more people try again, therefore ...

Yes, I'm contributing to the problem: I'm running two separate downloads in the hopes that one will finally succeed. Probably a lot of net-savvy people are doing the same thing, or better (worse?)

Completely beside the point, the program I am trying to download is the new version of MediaPlayer. On Friday it was a 4.8 meg file. Today the same file is 3.4 meg. One of the never-to-be-known mysteries of the net, I guess ...

rslade@vcn.bc.ca rslade@sprint.ca robertslade@usa.net p1@canada.com

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

Date: Mon, 22 Mar 1999 08:11:20 +0000 From: "Silas S. Brown" <ssb22@cam.ac.uk> Subject: More e-mail risks

> Once again we are reminded of the incredible variety of risks of e-mail.

Here's a really strange one: Ever heard of PostPet? It's a Japanese computer game that's also an e-mail client. Besides limited capability to deal with normal mail, you can send your "pet" with the message to another PostPet user. Your pet gets sent as an attachment and returned immediately upon delivery with updated status (depending on how your friend treats your pet etc); there is a timeout. (It gets returned in a "Secret Diary" message supposedly written by the pet; the language of this diary depends on that of the destination client.) Pet mail also causes the addition of the sender to the recipient's list of friends.

Risks:

1. If too many people use this thing, we may get spamming incidents in which the spammer adds a PostPet attachment to the spam, thus ensuring a personalised delivery, a guaranteed response from valid addresses and an addition to people's personal contact lists.

2. The file format of the attachment can be reverse-engineered, and a response generated artificially, for any social purpose whatsoever. In fact, once someone has sent you their pet, you can keep its ID for use later - all you have to do at any time is send a message with a custom status and arrange for it to arrive while the pet is "out".

3. There is no way of viewing full headers, and hence if someone is abused etc they can't report it. (Many other things can't be done, too.)

4. Games aren't really meant to live in the application world. If they ported it to Unix, it could consume vast amounts of CPU on a shared system and equally vast amounts of network bandwidth updating the display.

5. The buttons for "send pet" and "send normal e-mail" are far too close.

6. This is no way to introduce e-mail to people new to computers, and yet it is (apparently) being used for that in Japan. This could lead to people not learning things properly. The PostPet documentation is full of metaphors that don't really tell you what's going on.

7. It generally increases the amount of pointless e-mail and wasted time.

-- Silas S Brown, St John's College Cambridge UK http://epona.ucam.org/~ssb22/

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

Date: Mon, 22 Mar 1999 09:45:53 -0500 From: Frank Carey <carey@voicenet.com> Subject: Human input error on year causes $49-million error

On 21 Mar 1999, 180,000 families in New Jersey receiving food-stamps took advantage of an error by which their April credits were enabled 10 days early. In the 15 hours until the problem was discovered and fixed, the word spread rapidly and shoppers went on a feeding frenzy. Many stores ran out of staples (food, not metallic). A state employee was preparing for the 1 Apr 1999 crediting of food-stamp accounts; discovering that performance was dragging seriously, he off-loaded the processing onto the backup mainframe, and then moved the resulting files back to the main system. Initial blame was placed on a recent Y2K upgrade, but later reports observed that he had input "199" instead of "1999" in making the cutover, and the program coerced a zero on the end to make the year "1990". So, perhaps the problem was indirectly Y2K-related after all. [Source: *The New York Times* 22 Mar 1999, p. B1; *Newark Star Ledger* 22 Mar 1999, p. 13, with revisions to absolve Y2K two days later, *NYT* 24 Mar, B5. PGN-ed, starkly]

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

Date: Mon, 29 Mar 1999 23:54:00 -0500 (EST) From: Stefan Leue <sleue@fee.uwaterloo.ca> Subject: Baby death due to software-controlled air bag deactivation?

Under the headline "Vom Retter erschlagen" (`Slain by the Savior') the German weekly "Der Spiegel" (http://www.spiegel.de) reports on page 226 in its issue 12/1999 on the analysis of an accident in which a baby sitting in a rear facing car seat mounted to the front seat in a Volkswagen Golf was killed by the impact of the deploying air bag in an oncoming traffic collision. The car owners and parents of the killed baby had previously had the air bag disabled in a certified garage.

The wreck of the car is currently sealed by the public prosecutor's office and inaccessible to Volkswagen and the manufacturer of the air bag electronics, Siemens. Volkswagen maintains that the deployment of the air bag may either have been caused by a voltage surge in the car's electronic system resulting from the impact on the battery, or by electrostatic discharges.

Experts from the Technical University of Munich, working for the public prosecutor's office, consider these explanations implausible and target a systems engineering fault as a more likely causal factor. Deactivation of the airbag in a Golf is a software-controlled function, as opposed to other manufacturers who physically disconnect the air bag from the board electronics for deactivation. As physical circumstances in a car (temperature variations, moisture, vibrations) form a fairly hostile environment for the air bag control hardware, the software system running inside the control performs ongoing self checks using checksum algorithms. If an error has been detected, the current software settings, including the data responsible for the deactivation, will be replaced by backup software read out of a read-only memory. The backup software, however, only knows a simple set of rules, namely that all air bags in the car will be deployed upon impact. Evidently, the backup software is unware of a previous software-controlled deactivation.

Stefan Leue

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

Date: Mon, 22 Mar 1999 09:28:18 -0500 From: Mike Bell <mbell@albionresearch.com> Subject: Hyperlinks, free accounts, and fraud

SPAM-L this week contained a description of interesting method being used to obtain credit-card numbers.

1. Grab e-mail addresses of AOL users in chat rooms. 2. Mail them a forged message from AOL asking them to click on a hyperlink to verify their billing details. "Click here" takes them to a forged AOL page on a free web service asking for exact credit card details, passwords, etc. 3. If they fill out the form, it is POSTed to an innocent cgi script on another site which accepts a hidden argument specifying an e-mail address where the credit card information will be mailed to. 4. Finally the cgi script redirects the user to a third throw-away site ("Thank you for changing your account details"). 5. The perpetrator can now pick up a list of credit card numbers from the free e-mail account from anywhere in the world.

The basic risk here is an old one: clicking on a hyperlink may not always take you where you think. In addition the use of free anonymous e-mail accounts and web pages makes it far easier for the criminal to avoid a simple paper trail.

-- Mike --

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

Date: Thu, 1 Apr 1999 13:37:47 -0500 (EST) From: David Lesher <wb8foz@nrk.com> Subject: Melissa beyond denials of service

One thing only a fraction of the popular press coverage has touched upon is that: while spreading itself around the world, Melissa also appears to send the document the victim is dealing with at the time as well.

THAT may have consequences that last far past the Denial of Service logjam. If the file in Word was confidential and Melissa leaks [..you name it..] out....

This might draw some attention to other Word problems; such as its propensity to send along both deleted text as well as that from other document windows. It does not show when rendered by Word, but it's still there....

(A friend at a Fortune 500 communications company recently was sent a doc whose distribution was limited to 5 or 6 people. He used the Unix tool 'catdoc' to read it on his workstation & discovered most of an innocuous 2nd doc also in the file. "Suppose it had been the other way around?" he remarked.)

Such covert channels have always been a concern some people paid serious attention to [witness IntelLink's physically separate networks for U, S, and TS/SCI; and the recent release of AES material via printer-->scanner-->PDF route]; I hope more people will now do likewise...

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

Date: Thu, 01 Apr 1999 01:25:02 -0500 From: fbi.gov@orion-com.com (Joe Thompson) Subject: Melissa macro virus author tracking

As it turns out, the GUID is *not* a reliable identifier of the author for the Melissa virus:

http://www.zdnet.com/zdnn/stories/news/0,4586,2234018,00.html

Synopsis: If a Word document is passed to another person, modified, and saved, the original GUID is preserved even though none of the actual content may still be extant. In this case, the GUID in question has been discovered in works from other authors. The person currently under the most suspicion (known as VicodinES) says that the virus code in his document that has the same GUID as Melissa (a macro virus named PSD2000.DOC) is actually based on earlier virus code from another author (known as ALT-F11); indeed, the GUID on that earlier work *also* matches Melissa. So does the GUID on other work by ALT-F11, while work that VicodinES claims is original with him does *not* have the Melissa GUID. *Anyone* could have written Melissa and made VicodinES, or any other Word user they want, appear to be the culprit.

Here we see the inherent RISK of relying on a non-unique identifier; in this case, the fact that the ID is inherited poses additional risks of misidentification. -- Joe

Joe Thompson http://kensey.home.mindspring.com/ fbi.gov@orion-com.com

[Even if they are unique, such IDs may be easily forged. Once again, the use of digital evidence is tricky. PGN]

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

Date: Thu, 18 Mar 1999 00:20:00 -0500 (EST) From: Rebecca Mercuri <mercuri@gradient.cis.upenn.edu> Subject: Y2K alert!

--- Forwarded mail from a colleague at Disney --- FINALLY! A Programmers Drinking Song! Woo! Hoo!

PROGRAMMERS DRINKING SONG:

99 little bugs in the code, 99 bugs in the code, fix one bug, compile it again, 101 little bugs in the code. 101 little bugs in the code..... (Repeat until BUGS = 0)

[I think it's appropriate, given the rash of "buggy" animations these days. Rebecca.] [It's nice that Y2K is also brewing lyrics. PGN]

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

Date: Wed, 17 Mar 1999 22:23:46 -0800 From: Dave Stringer-Calvert <dave_sc@csl.sri.com> Subject: Apple Y2K

This is cute:

> "We may not get everything right, > but at least we knew the century was going to end." > -- Apple Computer, HAL 9000 ad for Macintosh Y2K compliance

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

Date: Wed, 17 Mar 1999 13:47:42 +1100 From: "Gillian Richards (02) 4780 3513" <gillian.richards@tafensw.edu.au> Subject: Re: Bringing Y2K fears to a new high -- or low (Gerlek, RISKS-20.24)

> [...] We don't want people going and buying > generators when they should be out buying jeans."

There's another *hidden* problem. In Australia, the most common brand of zippers (zip-fasteners) used on manufactured clothing is YKK.

I have no idea what sort of compliancy tests to run on my zippers, and, wishing to take *no* risks of the "system" being down at the wrong time, will be wearing either buttons or elastic on 31 December 1999.

Gillian Richards, Computer Systems Officer <gillian.richards@tafensw.edu.au> Wenworth Falls TAFE Campus, NSW Australia

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

Date: Mon, 22 Mar 1999 23:06:17 -0500 From: Jerome H Saltzer <Saltzer@MIT.EDU> Subject: Re: Great moments in e-mail history? (Neugent, RISKS-2.25)

Part of the problem is that the definition of e-mail is a bit fuzzy. If you define it to mean any mail-like electronic message, then you can trace it back to 1851, when the New York and Mississippi Valley Printing Telegraph Company (predecessor of Western Union) began sending telegrams. The AUTODIN messaging system may belong in that family tree.

If you mean mail-like messages between computer users, then CTSS certainly had a mail command that may be a candidate for first. If Corby [Corbato] searches his attic, he might be able to find a date earlier than the circa January 1965 PSN you identified. A survey of the other time-sharing systems of the time would probably turn up some other mail programs.

But that didn't go between machines. If e-mail means that two computers have to be involved, then Kleinrock may well have sent the first piece of e-mail that crossed the net. I don't recall that we ever had mail moving between the two CTSS machines (MAC and Computation Center) at MIT.

Jerry

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

Date: Mon, 22 Mar 1999 23:01:57 -0800 From: Tom Van Vleck <thvv@multicians.org> Subject: Re: Great moments in e-mail history? (Neugent, RISKS-20.25)

AUTODIN probably counts as one of the "first" e-mail systems. As I remember, there was a BBN project called "Mercury" that was also working on electronic mail. Noel Morris and I knew that both of these existed when we wrote CTSS MAIL, but were not sure whether Mercury was ever deployed.

PSN 40 _proposed_ a MAIL command. As I remember, Noel and I, junior energetic programmers, offered to do it while others were busy with Multics design, and were given permission. When I visited Roger Roach about 8 years ago, he still had the CTSS source, and I looked at the source of MAIL, and it was my code. It had Dick Mills's, Bill Bierstadt's, and my programmer numbers baked into the code. We, and M1416 * could send messages to all users. (See my story, quoted in _Wired_, about the first spam, sent by Peter Bos. Remember that? He abused his system programmer privilege to send a message beginning THERE IS NO WAY TO PEACE. PEACE IS THE WAY. When I remonstrated, he said, "But this is *important.* Wired got my name wrong. Peter Bos and Noel are both gone.)

>... If e-mail means that two computers have to be involved, ...

That definition would of course depend on the meaning of "computer." Would Tandem's multi-node, multi-CPU, single-system-image MAIL qualify? In some senses that system was a 645 with very long buses. Was it one computer or many? Was the 645?

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

Date: Tue, 23 Mar 1999 09:32:10 -0500 From: Jerome H Saltzer <Saltzer@MIT.EDU> Subject: Re: Great moments in e-mail history? (Van Vleck, RISKS-20.28)

Here is another try at imposing categories and milestones on what looks more and more like continuous evolution:

1. First mail-like communication by electronic means (telegrams): 1851, Mississippi Valley Printing Telegraph Company.

2. First interposition of computers in handling mail-like communication: perhaps 1957, TELEX, and probably also some predecessors of AUTODIN.

3. First mail-like communication within a system used for general-purpose computing: early 1960's, Van Vleck & Morris on CTSS or perhaps BBN Project Mercury.

4. First mail-like communication between two computers operated by different administrative entities: late 1960's, perhaps Kleinrock's anecdote, but it needs some more research.

Lenny Kleinrock can probably claim without fear of contradiction that he sent the first e-mail over the ARPANET, because he was standing at one end of the first ARPANET link that was installed. The fact that Kleinrock's anecdote is dated at practically the instant of that installation is pretty compelling evidence that e-mail was already well-known and operating within individual time-sharing systems.

Jerry

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

Date: Sat, 13 Mar 99 16:41:39 +1300 From: Don Mackie <donald@iconz.co.nz> Subject: Laughter causes loop with voice-recognition software

My son has dyslexia. To help him deal with life, he has some voice-recognition software on his PC. In the early stages of training he found that odd noises, such as laughter, were interpreted by the computer and, at best, produced long strings of random words. Having a normal teenager's sense of humour he found these funny, laughed some more and so on. When his giggles subsided he had to utter the command "delete last four pages". I now recognise the signs of mirth in his e-mails.

Even funnier is getting the computer to read back the laughter passages.

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

Date: Mon, 22 Mar 1999 10:01:40 -0500 From: Tim Kuehn <timk@tdkcs.waterloo.on.ca> Subject: Unusable backup power (Re: Weingart, RISKS-20.24)

> ... It's not enough to have a backup system in place...you need to make > sure it will work when needed.

... and that if it's there you're able to or allowed to connect to it.

A colleague maintains a number of Internet Web servers as a commercial venture. Friday he found out that the building that houses these servers was going to be disconnected from the power mains for 8 hours starting at midnight Saturday in order to conduct an annual power audit.

The company he was renting space from didn't have enough capacity in their battery backup systems to run his equipment, but would have the system upgraded "next month." The room is sealed, so putting in a small internal-combustion driven generator was out. There is a diesel-powered grid in place, but it only generates 48V DC used by a number of telco switches in the room. And trying to find a sufficiently sized 48VDC to 110VAC inverter for rent was an exercise in futility. A number of vendors were more than willing to sell him one of these ~$4K devices however.

The risk here is that even if backup power's available, you may not be able or allowed to use it.

Tim Kuehn

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

Date: Mon, 29 Mar 1999 18:30:56 -0800 From: "D.V. Henkel-Wallace" <gumby@zembu.com> Subject: "kibibyte" is still ambiguous (Re: Edupage, RISKS-20.25)

The new term "kibibyte" will more accurately describe the number of bytes in a kilobyte -- rather than being 1,000, as could be inferred by the prefix "kilo," a kilobyte actually has 1,024 (2 to the 10th power) bytes.

Has the 8-bit usage of the term "byte" been internationally standardized? Or is "kibibyte" still ambiguous (for Multics and PDP-10 hackers at least)?

"Kibioctets" anyone? Sounds like a cat food.

David Henkel-Wallace, Zembu Labs

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

Date: 27 Mar 1999 22:08:30 GMT From: cb@SEI.CMU.EDU (Carol Biesecker) Subject: Announcement - The Software Engineering Symposium '99

The Software Engineering Symposium '99 Theme: Improving the State of Software Engineering: Principles, Practices, and Projections

August 30--September 2, 1999 David L. Lawrence Convention Center Pittsburgh, Pennsylvania

Early Bird Registration: July 28, 1999

For the most up-to-date information, bookmark our Web site at http://www.sei.cmu.edu/products/events/symp/ or contact

Symposium '99 Conference Coordinator Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Phone: 412 / 268-3007 FAX: 412 / 268-5556 E-mail: symposium@sei.cmu.edu

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

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