Risks Digest 21.06

[risks@csl.sri.com]

[: hacktivism :]

RISKS-LIST: Risks-Forum Digest  Monday 25 September 2000  Volume 21 : Issue 06

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

  Contents:
Australian online voting scores: no oohs 'n Oz? (Garry Allen)
Youthful toothful (PGN)
Concorde Problem Visibility (Peter B. Ladkin)
Re: Concorde crash report (Zygo Blaxell)
Ostrich Farming? (Pat St-Arnaud)
Pentagon security gate goof, again (PGN)
U.Wisconsin alters photo to add "diversity" to student body (PGN)
Why software fails (Mike Lewis)
Filtering, censorship, silence: Who owns the language? (Richard Schroeppel)
Re: Decimalization and Ford Stock Splits (Timothy Prodin)
Re: Identity theft (Martin Minow)
Re: Qualcomm CEO's laptop vanishes (Camillo Sars)
Re: Risks of using HTML Mail and HTTP proxy "censorware" together (J.D. Abolins)
Artificial Intelligence strikes again (Rodger Whitlock)
SBC Calling Card PIN (Conrad Heiney)
Abridged info on RISKS (comp.risks)

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

Date: Thu, 21 Sep 2000 14:49:59 +1000
From: Garry Allen <GAllen@dspmedia.com.au>
Subject: Australian online voting scores: no oohs 'n Oz?

The Australian Broadcasting Corporation ran a television show recently
called Race Around Oz. It was a competitive documentary series where 6
competitors had to present a five minute documentary every two weeks. These
were then judged by industry representatives as a story with the overall
winner receiving a digital video camera and a two week stint as a producer
on one of the ABC documentary shows.

There was also an audience winner. Viewers were invited to vote either by
toll number or by an online voting form. The audience winner also received
a video camera and a two week stint. Apparently there was nothing to stop
someone voting early and voting often. The ABC also has a show looking at
the media, Mediawatch. For some reason, the audience voting patterns were
brought to the show's attention. The winner of the audience vote was 5
times as popular as any of the other contestants in the online votes
despite her documentaries being hated by the judges. In fact, according to
the program transcript, they asked the School of mathematics at the
Swinburne University of technology to investigate. they found that the
difference in online voting patterns being solely due to chance to be
statistically significant at the 1% level, ie highly unlikely. Mediawatch
did some research and has raised some questions about the results. 
http://www.abc.net.au/mediawatch/transcripts/s175489.htm
http://www.abc.net.au/mediawatch/transcripts/s181183.htm

The comments quoted below are pertinent.

>From the first show:

> ABC Online say they're working on the problem but warn: The ABC is aware
> that online voting does have limitations ... such voting should never be
> construed as an accurate representation of an entire audience or
> population's views.  (ABC Online e-mail to Media Watch 8/9/00)

> Paul Barry: And that's a warning that Race Around Oz might take on board
> before they rely on their online votes again.

> As Jane put it: Thanks for coming with us for what has been the ride of a
> lifetime for everyone involved with the program ...  (ABCTV Race Around Oz
> final episode)

> Paul Barry: Or maybe - thanks for letting us take you all for the ride of
> a lifetime.

And from the second show:

> So what will the ABC be doing about this?  The ABC will, of course, look
> closely at the allegations and at all documentation before deciding on a
> course of action.  (Race Around Oz fax to Media Watch 18 Sep 2000)

> Paul Barry: Yes. And when they've worked out what to do about Stacey,
> they'd better take a closer look at what to do about their own reliance on
> a voting system that is so easily abused.

It is hard to believe that an online voting system could ever be manipulated
like this, particularly not one associated with a reputable media
organisation such as the ABC. (:-)) And no doubt the e-mails purporting to be
from Stacey could have been forged. But somehow I doubt that the organisers
of Race Around Oz will use a voting system like this again.

Garry Allen

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

Date: Wed, 20 Sep 2000 19:52:21 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Youthful toothful

On 20 Sep 2000, Jonathan Lebed, 15, settled a federal civil-fraud process,
agreeing to pay $272,826 for perpetuating bogus information on the Internet
that led to the stock fluctuations in Just Toys Inc. and The Havana Republic
and profiting therefrom.

