Risks Digest 20.92

[risks@csl.sri.com]

[: hacktivism :]

RISKS-LIST: Risks-Forum Digest  Friday 16 June 2000  Volume 20 : Issue 92

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

  Contents:
Grade fixing (PGN)
Jury blames computers for Cali plane crash (Scott Lucero)
Black boxes, telemetry, and autopsy (Lord Wodehouse)
For want of $35, J.P. Morgan loses its Web site and e-mail (Keith A Rhodes)
Another example of systems that don't talk to each other (John Pettitt)
Bad background checks on Slashdot (Michael D. Crawford)
No password recovery on B2B WWW site (Dirk Bank)
JustBeFriends for macro virus control (Gary McGraw)
Re: Bloat Dissections II (Martin Ward, Graham Mainwaring, Edward Reid, 
    Nevin Liber)
Re: Indian Railway Fiber (Jay R. Ashworth, Chuck Charlton, Bart van Leeuwen,
    James Ryan)
REVIEW: "Information Hiding Techniques for Steganography and 
    Digital Watermarking (Rob Slade)
Call For Participation - RAID 2000 (Herve Debar)
Abridged info on RISKS (comp.risks)

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

Date: Thu, 15 Jun 2000 9:02:47 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Grade fixing

At least 20 Berkeley High School seniors (hopefully, graduating) are
apparently involved in a grade altering episode.  The grade program is
accessible to only about 20 employees, who must use *two* passwords.  (Wow,
that is REAL security!)  But one of the computers was most likely left
logged in and unattended.  One student admitted paying $10 for the change.
[Source: article by Meredith May, *San Francisco Chronicle*, 15 Jun 2000,
A26]

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

Date: Thu, 15 Jun 2000 14:09:04 -0400
From: "Scott Lucero" <LuceroDon@hq.optec.army.mil>
Subject: Jury blames computers for Cali plane crash

A US federal jury today found that an aviation computer software company and
a flight-computer manufacturer contributed to the 1995 crash of an American
Airlines jetliner in near Cali, Colombia.  159 out of 163 passengers were
killed.  The jury said Jeppesen was 17 percent responsible, Honeywell 8
percent at fault, and American Airlines 75 percent responsible.

Honeywell attorneys believe the pilot guessed by punching in the first of 12
options for navigational beacons sharing the code letter R instead of the
correct code "Rozo", which would have carried the jet straight down a valley
into Cali. The first "R" turned the jet toward Bogota, and the intervening
mountains.

It turns out that 95 of 8,000 navigational beacons worldwide were not coded
in the database as beacons.  "Rozo" was stored in another file.

Apparently, Jeppesen understood the risks.  11 months before the crash, one
of their memos states: "The situation with this group of navigational aids
has reached a boiling point. We will have to act now to meet our customer
needs."

Another unfortunate example of the risks of doing nothing when safety
critical problems surface.
  http://abcnews.go.com/sections/travel/DailyNews/Software000613.html

Scott Lucero

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

Date: Fri, 14 Apr 2000 10:27:34 +0100
From: Lord Wodehouse <w0400@ggr.co.uk>
Subject: Black boxes, telemetry, and autopsy

Watching a few nights ago on Channel 4 in the UK, I saw a programme called
Equinox on flight data recorders (black boxes) and and the "failures" of
these to identify the cause of accidents, especially when only recording a
few parameters. The case against Boeing was put, when the company adopted a
different interpretation of the data, because not enough points were
available to actually determine exactly what happened at certain times. This
is all somewhat emotive as it was connected with the 737 rudder deflection
crashes.

However one view put forward was that real-time telemetry would ensure that
potential problems could be spotted as they happen and this would move the
problem of crash investigation from autopsy mode to crash prevention.

I myself remain unconvinced. For a start to get all the real-time data
logged and monitored would be a huge effort, requiring lots of technology
and be expensive and hence resisted. Secondly when a problem strikes,
although the pilot may have incomplete or no information about the cause
s/he is the person up there where the problem is. The ground monitoring
staff will only see one side of the issue and I can see a conflict between
their views and the flying crew. Telemetry may well work well for the USN
and test pilots or for space missions like Apollo (13 in particular), but
when there are so many planes flying, will it really work as well?  Any
failure to get the real-time data could also lead to issues of whether a
plane half-way across the ocean should fly on or turn back.

