[1210] in RISKS Forum
RISKS DIGEST 17.85
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Wed Mar 6 12:19:50 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Wed, 6 Mar 96 9:17:00 PST
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Weds 6 March 1996 Volume 17 : Issue 85
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, etc. *****
Contents: [*The leap-flurry may die down soon, but the problem lingers on.*]
Compromise Bills on Data Encryption (Edupage)
Re: Spamming spoof floods autoresponder@WhiteHouse (Joel M Snyder,
via Prentiss Riddle)
More on Java applet loading (Li Gong)
Re: Telephone exchange "collapses" following bombing (Lauren Weinstein,
Dave Hinerman)
Power, sensors, and alarms (Jim Hudson)
My all-time favourite leap-year bug (Max Hadley)
Leap years at Digital [FORWARD] (Lord Wodehouse)
Leaping to conclusions (Sidney Markowitz)
More on leap-year calculations (Gareth Husk)
More on Excel and Lotus Dates (leap year 2000) (Frank Dougherty)
Re: 29 Feb 1900 and Excel (Steve Loughran)
Automated PC services (Matt Welsh)
The risks of assuming you know a domain ownership... (Jot Powers)
Re: PKZip Virus Alert (Dan Zerkle)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 5 Mar 1996 21:09:57 -0500 (EST)
From: Educom <educom@elanor.oit.unc.edu>
Subject: Compromise Bills on Data Encryption (Edupage, 5 March 1996)
Legislation has been introduced in both the House and Senate to permit the
export of data encryption hardware and software if similar technology is
available from foreign suppliers. The bills affirm the right of U.S.
citizens to use any type of encryption equipment domestically, and prohibit
the mandatory use of special keys that would allow law enforcement officials
access to encrypted messages. In addition, the legislation would make it a
crime to use encryption technology in the commission of a crime. (*The New
York Times*, 4 Mar 1996, C6)
------------------------------
Date: Wed, 6 Mar 1996 09:02:34 -0600 (CST)
From: Prentiss Riddle <riddle@is.rice.edu>
Subject: Re: Spamming spoof floods autoresponder@WhiteHouse
I thought you might be interested in some of the measures allegedly taken by
the White House sysadmins to prevent a total meltdown of its mail service.
-- Prentiss Riddle riddle@rice.edu
-- RiceInfo Administrator, Rice University / http://is.rice.edu/~riddle
* -------------------------- Forwarded message --------------------------
> Date: 9 Feb 96 16:03:20 -0700
> From: jms@tennis.opus1.com (Joel M Snyder)
> Subject: High mail volumes at whitehouse.gov
> Organization: Opus One, Tucson, Arizona
> Newsgroups: comp.mail.misc,comp.security.misc,news.admin.net-abuse.misc
>
> Good day. By way of introduction, I'm the consultant who did the
> "anti-mailstorm/anti-mailbomb" software that runs on the MX host for
> WHITEHOUSE.GOV. Now that the Telecom. Act of 1996 has been signed,
> the volume of mail through WHITEHOUSE.GOV has gone up significantly.
> For example, there were about 85,000 lines in the mail log file yesterday.
>
> Most of that is just people who want to express their opinion. However,
> several misguided individuals have decided that they want to throw a monkey
> wrench into the works by storming the President's e-mail.
>
> I'm writing this to let any system administrators out there know that you
> may find mail from your site to WHITEHOUSE.GOV is not moving very quickly.
> This is normal; it's a sign that the automatic protections of that system
> have kicked in.
>
> Without going into details, if too many messages come from a single site,
> the mail handler will throttle back accepting messages. Eventually,
> though, the mail will be accepted for delivery. If you have legitimate
> mail, it will eventually get through (many messages from the same
> correspondent will be flushed without acknowledgement). However,
> correspondents who were used to getting a reply within seconds telling them
> that their message was accepted may see a substantial delay.
>
> Finally, if any users on your site have any delusions about the effect of a
> mail bomb or storm of mail, let me help you dispel them: (1) no one
> important enough to make a difference will be affected or know or care; (2)
> if the messages are nasty or threatening enough, someone equally nasty may
> come and visit; (3) what you'll succeed most in doing is ruining the
> weekends and/or days of underpaid civil servants as well as wasting federal
> tax dollars.
>
> Please feel free to redistribute this or use parts of it in your motd.
>
> Joel Snyder
> (jms@opus1.com)
>
> PS: I don't read these newsgroups and am spending most of the weekend
> trying to make sure that the mail system doesn't melt down anyway, so if
> there is discussion on this, I won't see it.
------------------------------
Date: Tue, 5 Mar 1996 18:08:08 -0800 (PST)
From: Li Gong <gong@csl.sri.com>
Subject: More on Java applet loading (Re: RISKS-17.83)
David Hopwood in RISKS_17.83 mentioned, "If an attacker can arrange for two
files (a "Loader" class, and a dynamic library) to be installed in any
readable directory on the client machine, he/she can bypass all of Java's
security restrictions."
This does not appear to be a bug (e.g., a slip in the implementation) but
rather a design decision. It is clearly documented in Java that any applet
downloaded from the local machine is not subjected to the security
restrictions that apply to applets downloaded from elsewhere. This at first
appears quite reasonable -- otherwise, you cannot do a lot of interesting
things even locally.
A security problem occurs, however, if the remote web page refers (directly
or indirectly) to code that happens to exist on the client machine. For
instance, the following line can be found at the bottom of my home page <A
HREF="file:/tmp/play.html"> Fancy page </A>. If you click on that, and if
your trojan-co-worker has placed a file called play.html and its associated
class files in /tmp on your machine, those applets will run.
Alternatively, if someone knows that you have certain code X (applet or not)
in your directory -- suppose you have been developing it as a possible
attack on others -- that person may trick you into invoking X on yourself.
An immediate question is which file should "file:/tmp/play.html" refer to?
The one on the remote machine or the local one? There are pros and cons
either way.
The real problem is rooted in the fundamentally flawed philosophy that an
applet you downloaded runs on the local machine as you. This goes against
years of research in computer security. Such an applet, unless its
authenticity can be verified to the satisfaction of the downloading client,
should instead run within a confined (protected) sub-domain, and any further
invocations from this code should also run within this sub-domain. (PGN can
tell us all about the required and desirable properties of such a domain.)
Most machines and OSs obviously do not support such confined domains. The
point is whether Sun should have done the Java interpreter differently to
make life safer. For instance, on Unix machines, it is possible to set uid
on downloaded stuff. This is just one of the many ways to improve security
within the Java execution model.
Nevertheless, Java security will probably remain a news item until the day
when the fundamentally flawed philosophy is changed.
Securely yours, Li Gong, SRI International, http://www.csl.sri.com/~gong/
------------------------------
Date: Tue, 5 Mar 96 16:53 PST
From: lauren@vortex.com (Lauren Weinstein)
Subject: Re: Telephone exchange "collapses" following bombing
Assuming no significant damage to a telephone central office or supporting
infrastructure, the most common cause of "collapse" (defined in this case as
a dramatic form of overloading) is indeed the simple act of too many people
trying to use the phone at the same time. Telephone switches (and related
trunking) are designed to a designated expected maximum number of
simultaneous calls, which is far less than the total number of
lines/subscribers. In widespread emergency situations, that threshold can
be easily exceeded.
In the case of earthquakes here in L.A., the quake itself can cause its own
telephone problem even before people have had a chance to reach for the
handset--the quake can knock so many phones off the hook that (at least
initially--there are timeouts in modern switches) the switch thinks that
everyone and his brother is trying to make calls. Phones off hook also can
fool some people into thinking that their line is dead, since most modern
switches, after a few minutes of tones and recordings, will only put forth
silence until all phones on a line have been hung up and reset. If an
extension phone is off-hook under a pile of books, it's easy to miss
(especially in the dark!)
However, the most common cause of frustration during overload events is that
people are not patient enough. Modern switches establish a queue for
providing dialtone. Under normal conditions, you typically get a dialtone
essentially immediately. But under overload, you might have to wait ten
seconds, thirty seconds, or even for minutes. It seems like a *long* time.
Most folks don't realize this and keep hanging up and picking up the phone
again, trying to get a dialtone. Each time they hang up they lose their
place and reset back to the end of the queue.
So, in emergency situations (assuming you have a serious need that really
requires use of the phone), pick it up and *wait* for dialtone. To test to
see if you're still connected with the central office, simply blow into the
handset microphone and see if you can hear the blowing lightly in the
earpiece (this is easiest to test by blowing while alternately being hung up
and off-hook). If you hear a difference, you've still got current on the
line, and your connection to the switch is intact. If you wait, you'll
probably get dialtone--sooner or later. (Whether or not there will be
sufficient trunking for your call to get *out* of the office to your
destination is another matter...)
--Lauren-- Moderator, Internet PRIVACY Forum http://www.vortex.com
------------------------------
Date: Wed, 6 Mar 96 09:06:22 PST
From: Dave Hinerman <hinermad@sanfrancisco.aldiscon.com>
Subject: Re: Telephone Exchange Collapses After Bombing
In RISKS-17.84, Jake Livni described an Israeli news report in which it was
stated that the local telephone system "collapsed" shortly after a terrorist
attack. The term "collapse" was not defined in the article.
Jake also noted that people near to a disaster tend to use a nearby phone to
inform others (family members, etc.) of the event, and that people who know
someone near a reported disaster will attempt to call and verify that
person's well-being.
While a telephone system can "collapse" in a number of ways, most systems in
use today go to great lengths to avoid a total failure under abnormal
loading (which is caused by the human tendencies noted above). A system's
performance will degrade under such conditions, but not necessarily fail
completely. (This is, of course, neglecting bugs and other unpredictable
situations.) While some systems may indeed fail to the point of requiring
repair service, most will simply slow down until the overload dissipates.
The Risk in this case is that under disaster conditions, calls to emergency
services may be blocked by bystanders using up the available phone bandwidth
to call Aunt Martha to say, "I'm OK, but you should see the mess!"
Communications into and out of San Francisco area after the World Series
earthquake a few years ago were rendered almost useless by this condition.
I spoke with the commander of the Central Ohio HAZMAT (Hazardous Material)
Response Team (operated by the local fire departments) two years ago. Part
of his equipment is a cellular telephone, but he admitted that it is rarely
used because by the time his team arrives at a disaster the locals have
swamped the system and he can't get a dial tone. The Team is considering
using volunteer Amateur Radio operators to provide contact with various
telephone information services during a disaster, to bypass the need for
local telephone access at the disaster site.
Telephone systems are expensive to install and maintain, so operators design
their systems to carry "normal" loads, with some reserve capacity. A system
designed to carry the entire load during a disaster would make the price of
telephone service prohibitively expensive. (Thereby reducing load? Hmmm...)
David Hinerman Aldiscon, Inc. phone (614) 764-2490 ext 228
E-mail: hinermad@aldiscon.com fax (614) 764-2461
------------------------------
Date: Wed, 6 Mar 1996 11:48:29 +0500
From: jim@lightning.met.fsu.edu (Jim Hudson)
Subject: Power, sensors, and alarms
Last Friday we had a power outage that lasted for about 2 hours. It was one
of those dirty outages. The ones where the power goes off and on four or
five time in the span of about two seconds, before it goes out for good.
We made the decision to move our computer that serves as a file server and
mail server to the other side of the computer room so we could plug it into
the ups system. This computer carries a lot of baggage with it--a tape
drive, external disk drives, and two printers.
After we moved this equipment, the security alarm started going off in the
mornings before I was coming in to deactivate it. One of our observant
employees thought that the printer was the problem. So we ran some tests,
and sure enough, the security system's motion sensor was detecting the paper
as it came out of the printer and setting off the alarm, which also sounds
an alarm in the campus police dept.
We have now moved the printer to its original spot, under the motion
sensor, and we are on good terms with the police again.
Jim Hudson
[Now you have a protector protector detector rejector? PGN]
------------------------------
Date: Wed, 06 Mar 1996 10:24:33 +0000
From: Max Hadley <mrh@shl.co.uk>
Subject: My all-time favourite leap-year bug
On March 1st 1989 we received a support call from a user of our equipment
based in the (Persian) Gulf. It wasn't working! The equipment comprises two
boxes, both using the Microware OS/9 operating system (completely blameless
throughout, I hasten to add). Box 'C' was a battery portable computer, with
a real-time clock chip & continuous memory. Box 'D' was a volatile system
where the OS was re-started at each power on. The system was developed in
1987 & first shipped in 1988.
On 1/3/89, box 'C' attempted to boot box 'D' as usual. As part of this
process, it set the date - to 29/2/89! The OS date validation routine in box
'D' rejected this, quite rightly. Box 'C' *knew* it had the right date - the
RTC chip told it so, and rebooted box 'D' to teach it a lesson. And so the
process continued (all day if necessary).
It turns out that the RTC chip used - a 58274C - only has a 2 digit year
counter (!). As a result, it needs a separate 2-bit leap year counter, which
has to be correctly initialised. Since the initial boot of the box 'C'
operating system was part of manufacture, initialising the clock chip was
part of the manufacturing test procedure - which was written and tested in
1988!
We had worked this out quickly enough to call our manufacturing partners in
San Diego CA first thing in their morning & tell them to expect a lot of
support calls that day! The problem was actually in the driver for the RTC
chip, which bypassed the OS date validation code when setting the time &
date.
This was not the last problem we had with the 58274C clock chip, but that is
another story...xxxxxxxxxx
Stewart Hughes Ltd, School Lane, Chandlers Ford,Eastleigh, Hampshire SO53 4YG
UK xx@shluk.co.uk +44 (0) 1703 270027 xx@shluk.uucp Fax:+44 (0) 1703 270007
------------------------------
Date: Wed, 6 Mar 1996 15:52:29 +0000 (GMT)
From: Lord Wodehouse <w0400@ggr.co.uk>
Subject: Leap years at Digital [FORWARD]
Dear Customer,
The following is important information about Digital UNIX[R], formerly known
as DEC OSF/1[R]. Thank you, Digital Customer Support Center
SOURCE: Digital Equipment Corporation DATE: February 28, 1996
TITLE: Digital UNIX Systems Date/Time Problems - Leap Year
PROBLEM:
Recently Digital Equipment Corporation discovered a time keeping problem
in Digital UNIX with respect to leap year recognition.
1) The 'date' command rejects February 29, 1996 (or any other leap
year) as a valid date.
2) When the system time is changed with the 'date' to any date in March
of a leap year and then rebooted, the system clock will lose
one day.
IMPACT:
Reboots during the month of March will cause the loss of a day.
On machines without this ECO/patch installed, the problem is seen
only if the system is rebooted during the month of March.
------------------------------
Date: Tue, 5 Mar 1996 15:43:32 -0800
From: sidney@atg.apple.com (Sidney Markowitz)
Subject: Leaping to conclusions
I just found a URL for the Digital SPR 11-60903 that Dale Robinson quoted in
RISKS 17.83, and I highly recommend it for both its completeness and its
humor as an explanation of why the year 2000 *is* a leap year. The SPR can
be found at
http://www.southern.edu/people/bnbennet/text/lycomplaint.html
-- sidney markowitz <sidney@atg.apple.com>
------------------------------
Date: Tue, 5 Mar 1996 21:47:37 +0000
From: Gareth Husk <gareth@thaw.demon.co.uk>
Subject: More on leap-year calculations (RISKS-17.83)
Another aspect of people's confusion with the rules for dates came to light
the other day when I was tring to match the behaviour of two Julian
functions.
One, the Oracle numbers is well behaved and successfully handles the leap
from Julian to Gregorian calendars in (a gap of 10 days in 1582). As has no
doubt been discussed before just when the adjustment of calendars were
adjusted was a matter of national preference and several nations did not
make the move until this century.
Unfortunately the set of public domain clipper routines I
encountered that had been embedded in a new system I was trying
to interface with didn't understand:-
The Julian Gregorian change.
No leap years when the year is divisible by 100.
(I assume the fact that it will get 2000 right is an
accident).
The documentation with the routine claimed it was accurate back to
01-Jan-0100; unfortunately it fell over for dates before 01-Jan-1901.
The risk here is of course embedding 'shrink-wrapped' software in your apps
and trusting it to do the job on the label. In fact this software didn't
even come with disclaimers I'll post the names of the routines and the
author if people suddenly wonder if their Clipper apps are going to run
alright.
Note: For UK/US dates in the range 01-Jan-1901 to 31-Dec-2099 they work
fine.
[Julienne calendars is more like it -- chopped up
in thin strips around funny leap years. PGN]
------------------------------
Date: Tue, 5 Mar 96 16:33:52 -0700
From: "frank dougherty" <>
Subject: More on Excel and Lotus Dates (leap year 2000)
A note to followup to Tom Dickens' message regarding
29 Feb 1996 errors in Excel (RISKS-17.83)
I use Lotus 1-2-3 Release 5 for Windows and Excel 5.0 on the MAC.
My tests revealed the following:
1. Lotus uses a "date number" system where Day 1 is
January 1, 1900. The following is a quote from the Lotus
Help file:
date number
A number from 1 through 73050 that 1-2-3 assigns in sequence to each
date from January 1, 1900, through December 31, 2099. For example,
the date number for July 21, 1991, is 33440.
Lotus has various number formats for dates including a
day-month-year format that shows today's date, for example,
as 05-Mar-96. When one enters (or calculates) a date past
December 31, 1999, the format changes such that February 29,
2000 is represented as 29-Feb-2000. If the column width is
set to accommodate a dd-mmm-yy format, one gets a string of
********* for dates past December 31, 1999. Also, the @YEAR
function returns a value of 100 for a year 2000 date (@YEAR
returns 96 for a 1996 date).
These results may surprise spreadsheet users who have expectations
about the consistency of formatting and who do not understand
the convention that Lotus uses. By the way, the maximum date
for Lotus is December 31, 2099 (date number 73050).
2. The problems with 2/29 do not appear to occur in Mac
version 5 of Excel. It represents 2/29/2000 as
02/29/00 is nn-mm-yy format and returns a year value
of 2000 when the @YEAR function is applied. The
@YEAR function returns 1996 for current year dates.
Users who work with both Lotus and Excel should be
aware of the differences in how the two programs
handle dates.
Frank Dougherty
------------------------------
Date: Wed, 06 Mar 1996 16:07:55 +0000
From: Steve Loughran <slo@HPLB.HPL.HP.COM>
Subject: Re: 29 Feb 1900 and Excel
After reading about the fact that Excel 5 assumes that there is a leap year in
1900, and so all its dates (recorded as days since 1/1/1900) are wrong, I was
struck by a horrible thought.
Ole Automation, the Windows inter-application macro programming interface,
uses data types based upon those of Microsoft's spreadsheets and Visual
Basic. One of these datatypes is a date. Did this "Date" type deal with the
leap year properly, or were apps using it meant to assume that 1900 was a
leap year for compatibility.
I bit of CD searching cam up with the following answer from from the Win32
SDK, Ole Automation, "Data Types, Structures, and Enumerations":
VT_DATE
A value denoting a date and time was specified. Dates are represented as
double-precision numbers, where midnight, January 1, 1900 is 2.0,
January 2, 1900 is 3.0, and so on. The value is passed in date. This is
the same numbering system used by most spreadsheet programs, although
some incorrectly believe that February 29, 1900 existed, and thus set
January 1, 1900 to 1.0.
So, modern apps are meant to assume that 1/1/1900 is really the second day
of the year/century, rather than the first so that from 1/March/1900 onwards
the value of a date calculated by a broken (assumes 29/Feb/1900 exists)
application and a non broken application is the same.
I can't decide if this is an elegant workaround of the problem or not...
Steve Loughran, Hewlett-Packard Laboratories, Bristol
------------------------------
Date: Tue, 5 Mar 1996 20:52:17 -0500
From: Matt Welsh <mdw@CS.Cornell.EDU>
Subject: Automated PC services (Elliot, RISKS-17.83)
In 17.83, Steve Elliot asks:
>Over the weekend, Win95 erroneously took my system out of Sydney Daylight
>Saving. This should not happen until the end of March.
> [...]
>
> * What other "automatic" operations may be instigated without my knowledge?
Plenty. Lots. This is, after all, what computers are for. Modern operating
systems are designed to hide functionality --- especially with regards to
chronic activity --- from the guise of the user. Multitasking
(and multiprocessing) systems have the intentional property that "daemons"
perform routine actions without the end-user's knowledge and perhaps consent.
There is a very good reason for this: If the user were asked to verify and
understand every subtle operation of an operating system or daemon process,
no useful work could ever be done. (Could you imagine having to answer for
a dialog box for every operation taking place on your system?)
Unfortunately, this problem is only going to get worse --- not better. As
personal computers and the operating systems that they run become more
complex, much more will be going on in the system "behind your back", and
you may never be aware of it. Most people are used to thinking of the PCs
on their desks as predictable boxes that only do what they are explicitly
told to do. MS-DOS and Mac operating systems aren't going to spawn spurious
processes on you to, say, initiate their own I/O or network activity.
This is, of course, something of a myth. Nearly all computers (regardless
of the power of the O/S) are capable of performing "asynchronous" activity
which is unknown to the user. These functions are both necessary and
desirable in nearly all systems. Examples include:
* Timer interrupts, and anything latched to them (say, TSRs under
MS-DOS).
* Time-based scheduling of processes, such as those spawned by
the UNIX 'cron' and 'at' mechanisms.
* Any sort of network server process, e.g., an FTP or telnet daemon
which responds to stimuli from the "outside world".
* Administrative programs which, say, monitor the system for
viruses or perform quota services.
* Viruses themselves, and all manifestations (e.g., "surprise"
programs embedded in Microsoft Word documents).
Computers only give the end-user the perception that he or she is in
control. In reality, the operating system and all of the applications are
in control. Computers and applications present an interface which implies
causality. But I'm sure we've all seen enough Trojan Horses to know that
this is but an illusion.
M. Welsh, mdw@cs.cornell.edu Cornell University Computer Science Department
------------------------------
Date: Tue, 5 Mar 1996 12:23:15 -0700 (MST)
From: jot@tmp.medtronic.com (Jot Powers)
Subject: The risks of assuming you know a domain ownership...
I came into work today to find e-mail waiting in my in-box from someone who
had clearly reached their frustration point with their bank.
It appears that this person [who will remain nameless] has had a great deal
of difficulty with some banking and credit card services for the Bank of
Hawaii. It just so happens that I am the owner of the BOFH.COM domain,
which I use. This person sent me copies of all of his past correspondence
with the bank, including his home telephone number, his VISA number and
credit line. Now, being a relatively nice guy (and completely against the
spirit of the domain ;) I sent him a polite note informing him of his
mistake.
I believe the risks are obvious, but here are a few I can think of:
1) The large number of "novices" on the internet that think they
understand the naming schemes for companies.
2) The complete lack of knowledge of whois, which would have shown
him that the domain certainly did not belong to the Bank of Hawaii.
3) Unsecured transmission of credit card numbers to people who have
no legitimate need for them.
4) Assuming that all business can be deal with via the Internet.
[P.S. My new Alpha PC with the 20 gigabyte storageworks should be
here once his credit-card company approves it. ;)]
Jot Powers Unix System Administrator, Medtronic Micro-Rel (602) 929-5418
jot@tmp.medtronic.com
------------------------------
Date: 5 Mar 1996 21:59:49 GMT
From: zerkle@cs.ucdavis.edu (Dan Zerkle)
Subject: Re: PKZip Virus Alert
T Bruce Tober <octobersdad@crecon.demon.co.uk> wrote:
: In more than ten years of computing I've been hit by a virus only once.
Actually, that's probably not true.
....
: Phil Katz's Arc program (now known as PKZip). I
: downloaded it and ran the supposedly self-extracting file.
: Boom.
: No hard drive. All files deleted.
*Sigh*. You've just described a trojan [horse program], not a virus.
It's still bad, of course.
The risk? Virus detection programs typically won't help at all in detecting
or avoiding trojans. Calling everything a virus might lead to an
unwarranted complacency in people who have such protection software.
------------------------------
Date: 27 February 1996 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: ABRIDGED info on RISKS (comp.risks)
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...]
DIRECT REQUESTS to <risks-request@csl.sri.com> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for unabridged version of RISKS information]
CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, nonrepetitious, and without caveats
on distribution. Diversity is welcome, but not personal attacks. [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
By submitting an item that is accepted for publication in RISKS, the author
grants permission for unlimited noncommercial public distribution and
redistribution in electronic and print form. Relevant contributions may
appear in the RISKS section of regular issues of ACM SIGSOFT Software
Engineering Notes or SIGSAC Review.
RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
RISKS ARCHIVES: "ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP. [...]
[Back issues are in the subdirectory corresponding to the volume number.]
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]
ftp://ftp.sri.com/risks
PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest,
see the unabridged INFO file at RISKS-Request (send one-line message INFO
to risks-request@CSL.sri.com as noted above).
------------------------------
End of RISKS-FORUM Digest 17.85
************************
