[RISKS] Risks Digest 24.42

From: RISKS List Owner (risko@private)
Date: Wed Sep 13 2006 - 12:21:22 PDT


RISKS-LIST: Risks-Forum Digest  Weds 13 September 2006  Volume 24 : Issue 42

ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
  <http://catless.ncl.ac.uk/Risks/24.42.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents: [Seriously backlogged]
Risks of exhaustive testing (Jim Horning)
Tax blunder undermines Belgian federal budget (Wim Heirman)
New UK biometric passports & identity theft (C Greenock)
Avi Rubin's latest report as an election judge (PGN)
Princeton's Diebold analysis (Feldman-Halderman-Felten via PGN)
REVIEW: "Scene of the Cybercrime: Computer Forensics Handbook", Shinder
  (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Tue, 12 Sep 2006 17:58:45 -0700
From: "Horning, Jim" <Jim.Horning@private>
Subject: Risks of exhaustive testing

After 45 years, I've finally gotten round to documenting the story of a
small subroutine whose QA included running 10,000,000 distinct test
cases.  Since the background is rather complicated and non-linear, I've
done it via a collection of web pages, rather than try to put it all in
one email message.

  http://horningtales.blogspot.com/2006/09/exhaustive-testing.html

"The most exhaustively-tested program that I know of still had a serious
bug when it was released... If you have ten million test cases, you
probably missed one."

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

Date: Wed, 13 Sep 2006 13:59:27 +0200
From: Wim Heirman <wim.heirman@private>
Subject: Tax blunder undermines Belgian federal budget

"The Belgian federal budget for 2006 will need to be reviewed after the tax
administration discovered a "calculation error" of 883M Euro. ... In total,
errors in the processing of 26 tax reports led to an overestimate of federal
income by 883.6M. One taxpayer was told he would be refunded 99.9M, another
one would have to pay 187.9M extra. ... Most of the errors were made between
9 and 22 May. For an unknown reason, several safety filters in the tax
calculation software were disabled at that time. Manual checks did not
reveal the error."

And further down the article, a quote from a high-ranking officer of the tax
administration dated end February:

"The software contains a number of automatic filters to discover
irregularities in the tax reports. ... But to speed things up, we have now
strongly simplified these filters."

A not so nice surprise for our ministers, just weeks before the (local)
elections. And a cold shower after a summer of handing out budgetary
presents in the expectation of a 500M rise in tax income since last year...

[Source: De Standaard, 13 Sept. 2006]
  http://www.standaard.be/Artikel/Detail.aspx?artikelId=GA111JA8J
  and
  http://www.standaard.be/Artikel/Detail.aspx?artikelId=G8H11J3MC
    (in Dutch)]

ir. Wim Heirman, ELIS Department, Ghent University, Belgium  +32-9-264.95.27
E-mail: wim.heirman@private  http://www.elis.UGent.be/~wheirman/

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

Date: Fri, 8 Sep 2006 15:53:49 +0100 (BST)
From: C Greenock <cigwork@private>
Subject: New UK biometric passports & identity theft

It was noted recently by one of the 'new totalitarian' enthusiasts for the
new passport that it shouldn't be possible to interrogate the new UK
'biometric' passport at any other than a distance of a foot or two.
 
It was then pointed out (on RISKS) that read range can be extended with a
sufficiently powerful transmitter/reader.  However it seems that the way in
which passports are delivered means that a standard reader is all that is
required to read the new passport and still be able to steal the information
it contains.

I recently renewed my passport as part of the protest about the introduction
of the 'ID card'. I received it through the post. It was delivered by a
courier company (not Royal Mail). Despite there being nothing blatantly
obvious on the envelope to identify it as a passport the delivery driver
knew that it was a passport.  If this is the case then it seems to me that
it would be fairly straightforward for a courier using a standard RFID
reader to scan each passport, in its envelope, as he or she delivers it and
hand the details on to an accomplice at some later time.  We know that the
encryption has already been broken.

So. No need to steal the passport, no need even to open the envelope
containing the passport. All the details taken & no evidence to show it.