On 21 Sep 2000, Jonathan James (cOmrade), 16, pleaded guilty to two counts
of juvenile delinquency and was sentenced to six months detention for having
penetrated DoD and NASA computer systems, intercepting 3,300 e-mail messages
and stealing passwords.  (He was 15 at the time.  If he had been an adult,
he reportedly would have received a sentence of at least 10 years.)

On 21 Sep 2000, Jason Diekman, 20, was charged with cracking into university
(including Harvard, Stanford, and Cornell) and NASA computer systems, and
stealing hundreds of credit-card numbers to buy thousands of dollars of
clothing, stereo equipment, and computer hardware.

(Also, the Emulex stock manipulation case was noted in RISKS-21.02.)

  [Sources include an article by David Stout, *The New York Times*,
  23 Sep 2000, National Edition A9, plus AP item 22 Sep 2000.]

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

Date: Thu, 21 Sep 2000 11:14:39 +0200
From: "Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>
Subject: Concorde Problem Visibility (Kaiser, RISKS-21.05)

> Undoubtedly the passengers on the left side of the plane could see
> the flames and the disintegration of the left wing.

Let me doubt it. The fuel leak came from under the wing approximately
adjacent to the main gear and streamed backwards, burning in the
process. The Concorde wing is a delta (unique among in-service passenger
transports) and extends some meters rear of the last passenger cabin
window. Airflow under the wing is rearward during takeoff, flight and
landing; in particular it may be seen on the still pictures and video how
the burning fuel streamed.

As far as I know, the left wing did not "disintegrate" until impact (but that
depends on what "disintegrate" means). 

These observations, however, go to substantiate Kaiser's point that the
evidence of the problem was sparse to those on board.

Kaiser recounts the retrieval of evidence from various recorders. The issues
concerning installation and use of recorders are broadly thus.  Recorders
are fallible devices, depending on what happens in the accident.  More
recorders mean more complex devices to go wrong, potentially hindering
normal operations (fully working recorders are required for any normal
operations); and more complex devices to attempt to analyse in a
partly-destroyed state; finally, more discrepancies to resolve if their
readings don't all cohere. External video recorders have been proposed,
mainly to help resolve gear problems and other problems the pilots can't see
(1979 DC-10 in Chicago; Concorde). Cockpit video recorders (which I call
CVidR) have been proposed, and recommended by certain safety watchdog
authorities. While they may have some benefits in identifying what was
actually on frangible CRT displays at the time of an incident (2000 Crossair
crash in Zuerich), pilots are concerned that the presence of CVidR may
hinder their competent conduct of the flight in normal operations as well as
in emergency situations; not only that, but that CVidR evidence could
broaden the possibilities for civil litigation in directions detrimental to
air travel as a whole.

Peter Ladkin

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

Date: 21 Sep 2000 19:50:53 -0400
From: uryse0d5@umail.furryterror.org (Zygo Blaxell)
Subject: Re: Concorde crash report (Kaiser, RISKS-21.05)

> No one had ever before tried to recover one of these memory units live
> from a damaged recorder ... they managed to move it intact and operational
> to a working card.

I hope that "no one had ever before" refers to retrieving data from that
specific type of memory unit or from that specific type of recorder, because
anything less specific is inaccurate.  ;-) I know of at least two previous
incidents of flight data extracted from memory devices on crashed aircraft.

One company was able to extract engine data from a memory device on the
same aircraft, but unfortunately the only press copy available to the
public I can find for that device isn't very specific:

	http://www.airdisaster.com/news/0500/25/news3.html

In the other case the circuitry around the memory was damaged, and it
was necessary to repair this damage (microsurgery with an FIB) without
disturbing the contents of the memory:

	http://www.chipworks.com/News/11Swissair.htm

> So the flight data recorder didn't survive the crash unharmed, but a
> perfect recording was recovered from the volatile digital medium within an
> unprotected, vibration-sensitive, optional recorder.

