Risks Digest 22.45

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Weds 1 January 2003  Volume 22 : Issue 45

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

  Contents:
Hard-coded calendar dates (Dave Stringer-Calvert)
Somebody stole backup tapes containing citizen's private information (Ishikawa)
Poor encryption: Transportation Security Administration (M Taylor)
Browser incompatibilities cost business (Geoff Kuenning)
No such thing as "knowing that a check has cleared?" (Daniel P.B. Smith)
Re: O Big Brother, where art thou? (Edward G. Nilges)
Re: Why you should read or should not read... (Fred Cohen)
REVIEW: "Software Engineering", Ian Sommerville (Rob Slade)
REVIEW: "Trusted Computing Platforms", Siani Pearson (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Wed, 01 Jan 2003 12:45:28 -0800
From: Dave Stringer-Calvert <dave_sc () csl sri com>
Subject: Hard-coded calendar dates

The front page of the *Yorkshire Evening Press* Web site
(http://www.thisisyork.co.uk) is declaring today to be 
Wednesday, January 1 2002.  The JavaScript on the page is:

document.write(dayNames[day] + ", " + monthNames[month] + " " + date + ", 2002");

Happy *NEW* year!

Dr Dave Stringer-Calvert, Assistant Director, Computer Science Laboratory
SRI International, Menlo Park CA 94025-3493  1-650-859-3291 

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

Date: Tue, 31 Dec 2002 00:50:48 +0900
From: Ishikawa <ishikawa () yk rim or jp>
Subject: Somebody stole backup tapes containing citizen's private information

I would like to report an incident which made me feel dizzy at this
otherwise tranquil days at the end of the year.

In Japan, a national system to coordinate citizen's private information
stored in government computer is being prepared amid vocal opposition from
various parties.

Basically, a single number, 11 decimal digits number is assigned to each
individual and this will be used as the search key in accessing various data
bases.  (Some kind of mapping table would be prepared by local government
agencies with this nationally unique number to access individual's record in
local government databases .)  There would be a nation-wide network where
the key would be used as the primary key for accessing various databases
scattered across the nation.

The danger for abuse is obvious and the fear is so much that some cities and
jurisdictions decided to challenge the national policy by declaring that
they would not be online with the system, etc. when the final preparation
for the full-scale deployment began this summer.  (The city of Yokohama
where I live decided to allow the citizen to decide if the personal number
assigned to them would be delivered to the prefectural level data center or
not unless sufficient assurance for protection is forthcoming from the
national government.  About 30% of the population asked the number not be
sent, and this popular demand made national newspaper headlines : Yokohama
has about 3 million population and is a big city in Japanese scale of
things.  Obviously the government agency which is pushing the national
policy and the construction of the network has PR problems now.

The risk is now huge since the diet (national parliament) failed to enact a
privacy protection law which should have been prepared along with such a
numbering system.

Anyway, the national government has been trying to assure that the system
would be safe with computer security protection, etc..

However, it has already been criticized for such mundane thing as slow
anti-virus data update which would take place once a few months(!) [makes me
wonder where on earth they have been living in the last few years.], which
the government agency claims is not a serious threat since the network in
question is not directly connected to Internet, etc..  But, of course, some
town offices seem to use the same computer for internal LAN and accessing
the national network in question. (There must be some form of physical
switches in place, but we never know what happens. Murphy's law always
strikes.)

Probably the last straw which might break the pro-numbering support is the
theft of backup magnetic tapes that happened in a town north east of Tokyo.

There, five backup DAT tapes of the town office computer systems containing
privacy data of approximately 9600 were stolen from a parked car of a
computer maintenance service company. The tapes were on the way for off-site
storage, and were in a metalic attache case.  It seems that whoever stole
the case mistook it for one containing money or some other valuables.  (On
the other hand, since the parking lot belongs to the computer maintenance
company, we should not rule out that a serious cracker (or two?) stole the
tapes to gain foothold into the national network.)

The newspaper articles aren't clear what are on the tapes and in what form,
but the city spokesman stated that the data did include the national numbers
for the citizens and privacy data such as address, name, gender, birth date,
qualification status for the various national health insurance plans, and
pensions.  The data is claimed to be in encrypted form (but no detail) and
won't be easy to read according to the statement.  However, given the risks,
the city officials decided to ask the permission of each citizen to change
the numbers assigned to them so that the numbers themselves won't be used
for some malicious tampering in the future.  (The law requires that the
change of numbers needs the consent of the citizen.)

Numbers aside, the rest of the information, if decrypted, would be the
staggering source for privacy theft, etc.

I can't say for sure but some say that backups were made using ARCserver
backup software or something. I have no idea what type of cryptography it
supports, but I surely hope the algorithm is a good one and the key length
is long enough if ARCserver is indeed used for this national network.

The tapes were stolen on 26th, and found scattered on a river bank on 30th.
Three tapes were found outside the opened metallic case.  The lock to the
attache case was forced open.  (So two of the DATs were still missing, it
seems.  Again the newspaper article that I read was not very clear on this
point.)

Using encryption for backup data is a common sense.  But then I have no idea
how the key for the encryption is managed and what type of algorithms are
used in this particular case, and if I were the citizen of the town of
Iwashiro, I would have been disturbed very much.

One thing I don't like about this national network being built is the
apparent lack of security policy.

Since there is no clearly written national security policy, this type of
problems, like the maintenance person leaving the valuable data tape in an
attache case inside a car parked at company parking lot, may happen in the
future.  The way the network is built and the apparent lack of nation-wide
security policy of this network force me to think that information leak
caused by computers that are linked to the network and also have outside
connection inside the town/city office LAN, which in turn, may have
unexpected Internet link via somebody's modem, or even caused by simple
eavesdropping via wireless LAN may happen not in the distant future.

I hate to think that the government has to go through such incidents before
learning the basic of security management.

After writing this, I realize the above may look unbelievable to security
consultants who read Risks today, but is true and is happening now in Japan.

Only in the last few months, some government agencies learned the danger of
wireless LAN: some drive-by inspection caught the contents of the unencrypted
traffic easily.

I hate to think about the mess caused by large-scale identity theft, etc..
This incident of stolen tapes wiped out the last trust I had in this
national numbering system and I am no longer in the mood of festive holiday
season.

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

Date: Tue, 31 Dec 2002 16:07:21 +0000
From: M Taylor <mctaylor () privacy nb ca>
Subject: Poor encryption: Transportation Security Administration

TSA Documents' Protection Easily Circumvented

Several restricted U.S. Transportation Security Administration (TSA)
documents are accessible to anyone with an Internet connection. While
they are password protected within Microsoft Word, once they are
downloaded, they can be attacked with password cracking software at
the user's leisure.
  [Source: reuters 24 Dec 2002, in SANS NewsBites, 30 Dec 2002, Vol 4 no 53]
  http://reuters.com/newsArticle.jhtml?type=internetNews&storyID=1958544

So how risky is it to provide insecure "encryption", that misleads uses into
thinking that their documents are safe? It appears to be RISKy for the user,
to rely on such labelled "features" in the software they choose to use.

M Taylor  http://www.mctaylor.com/

  [Geoff Kuenning noted this quote in the article:
    "We think it's safe," a spokesman said. "From our
    standpoint it's very workable and secure."  
  PGN]

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

Date: Mon, 30 Dec 2002 04:13:25 -0800 (PST)
From: Geoff Kuenning <geoff () cs hmc edu>
Subject: Browser incompatibilities cost business

I have noticed a trend in the past 6 months of increasing numbers of
Web sites that will not work correctly with my browser.  The most
common symptom is a blank page, presumably because some bit of
JavaScript failed to execute the way they assumed it would.  (In one
case, I took the trouble to diagnose the failure and found that a null
URL was expected to load the referring page; replacing it with a
proper URL cured the problem.)

What amazes me is that most of these bugs are caused by unnecessary
use of new (i.e., not widespread) features, and that they cost
companies business.  For example, this evening I tried to buy Kevin
Mitnick's book, as recommended by Don Norman in RISKS.  Try as I
might, I could not get buy.com's site to allow me to enter an updated
credit-card number.  I finally gave up, started the search over, and
purchased the book elsewhere.

One has to wonder how much business has been lost because gadget-loving
programmers are more fascinated with the latest features than with
compatibility.

    Geoff Kuenning   geoff () cs hmc edu   http://www.cs.hmc.edu/~geoff/

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

Date: Mon, 30 Dec 2002 07:05:40 -0500
From: "Daniel P. B. Smith" <dpbsmith () bellatlantic net>
Subject: No such thing as "knowing that a check has cleared?" (Re: RISKS-22.44)

In reference to a Nigerian scam, "Sidney Markowitz" <sidney () sidney com> says
that "It is common for check transactions to be held until the check clears,
to ensure that the check is good. Now we see that the time it takes for a
check to clear is determined by US law that sets a limit on how long a bank
can delay paying for a deposited check. But that limit does not make it any
faster for the bank to really determine if the check is good. The unintended
consequence of the law is that a cleared check may not be a cleared check."

Some years ago I once was in a situation where I wanted to be certain that a
check "was good" and "had cleared."

I had a lengthy discussion with a bank vice-president, and I understood him
to say that the clearinghouse system does not provide any way to ever know
for certain that any particular check has cleared.  If a check FAILS to
clear, everyone finds out about it.  But when a check clears successfully,
there is no traceable information about the transaction.  He said that,
theoretically, there was no way to know that a particular check had cleared.

I was told that it "was safe to ASSUME" that if the check had not bounced
within two weeks, that it "must have cleared," but that there was no
positive guarantee and no way to check the status of any particular check.

Daniel P.B. Smith  dpbsmith () world std com   dpbsmith () alum mit edu

  [Similar comments from Brian Reynolds ("This is not a new scam."), Tony
  Lima, Ron Bean ("Could be a big risk for banks as well, given their
  Clinton-esque definition of the word "cleared").  PGN]
  
------------------------------

Date: 1 Jan 2003 12:33:12 -0800
From: spinoza1111 () yahoo com (Edward G. Nilges)
Subject: Re: O Big Brother, where art thou? (RISKS-22.44)

I would strengthen Dorothy Denning's objections, for they redescribe
terrorist surveillance as a "daunting task."

Unfortunately this shares with the TIA the assumption that the task, of
surveillance, is one that can be solved at all.

The literary critic, and Palestinian moderate activist, Edward Said, has
pointed out that the US State Department tends to hire people with easily
measured skills in development economics to work on Mideast problems.  He
has contrasted this with the older practice of Britain's foreign and
colonial desks, which was to hire literary dons who had specialized in
topics such as Persian poetry.

The most recent example of this mindset was the termination of several
Arabic speakers at the Defense Language Institute because of their sexual
orientation; for there is a linkage between hatred of "soft" skills and
homophobia.

There are drawbacks to both practices, but Said does point to a bias...in
favor of the technological quick fix of which the Total Information
Awareness program is an example.

Furthermore, solid technical arguments lead one to conclude that the TIA
will not work.

First of all, Groove is a commercial software product, and, if my guess
(that the TIA is in part a bit of a bailout for Bush's friends in the IT
industry, suffering as it is in a depression), the design of the TIA will
emphasise commercial and off-the-shelf solutions.

The problem is that this MEANS that the ill-defined "enemy" can acquire the
same software being used to surveille him, run it to detect what it, in
turn, detects, then change his patterns.  In a sense, a Turing machine (the
Groove system running on TIA computers) is examining a social Turing machine
(the bad guys and their copy of Groove) to see whether it will arrive at a
"halt" state (an attack.)

This Turing problem is independent of hardware and software.  We can be
certain that terrorists will no longer try to carry box cutters on board
airplanes and overwhelm the passengers and crew in what seems a
"conventional" hostage situation but what is a suicide attack, for such
behavior will now be coded, by the passengers, as a suicide attack.

Unfortunately, Professor Denning's objection, that it's a "daunting" task,
can be met by the language of go-ahead problem-solving in which the person
who says it's a "daunting" task is placed at a disadvantage, rhetorically.
She makes it sound as if we're not up to it.

Unfortunately, negative results (such as Turing's) stay true and are not
disproved by technical progress, any more than perpetual motion becomes
true.

In algorithmic terms, a "computer" (the US defense establishment) is
examining another "computer" (al-Qaeda) to find its halt state, and, to
complicate matters, the examinee knows of the monitoring.

Even if a data base existed with full optics and sound that replicated ALL
activity in Eurasia alone, any one action could, or might not, be an
encoding of terrorist intelligence and for this reason, interpretation would
become the job of the same people who failed to bring in the "twentieth
highjacker" for questioning.  Our government would have to refute, at the
level of basic science, Alonzo Church's thesis to the effect that all
computers are Turing machines, and it would have to make or buy a Turing+n
system that could defeat other Turing+0 systems.

Nor can our government "scale up" for adding cycles doesn't change the math.
The near-demise of supercomputing as big iron shows us that the bad guys can
use networks in place of centralized big iron.

Of course, this is the point at which truly rational men and women throw
down their gear and advance across wastelands with ancient symbols of peace.
This is the point at which Ronald Reagan, a quite ordinary man, abandoned
the equivalent insanity of Mutual Assured Destruction and went to Reykjavik.

However, what American politician has the courage to solve the Mideast
problem by raising our gasoline taxes, and announcing that the US should be
considered an alternate homeland for Jews worldwide (boy, that was easy)?

The problem is that the United States is engaged (like it or not) in a
dialogue with terrorists.  If like Sharon in Israel and Cheney here, our
statesmen play to the gallery, and "refuse" to "dialog" with "terrorists",
they discover that violence becomes the language of choice.

"Hackerz" already change the spelling of code words faster than they can be
defeated by scanners.  Unless the US develops (at considerable expense) a
proprietary technology-of-surveillance which cannot be reverse engineered,
the TIA is at best a boon doggle and at worst a replacement for a needed
dialog.

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

Date: Mon, 30 Dec 2002 08:23:25 -0800 (PST)
From: Fred Cohen <fc () all net>
Subject: Re: Why you should read or should not read... (Norman, RISKS-22.44)

Why not read the book?
Because the author is a con artist and you are sending him $s?

OK - so Don makes the point that:
        "I'm a student of human psychology...
        I read books by ex-criminals:...
        I learn a lot."

Fair enough.  If you are studying criminal behavior, reading books by
crooks is probably a good idea.  But if you want to know about cons,
far better books are:

        "Flim-Flam" by James Randi
        "Scam School" by Chuck Whitlock
and     "Rip-Off" by Fay Faron

All three are by legitimate researchers who present results taken from
scores to hundreds of incidents and present how and why scams work, the
techniques used, the different plots, and so forth.  They present many
excellent examples of how these sorts of crimes work, how they impact
the victims, the psychology of the criminals, and so forth.

> I learned a lot from ... I was impressed by his approaches. They
> are not as simple and easy to do as a quick reading would make them
> appear. After the fact, everything always looks obvious. But I, for
> example, would find it difficult to even think of the schemes, let alone
> carry them out successfully.

One of the major problems we face in information protection is people who
just don't think cleverly of bad things that could happen.  It might serve
Don well to take an introductory course in the subject matter.  He will
learn a lot more than from a book by a crook and he will be supporting
defenders rather than attackers.

Fred Cohen - http://all.net/ - fc () all net - fc () unhca com
tel/fax: 925-454-0171 Fred Cohen & Associates - University of New Haven 

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

Date: Tue, 24 Dec 2002 08:17:04 -0800
From: Rob Slade <rslade () sprint ca>
Subject: REVIEW: "Software Engineering", Ian Sommerville

BKSFTENG.RVW   20020916

"Software Engineering", Ian Sommerville, 2001, 0-201-39815-X, C$104.95
%A   Ian Sommerville ian () software-engin com
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2001
%G   0-201-39815-X
%I   Addison-Wesley Publishing Co.
%O   C$104.95 416-447-5101 fax: 416-443-0948
%O  http://www.amazon.com/exec/obidos/ASIN/020139815X/robsladesinterne
%P   693 p.
%T   "Software Engineering, Sixth Edition"

Part one is an overview.  Chapter one is an introduction, a FAQ
(Frequently Asked Questions list), definitions, and, interestingly, a
section on ethics.  A broad review of system development concepts
(such as emergent properties) is presented as computer based software
engineering, in chapter two.  Stages in the software development
process, none detailed, are listed in chapter three.  Project
management is discussed in chapter four.

Part two looks at software requirements.  Chapter five examines
different types of requirements.  Requirements engineering is software
engineering in miniature, as chapter six points out.  There is a heavy
emphasis on the Universal Modeling Language (UML) in chapter seven's
explanation of system models.  The benefits and dangers of software
prototyping are examined in chapter eight.  Chapter nine points out
that formal specification does require special training on the part of
users, but can identify problems in requirements specifications. 
(More extensive examples would be helpful in making this point more
convincing.)

Part three reviews design, and the chapters are mostly divided by
system type.  Chapter ten explains architectural design, and reviews
tools and models.  (Security, and other concerns, are addressed
throughout the book: an example in this chapter points out that
interrupt driven architectures are complex and difficult to validate.) 
Distributed systems architecture itself gets oddly short shrift in
chapter eleven, which concentrates on client/server and CORBA (Common
Object Request Broker Architecture).  Object-oriented design is shown
to be very much like modular design in chapter twelve.  (The stated
objective of the text is to introduce UML, but the explanations are
not very clear.)  Chapter thirteen looks at real-time software design
but does not seem to be as complete as other topics.  Design with code
reuse is a good overview, but chapter fourteen starts out with the
statement that electrical and mechanical engineers rely on component
reuse, ignoring the lack of a broad range of standard components in
the software environment.  There are good, basic suggestions for user
interface design, in chapter fifteen, although the discussion is
limited.  For example, the recommended principles suggest confirmation
of destructive actions, but don't note the fact that even such
confirmations become automatic over time, and therefore are not
particularly useful.

Part four deals with critical systems.  Chapter sixteen looks at
dependability in terms of availability, reliability, safety, and
security.  Critical systems specification, in chapter seventeen,
examines dependability (and failure) metrics.  Risk analysis is
discussed, but not in the usual combination of probability and
severity.  Critical systems development is examined both in terms of
fault avoidance and fault tolerance in chapter eighteen.

Part five covers verification and validation.  Chapter nineteen
concentrates on code inspection and the Cleanroom process.  Software
testing, in chapter twenty, looks at types, cases, and procedures. 
Critical systems validation, in chapter twenty one, is basically the
same process as the previous chapter, but more important.

Part six, on management, is mostly a precis or list of principles from
other sections.  Chapter twenty two deals with managing people,
looking at limits, motivation, group dynamics, recruiting, and
keeping, as well as a quick overview of the People Capability Maturity
Model (P-CMM).  It's not a large section, but it is nice to see the
importance of personnel recognized in this way.  Software cost
estimating, in chapter twenty three, is interesting, but possibly not
terribly useful.  Quality management is dealt with in chapter twenty
four.  Chapter twenty five reviews process improvement and the
Capability Maturity Model (CMM), mentioning the work of Walter Deming
but not, intriguingly, dealing with the fact that Deming's later work
suggested that business had gone overboard in the pursuit of quality.

Part seven deals with evolution and change.  Chapter twenty six
discusses legacy systems with a description of mainframe program
structures and guidelines for the assessment of the possibilities for
updating the system.  Software change is reviewed in chapter twenty
seven, with maintenance and re-architecting leading to a description
of re-engineering in chapter twenty eight.  Chapter twenty nine
finishes off with configuration management, emphasizing version
documentation more than change control.

The book is written as a textbook, with a summary of key points and a
very decent set of exercises at the end of every chapter.  It
certainly stands above the other systems development texts that I have
experienced.  However, this work also has value beyond the classroom. 
A great many professionals, such as information security officers,
need to know the operations, procedures and concepts of software
engineering without necessarily being programmers themselves.  For
these people, this volume makes a clear and excellent reference.

copyright Robert M. Slade, 2002   BKSFTENG.RVW   20020916
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, 27 Dec 2002 08:02:27 -0800
From: Rob Slade <rslade () sprint ca>
Subject: REVIEW: "Trusted Computing Platforms", Siani Pearson

BKTRCMPL.RVW   20020916

"Trusted Computing Platforms", Siani Pearson, 2003, 0-13-009220-7,
U$49.99/C$77.99
%E   Siani Pearson
%C   One Lake St., Upper Saddle River, NJ   07458
%D   2003
%G   0-13-009220-7
%I   Prentice Hall
%O   U$49.99/C$77.99 +1-201-236-7139 fax: +1-201-236-7131
%O  http://www.amazon.com/exec/obidos/ASIN/0130092207/robsladesinterne
%P   322 p.
%T   "Trusted Computing Platforms: TCPA Technology in Context"

Part one introduces trusted platform technology, as a kind of public
key infrastructure implemented in hardware.  (Which begs the question:
what do you do about key revocation?)  Chapter one, an overview of the
trusted computing platform concept, is not very clear on basic ideas
beyond hardware implementation involvement and the notion of
measurement, or assurance.  There are usage scenarios of applications
that can be done, or done better, with trusted platforms, in chapter
two.  Not all of these cases are convincing evidence that trusted
platforms are better.  The cryptographic underpinnings of trusted
platforms are examined in chapter three, but it would be clearer if
the basics of asymmetric cryptography were covered and standard
cryptographic and certificate authority terms were used.

Part two concerns trust mechanisms in a trusted platform, but is
basically a list of commands.  Chapter four deals with access control,
to do with physical presence requirements, ownership, and
authorization.  Platform identification and endorsement is covered in
chapter five.  Chapter six discusses integrity recording, reporting,
and secure boot.  Protected storage of keys is in chapter seven,
migration and maintenance methods in chapter eight, and other assorted
functions in chapter nine.

Part three reviews trusted platforms in practice and operation. 
Chapter ten describes the setup of a new trusted platform, chapter
eleven deals with what would elsewhere be known as trust
relationships, and challenging a trusted platform--authentication of a
server--is in chapter twelve.

Part four presents the benefits of trusted platforms, first to
organizations and corporations, in chapter thirteen, and then to
individuals and users, in chapter fourteen.

This book is not clear, either about what TCPA (Trusted Computing
Platform Alliance) technology is, nor how it can effectively be used. 
Although the authors occasionally admit that there may be problems
with the system, there seems to be a kind of background arrogance in
operation, that assumes everyone will have to use this technology, so
they might was well learn the commands.

copyright Robert M. Slade, 2002   BKTRCMPL.RVW   20020916
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: 29 Mar 2002 (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 e-mail requests to <risks-request () csl sri com> with one-line body
   subscribe [OR unsubscribe]
 which requires your ANSWERing confirmation to majordomo () CSL sri com .
 If Majordomo balks when you send your accept, please forward to risks.
 [If E-mail address differs from FROM:  subscribe "other-address <x@y>" ;
 this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
 Lower-case only in address may get around a confirmation match glitch.
   INFO     [for unabridged version of RISKS information]
 There seems to be an occasional glitch in the confirmation process, in which
 case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
   .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 21" for volume 21]
 http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
   Lindsay Marshall has also added to the Newcastle catless site a
   palmtop version of the most recent RISKS issue and a WAP version that
   works for many but not all telephones: http://catless.ncl.ac.uk/w/r
 http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
 http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
    http://www.csl.sri.com/illustrative.html for browsing,
    http://www.csl.sri.com/illustrative.pdf or .ps for printing

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

End of RISKS-FORUM Digest 22.45
************************