[1223] in RISKS Forum
RISKS DIGEST 18.02
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Tue Apr 9 13:38:23 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Tue, 9 Apr 96 10:37:03 PDT
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Tuesday 9 April 1996 Volume 18 : Issue 02
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. *****
Contents:
The weakest link: Social (In)security Administration (Sean Reifschneider)
``Jail Gives Hackers a Lesson in Reality'' (PGN)
Australian Insurance Company and Database (Andrew Waugh)
De facto Daylight Savings (Matt Welsh)
Re: Teen Accused of Hacking (William Ehrich)
Microsoft Exchange helpfully misdirects e-mail (John Hoffmann)
Re: Notes on e-mail: Use diaeresis (Tim Pierce, Otto Stolz)
CompuServe's "secure login protocol": two steps forward, one back
(Heinz-Bernd Eggenstein)
IBMMAIL e-mail address woes (Erik Naggum)
Re: X-Confirm-Reading-To: Pegasus woes on mailing lists... (Peter Yamamoto)
The risks of .forward (Christophe Beauregard)
Re: Wrong approach to Java security (Andrew Berman)
Re: Risks of rewritable BIOSes (Jeremy J Epstein, Nicholas C. Weaver)
Re: Computers, Freedom and Privacy '96 (Shabbir J. Safdar)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sun, 7 Apr 1996 22:12:30 -0500 (CDT)
From: Sean Reifschneider <jafo@tummy.com>
Subject: The weakest link: Social (In)security Administration
The URL "http://www.nando.net/newsroom/ntn/info/040696/info5_14984.html"
reports "one of the biggest breaches of security of personal data held
by the federal government". Apparently several employees of the Social
Security Administration sold information including SSNs and mother's
maiden names of more than 11,000 people to a credit-card fraud ring.
The fraud ring was able to use this information to activate cards which
were stolen from the mail. Citibank had implemented a scheme which
required customers to "activate" their credit cards when they receive
them by calling a phone number and providing personal information like
their mothers maiden name.
It seems that while systems are being designed to protect our property, it's
just causing the crime to move closer to the person. If someone steals your
credit card from the mail or your car from the parking lot, you're probably
at a safe distance. Instead, they are forced to carjack your car at a
stoplight because of your alarm system, or find out personal information
about you.
Similarly, I heard about home breakins on alarmed houses in which the
burglar would regularly trigger the alarm and be careful to leave no
traces. Once the police stopped coming (because the alarm was faulty),
they were free to break in and swipe whatever they like.
No matter how secure the system, the weakest link can be the clerk who's
paid $12K/year to work on the system. It doesn't take much money to
convince this person to hand out our personal information.
This sort of thing kind of makes the hassle I went through in keeping my
SSN from my insurance company. If you've never tried it, for me it was
a huge hassle... Apparently, all of my claims needed to be handled by
hand by one of the supervisors. Of course, if everyone did it, their
$4/hour clerks could take care of it.
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD X11 scanning software.
[Also noted by Monty Solomon <monty@roscom.COM> quoting from Edupage,
and WOODWARD@BINAH.CC.BRANDEIS.EDU (Beverly Woodward), who cited the
article in "U.S. Workers Stole Data on 11,000, Agency Says" in
*The New York Times*, 06 Apr 1996, p. 6, from which most other
reports seem to have been drawn. PGN]
------------------------------
Date: Mon, 8 Apr 96 18:45:15 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: ``Jail Gives Hackers a Lesson in Reality''
Terry Ewing (now 21, with 21 months in federal custody ahead of him)
downloaded 1,700 credit-card numbers off of a Tower Records computer system,
just before leaving for DefCon, the West Coast "hackers' convention". His
friend Michael Kim (now 20) is facing an 18-month sentence. Apparently,
Tower folks knew their systems had been under attack previously, and were
monitoring misuse. Police encouraged Tower to wait for the next attack --
in which the intruders used the Tower computer to sort the captured
credit-card numbers by expiration date and create a file of those with a
date at least a year away -- while being observed. Agents tracked the
intrusion to their apartment, which was searched, revealing the purloined
information. The two young men were convicted of a felony, although they
had not profited from the credit-card numbers. [Source: *San Francisco
Chronicle*, 8 Apr 1996, p.A2.]
The article concludes with a quote from Mike Godwin of EFF about those
who ``have this myth that they are cool guys, and [that] the cool guys
always win over the suits. But the fact is that they are half-socialized,
post-adolescents with serious ethical and moral-boundary problems.''
[Stores should not store credit-card numbers, but I guess we can no
longer number the stores that do not behave sensibly. I just asked a
mail-order outfit if they would keep a card number around for a
long-deferred delivery; the answer was, ``yes, but we keep in a place
where no one can access it.'' I am sure that gives you RISKS readers a
lot of comfort. PGN]
------------------------------
Date: Sat, 06 Apr 1996 15:07:33 +1000
From: Andrew Waugh <A.Waugh@mel.dit.csiro.au>
Subject: Australian Insurance Company and Database
The 6-7 Apr 1996 edition of 'The Weekend Australian' carries a report (p 5)
on a court case involving the large Australian insurance company AMP and an
attempt to build a large database of all Australian households.
It was alleged that the "massive database... was supposed to identify every
household in Australia, give each household a unique identifier number,
detail the dwelling type of each household - whether it was two-story,
weatherboard [timber] or brick - and also detail the fire, storm and flood
risk rating of each home." The contractor developing the database, Indata,
expected this database to give AMP a significant commercial advantage.
This database was alleged in court to to have been based on a magnetic tape
of the Australian electoral roll. Under the Australian Electoral Act,
magnetic tapes of the electoral roll cannot be obtained for commercial
purposes. The former manager of Indata said that he had assumed AMP had
investigated the legalities of purchasing the tape and that Indata and AMP
were acting within the law. The tape had already been purchased before the
manager joined Indata.
The court case is a committal hearing against a former AMP client manager
who is charged with 12 counts of attempting to defraud AMP. The fraud
involves payments to Indata totalling $324,809 (Aus). AMP is expected to
claim that was not aware of the illegal purchase of the electoral roll and
that their client manager had inappropriately authorised payment to Indata.
AMP has demanded return of the money.
The committal hearing will continue next month.
andrew waugh
------------------------------
Date: Sun, 7 Apr 1996 13:31:38 -0400
From: Matt Welsh <mdw@CS.Cornell.EDU>
Subject: De facto Daylight Savings
At http://www.timing.se/Daylight.html there is a brief discussion
of the rules for Daylight Savings Time changeovers for central Europe
and the UK. At the end of the page it says:
> NOTE: From autumn 1996 the rule of changing from standard time to
> daylight time is changed. The new rule is valid for central Europe
> including the UK is:
>
> Standard time to Daylight Saving LAST SUNDAY OF MARCH
> Daylight Saving to Standard time LAST SUNDAY OF OCTOBER
>
> The rule is a "de facto standard," not a law.
>
> The switching occurs at 01:00 UTC for central Europe (Stockholm Paris etc.)
> Local time that is at 02:00 STD to DST and 03:00 DST to STD.
> (STD = Standard time, DST = Daylight Saving Time or Summer Time.)
>
> Note: The legal switching is steered by laws that state dates for a couple
> of years. When a period ends a new law is issued that gives the dates for
> the next years.
>
> The Laws do not state any general rule. Only dates for a couple years
> each time. The "de facto rule" works, but there is no warranty it will
> work forever!
With all of our scrambling about to deal with the Year 2000 problem,
shouldn't we be just as concerned with this inconsistency that arises
yearly (especially if there are no 'hard and fast' laws/standards to dictate
DST changeovers)?
M. Welsh, mdw@cs.cornell.edu
------------------------------
Date: Sat, 6 Apr 1996 11:32:31 -0600
From: ehrich@minn.net (William Ehrich)
Subject: Re: Teen Accused of Hacking
If my bank kept my money in a cardboard box in their parking lot and
children stole it, I would blame the bank before the children. As long as
corporations and institutions design their computer systems only for
convenience and least cost, with maybe a superficial gesture at something
called 'security', they won't solve the problem.
The biggest risk of all is from people who won't accept their responsibility.
- William Ehrich
------------------------------
Date: Mon, 8 Apr 1996 11:40:21 -0400
From: John Hoffmann <john@netweave.com>
Subject: Microsoft Exchange helpfully misdirects e-mail
Like most e-mail clients, Microsoft's Exchange allows you to maintain lists
of user's addresses along with aliases. In our simple configuration, we
have two, a personal list and a global list. Up until recently, since our
e-mail system was closed and limited to project members, my personal list
was almost empty. Since we have added an Internet gateway, I've begun
adding addresses not on the global list to my personal list.
Exchange has another useful feature as well, it will expand names from just
the first characters. If multiple names match the abbreviation, it will ask
you to pick one.
Today I sent out an internal message, using "schu" as an abbreviation for
schumacher, which I have done many times in the past. Shortly there after
the message was returned from the AOL e-mail daemon as undeliverable, highly
surprising since it was an internal message not destined for the Internet.
It turns out that last week I incorrectly added an AOL user whose name also
begins with "schu" to my personal address list. Exchange apparently only
checks one list at time, flagging multiple possibles only within the list.
In this case, it checked my personal list first, matched the AOL user, and
quietly sent the message on. If the name at AOL had been correct, I would
have not known about the misdirection at all.
The risks are obvious - instead of a somewhat trivial and incomprehensible
internal message, the message could have been highly confidential or time
critical. The solution is trivial as well - check all mail lists for
conflicts (or at least have that as the default configuration & easily
selectable).
------------------------------
Date: Fri, 5 Apr 1996 19:09:29 GMT
From: Tim Pierce <twpierce@midway.uchicago.edu>
Subject: Re: Notes on e-mail: Use diaeresis (Sandee, RISKS-18.01)
>Usenet (at least NNTP) is generally 8-bit transparent, and any European
>soc.culture group will tell you that ISO 8859-1 usually works, ...
Though many machines on Usenet are eight-bit clean, NNTP is defined to be
seven-bit. There's no guarantee that the use of raw characters in
ISO-Latin-1 will come out unharmed on the other end.
More risks: assuming that an action is advisable simply because it "usually
works." This, unfortunately, is becoming more and more common even among
news software developers, some of whom have simply conceded the seven-bit
encoding battle and now write for an eight-bit net.
------------------------------
Date: Tue, 9 Apr 1996 10:39:53 -0500
From: Otto Stolz <Otto.Stolz@uni-konstanz.de>
Subject: Re: Notes on e-mail: Use diaeresis (Sandee, RISKS-18.01)
On 2 Apr 1996 16:20:16 GMT, sandee@Think.COM (Daan Sandee) said:
> [...] "co=F6perate", "na=EFf", and "Bront=EB.". [...] It was already
> mangled in the RISKS posting
Apparently, these examples were sent to RISKS encoded as "quoted-printable".
I guess, they were contained in an e-mail item adorned with the appropriate
MIME headers to announce that transfer encoding to any interested parties.
However, in the process of digesting, all header fields (except the From,
To, and Subject fields) were stripped off.
This seems to be a general problem with contemporary mail-digesting software.
Of course, the transfer-encoding has to be undone before you can safely
remove the pertinent header field. I hope, our moderator will be able to find
a mail-digesting program that handles MIME headers properly.
> [...] I wish people wouldn't assume that the way their machine handles
> non-ASCII characters is the same as everyone else's.
This is exactly the reason MIME was invented for.
> Usenet (at least NNTP) is generally 8-bit transparent, and any European
> soc.culture group will tell you that ISO 8859-1 usually works [...]
Not quite so! There are mail transfer agents, and perhaps other intermediate
software, that still will drop the most significant bit of every 8-bit
character.
> This post of mine, however, goes out by e-mail (SMTP) and upper bits will
> be stripped [...]
Hence, contributions to RISKS, and other e-mail based services, must exploit
MIME to convey those characters (until, eventually, the powers that be might
agree on a 8-bit, or even 16-bit, based mail protocol). It is the digester's
duty to undo any transfer-encoding before the mail is digested, and to encode
the whole digest for transport, as necessary.
> Well, I can handle diaereses all right, as long as they arrive in a form
> recognizable by my software.
And it will be the subscriber's duty to undo the transfer-encoding of the
whole digest.
Otto Stolz
[I have asked several folks what I would need to do to MIME-ify RISKS.
I get responses that it is not that easy, or that it won't help
those who don't deal with MIME, or that perhaps I should just
wait until things settle down. Meanwhile, we have a justification
for indigestion with undigestification. PGN]
------------------------------
Date: Thu, 04 Apr 1996 19:34:12 +0200
From: Heinz-Bernd Eggenstein <eggenste@noether.informatik.uni-dortmund.de>
Subject: CompuServe's "secure login protocol": two steps forward, one back
Summary: a new CompuServe Information Service (CIS) logon protocol was
designed to prevent passive and active attacks (where the attacker
impersonates a CompuServe node) but a flawed implementation in the
WinCIM 2.0(.1) client software still allows active attacks.
Version 2.0 of the "WinCIM" access software introduced a new logon protocol.
Previous versions of the software had transmitted the user's UID AND his/her
password in plaintext during logon. The risks are obvious, especially when
connecting via the Internet to CompuServe (e.g. to save long distance
telephone charges).
The new, "secure logon protocol" is a challenge-response type protocol where
the "challenge" is to compute a keyed hash-function, the key is derived from
the shared secret, the user's password:
1) The client (WinCIM) generates a pseudorandom string of bits, its "nonce"
(RB)
2) The client transmits the user's UID (e.g. 12345,6789) and the additional
parameter "/secure:1" to request a secure login.
3) The host transmits its pseudo random nonce (RA) (The old protocol would
instead prompt for the password)
4) client sends RB to the host
5) client computes UR:=MD5(S|Z|RA|RB|S) and sends it to the host
(where S (128 bits) is a function of the password, "|" stands for
concatenation, Z is a 128bits block of 0s and MD5 is the well
known message digest function.)
6) The host performs the same calculation with it's copy of the user's
password. If the results match, the host sends HR:=MD5(S|Z|RB|RA|S)
(Note the symmetry in the calculation of HR and UR)
7) The client software verifies HR with it's copy of the password to
make sure the host is really a CIS node (!)
(See the script-files cserve.scr and seclog.scr in the subdirectory SCRIPTS
of a WINCIM 2.0(.1) installation, WinCim is available via anon. ftp
at ftp.compuserve.com).
Weaknesses:
a) The scriptfile cserve.scr (versions 3.8 & 3.8.1) has the following bug:
even after requesting a secure logon, the client software will fall back
into the old protocol when receiving a "Password" prompt (Client: "I want
a secure logon" Host:"OK, but anyway, give me your password" Client "Well
ok then, here it is ..."). It will send the password in plaintext! This
makes the protection against active attacks (see step 7) obsolete.
b) A timeout condition or even an invalid HR response form the host will
(seclog.scr & cserve.scr version 3.8.1) restart the protocol (it won't
disconnect!), using *the same* client-nonce RB again, instead of
generating a new one. If a spoofing host can predict RB as in this
situation, it can pick the same nonce, leading to HR=UR=MD5(S|Z|RB|RB|S),
so the host can just send back UR as HR.
Note that unlike a), b) does not compromise the user's password.
There may be other ways to predict the client software's nonce e.g. *if* the
PRNG used by WinCIM is predictable (this calls for further investigation).
Note that *offline* dictionary attacks to guess the password are possible
after a passive, eavesdropping attack (so you still have to pick a "good"
password). It's debatable whether CIS's password recommendation
(<word><non-alphanum. char.><word>, both words unrelated, e.g.
apple@battery) is adequate in this context).
I notified CIS about these weaknesses and I was informed that they are
"fixed" now, no details were given about the fix (source: Britta Herbst,
German customer support (11111.754@compuserve.com)).
Risks? The new protocol is obviously an improvement over the old,
plaintext-password-only version. It's debatable whether protection against
active attacks is at all necessary for access to an online service. However,
CIS itself designed it's protocol to prevent spoofing attacks. Anyway, I
think this a good example how to half-ruin a good protocol by embedding it
into carelessly written code.
Credits: Thanks to Gary Brown (70003.1215@compuserve.com) for sending me
information on the implementation of the new protocol).
Heinz-Bernd Eggenstein [usual disclaimers]
------------------------------
Date: 03 Apr 1996 13:11:21 UT
From: Erik Naggum <erik@naggum.no>
Subject: IBMMAIL e-mail address woes
You may not know the IBMMAIL system. Internet addresses are translated to a
seven-digit number, which users use instead of real addresses. It so
happens that I once ran a large mailing list and needed to track down which
messages were not delivered to which people, and so generated a unique
Return-Path for each message. This caused a large number of IBMMAIL numbers
to be assigned to such addresses. About once a month, I receive
confirmations of business transactions between Hong Kong and Singapore
companies to one of these addresses. Clearly, the RISK is that humans
mistype numbers all the time, and when the addresses in a given range are
all valid, will send mail to the wrong recipient every now and then, just as
people misdial telephone numbers.
All information expressed in long numbers whose accuracy matter to either
party include redundant digits to reduce the number of valid numbers and to
provide consistency checks. The same should be true of IBMMAIL numbers.
(Indeed, it should perhaps be true of domain names and usernames, too.)
#<Erik>
------------------------------
Date: Thu, 4 Apr 1996 10:42:36 -0500 (EST)
From: Peter Yamamoto <pjyamamo@daisy.uwaterloo.ca>
Subject: Re: X-Confirm-Reading-To: Pegasus woes on mailing lists...
> Recently, on a mailing list I maintain, a Pegasus (the name of a
> Mac/Windows e-mail reader) user posted a message with a line:
>
> > X-Confirm-Reading-To: <e-mail address>
>
> This would be fine if Pegasus respected the field value when acting on
> the presence of this field. But Pegasus programmers apparently took the
> RISK of assuming that they didn't have to. Now every list member using
> Pegasus is generating a confirmation message to the list.
Well, the problem wasn't as simple as that, that is only what it looks
like...
The "problem" is due to a new release of Pegasus which added a directed
confirmation header field as well as keeping the old confirmation header
field (which old versions simply respond to as best as they can). The new
field name is called X-Confirm-Reading-To: <e-mail address> and the old name
is "X-pmrqc: 1".
Hence, unless familiar with these things, the mailer looks like it is not
behaving.
There are Risks in this whole episode, but I've worn myself thin trying to
defend the meaning of my post to a listserv listowner's list (a warning of
disruptive behaviour) with the author of Pegasus who took my comments
differently (as a rude personal attack).
Peter
------------------------------
Date: Tue, 2 Apr 1996 11:12:20 -0500 (EST)
From: cpbeaure@undergrad.math.uwaterloo.ca
Subject: The risks of .forward
Standard procedure for us net types is to leave .forward files when we
change accounts. This is what I did when I left my previous employer.
Because of the nature of the Internet firewall we had there, to access the
net users had to actually log into the firewall machine - a bad idea in
itself, but it gets worse.
One fine day, I logged in to find a message informing me that the
firewall password had changed. Conveniently, the message also included
the new password. It seems that when I left, not only had they not
erased the .forward file, but they hadn't removed me from the system
alias file.
The risks?
1) Clean up after your old employees.
2) E-mail goes everywhere.
3) Don't e-mail passwords. Ever.
------------------------------
Date: Fri, 05 Apr 1996 16:59:49 PST
From: Andrew Berman <aberman@cs.washington.edu>
Subject: Re: Wrong approach to Java security (Stuart, RISKS-18.01)
>In RISKS-17.95, Jacob Palme suggests that the reputation of "well-kept
>depositories" and PICS-like ratings can be used to guard against malicious
>Java code. A more useful idea along the same lines is to allow for code to
>carry a digital signature. ...
Neither PICS-like ratings nor Digital Signatures is going to solve the
problem. Yes, they might constrain some malicious users. But what about
the data loss from buggy software? Also, decentralization of code is a
promise of web-based languages. A world in which every piece of code has to
be checked against a database of signatures is a much less flexible world
than one in which code runs in a "safe" environment.
Not to mention that a digital signature for a company will undoubtedly be
known by more people than a digital signature for a single user. Thus,
the opportunities for theft of the signature would increase dramatically.
Andrew P. Berman Dept. Of Computer Science, University Of Washington
aberman@cs.washington.edu| http://www.cs.washington.edu/homes/aberman
------------------------------
Date: Tue, 09 Apr 1996 09:58:42 -0500
From: JEREMY J EPSTEIN <JEPSTEIN@mail.cordant.com>
Subject: Re: Risks of rewritable BIOSes (Epstein, RISKS-8.01)
After my posting in RISKS-18.01, several people sent me e-mail. A few
clarifications to my original note:
* Some PC vendors have a jumper that disables writing the flash. In my
experience, this is unusual, although it's clearly present in some cases.
For those who are lucky enough, the jumper is even documented. Clearly this
is a good solution for those whose PCs have the option. Of course most
users won't read the manual that comes with the PC and thus won't realize
that there's a risk, much less understand how to thwart it. [Pointed out by
mark@leasion.demon.co.uk (Mark Evans) and
afelson@milton.ecte.uswc.uswest.com (Adam Felson).]
[AND also by "Nicholas C. Weaver" <nweaver@CS.Berkeley.EDU>,
with the default being disabled -- see the next item. PGN]
* I wrote "...each vendor has solved the problem differently..." The word
"vendor" should be understood as the vendor of the motherboard, which may
not be the same as the PC vendor. That is, a brand X PC may use a brand Y
or brand Z motherboard. So looking at the outside of the case may be
insufficient to determine whether the PC is "safe". [Pointed out by Mark
Evans.]
* As an aside I wrote that the risk would be eliminated if people used more
modern systems such as UNIX, OS/2, or NT. As pointed out by Benedikt
Stockebrand (benedikt@devnull.ruhr.de), it doesn't *eliminate* the risk,
because there may be bugs that allow subverting the system and thus gaining
access to the flash RAM. Stockebrand also pointed out that (on UNIX
systems) if you can get the virus/trojan run by root, then all bets are off.
Perhaps I should have said that running a more modern system *reduces* the
risk, since a virus/trojan would have to be a lot smarter than in a
DOS/Windows environment.
The above not withstanding, the point stands: most Pentium-based PCs are
extremely vulnerable to flash-based attacks.
------------------------------
Date: Fri, 5 Apr 1996 10:52:40 -0800
From: "Nicholas C. Weaver" <nweaver@CS.Berkeley.EDU>
Subject: Re: Risks of rewritable BIOSes (Epstein, RISKS-17.81)
Although I believe software solutions are necessary for correcting the
flash-BIOS problem on existing motherboards, I think all future motherboards
should just resort to an old-fashioned physical jumper. If the jumper is in
place, then the BIOS is reprogrammable. (If a malicious person has access
to your motherboard, he/she can do a LOT more damage then simply reflashing
the BIOS, but a malicious program can't -- especially if the motherboard is
shipped without the jumper in-place.)
------------------------------
Date: Sat, 6 Apr 1996 15:59:55 -0500 (EST)
From: "Shabbir J. Safdar" <shabbir@panix.com>
Subject: Re: Computers, Freedom and Privacy '96 (RISKS-18.01)
My RISKS commentary about the Bruce Sterling piece at CFP '96 drew
many pieces of e-mail. You can get a RealAudio recording of it from
URL:http://www.w3.org/pub/WWW/CFP4/live.ram
(I don't have a RealAudio player on this machine, so I cannot verify
that it works..)
The live version left me feeling numb and panicky.
[oram@unixg.ubc.ca (John Oram) reported that the audio version
of the entire CFP 96 is available for your listening pleasure
"(in the bandwidth-conserving RealAudio format)" at:
http://swissnet.ai.mit.edu/~switz/cfp96/ .]
------------------------------
Date: 18 March 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.
Particularly relevant contributions may be adapted for the RISKS sections
of issues of ACM SIGSOFT Software Engineering Notes or SIGSAC Review.
* Submissions: By submitting an item that is accepted for publication
in RISKS, the author grants permission for unlimited public distribution
and redistribution in electronic or other form.
* Reuse: Blanket permission is hereby granted for reuse of all materials
in RISKS, under the following conditions. All redistributed items must
include the Risks-Forum masthead line. All reuse must be accompanied by
the following statement:
Reused without explicit authorization under blanket permission
granted for all Risks-Forum Digest materials. The author(s), the
RISKS moderator, and the ACM have no connection with this reuse.
As a courtesy, reusers of individual items (as opposed to forwardings of
entire issues) should notify the authors, and should pay particular
attention to any subsequent corrections.
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
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
get illustrative.PS
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 18.02
************************
