precedence: bulk
Subject: Risks Digest 20.71

RISKS-LIST: Risks-Forum Digest  Friday 31 December 1999  Volume 20 : Issue 71

  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.71.html>
and by anonymous ftp at ftp.sri.com, cd risks .

 Contents:
First real Y2K clock problem... (Peter da Silva)
Whoops! Aukland Awkward Awk! (John Wharton via Dave Farber)
Game Over at end of millennium... (John Elsbury via Dave Farber)
Credit-card machines in U.K. confused by Y2K (NewsScan)
Y2K claims early victims (John Locke-Wheaton via Dave Farber)
Pentagon Y2K preparations (Dave Stringer-Calvert)
Oakland CA 911 (John Wharton via Dave Farber)
Two possibly unaddressed Y2K problems (Brett Glass via Dave Farber)
Low-tech Y2K failure (Earl Truss)
Risks of expiring digital certificates in older Web browsers (David Tarabar)
Shirley you can't mean this date is bad! (Conrad Heiney)
The risks of last minute Y2K patches (Matt Blaze)
Re: Y2K fear vs. Common sense (Scott Nicol, Eric Roesinger)
Abolishing leap-seconds (Rob Seaman)
Is the connection secure or isn't it? (Don Byrd)
Privacy broken by Sanity.com (John McLean)
Still another appalling web security story (Identity withheld)
Abridged info on RISKS (comp.risks)

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

Date: Fri, 31 Dec 1999 08:32:53 -0600
From: Peter da Silva <[email protected]>
Subject: First real Y2K clock problem...

The Australian Y2K readiness news page
       http://203.2.193.77/news-index.cfm.htm
seems to have a clock problem. I was checking it as the time change swept
over Australia, and it "hung" at 23:56:15 for quite a while.  I quit
watching it about half an hour later.  I just checked it again and it's lost
over 15 days: The "last update" just jumped back to 15 Dec 1999, 00:23.

I wonder what the cause is? One of my co-workers has noted that other web
pages are having similar problems.

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