It just goes to show that more is usually better when it comes to
redundant storage devices on mission-critical systems.  ;-)

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

Date: Thu, 21 Sep 2000 14:20:42 -0400
From: Pat <pat@machome.com>
Subject: Ostrich Farming?

I would find it funny if it was not so scary: I thought I was doing the
responsible thing when I sent a special notification to our subscribers, an
article and link to a recent CERT advisory bulletin regarding a potential
upcoming DDoS, and what to look for in a server audit.  Albeit I knew there
was many readers to whom this would not be of any use, we also have a lot of
system managers on board. I felt ready and able to answer a predicted flood
of questions this would generate. I was actually glad of the opportunity to
sensitize some people to the issue of network security.

What I DIDN'T EXPECT were the numerous flames that would follow!

I was called by all possible names, accused of sending SPAM or disseminating
rumors.

Six months have elapsed since last February's massive distributed
denial-of-service attacks, yet the following article reports that there are
still over 100,000 vulnerable computers all around. With billions of dollars
of lost business, one would think people would take the issue more
seriously!

See <http://www.internetnews.com/bus-news/article/0,2171,3_436031,00.html>

Pat St-Arnaud, Editor, MacHome Journal's Hot Tips Weekly  pat@machome.com
www.machome.com

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

Date: Sun, 24 Sep 2000 11:46:52 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Pentagon security gate goof, again

In RISKS-19.97, we reported on a Pentagon security system that injured the
visiting Japanese Defense Minister and five others when a barricade was
raised at the wrong time, in September 1998.  That accident was attributed
to a faulty sensor, and resulted in the installation of a new barricade
control system.

On 5 Aug 2000, the same barricade sprang up under the German Defense
Minister, who -- arriving for a Pentagon honors ceremony -- was injured and
briefly hospitalized, along with the German defense attache' and an American
security aide.  [Source: Reuters item in *The New York Times*, 6 Sep 2000]

  [Conspiracy in Artificial Intelligence?]

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

Date: Wed, 20 Sep 2000 21:08:09 -0700 (PDT)
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: U.Wisconsin alters photo to add "diversity" to student body