However British Airways does have a system of recording lots of aircraft
parameters on recorders on the flight deck. The tapes are played back after
the flight to see if issues occurred and to monitor the state of the
plane. This seems to be a way of spotting problems and following trends, so
that fault prediction can be done and the risk of crashes reduced.

Planes will always crash, often due to human error and almost always due to
unforeseen circumstances. By ensuring that the flight data recorders store
enough data and that a quick access means such as a separate data recorder
in the cockpit is available so data is collected easily from each flight, it
will be possible to reduce the accidents and provide a better chance of
uncovering the cause.  Relying on technology like real-time telemetry to be
a magic bullet is folly.
  
Global Research Information Systems, Glaxo Wellcome Medicines Research Centre
Gunnels Wood Road, Stevenage SG1 2NY UK  +44 1438 76 3222  w0400@ggr.co.uk
http://ds.dial.pipex.com/lordjohn/ and http://www.lordjohn.demon.co.uk/

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

Date: Wed, 14 Jun 2000 09:35:43 -0400
From: "Keith A Rhodes" <rhodesk.aimd@gao.gov>
Subject: For want of $35, J.P. Morgan loses its Web site and e-mail

J.P. Morgan & Company (worth $21 billion) lost its Internet connectivity on
13 Jun 2000 because they failed to pay their $35 bill from Network Solutions
for their jpmorgan.com domain: three bills ignored over six weeks.  All of
their Net customers were affected.  (Last year Microsoft failed to
reregister a domain name necessary for Hotmail service, although a computer
consultant bailed them out by paying the fee for them.)  [Source: Article by
Patrick McGeehan, 14 Jun 2000; PGN-ed]

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

Date: Mon, 12 Jun 2000 12:08:33 -0700
From: John Pettitt <jpp@cloudview.com>
Subject: Another example of systems that don't talk to each other

CobraServ (a service company that handles health insurance payments) sent 
me a "you didn't pay so we're going to cancel you" letter dated June 
7th.  Yet when I call their automated voice response system it happily 
tells me that my last payment was received June 5th!      Almost makes me 
want to go back to the British National Health Service.

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

Date: Thu, 15 Jun 2000 15:01:54 -0700
From: "Michael D. Crawford" <crawford@goingware.com>
Subject: Bad background checks on Slashdot

The story "When Background Checks Go Wrong" on http://slashdot.org at
  http://slashdot.org/article.pl?sid=00/06/07/211250&mode=thread
is about someone who couldn't get a job because of a mistaken felony
arrest that appeared on her record, and discussion of liability for the
employers and private investigators.

Many, many people weigh in on the commentary with their own experiences
with mistaken background checks, and I post my own experiences in being
mistaken for other Michael Crawford in the same schools, at the same
companies, and in the arts (hint: I didn't star in Phantom of the
Opera).

BTW, I try to refer people to Risks sometimes on Slashdot.  I think it
would be helpful if more risks readers would post on slashdot and refer
the readers to relevant issues of Risks.  Slashdot is a very
high-visibility site in the open source community and I think they could
use the sober realizations that come from reading risks when writing
more open-source code.

Michael D. Crawford crawford@goingware.com http://www.goingware.com

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

Date: Mon, 12 Jun 2000 18:23:16 -0400 (EDT)
From: Dirk the Daring <dirk@psicorps.org>
Subject: No password recovery on B2B WWW site

I work for a large, multinational telecomm and computer firm based in the
western USA. We have a standing contract with a large US-based printing and
stationery firm to produce all our stationery, letterhead, business cards,
etc.

Having recently obtained a number of industry certifications (something I
studiously avoided doing for the past 15 years, but I now find myself
employed by a company which cares about these), I decided it was time to
update my business cards to reflect these certifications.

I followed the links from our company intranet site to the printing firm's
B2B site where we can order such things. I was prompted for some
information, including my Human Resources ID (HRID) and password. Well, its
been two months since I ordered anything, so I'd forgotten my password. They
offered a helpful "Lost your password?" link, which led me to another screen
where they asked from the E-Mail address I had used. I tried all my E-Mail
addresses, none of them were accepted by the system as a valid E-Mail
address to send a password to.