Date: Fri, 31 Dec 1999 10:47:06 -0800 (PST)
From: John Wharton <[email protected]>
Subject: Whoops! Aukland Awkward Awk!  (From Dave Farber's IP)

The Aukland (N.Z.) International Airport has a web site to keep the public
informed on Y2K issues (www.auckland-airport.co.nz/airport_newsflash.html).

This morning they issued a "News Flash" stating that "the airport is
operating as normal. No Y2K problems have been experienced and all
operations are continuing as usual."

The News Flash is time-stamped "02:58 1 Jan 100".

  --John Wharton

 [Y2Kudos to Dave Farber, whose IP distribution is often full of
 RISKS items.  This time his recent mailings have been chock full
 of fresh Y2K items.  Dave, MANY THANKS, and Happy New Year to
 all of you!  PGN]

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

Date: Thu, 30 Dec 1999 09:32:21 +1300
From: "John Elsbury" <[email protected]>
Subject: Game Over at end of millennium... (via Dave Farber's IP)

I just have to share this...  From NZ Herald, December 30 1999:

"The Waitakere City Council (West Auckland, New Zealand) has fixed an
embarrassing glitch in a millennium clock in Henderson that flashes a message
telling people to be Y2K-prepared.  In a test run on the clock, donated by a
Korean couple, officials discovered that the message would have changed to
"GAME OVER" at midnight on New Year's Eve."

Do they know something we don't?  Shades of that Arthur C Clarke story about
the names of God...

By the time this appears we will know.

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

Date: Wed, 29 Dec 1999 07:42:56 -0700
From: "NewsScan" <[email protected]>
Subject: Credit-card machines in U.K. confused by Y2K

Because central computers doing four-day diagnostic checks were unable to
recognize the year 2000 as a valid date, as many as 20,000 credit card
machines in England failed to allow merchants to "swipe" the cards through
the machines during recent holidays, forcing the data to be entered manually
and causing shopper delays. The machines are manufactured by Racal
Electronics and supplied to merchants by HSBC, a bank holding company. A
Racal executive says, "It is a software and date-related issue, which will
be resolved and we're entirely confident that terminals will revert to full
functionality at the start of the New Year."
[Reuters/*San Jose Mercury News*, 29 Dec 1999;
http://www.sjmercury.com/svtech/news/breaking/reuters/docs/35990l.htm
NewsScan Daily, 29 Dec 1999, reproduced with permission]

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

Date: Wed, 29 Dec 1999 12:58:45 -0500
From: "John Locke-Wheaton" <[email protected]>
Subject: IP: Y2K claims early victims (from Dave Farber's IP)

In the UK yesterday 20,000 machines in shops across the UK were reported to
be rejecting all credit cards as customers tried to pay for goods. The
reason? The settlement date is four days later - January 1, 2000 and so the
set of transactions that make up the credit payment crosses the date
changeover. The problem may disappear in four days time, when the entire
transaction set will be within the new millennium.

Like most bugs, it is totally understandable and - given hindsight - totally
predictable. As will be all the other Y2K problems that creep out of the
woodwork. Let's hope that none of the other bugs are life threatening.

[email protected]  +44 (0) 7044 011 532

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

Date: Fri, 31 Dec 1999 11:54:16 -0800
From: Dave Stringer-Calvert <[email protected]>
Subject: Pentagon Y2K preparations

DefenseLINK, the Pentagon's main Web site, ws intended to keep the public
assured that Y2K was a nonproblem for DoD.  However, the site was
accidentally disabled on 30 Dec 1999 when other sites were taken off the Net
to guard against cracker activities.  The process of restoring service was
hindered by admins corrupting the domain name server.  [Source: PGN-ed from CNN
http://www.cnn.com/1999/TECH/computing/12/31/y2k.reports.roundup.01/index.html]

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

Date: Wed, 29 Dec 1999 10:47:58 -0800 (PST)
From: John Wharton <[email protected]>
Subject: Oakland CA 911

 [This item is retitled and adapted from the IP list of
 Dave Farber <[email protected]>.]

KCBS radio is reporting this morning that the Oakland 911 Emergency call
system has determined its call prioritization algorithm is, well,
technically speaking, /not/ fully Y2K compliant yet.

Apparently incoming calls are timestamped with just a two-digit year code.
Normally the call routing software gives top priority to the oldest
(=earliest) calls, as one would expect.

Alas, this means that as of the Friday midnight roll-over, all pending
calls will instantly be kicked to the bad end of the priority list.  As I
interpret the news reports, the post-rollover calls will be stamped
1/1/1900, and, naturally, anyone who "just" called -- at 11:58 Friday
evening, say -- is in far less dire straits than people who have been
on hold for nearly 100 years.

Oakland's solution, the 911 officials say, will be that, starting at
11:50pm or so, all not-yet-dealt-with calls will be transferred to a
different phone system to ensure that they don't get lost.  Dispatchers
can then continue dealing with existing emergencies while newer calls
queue up normally until dispatchers again become available.

(The moral?  It's probably best /not/ to have an emergency in Oakland
during those last few minutes before midnight...)

>=====

My first impression was that this was a terribly embarrassing oversight,
for this problem not to have been "fixed" months ago.  Date-stamps being
processed backwards is /exactly/ the textbook example of what happens
when the year field overflows.

On the other hand, it /does/ seem the problem will be terribly short-lived,
affecting maybe five or ten minutes' worth of calls -- ever.  After 12:10am
or so, then, and for the remainder of the next century, the original call
prioritization algorithms should continue to work just fine.

Whereas re-opening the program source, rejiggering the code, augmenting
the data structures and so forth could quite plausibly introduce new
problems and incompatibilities that might bedevil emergency call
processing for months.

Leading one to wonder: was this just an embarrassing oversight?  Or a
deliberate, rational cost-benefit decision to leave sleeping codes lay?

  --John Wharton

 [Note added later in Dave Farber's IP from John:
 (If) unchecked, this WOULD have been a most-life-threatening oversight.]

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

Date: Thu, 30 Dec 1999 16:52:36 -0700
From: Brett Glass <[email protected]>
Subject: Two possibly unaddressed Y2K problems (From Dave Farber's IP)

While performing a Y2K check of a client's computers, I discovered a small
program, written in BASIC, which suggests an entire class of potential Y2K
glitches which has not been publicized and may plague us on or after
January 1, 2000.

In the client's back office was an older PC attached to a modem. Each time
the computer was booted, it ran a simple program which instructed the
internal modem to make a brief telephone call to a telephone number
somewhere in Colorado. Upon connecting, the computer received the date and
time, set its clock accordingly, and then hung up.

Inspection of the program revealed that it received and used only two
digits for the year.

What number was the computer calling? After a bit of snooping on the
Internet, I discovered that the number was that of the Automated Computer
Time Service (ACTS), provided by NIST (the National Institute of Science
and Technology, previously known as the National Bureau of Standards). The
time message received by the program, derived from an atomic clock, looks
like this:
 JJJJJ YRMODA HH:MM:SS TT L DUT1 msADV UTC(NIST) OTM
where
 JJJJJ is the Modified Julian Date (MJD);
 YRMODA is the date (two digits each for year, month, and day); and
 HH:MM:SS is the time in hours, minutes, and seconds.
(The remaining fields are documented online at
http://www.bldrdoc.gov/timefreq/service/acts.htm.)

What is interesting is that the BASIC program provided by the NIST itself
(the same agency, ironically, which distributes the Malcolm Baldridge
quality awards and offers Y2K help to small businesses) ignored the Julian
date and used only the two-digit year to set the computer's clock. This
software was posted on the Internet by the NIST until approximately last
October.

While ACTS can be used in a Y2K-compliant manner, the way to do this is
somewhat arcane (few programmers understand the concept of a Julian date,
and conversion is tedious). Perhaps this is why the NIST's own software --
which was doubtless used verbatim or as the basis for other programs -- cut
corners, as most programmers were likely to do, and used only the two digit
"YR" code for the year.

According to the NIST's ACTS Web page
(http://www.bldrdoc.gov/timefreq/service/acts.htm), more than 10,000
computers call the NIST's number each day. How many are running that old
BASIC program, or similar ones published on computer bulletin boards, in
magazines, or on the Internet, which have the same flaw?

But wait.... It gets worse. Apparently, the time code transmitted by ACTS is
similar to that used by the NIST's radio stations --WWV, WWVH, and WWVB --
to transmit time and date information the entire world. WWV's binary coded
decimal format, described on the Web at
http://www.boulder.nist.gov/timefreq/pubs/sp432/s_appb.htm, also uses only
two digits for the year. Worse still, the Julian date is not present, so
there is no way, using this code, to distinguish between the years 1900 and
2000.

Alas, some digital logic circuits which interpret the codes from WWV, WWVH,
and WWVB are literally hard-wired to the existing format. (According to some
quick research I've done on the Net, these range from an old Heathkit called
"The Most Accurate Clock" to laboratory instruments to traffic signal
controllers.) So, the NIST does not have the option of changing the format
to include a 4-digit year for fear of breaking this
equipment. Unfortunately, it is unclear whether owners of this equipment are
aware of the potential problems in these embedded systems -- some of which,
again, use hard-wired digital logic rather than microprocessors.  Will
traffic signals in Los Angeles and Orange County, which are said to use WWV
as a time standard (http://www.odetics-its.com/showcase/TASK2-2/la.html),
fail? Or will they become confused about the day of the week and snarl
traffic by using "weekend" timings on a weekday, or vice versa? What other
municipal, scientific, or military embedded systems will go awry because
they rely on the NIST's 2-digit time codes?

Ironically, while the NIST Web site contains an article
(http://www.nist.gov/y2k/embeddedarticle.htm) warning users to evaluate
embedded systems for Y2K compliance, I have been unable to find any article
in which the NIST mentions the format of its own time signals as a potential
source of Y2K problems. Today, when I used the "Advanced Search" facility on
the NIST's Web site to search for the call sign "WWV" together with the term
"Y2K" or "2000," it failed to turn up any hits whatsoever.  The NIST's Y2K
compliance page, at http://www.nist.gov/y2k/nistcomp.htm, lists both ACTS
and the agency's "time synchronization" services as Y2K compliant.

Conclusions are left as an exercise for the reader.

--Brett Glass

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

Date: Sun, 26 Dec 1999 16:27:10 -0600
From: "Earl Truss" <[email protected]>
Subject: Low-tech Y2K failure

[Source: Bank blames error on printing vendor, Dee DePass,
*Minneapolis Star Tribune*, 21 Dec 1999; PGN-ed]

Wells Fargo & Co. sends out a batch of renewal notices - dated 1900

Wells Fargo & Co. experienced its first public Y2K glitch last week when it
mailed 13,000 certificate-of-deposit renewal notices with the year 1900 on
them.  The bank said the notices told customers in 10 states that their
certificates would expire in January 1900 instead of January 2000.  It isn't
known if any Minnesota customers received the letters.  Wells spokeswoman
Teresa Morrow said the error was attributable to a statement-printing vendor
who forgot to change the date on its printing machines.  Morrow said Wells
sent statements to the printer that said 1/15/00 and the vendor mistakenly
translated the 00 as the year 1900.  The mistake was discovered Dec.13, and
officials immediately sent out letters apologizing for the error. Customers
were told they would receive revised renewal notices in a few weeks.  Morrow
said, "We asked [the printer] if it was Y2K related and they said, 'It was
just us not setting our date on our printer.'"  Morrow said she didn't know
if the mistake would alter Wells' relationship with the vendor. She added,
"If that is the worst thing that happens to us with Y2K, then we will be set
for life."  Still, observers called the error an embarrassing blow to a
company that just last week declared it and its critical suppliers were
ready for Y2K, after having tested all its computer systems three times.
Federal regulators and the Minnesota Bankers Association have repeatedly
said all banks in Minnesota are ready for Y2K and don't expect any problems.
Even so, Wells Fargo and its competitors are staffing technical command
centers for four or five days after New Year's Eve, just in case a more
serious glitch occurs.  While most banks will be closed for the New Year's
Day holiday, many will have technical staff in the branches checking on
lights, heat and computers.

The risks: not testing the low-tech procedures for updating date
information -- "Well, we never changed that part of the date before."

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

Date: Wed, 29 Dec 1999 10:16:09 -0500
From: David Tarabar <[email protected]>
Subject: Risks of expiring digital certificates in older Web browsers

> Millions of people using older versions of Netscape and Microsoft Web
> browsers may not be able to access some personal finance and e-commerce
> sites starting January 1.  It won't be due to the dreaded Y2K
> bug. Instead, it's because electronic credentials embedded in browsers are
> set to expire on Dec. 31 at midnight.

This is the lead of an article in the *San Jose Mercury News* on 29 Dec
1999, which warns that secure transactions may fail or be blocked because of
expiring digital certificates. Many banks are posting warnings to their
customers, warning that they need to update their net browsers, and SOON !!

Microsoft's Internet Explorer for Macintosh only discovered this
problem in the last three weeks and posted a fix on Dec 21.

I especially enjoyed this quote:

> Ben Golub, VeriSign's director of Internet marketing and sales, said the
> Dec. 31 expiration date was chosen about five years ago because at the
> time browsers couldn't accept dates beyond 1999.

> "In retrospect, maybe we should have chosen December 15," he said. "It's
> just an unfortunate timing kind of thing."

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

Date: Thu, 30 Dec 1999 15:07:09 -0800
From: "Conrad Heiney" <[email protected]>
Subject: Shirley you can't mean this date is bad!

There are multiple risks, apparently, involved with multiple types of dates.
Experts said early efforts focused on checking dates -- typically identified
with a heading "mm-dd-yy" or "date" -- buried within computer code.  But
prankster programmers sometimes used unusual nomenclature that can make
these date variables nearly impossible to find.  Data Integrity said it
found a date field called "Shirley" when it reviewed software at a major
bank in the Northeast, which it declined to identify.  The programmer
responsible, it turned out, was dating a woman named Shirley when he wrote
the software.  [Source: The Year 2000 Challenge, *Wall Street Journal*, 30
Dec 1999]

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

Date: Fri, 31 Dec 1999 01:55:01 -0500
From: Matt Blaze <[email protected]>
Subject: The risks of last minute Y2K patches

Jane Garvey, the FAA administrator, was quoted that a late software patch
was applied to her agency's critical ``HOCSR'' computers, which process
flight plan and radar data for controllers.  The repair was completed early
on 30 Dec.  Garvey said the minor problem turned up during continued testing
of the agency's systems, which were declared Y2K-ready in June.  ``We're
continuing to test right up to the last moment.  We erred on the side of
caution.  The patch is in.  It's been fixed.  It's a very, very minor
issue.''  ["Last Minute Y2K precautions Taken", *The New York Times*, 31 Dec
1999 <http://www.nytimes.com/aponline/w/AP-Y2K-National.html>]

Assuming the story is accurate, RISKS readers will undoubtedly wonder
whether whatever benefits this fix might convey will be outweighed by the
risks of patching a critical system the day before the very event that will
trigger the execution of the patched code.  Given the combinatorially
explosive number of potential interactions in any complex system, it seems
strange indeed to conclude that *any* change is just a "very, very minor
issue".  Pondering this question will certainly give me something to do on
my Saturday morning flight...  matt

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

Date: Mon, 20 Dec 1999 01:12:45 -0500
From: Scott Nicol <[email protected]>
Subject: Re: Y2K fear vs. Common sense (RISKS-20.70)

> 1) The generator is in a hastily built wooden hut secured with a padlock.
> The hut is located on the outside wall of our data center.  3,500 gallons
> of boom.

Most large generators are diesel.  I don't know if this particular
generator is diesel, but if it is, diesel does not go boom, and it
doesn't burn very well, either.  It's about as stable as cooking oil.

Gasoline, in its liquid state, does not go boom either.  It does burn pretty
well, though.  If you had an almost empty tank of gasoline, you could have
enough vapor that it might go boom.

I'm not a chemical engineer, so check this with other sources if you like.

Scott Nicol <[email protected]>

 [Lots of you commented on this gaffe.  PGN]

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

Date: Thu, 30 Dec 1999 18:15:59 GMT
From: [email protected] (Eric Roesinger)
Subject: Re: Y2K Fear vs. Common Sense (RISKS-20.70)

> All of our upper management is absolutely terrified of the end of this
> year.  They are convinced that there is going to be a major disaster
> at the stroke of midnight.

Would it frighten them any more, to know that power companies generally
operate on GMT?

The risks of failing to understand this necessity of managing a power
grid connecting multiple utilities and spanning several time zones, are:

+  presumption of more time for disaster preparation, than actually
  exists, should fears be justified; and

+  hysteria over impending doom, after the possibility of its occurrence
  has passed, should fears be unjustified.

I keep telling people where I live, that they can stop worrying about
their electric power, shortly after 7PM.  West of here, people can stop
worrying even earlier (4PM in California, for example).

Even if a few generating facilities did fail, unless they lost station-
keeping power, those facilities would remove themselves from the grid,
immediately. As far as I know, it's become standard practice to have
battery-backed station-keeping power, since a station without it caused
a major regional blackout in the Northeastern US, some years ago.

(Either their backup generator failed while the others were down for
maintenance, or vice versa; I don't remember. The story comes second-hand
from a former colleague, who, at the time, worked at a nearby manufacturing
plant, whose generators were used to provide the power to bring the station
back online.)  [...]

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

Date: Tue, 21 Dec 99 17:13:33 MST
From: [email protected] (Rob Seaman)
Subject: Abolishing leap-seconds

Various issues involving leap-seconds have been discussed in RISKS in the
past.  One of the most creative was "Length of Day & Reservoirs" by Scott
Lucero in RISKS-17.87, suggesting that we might avoid future leap-seconds
through calibrating the Earth's actual rotation rate by selectively filling
reservoirs.  (Some mechanism would be needed for recalibrating the Earth
once the reservoirs were full...)

The time and frequency community is in the early stages of considering a
proposal to simply stop issuing leap-seconds.  (Alternatives are also being
considered.)  There has been some rousing discussion of this in
comp.protocols.time.ntp and sci.astro.fits (among others).

Possible risks include Y2K-style risks of software and firmware relying on
|UTC-UT1| < 0.9s.  More fundamentally, this would be a change to the
original design requirement of UTC that ties clocks around the world to our
most visible standard of civil time - the Earth itself.  The general risks
are similar to other small communities that control technical resources (for
instance, utility companies) used by virtually everybody.  The effects of
overtly minor operational changes are highly non-linear and can be magnified
immensely.

For a sense of the scale of the change, a century of leap-seconds is about
equal to half the width of the sun or the moon on the sky.  This is enormous
for some purposes, negligible for others.

Should we take comfort or dread that the metrologists are debating this
issue with Y2K looming?

Rob Seaman

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

Date: Mon, 20 Dec 1999 16:45:26 -0500
From: Don Byrd <[email protected]>
Subject: Is the connection secure or isn't it?

A month or so ago, I was trying to order plane tickets via the Travelocity
Web site, when I noticed that--though the page I was looking at prominently
claimed to be "secure", and even had a link to click on where they
explained in detail why it really did protect your privacy--Netscape (4.5
for Windows) didn't agree: the little lock icon on the bottom was open! I
asked for Page Info, and that confirmed that the connection was not secure.
Needless to say, I didn't go ahead with the purchase.

Much more recently, I was trying to order a CD from the U.S. Public Radio
Music Source (www.75music.com) when what appeared to be the same thing
happened. But this time Page Info showed the connection _was_ secure, and I
went ahead and gave them my credit card info.

The RISK? Presumably the chance of outsiders seeing your confidential
information because what you assumed was a secure connection really wasn't.
Of course one should never trust a Web site's statement that the page
you're viewing is secure, but if it's an outfit as well-known and reputable
(as far as I know) as Travelocity, I'll bet a lot of people will assume it
is--especially if they explicitly tell you how they're protecting your
confidential information, as this page did.

My experience also raises the question as to whether you can even trust the
browser to tell you if you have a secure connection; I sure hope so, at
least if JavaScript is disabled (I seem to recall the Princeton group
pointing out that JavaScript can take over the browser's UI almost
completely).

Don Byrd, Center for Intelligent Information Retrieval (CIIR), Computer
Science Department, UMass, Amherst, MA 01003 [email protected] 413-545-3147

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

Date: Wed, 29 Dec 1999 14:02:33 +0100
From: John McLean <[email protected]>
Subject: Privacy broken by Sanity.com

Sanity.com, the Australian company who keen readers will remember as
allowing purchases of CDs without payment (RISKS-20.68), have stuffed up
again, this time sending all their customers an e-mail that included the
e-mail addresses of more than 140 of its customers.  This violated their own
stated privacy policy.  [Source: Fairfax newspapers - *The Age* and *Sydney
Morning Herald*, PGN-ed from John McLean, Zurich, Switzerland;
http://www.it.fairfax.com.au/e-commerce/19991222/A52132-1999Dec22.html]

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

Date: 20 Dec 1999
From: [Identity withheld]
Subject: Still another appalling web security story

A friend recently asked me to join an online "community" which he had
created on a service called Intranets.com (http://www.intranets.com/).  There
was some sort of verification code to enter, then I was asked to create an
account, including a username and password.  I went ahead and did so.

To my utter surprise, I then received an e-mail message from
[email protected] containing the login and password I had provided!

The risk is clear.  Electronic mail is an inherently insecure medium, both
because of the way it is generally stored and because it is transmitted as
clear text over TCP/IP networks.  Not only is the security of an account on
Intranets.com jeopardized by this practice, but if someone should use a
password which they already use for other services, then their other
accounts are also at risk.

Intranets.com does have a privacy statement, including a section on
security, but there's nothing there which would lead one to believe that the
company would do something like this.

The lessons for users? First, when signing up for a service, never use a
password which you wish to keep secret.  If you wish to have a consistent
password across sites (itself a risky practice), you should change the
password after you've signed up.  And even then, you should probably perform
an experiment to make sure the site isn't so daft as to send you a copy of
your changed password in the e-mail.

The lesson for developers? Security mustn't be so difficult to use that
users and website owners are tempted to defeat it by practices such as
reusing passwords and sending them over e-mail.  The answer may lie in
something like the digital keychain which I've read is contained in MacOS 9.
However, unless there's a way to take your keychain with you (on a disk,
card, etc.) or to access it from a central location (via a trusted keychain
storage site), this will only work for people who access the web from one
computer.

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

Date: 13 Dec 1999 (LAST-MODIFIED)
From: [email protected]
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 <[email protected]> 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 <[email protected]> (Dennis Rears).
.UK users should contact <[email protected]>.
=> 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 [email protected] 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].
Also, new AUSTRALIAN archive http://mirror.aarnet.edu.au/risks/
PostScript copy of PGN's comprehensive historical summary of one liners:
  illustrative.PS at ftp.sri.com/risks .

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

End of RISKS-FORUM Digest 20.71
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.