The University of Wisconsin has owned up to altering a 1993 photo of a crowd
of white football fans, inserting the face of a 1994 black senior in an
effort to have their brochure illustrate the diversity of the student body.
[Digital editing capabilities of course make such manipulations ever easier,
as we have noted here many times.]  (For old-time programmers, this might
make the fight song "On Wisconsin" be interpreted as a PL/I ON-condition.)
[Source: AP item, *Palo Alto Daily News*, 21 Sep 2000.  See also
http://www.cnn.com/2000/US/09/20/photo.fix.ap/index.html.]

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

Date: Tuesday, September 19, 2000 6:15 PM
From: Mike Lewis <mglewis@uswest.net>
Subject: Why software fails

As is well known, entropy is a measure of the extent to which energy can be
lost in statistical systems.  It appears in many equations, particularly two
 
  G = U - T * S, a thermodynamic equation, and
 
  S = - k * log (p), the equation used to describe
                     the entropy of information, that is, of files.
 
In these, S is the entropy, G is the Gibbs Free Energy, T is temperature,
and U is internal energy; k is Boltzmann's constant and p is the
probability.
 
In systems, the semantic and philosophical and epistemological boundaries
two seemingly different forms of entropy inevitably become uncertain, they
overlap, and the difference gradually becomes degenerate.  That's when much
software fails or becomes obsolete.
 
Software is very complex systems and it can readily be demonstrated that a
well written, strong program competing for control of hardware against a
badly written program can usually get control of the machine.  This happens
all the time as different software designers write their very best code to
get control of the processor as quickly as possible in the face of competing
software from other manufacturers.  In short, software is vulnerable to
statistical failures as well as to outright bugs or errors in coding, bad
logic, etc.  This problem is not very much discussed yet, but one supposes
it will be in time.
 
An example might be a financial program.  Ostensibly it has nothing
explicitly related to thermodynamics, but the dimension of entropy appears
both in software and in thermodynamics which occurs in winter in heating a
house and in summer, cooling it.  The financial program is required to have
a sensible relation to income and expense, while the flow of enthalpy into
and out from the house reverses direction each winter and summer.  I have
thought for a long time, after first seeing the connection, for a good
example of a case in which we do not yet define how to predict just where
the system will fail, and this is about the best I can propose.
 
I think that software's statistical entropy tends to drift around in the
environment's thermodynamic entropy and this is one of the reasons why some
failures are not yet completely understood--the entropy dimension is not
taken explicitly into account in designing systems, except in the solid
state quantum mechanics of the CPU and other chips in the machine.
 
Solutions to this problem will require the assumption, in early planning of
the system, that eventually the software file entropy, the electron entropy
of the silicon, and the environment's thermodynamic and other statistical
entropy will always inevitably become indistinct, and then plan the system
knowing they cannot be held absolutely distinct from the outset.
 
It should be noted that the word "environment" is extremely general, and
includes that of the climate, as well as of the surroundings of the planet.
Also, the time scale is very general, ranging from the geological time scale
of the evolution of life, to the very short durations of time found in
computers.  This is because thermodynamic spectra, for instance contain and
are sensitive to energy-stable terms, which do not vary in time where they
are involved with immediate electronic transitions in atoms and molecules.
 
Interesting speculations may be found on, for instance, the burning of
fossil fuels to put carbon back into circulation, because early life
forms--mainly plants--from which these deposits were formed, were apparently
not able to measure or control the dimension of entropy.  Are we
recirculating all that carbon now because we can deal now with entropy?
That is, though, beyond the scope of my intention here.
  
Mike Lewis <mglewis@uswest.net>

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

Date: Thu, 21 Sep 2000 09:16:31 -0700 (MST)
From: Richard Schroeppel <rcs@baskerville.CS.Arizona.EDU>
Subject: Filtering, censorship, silence: Who owns the language?

>  Subject: OPEC site hacked
>  ...
>  when I say to you guys to get your collective a**es in gear with the crude
>  ...
>  [http://dailynews.yahoo.com/h/nm/20000913/od/website_dc_1.html, PGN-ed
>  with ** filtering]

Peter, does this mean that you've decided to accommodate to filtering
software as the "lesser evil"?  [See NOTE]  I think this issue deserves more
discussion with your audience.  We probably won't be talking about b****t
cancer, but we've already seen too many amusing examples of filters gone
am*k.

What are the issues when persons impose communications restrictions by
threatening to cutoff communications (or doing it) that don't adhere to
policy?  Typically the person defining the restrictions is inaccessible to
reason, being buried within a large impersonal organization.  Often the
restrictions are a trade secret.  The rejected mail gives no particular
notice to either the intended recipient or the sender -- the discard is
silent.

I operate a couple of "ascii text only, please" mailing lists, but it's a
struggle to maintain what's become a minority format.

Most of the NIST AES documents are in PDF-only, and not readable by a
text-based terminal.  (From a standards organization!)  The IRS tax forms
and instructions aren't available as text.  The instructions should be
grep-able, but aren't.  And so on.

This seems like a losing battle to me, but I still think a general
discussion is long overdue of the consequences that follow from "I'll only
communicate in my special language."  I've always assumed that the pressure
was toward a common language, but the business interests of Microsoft,
Adobe, IBM &c seem to operate in the other direction.

We might require by law that govt stuff be available as text
(where possible), but that's only part of the larger issue:
"Who controls the terms of communication?"

Rich Schroeppel   rcs@cs.arizona.edu

  [NOTE: Actually, no.  In this case there is no lesser of weevils.
  Sometimes I get many filtering bounces because I have let challenging
  words go through.  But I have also been assiduously informing RISKS
  recipients that their filtering is stupidly overaggressive in response to
  all of the bounces I receive each time I send out an issue.  PGN]

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

Date: Thu, 21 Sep 2000 11:28:58 -0400
From: "Prodin, Timothy (T.R.)" <tprodin@ford.com>
Subject: Re: Decimalization and Ford Stock Splits (Carroll, RISKS-21.05)

On 7 Aug 2000, Ford completed its Value Enhancement Plan, a somewhat
complicated stock transaction where Ford created a new company (Ford Value
Company) and issued a new stock.  Ford Stock holders of record on July 27th
had the option of taking the new common or Class B stock plus 1) $20 per
share, 2) a fraction of the new common stock that would be the equivalent of
$20, or 3) a fraction of cash and fractional shares that would maintain
their percentage ownership of all outstanding shares constant.