OK, fine. I called the toll-free help #, and spoke with a nice woman. I
explained the problem to her, and she immediately grasped it. She suggested
that I return to the main page and enter a whole new record, using a new
(fake) HRID.

This seemed redundant to me - I already had a valid system record with all
my demographic information, and I wasn't enthused about re-entering all that
information. Couldn't she just reset the password? No, she explained, she
had no access to that, and had no idea who did. The only way for me to get
back in would be to totally re-create my user profile, using a faked HRID.

Risks: B2B e-commerce is great, but systems need to have competent human
backups. The help phone # was basically the printer's sales line.  The staff
there knew about the WWW site, but had little technical information on it.

Too, if HRIDs can be faked, then its child play for anyone to get business
cards showing them to be employed by my company, whether or not they are
actually employees.

Finally, there as only one mechanism for triggering the forgotten password
service, and that was based on E-Mail address. However, the system evidently
keyed its records on HRID, because when I re-created my user profile,
everything was the same as I had previously entered, except for the fake
HRID (when I originally tried to re-create my user profile, I used my actual
HRID, and it told me the record already existed). There's no good reason to
my mind that the system should key off of HRID but use the E-Mail address
for triggering the forgotten password service.
 
In all, I found this printing company's B2B WWW site a good example of how
NOT to implement B2B services.

Dave Bank dirk@NOSPAM.psicorps.org

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

Date: Wed, 14 Jun 2000 16:48:11 -0400
From: Gary McGraw <gem@rstcorp.com>
Subject: JustBeFriends for macro virus control

Reliable Software Technologies has just released a new program
(JustBeFriends) designed to prevent e-mail macro viruses from spreading.  It
can be used along with or instead of the Microsoft supplied e-mail
protection patch.  JustBeFriends works will all versions of Outlook and
Outlook Express, and is substantially simpler than the Microsoft patch.  For
full details, see http://www.rstcorp.com/news/jbf.html.

E-mail viruses spread by exploiting existing mail programs to send
themselves to a large number of new recipients. In addition, many viruses
may also modify or damage the computer on which they are run. While most
home and office computers are not sufficiently secure to make preventing
damage to files on the computer possible, it is possible to make sending
e-mail from scripts much harder. This move limits a particularly nasty way
that viruses propagate. Both Microsoft's security update and JustBeFriends
succeed in disabling script-based e-mail.

Microsoft's approach works by internally controlling access to a large
number of subsections of Outlook that can be used to gather e-mail addresses
or send e-mails. Unfortunately, in order to prevent future e-mail viruses,
this list of protected objects needs to be exhaustive. E-mail addresses may
still be exposed if they appear in signatures, message bodies, or other
documents. Future methods for exploiting flaws in Outlook to send e-mails
are likely to be found.

JustBeFriends works by controlling the ability of other applications to
access Outlook or Outlook Express. In the event that the access comes from a
script being run from the desktop or from an attachment, the access is
denied. Otherwise, the user is asked to confirm that the application should
be allowed access to Outlook.

JustBeFriends was developed primarily by Tim Hollebeek, Research Associate
at RST Labs. It makes use of advanced technology developed in part under a
DARPA grant titled "Sandboxing Mobile Code Execution Environments". 

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

Date: Fri, 9 Jun 2000 10:12:54 +0100 (BST)
From: Martin.Ward@durham.ac.uk (Martin Ward)
Subject: Re: Bloat Dissections II (Downes, RISKS-20.91)

Someone at out company wrote a short MS Word document (just a handful of
pages) and e-mailed it, as an attachment, to several people in the
company. The document contained several screenshots.  For some reason, MS
Word stores these images in a *completely* uncompressed format. The result
was a 20Mb document which expanded into a 26Mb e-mail message. This message
was too big to be delivered via modem: the pop3 server kept timing out after
about 20Mb worth.

The kicker is that when I finally downloaded the document via a fast
internet connection and ran gzip on it, it compressed down to just 180Kb!
That's a factor of over 100 to 1 compression from just a few seconds of
effort.