One other thing that amused and irritated me. According to the leaflet that
came with the passport the chip and aerial are fragile and I should
therefore take great care of the passport and not subject it to heat nor
magnetic and electric fields (I'm paraphrasing). You have to question the
sense of sending out something so vulnerable that it can't withstand the
sort of mistreatment that the old fashioned paper document could withstand
for years on end.

However the leaflet went on to assure me that the passport reached me, 'in
perfect working order'. So that's alright then.

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

Date: Wed, 13 Sep 2006 10:27:43 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Avi Rubin's latest report as an election judge

  [This is from Avi Rubin's blog, on his latest experiences as an election
  judge.  This is a extremely relevant item for RISKS.  PGN]

My day at the polls - Maryland primary '06
http://avi-rubin.blogspot.com/2006/09/my-day-at-polls-maryland-primary-06.html

I don't know where to start. This primary today is the third election that I
have worked as an election judge. The last two elections
<http://avirubin.com/judge.html> were in 2004, and I was in a small precinct
in Timonium, MD. This time, I was in my home precinct about 1/2 a mile from
my house. We had 12 machines, over 1,000 voters and 16 judges. I woke up at
5:30 in the morning and was at the precinct before 6:00. It is now 10:18 pm,
and I just got home a few minutes ago. As I have made it my custom, I sat
down right away to write about my experience while everything was still
fresh. In anticipation of this, I took some careful notes throughout the
day.

The biggest change over the 2004 election was the introduction of electronic
poll books that we used to check in voters. I was introduced to these in
election judge training a few weeks ago. These are basically little
touchscreen computers that are connected to an Ethernet hub. They each
contain a full database of the registered voters in the county, and
information about whether or not each voter has already voted, in addition
to all of the voter registration information. The system is designed so that
the machines constantly sync with each other so that if a voter signs in on
one of them and then goes to another one, that voter will already be flagged
as having voted. That was the theory anyway.  These poll books turned out to
be a disaster, but more on that later.

Around 7:15, when we had been open for business for 15 minutes already, a
gentlemen shows up saying that he is a judge from another precinct nearby
and that they did not receive any smartcards, so that they could not operate
their election. We had 60 smartcards, and the chief judge suggested that we
give them 20 so that they could at least get their election started. As she
was handing them over, I suggested that we had to somehow verify his
claim. After all, anyone could walk in off the street and claim this guy's
story, and we would give them 20 access cards. The chief judge agreed with
me. The guy pulled out his driver's license to prove who he was, but I told
him that we were not doubting who he was, we just wanted to verify that we
should give him the cards.  He seemed to understand that. After calling the
board of elections, we were told to give him the cards and we did. A little
later, several voters who came in informed us that news reports were saying
that in Montgomery county, there was a widespread problem of missing
smartcards.  I could only imagine what a nightmare that was for those poll
workers because as it was, our precinct did not have this problem, and as
you'll see, it was still tough going.

My precinct uses Diebold AccuVote TS, the same one that we analyzed in our
study <http://avirubin.com/vote/analysis/index.html> 3 years ago.  The first
problem we encountered was that two of the voting machine's security tag
numbers did not match our records. After a call to the board of elections,
we were told to set those aside and not use them.  So, we were down to
10. We set up those machines in a daisy chain fashion, as described in the
judge manual, and as we learned in our training. We plugged the first one
into the wall and taped the wire to the floor with electric tape so nobody
would trip over it. About two hours into the voting, I noticed that the
little power readout on the machines was red, and I thought that this meant
that the machines were on battery power. I pointed this out to one of the
chief judges, but she said this was normal. An hour later, I checked again,
and this time, the machines were on extremely low power. This time, I took
the plug out to of the wall and tried another outlet nearby. The power icon
turned green. I showed several of the judges, and we confirmed that the
original outlet was indeed dead. Had I not checked this twice, those
machines would have died in the middle of the election, most likely in the
middle of people voting. I hate to think about how we would have handled
that. A couple of hours later, the board of elections informed us that we
should use the two voting machines with the mismatched tags, so we added
them and used them the rest of the day (!).

When we were setting up the electronic poll books, I took over because I was
more comfortable with the technology, and the others quickly deferred to
me. So, a couple of hours into the election, when one of the poll books
seemed to be out of sync with the others, the judges came and brought me to
have a look. It appeared that this poll book was not getting synced with the
others. I tested it by waiting for someone to sign in with a different poll
book, and then a few minutes later trying to sign in that voter on the one
in question. The voter was shown as having not voted yet. I repeated this
test for about 20 minutes, but it never registered that voter as having
voted, and the poll book was falling behind - about 30 by then - the other
poll book machines. I suggested rebooting that machine, and we tried that,
but it did not change anything. I pointed out to the chief judges who were
huddled around me as I experimented, that as time went by, this poll book
was going to fall further and further behind the others, and that if someone
signed in on the others, they would be able sign in again on this one and
vote again. After a call to the board of elections, we decided to take this
one out of commission. This was very unfortunate, because our waiting lines
were starting to get very long, and the check-in was the bottleneck. The
last few hours of the day, we had a 45 minute to an hour wait, and we had
enough machines in service to handle the load, but it was taking people too
long to sign in.

The electronic poll books presented an even bigger problem, however.  Every
so often, about once every 15-25 minutes, after a voter signed in, and while
that voter's smartcard was being programmed with the ballot, the poll book
would suddenly crash and reboot. Unfortunately, the smartcard would not be
programmed at the end of this, so the poll worker would have to try
again. However, the second time, the machine said that the voter had already
voted. The first few times this happened, we had some very irate voters, and
we had to call over the chief judge. Soon, however, we realized what was
happening, and as soon as the poll book crashed, we warned the voter that it
would come up saying that they had already voted, but that we knew they
hadn't. Then, the chief judge would have to come over, enter a password, and
authorize that person to vote anyway. Then we had to make a log entry of the
event and quarantine the offending smartcard. Unfortunately, the poll books
take about 3 minutes to reboot, and the chief judges are very scarce
resources, so this caused further delays and caused the long line we had for
most of the afternoon and evening while many of the machines were
idle. Another problem was that the poll book would not subtract a voter from
its total count when this happened, so every time we had an incident, the
poll book voter count was further off the mark. We had to keep track of this
by hand, so we could reconcile it at the end of the day.

At times, the remaining two poll books were way out of synch, but after a
while, they caught up with each other. When the lines got really long, we
considered the idea of trying to use the third one that had caused problems,
but we all agreed that we would feel very stupid if all of them started
crashing more. I was worried that synching three of these on an Ethernet hub
was more complex than 2, and in fact, they were crashing a bit less often
when we had only 2. The whole time I was worried about what we would do if
these thing really died or crashed so badly and so often that we couldn't
really use them. We had no backup voter cards, so the best we could have
done would have been to start letting everybody vote by provisional
ballots. However, we had two small pads of those ballots, and we would have
run out quickly. I can't imagine basing the success of an election on
something so fragile as these terrible, buggy machines.

Throughout the early part of the day, there was a Diebold representative at
our precinct. When I was setting up the poll books, he came over to "help",
and I ended up explaining to him why I had to hook the ethernet cables into
a hub instead of directly into all the machines (not to mention the fact
that there were not enough ports on the machines to do it that way). The
next few times we had problems, the judges would call him over, and then he
called me over to help. After a while, I asked him how long he had been
working for Diebold because he didn't seem to know anything about the
equipment, and he said, "one day." I said, "You mean they hired you
yesterday?" And he replied, "yes, I had 6 hours of training yesterday. It
was 80 people and 2 instructors, and none of us really knew what was going
on." I asked him how this was possible, and he replied, "I shouldn't be
telling you this, but it's all money. They are too cheap to do this
right. They should have a real tech person in each precinct, but that costs
too much, so they go out and hire a bunch of contractors the day before the
election, and they think that they can train us, but it's too compressed."
Around 4 pm, he came and told me that he wasn't doing any good there, and
that he was too frustrated, and that he was going home. We didn't see him
again.

I haven't written at all about the AccuVote machines. I guess I've made my
opinions about that known in the past, and my new book
<http://bravenewballot.org> deals primarily with them. Nothing happened
today to change my opinion about the security of these systems, but I did
have some eye opening experiences about the weaknesses of some of the
physical security measures that are touted as providing the missing
security. For example, I carefully studied the tamper tape that is used to
guard the memory cards. In light of Hursti's report
<http://www.blackboxvoting.org/BBVtsxstudy.pdf>, the security of the memory
cards is critical. Well, I am 100% convinced that if the tamper tape had
been peeled off and put back on, nobody except a very well trained
professional would notice it. The tamper tape has a tiny version of the word
"void" appear inside it after it has been removed and replaced, but it is
very subtle. In fact, a couple of times, due to issues we had with the
machines, the chief judge removed the tamper tape and then put it back. One
time, it was to reboot a machine that was hanging when a voter was trying to
vote. I looked at the tamper tape that was replaced and couldn't tell the
difference, and then it occurred to me that instead of rebooting, someone
could mess with the memory card and replace the tape, and we wouldn't have
noticed. I asked if I could play with the tamper tape a bit, and they let me
handle it. I believe I can now, with great effort and concentration, tell
the difference between one that has been peeled off and one that has
not. But, I did not see the judges using that kind of care every time they
opened and closed them. As far as I'm concerned, the tamper tape does very
little in the way of actual security, and that will be the case as long as
it is used by lay poll workers, as opposed to CIA agents.

As we were computing the final tallies towards the end of the evening, one
of the Diebold machines froze. We had not yet printed the report that is
used to post the results. One of the judges went to call the board of
elections. She said she was transfered and then disconnected.  We decided to
do a hard reboot of it after we closed down the other machines. When we
finished the other machines, we noticed that the problem one had somehow
recovered, and we were able to finish. Strange because it was frozen for
about 10 minutes.

So, this day at the polls was different from my two experiences in 2004
<http://avirubin.com/judge.html>. I felt more like an experienced veteran
than a wide eyed newbie. The novelty that I felt in 2002 was gone, and I
felt seasoned. Even the chief judges often came to me asking advice on how
to handle various crises that arose. Several other suggested that I should
apply to be a chief judge in the next election cycle, and I will probably do
that. The least pleasant part of the day was a nagging concern that
something would go terribly wrong, and that we would have no way to
recover. I believe that fully electronic systems, such as the precinct we
had today, are too fragile. The smallest thing can lead to a disaster. We
had a long line of "customers" who were mostly patient, but somewhat
irritated, and I felt like we were not always in a position to offer them
decent customer service. When our poll books crashed, and the lines grew, I
had a sense of dread that we might end up finishing the day without a
completed election. As an election judge I put aside my personal beliefs
that these machines are easy to rig in an undetectable way, and become more
worried that the election process would completely fail. I don't think it
would have taken much for that to have happened.

One other thing struck me. In 2004, most voters seemed happy with the
machines. This time around, many of them complained about a lack of a paper
trail. Some of them clearly knew who I was and my position on this, but
others clearly did not. I did not hear one voter say they were happy with
the machines, and a dozen or so expressed strong feelings against them.

I am way too tired now (it's past 11 pm) to write any kind of philosophical
ending to this already too long blog entry. I hope that we got it right in
my precinct, but I know that there is no way to know for sure. We cannot do
recounts. Finally, I have to say a few words about my fellow poll
workers. We all worked from 6 a.m. to past 10 p.m. These volunteers were
cheerful, pleasant, and diligent. They were there to serve the public, and
they acted like it. I greatly admire them, and while the election technology
selection and testing processes in this country make me sick, I take great
hope and inspiration from a day in the trenches with these people.

  [See Avi's blog for some very relevant responses as well.  PGN]

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

Date: Wed, 13 Sep 2006 9:22:18 PDT
From: "Peter G. Neumann" <neumann@private>
Subject:  Princeton's Diebold analysis

Security Analysis of the Diebold AccuVote-TS Voting Machine
  Ariel J. Feldman <http://www.cs.princeton.edu/~ajfeldma>,
  J. Alex Halderman <http://www.cs.princeton.edu/~jhalderm>,
  and Edward W. Felten <http://www.cs.princeton.edu/~felten>

Abstract.  This paper presents a fully independent security study of a
Diebold AccuVote-TS voting machine, including its hardware and software.  We
obtained the machine from a private party. Analysis of the machine, in light
of real election procedures, shows that it is vulnerable to extremely
serious attacks. For example, an attacker who gets physical access to a
machine or its removable memory card for as little as one minute could
install malicious code; malicious code on a machine could steal votes
undetectably, modifying all records, logs, and counters to be consistent
with the fraudulent vote count it creates. An attacker could also create
malicious code that spreads automatically and silently from machine to
machine during normal election a voting-machine virus. We have constructed
working demonstrations of these attacks in our lab. Mitigating these threats
will require changes to the voting machine's hardware and software and the
adoption of more rigorous election procedures.

  [See http://itpolicy.princeton.edu/voting/ for the full paper, executive
  summary, FAQ, and other studies.  PGN]

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

Date: Mon, 04 Sep 2006 11:38:55 -0800
From: Rob Slade <rmslade@private>
Subject: REVIEW: "Scene of the Cybercrime: Computer Forensics Handbook",
  Debra Littlejohn Shinder

BKSOCCFH.RVW   20060809

"Scene of the Cybercrime: Computer Forensics Handbook", Debra
Littlejohn Shinder, 2002, 1-931836-65-5, U$59.95/C$92.95
%A   Debra Littlejohn Shinder debshinder@private
%C   800 Hingham Street, Rockland, MA   02370
%D   2002
%E   Ed Tittel
%G   1-931836-65-5
%I   Syngress Media, Inc.
%O   U$59.95/C$92.95 781-681-5151 fax: 781-681-3585 amy@private
%O  http://www.amazon.com/exec/obidos/ASIN/1931836655/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/1931836655/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1931836655/robsladesin03-20
%O   Audience n+ Tech 2 Writing 3 (see revfaq.htm for explanation)
%P   718 p.
%T   "Scene of the Cybercrime: Computer Forensics Handbook"

There are some good forensics books out there, but there are also a number
of forensics titles that are nothing more than pamphlets suggesting that the
reader get a copy of EnCase and fool around.  Then there is this work.  I'm
not sure how I got a review book that is four years old, an eternity in the
technical realm, and particularly in security.  Astoundingly, Shinder
produced a work that cut to the heart of the necessary concepts, without
piling on technical trivia that would rapidly go out of date.  This volume
is as relevant and valuable today as it was when it came out.

The foreword notes that the author, herself from both a law enforcement and
a technical background, found that most technical security people know
little about law and legal procedures, and that law enforcement personnel
know next to nothing about computer internals.  She set herself to provide
geek info to the cops and cop smarts to the geeks, and to compile a
reference to other resources.

She has produced an admirably valuable text.

Chapter one starts out with a bit of a slip, stating that cybercrime is a
subcategory of computer crime, but then explains it in such a way as to be
basically identical.  However, Shinder goes on to provide an excellent
review of the problems in defining and categorizing cybercrime,
jurisdictional issues, and the difficulties in building a team and
infrastructure to fight cybercrime.  A concise history of computer crime
events and issues, and a review of common dangers, makes up chapter two.
(The material on high-speed Internet is somewhat dated, but the rest is
excellent.)  In other hands, chapter three's examination of the people
involved in cybercrime would be a rehash of old "hacker" stereotypes.
Instead, Shinder gives us criminal psychology, profiling (and
counterexamples to the stereotypes), victimology, and the characteristics of
a good investigator.

Chapter four looks into computer hardware basics.  Techies will think it
simplistic, but the content is pitched just right for computer neophytes who
need the fundamental concepts and enough detail to step up to further
studies.  Some may think that the coverage of networking, in chapter five,
spends too much time on analogue signaling and old LAN protocols, but you
have to remember that digital forensic investigators are not called upon to
use standard environments, but to assess the material found in arbitrary
ones.  The presentation of network intrusions and attacks, in chapter six,
has clear representation of the concepts, without deluging the reader with
quickly datable minutia.

Chapter seven, turning to cybercrime prevention, presents general
information security concepts, with a concentration on networks and
cryptography.  (As with many, Shinder seems to be fascinated with
steganography out of all proportion to its importance.)  Implementing system
security, in chapter eight, is similar, but with greater emphasis on
specific settings.  (Although this is very helpful, particularly to the home
user, it has limited application to forensics.)  Chapter nine looks at
cybercrime detection techniques, primarily audit information in its various
forms.  The collection and preservation of digital evidence is an important
and difficult task.  Chapter ten does not go into the same level of detail
as Michael A.  Caloyannides' "Computer Forensics and Privacy"
(cf. BKCMFRPR.RVW), "Computer and Intrusion Forensics" by Mohay et al
(cf. BKCMINFO.RVW), Kruse and Heiser's classic "Computer Forensics"
(cf. BKCMPFRN.RVW), the somewhat challenging "Forensic Discovery" by Farmer
and Venema (cf. BKFORDIS.RVW), and Brian Carrier's resourceful "File System
Forensic Analysis" (cf. BKFSFRAN.RVW), but presents a broad overview, and
has good advice on evidence management and a useful list of resources.
Legal systems, types of laws, jurisdictional issues, and the preparation of
a case is covered in chapter eleven, which extends "A Guide to Forensic
Testimony" by Smith and Bace (cf. BKGDFOTS.RVW).

For anyone just becoming involved in digital forensics, the book is an
excellent introduction and overview of the field in its proper context.  For
those already involved, this manual is both a solid reminder of what needs
to be taught to those becoming involved in computer forensics, and also a
resource for a number of areas that the individual specialist may not cover
every day.  Despite the age of the work, in this fast changing environment,
Shinder has produced a text of classic depth and lasting value.  (Hopefully
Syngress will get her to produce updates on a regular basis.)

copyright Robert M. Slade, 2006   BKSOCCFH.RVW   20060809
rslade@private     slade@private     rslade@private
http://victoria.tc.ca/techrev/rms.htm

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

Date: 2 Oct 2005 (LAST-MODIFIED)
From: RISKS-request@private
Subject: Abridged info on RISKS (comp.risks)

 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
 if possible and convenient for you.   The mailman web interface can
 be used directly to subscribe and unsubscribe:
   http://lists.csl.sri.com/mailman/listinfo/risks
 Alternatively, to subscribe or unsubscribe via e-mail to mailman your
 FROM: address, send a message to
   risks-request@private
 containing only the one-word text subscribe or unsubscribe.  You may
 also specify a different receiving address: subscribe address= ... .
 You may short-circuit that process by sending directly to either
   risks-subscribe@private or risks-unsubscribe@private
 depending on which action is to be taken.

 Subscription and unsubscription requests require that you reply to a
 confirmation message sent to the subscribing mail address.  Instructions
 are included in the confirmation message.  Each issue of RISKS that you
 receive contains information on how to post, unsubscribe, etc.

=> The complete INFO file (submissions, default disclaimers, archive sites,
 copyright policy, etc.) is online.
   <http://www.CSL.sri.com/risksinfo.html>
 The full info file may appear now and then in RISKS issues.
 *** Contributors are assumed to have read the full info file for guidelines.

=> .UK users should contact <Lindsay.Marshall@private>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks@private with meaningful SUBJECT: line.
 *** NOTE: Including the string "notsp" at the beginning or end of the subject
 *** line will be very helpful in separating real contributions from spam.
 *** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
   Lindsay 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/> .
==> 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 24.42
************************



This archive was generated by hypermail 2.1.3 : Wed Sep 13 2006 - 12:51:38 PDT