For the last two options; the fraction of cash and fraction of shares
depended on the total number of outstanding shares of the old company.

At the end of the exchange and disbursement; the new company transformed
back into the old company; and trades on the NYSE as F.

The final numbers wound up such that if you took the full fractional new
share with your matching full share; you received an additional 0.748
additional share.

Tim Prodin

  [Also commented upon by various other readers.  Many 
  thanks to you all for helping correct the record.  PGN]

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

Date: Wed, 20 Sep 2000 20:08:29 -0700
From: Martin Minow <minow@pobox.com>
Subject: Re: Identity theft (Ellison, RISKS-21.05)

> Now -- how do we get consumer protection laws that make it clear that a
> consumer is not liable for any debts incurred by someone claiming to be
> him/her ...

Having recently been on the receiving end of identity theft, I'm a bit more
optimistic than Carl. I solved my problem by reading the back page of the
credit report, where it provided addresses of the federal agencies that
regulate collection bureaus, banks, and similar organizations. Letters to
the agencies resulted in one "opening a case" and, eventually, a letter of
apology from the bank in question (who hadn't answered my previous
requests/complaints).  I used an account record book -- a bound notebook
with numbered pages -- that had dated notes of every interaction I had with
the banks and credit card agencies, interspersed with software notes,
interesting URL's, telemarketing caller numbers, and other scribbles. This
let me document my complaints with the specific dates and times that I
attempted to resolve the problem.

Martin Minow minow@pobox.com

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

Date: 21 Sep 2000 11:43:47 +0300
From: Camillo.Sars@F-Secure.com
Subject: Re: Qualcomm CEO's laptop vanishes (Lesher, RISKS-21.05)

As I have some experience in the field, having lead the development of one
of the tools David is referring to, I'd like to point out a few other risks
associated with this issue.

Using real (and real-time!) encryption on data files does help against the
threat of unauthorized information disclosure.  Which is good.  But, as
usual, increased security in one field can lead to increased risk in
another.  Encrypted files are subject to several threats.

The primary risk is threats against integrity.  Tweak a bit in an encrypted
file, and at least an entire block is corrupted *).  Usually the entire file
can be considered lost, and a backup needs to be restored.  I will not go
into the discussion about how to properly encrypt backups here.

Another threat is the risk caused by loss of the encryption key.  Strong
encryption has the nice property that nobody can get the data without the
correct key.  Strong encryption has the less nice property that not even the
owner of the information can get the data without the correct key.  I have
seen this happen.  It is not a nice situation.

> It's also a message to crypto companies. Create real tools for this task,
> ones that even C[E,F,T]O's can grok how to use {1}. A recent USENIX study
> reported that a large percentage of users failed to use PGP correctly.

I have come to the conclusion that persons that are not trained in security
must rarely or never be called upon to make security-related decisions.  As
Ross Anderson put it in his paper "Why Cryptosystems Fail": ..."most
security failures are due to implementation and management errors."  I have
taken to interpreting this in a very broad sense.

> {1: Getting them to follow practices is the 2nd half of the problem; as the
> Deutch case demonstrates....}

Thus, I second Ross Anderson's view that a paradigm shift is required.
Let's not only make systems that are easier to use correctly.  Let's make
systems that are difficult to use incorrectly.

Camillo Sars

*) Tweaking a bit in an encrypted file should invalidate data.  If it
does not, the system is vulnerable to replacement attacks.
E.g. copying the encrypted salary of the CEO and pasting it over the
encrypted salary on your own paycheck.  Which would be nice.

Camillo Sars <Camillo.Sars@F-Secure.com>       http://www.iki.fi/ged/
Researcher, F-Secure Corporation               http://www.F-Secure.com

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