With just a few mouse clicks you can bloat your word document to
multi-megabyte network-spamming size and send it to hundreds of mail
boxes. There are any number of lossless image compression formats, plus any
number of general purpose file compression algorithms, any of which would
make a huge improvement. Even the dumbest run length encoding would make a
big difference on a screenshot.  But Microsoft just doesn't care:

(*) Their image file format doesn't compress images;
(*) MS Word doesn't compress files when it stores them;
(*) E-Mail attachments are not compressed.

As RA Downes says:
> It's professional pride on the one side -- and "who cares?" on the other.

Martin.Ward@durham.ac.uk http://www.dur.ac.uk/~dcs0mpw/
Maintainer of the G.K.Chesterton web site: http://www.dur.ac.uk/~dcs0mpw/gkc/

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

Date: Fri, 9 Jun 2000 20:25:22 -0400 (EDT)
From: Graham Mainwaring <graham@mhn.org>
Subject: Re: Bloat Dissections II (Downes, RISKS-20.91)

While I generally agree with Mr. Downes that software bloat is undesirable,
unnecessary, and often quite easily prevented, I take exception to the
manner in which Mr. Downes and Bloatbusters make their case.

For example, they do not use the same standards when measuring the size of
their own code as they do when measuring the size of 'bloat'
examples. Bloatbusters claims their replacement for Solar Winds' DNS
resolver is only 7k. In fact it also depends on MSVCRT.DLL, the Visual C++
standard library, which is 288k. It would be reasonable to claim that since
this file comes with Windows, it shouldn't be counted against Bloatbusters'
totals - yet they count this file in totals where their agenda calls for a
higher figure. The case against bloat is clear enough without resorting to
this sort of accounting trickery.

I would also like to contest Bloatbusters' claims regarding the Delphi
programming language. It is certainly true that if you naively load Delphi
and create a project with a single form, you will link in a lot of stuff you
don't need. The same is true of an MFC application in Visual C++. The
conclusion to reach is not that Delphi can only produce bloated
applications, but that bloat reduction requires skill on the part of the
programmer.

Bloatbusters at one point refers to the size of a minimal windows GUI
application, capable of displaying a window, closing itself, and nothing
else. I have coded this application in both Visual C++ 6.0 and Delphi 5.0.
In C++ it is 63 lines of code and a 24k EXE. In Delphi it is 59 lines of
code and a 17k EXE. (Source available on request via e-mail.) These
applications are very much identical line-by-line, do not depend on any
external libraries or DLLs other than Windows itself, and behave
identically. I believe these are the smallest possible self-contained
Windows EXEs sizes for each environment. If, as Bloatbusters' site claims,
"Delphi means BLOAT," then why is the Delphi app smaller?

However, having gone to the trouble of writing these applications, it occurs
to me that I am departing wildly from my normal style of programming in both
Delphi and C++. I have not actually coded a message loop in several years,
and would not expect to do so outside this contrived example. If I were
writing a GUI application of any complexity, it would be frightful to
consider writing it with nothing but C message loops and massive switch
statements. Not only would the initial development require much more
programmer effort, it would be far more difficult to maintain once
complete. Windows applications had to be written this way in 1988 because
there were no better tools. Today, I would consider it unforgivably
irresponsible to code this way.

Good management of software development risks is a very hard thing to do,
and certainly, excessive code bloat represents a real risk to eventual
maintainability and supportability. But it is not the only one or the most
serious one. Writing code in such a way that mid-level programmers inspect
and understand it in relatively short time periods is at least equally
risk-preventive. Sacrificing every other consideration for the pursuit of
small EXE sizes is really not the right thing to do.

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

Date: Sun, 11 Jun 2000 23:41:18 -0400
From: Edward Reid <edward@paleo.org>
Subject: Re: Bloat Dissections II (Downes, RISKS-20.91)

> Things can be done right from the beginning, or even if not, corrected in
> a negligible envelope of time.

On the latter, minor point I disagree. It is *not* always trivial to
eliminate bloat once the program is written. Many times it is, but sometimes
it requires serious reworking of the program.

Done properly to begin with, it's not only as easy to deflate as to bloat,
in general it's easier just because it involves thinking ahead about the
design. It's a good example of the old maxim "if you don't have time to do
it right, where are you going to find the time to do it over?".

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