Date: Thu, 21 Sep 2000 11:02:37 -0400 (EDT)
From: "J.D. Abolins" <jda-ir@pluto.njcc.com>
Subject: Re: Risks of using HTML Mail and HTTP proxy "censorware" together

This risk underscores monitoring tools' user to realize that their tools
have limitations. The assumption may be that a "hit"on a forbidden site
means that a particular user willfully went there. Wrong, as Dan Birchall's
posting shows.

I have been testing the recently reported MS Office document Web bugs to see
if they can be used to rack up hits on workplace HTTP "censorware."  The
tests aren't finished but here's the concept. Insert spacer gif URLs from a
banned site in an "appropriate for the workplace" Word document, Excel
spreadsheet, or PowerPoint presentation. When the document is opened, it
should attempt to pull the graphic form the "banned" Web site and, thus,
score hits on the "censorware." A document could be loaded with multiple
bugs, each from a different banned site.

It is also possible to resize a URL-based image so it is hard to see. So it
might not be only transparent gifs that could be (mis)used in this manner.

People investigating hits on banned sites should look for other evidence
besides the "censorware" logs and not assume automatic guilt.

Beside nearly invisible graphics in the HTML e-mail, there is the risk of
spoofed links. The e-mail text says the link goes to one place while the
underlying HTML gives a different HREF. This has been reported elsewhere. A
variant can be to use the file:// type of URL to bring up locally accessible
files. Sometimes this is used as a Web joke where a visitor is convinced
that the Web site can see her C: drive or /etc/passwd file. If the sender of
HTML e-mail has a good idea of the systems used by the recipient, the spoofed
links can be tailored to use the file:// URLs or the res:// URL.

J.D. Abolins, Meyda Online -- Infosec & Privacy Studies http://www.meydabbs.com

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

Date: Sat, 23 Sep 2000 12:33:58 GMT
From: totototo@mail.pacificcoast.net (Rodger Whitlock)
Subject: Artificial Intelligence strikes again

One of our secretaries at work related an interesting tale: she and her
husband went to buy gasoline, using their Visa card at the pump.  It was
rejected. They tried another station. Same thing. They tried to buy flowers
for an aged relative. Same thing.

She phoned the issuer (Canadian Imperial Bank of Commerce - CIBC) and
asked what was going on.

The response was that the computer had detected an "unusual pattern of
purchases" and put a freeze on the card. The unusual pattern was the
use of the card to pay a ferry fare to Vancouver and when Visa phoned
to double check, there was no one home to answer the phone. Naturally:
the whole family was on the ferry!

As this secretary said, what would have happened if the card got frozen
after flying to Europe? Badly thought-out computer wonkism strikes again.

Regular RISKS readers probably recognize the syndrome.

Rodger Whitlock, Victoria, British Columbia, Canada

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

Date: Sat, 23 Sep 2000 14:02:43 -0700
From: "Conrad Heiney" <conrad@fringehead.org>
Subject: SBC Calling Card PIN 

SBC Communications, through my local telephone company (Pacific Bell) has
reissued their telephone "Calling Card" telephone cards. The new cards are
intended to be used worldwide and to replace previous local cards.

The card is marked with the subscriber's name and telephone number. There is
also a Personal Identification Number which is provided separately, the idea
being that both the telephone number and the PIN need to be present for
authentication.

However, there is a space on the card for your PIN, and you are instructed
to immediately write the PIN on this space so you won't forget it.

This contradicts the policy of bank ATM cards and other PIN-based systems,
in which the PIN is intended to be memorized and customers are instructed in
large capital letters not to write the PIN on the card or store it with the
card.

The risks here are twofold:

1) The PIN is useless if the card is lost or stolen
2) Consumers will be confused by contradictory policies from different
   organizations and will likely write their PIN on every card they use.

Two cheers for self-sabotaging authentication systems! 

Conrad Heiney  conrad@fringehead.org  http://fringehead.org/

  [Several other messages relating to credit cards per se are not 
  included here.  PGN]

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

Date: 15 Aug 2000 (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 20" for volume 20]
 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 21.06
************************


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