Date: Fri, 16 Jun 2000 02:21:44 -0500
From: "Nevin :-\] Liber" <nevin@enteract.com>
Subject: Re: Bloat Dissections II (Downes, RISKS 20.91)

> This is a savings of 83,968 bytes, or well over half the original image
> size. This is a new image only 45% the size of the original. And in less
> than ten minutes. I got 83,968 bytes of bloat off my disk that fast.

However, this ten minutes didn't include any regression testing so you could
have at least some confidence that your refactoring of the code didn't break
anything, let alone enough confidence to ship it knowing that there is 100%
backwards compatibility (and willing to put your reputation and/or money on
that guarantee).

The real cost isn't in the 10-minute fix; it's in verifying the 10-minute
fix.  That is the RISK.

> If this doesn't prove that bloat is inexcusable, I'll just have to send
> more examples.

Like everything else in software, it is a tradeoff.

Let us look at the cost of hard drive space.  A 20G drive can be gotten for
$170.  That is $8.5/GB which is less than 1 cent/MB.

Your fix is worth, at best, a fraction of a cent to your customer.  If this
causes you to slip shipping by even one day, you've made a bad decision to
work on it.

Now there are places where code space isn't so cheap and this is worth
doing.  I've worked on projects in the past where reducing the number of
floppies our product had to ship on was a significant cost savings.  OEMs
might want a smaller package to duplicate as they can increase the number of
systems they can build per hour.  Many embedded devices have a limited
amount of ROM and RAM, and it is worth the effort to tighten the code up to
get it to fit.

> It's professional pride on the one side -- and "who cares?" on the other.

That isn't it.  It is about knowing when it is worth taking the RISK and
spending the time to reimplement working code and retest it.  All the best
software engineers that I know take their professional pride in making that
decision correctly as well as when they reduce the bloat.

 Nevin ":-)" Liber  <mailto:nevin@enteract.com>  (773) 961-1620

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

Date: Sun, 11 Jun 2000 16:59:56 -0400
From: "Jay R. Ashworth" <jra@baylink.com>
Subject: Re: Indian Railway Fiber (Jones, RISKS-20.91)

> Southern Pacific Railroad INternal Telecommunication

I thought the N expanded to 'Network', myself, but...

Gee.  Isn't anyone catching the *real* risk?  Or do I just hang out on NANOG
too much?

The problem with putting high-cap fiber next to railroad tracks is that the
trains tend to fall off of them occasionally... and there's no good place to
put the backup fiber, precisely because of the reasons you wanted to put the
fiber by the tracks in the first place.

RISKS of assuming you've discerned all the RISKS?

Jay R. Ashworth, The Suncoast Freenet, Tampa Bay, Florida +1 727 804 5015
jra@baylink.com  http://baylink.pitas.com                

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

Date: Thu, 15 Jun 2000 16:03:51 -0700
From: Chuck Charlton <chuckc@stanford.edu>
Subject: Re: Indian Railway Fiber (Jones, RISKS-20.91)

Sprint did indeed start out as the telecommunications division of the
Southern Pacific Railroad, As Douglas Jones mentions, but with an important
difference.  By the time SP began to resell some of its capacity to other
businesses, they were not selling wires or access to wires.  They were
selling capacity on Supergroup 2 in the microwave system that paralleled the
tracks.

The acronym is suspect, also.  When SP spun off the communications company,
its official name was SP Communications for the first few years.  It was
only later that they changed the name to Sprint.

Chuck Charlton, Manager, Facilities Operations Work Support Center
650.723.5225 voice  650.723.0823 fax  650.867.8057 cell/pager

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

Date: Fri, 9 Jun 2000 10:26:59 +0100 (BST)
From: Bart van Leeuwen <bart@ixori.demon.nl>
Subject: Indian railroad communications

The Dutch railways have been participating in a Dutch telecommunications
company, and have been doing this for quite a few years already.  It is very
interesting to see this happen in India of course, but it is far from a new
concept, and the pilot is likely aimed at local implications of this, and
not at the technology as such.

Bart van Leeuwen  bart@ixori.demon.nl  -  http://www.ixori.demon.nl/

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

Date: Mon, 12 Jun 2000 14:03:25 +1200
From: "James Ryan \(Private E-Mail\)" <james_ryan@attglobal.net>
Subject: Re: India piggybacking on railway controls (Bakowski, RISKS-20.90)

Indeed, Japan Telecom did the same thing with Japan Railways capacity in the
early 90s...

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

Date: Fri, 16 Jun 2000 08:09:20 -0800
From: Rob Slade <rslade@sprint.ca>
Subject: REVIEW: "Information Hiding Techniques for Steganography and
      Digital Watermarking

BKIHTSDW.RVW   20000504

"Information Hiding Techniques for Steganography and Digital
Watermarking", Katzenbeisser/Petitcolas, 2000, 1-58053-035-4
%E   Stefan Katzenbeisser
%E   Fabien A. P. Petitcolas
%C   685 Canton St., Norwood, MA   02062
%D   2000
%G   1-58053-035-4
%I   Artech House/Horizon
%O   U$69.00 800-225-9977 fax: 617-769-6334 artech@artech-house.com
%P   220 p.
%T   "Information Hiding Techniques for Steganography and Digital
      Watermarking"

Steganography can be used for sending encrypted messages, but the primary
emphasis in this volume is in the use of techniques for detecting forgery,
theft of intellectual property, and modification of a digital object.
Digital watermarking is probably best known to the general public from the
transparent logos used on cable channels to try and prevent, or at least
identify, illegally taped copies of programs.  Chapter one gives us a
definition of steganography and digital watermarking, some history, and some
editorial on the counterintuitive links between the technical partnership of
encryption and digital signatures.

Part one outlines secret writing and steganography, the latter being the art
of hiding a message in plain sight.  Chapter two deals with the principles
of steganography.  Unfortunately, while the general principles are
explained, the details require some number theory.  The formal definitions
that are used, for example, refer to axioms that are not presented in the
text.  Most of the techniques explained in chapter three are graphical, but
a few are applicable to text.  Steganalysis is, of course, dependent upon
the techniques being used, and various products are analyzed in chapter
four.

Part two looks at watermarking and copyright.  Chapter five examines
watermarking principles and evaluation criteria.  Techniques are described
in chapter six.  Chapter seven deals with the reasons that copyright marking
technologies require highly robust algorithms and systems.  Chapter eight
reviews digital fingerprinting, for individual identification.  Legal
considerations are discussed in chapter nine, in regard to watermarking, the
Internet, and copyright.

A common problem in many collective works is that the various submissions
have differing styles and tend to overlap and repeat topics.  While there
are certainly stylistic differences between the chapters in this book, the
authors/editors have kept repetition and duplication to a minimum.

copyright Robert M. Slade, 2000   BKIHTSDW.RVW   20000504
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

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

Date: Fri, 16 Jun 2000 16:31:16 +0200
From: deb@zurich.ibm.com (Herve Debar)
Subject: Call For Participation - RAID 2000
              
Third International Workshop on the Recent Advances in Intrusion Detection 
October 2-4, 2000, Toulouse, France, in conjunction with ESORICS 2000

This workshop, the third in an ongoing annual series, will bring together
leading figures from academia, government, and industry to discuss
state-of-the-art intrusion detection technologies and issues from the
research and commercial perspectives.

RAID 2000 is being locally organized by ONERA in Toulouse, France, in
conjunction with ESORICS 2000 (http://www.cert.fr/esorics2000/).  The
program committee invites submission of extended abstracts, to be made
available on the RAID website.  

Registration is available online at
http://www.raid-symposium.org/raid2000/registration.html. A
preliminary program is available at
http://www.raid-symposium.org/raid2000/program.html.

  [This is abridged for RISKS, but it did not mention that  
  the advanced registration deadline is 16 Aug 2000.  PGN]

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

Date: 13 Dec 1999 (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]
 http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
 http://the.wiretapped.net/security/textfiles/risks-digest/ .
==> PostScript copy of PGN's comprehensive historical summary of one liners:
    illustrative.PS at ftp.sri.com/risks .

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

End of RISKS-FORUM Digest 20.92
************************


[: hacktivism :]
[: for unsubscribe instructions or list info consult the list FAQ :]
[: http://hacktivism.tao.ca/ :]