[risks] Risks Digest 23.16

From: RISKS List Owner (risko@private)
Date: Tue Feb 03 2004 - 11:50:26 PST

  • Next message: RISKS List Owner: "[risks] Risks Digest 23.17"

    RISKS-LIST: Risks-Forum Digest  Tuesday 3 February 2004  Volume 23 : Issue 16
    
       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 http://www.risks.org as
      http://catless.ncl.ac.uk/Risks/23.16.html
    The current issue can be found at
      http://www.csl.sri.com/users/risko/risks.txt
    
      Contents:
    Security holes at DMVs nationwide lead to ID theft and safety concerns
      (Monty Solomon)
    Defeating phishing scams (Andrew Rose)
    A nasty Phishing attempt (Avishai Wool)
    Another wireless risk (Chris Meadows)
    Hotel reservation system easily confused (Richard S. Russell)
    Browsers, online forms, rendering and opt-in marketing (Alistair McDonald)
    Drunk unlocks police car with own key (Max)
    Re: Happy 2**30'th birthday, time_t! (Steve Summit)
    Re: Suing the customers (Paul Robinson)
    Re: Lie-detector glasses, 90% accurate? (Ron Bean, Peter B. Ladkin)
    REVIEW: "Biometrics", Woodward/Orlans/Higgins (Rob Slade)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Mon, 2 Feb 2004 09:50:52 -0500
    From: Monty Solomon <monty@private>
    Subject: Security holes at DMVs nationwide lead to ID theft and safety concerns
    
    http://www.cdt.org/ 
    
    Security Holes at DMVs Nationwide Lead to ID Theft and Safety Concerns
    
    CDT has issued a report entitled "Unlicensed Fraud" documenting rampant
    internal fraud and lax security at state motor vehicle administration
    offices across the country placing the reliability of all driver's license
    at risk. While heavy public attention has been placed on new national
    standards and new technologies for driver's licenses, studying local news
    reports from throughout 2003 CDT finds that basic management processes to
    stop bribery and theft are lacking. In the report, CDT offers policy
    recommendations to address this dire issue.  2 Feb 2004
    
    Unlicensed Fraud: How bribery and lax security at state motor vehicle
    offices nationwide lead to identity theft and illegal driver's licenses:
    [pdf] 
      http://www.cdt.org/privacy/20040200dmv.pdf
    
    ------------------------------
    
    Date: Mon, 19 Jan 2004 10:11:35 -0000
    From: Andrew Rose <andrew.rose@private>
    Subject: Defeating phishing scams
    
    PGN commented on another 2 phishing scams highlighted in RISKS-23.13,
    > [This is increasingly becoming a problem!  We desperately need 
    > some greater authentication and accountability.  PGN]
    
    Work on a technical (part-)solution named SPF ("senders permitted from") is
    underway at http://spf.pobox.com/.  This simple technique has domains
    publish so-called SPF records in the DNS.  The SFP records detail those
    machines that may validly send email for the domain in question.  This
    allows receiving MTAs to reject or flag email that claims to come from e.g.
    paypal.com but isn't sent by a machine that is authorised to send on behalf
    of paypal (e.g. a phisher).
    
    The technical work on SPF is now complete and adoption has started.  Several
    thousand domains have published SPF records including some very large
    domains such as aol.com.  Plugins exist for most of the popular MTAs - the
    only notable exception being MS Exchange.
    
    For a more detailed overview see
    http://spf.pobox.com/for-mit-spam-conference.gif.  Those who are still
    interested should then read http://spf.pobox.com/ and join the mailing list.
    
    ------------------------------
    
    Date: Sat, 24 Jan 2004 09:12:42 -0800 (PST)
    From: Avishai Wool <avishai_w@private>
    Subject: A nasty Phishing attempt
    
    Perhaps this is ho-hum for RISKS readers, but I thought I'd pass this along
    anyway.
    
    I got a nasty spam today which I excerpt below. 
    It purports to be from the FDIC, and asks the reader
    to go to the FDIC web site and "verify" bank account details.
    It uses the 
      http://reasonable.site.name @criminal.site.ip.address/index.html
    trick, where the "reasonable" site name is treated as a username.
    The criminal site probably attempts to harvest these details (I tried it
    but the site was unresponsive).
    
    This is a clever piece of social engineering, which is especially
    effective against non-US residents that have (or had) a US bank account.
    
    Avishai
    
    > Subject: Important News About Your Bank Account
    > Date: Sat, 24 Jan 2004 09:32:39 -0400 (EST)
    >
    > [snip] 
    > As a result Department Of Homeland Security Director Tom Ridge has advised
    > the Federal Deposit Insurance Corporation to suspend all deposit insurance on
    > your account until such time as we can verify your identity and your account
    > information.
    
    > Please verify through our IDVerify below. This information will be checked 
    > against a federal government database for identity verification. This only
    > takes up to a minute and when we have verified your identity you will be
    > notified of said verification and all suspensions of insurance on your
    > account will be lifted.
    
    > http://www.fdic.gov/idverify/cgi-bin/index.htm 
      (the link behind the text was http://www.fdic.gov\1at_private/index.htm)
    
    > Failure to use IDVerify below will cause all insurance for your account 
    > to be terminated and all records of your account history will be sent to the
    > Federal Bureau of Investigation in Washington D.C. for analysis and 
    > verification.
    
    Avishai Wool, Ph.D.  http://www.algosec.com   http://www.eng.tau.ac.il/~yash
    yash@private   +972-3-640-6316
    
    ------------------------------
    
    Date: Mon, 26 Jan 2004 16:13:37 -0600
    From: Chris Meadows aka Robotech_Master <robotech@private>
    Subject: Another wireless risk
    
    The other day I was in the position of needing to print out my credit card
    site's invoice display.  Since I don't have a fully functional printer at
    home, and I needed to make a photocopy anyway, I decided to take my Mac
    Powerbook down to Kinko's and print it off there.
    
    The problem was, when I plugged the Powerbook into their Ethernet link
    (called a "Macintosh link" for some reason by their onsite
    documentation...never mind that any computer with an Ethernet port could use
    it), I couldn't reach the Internet.  (Nor could I see any printers in my
    application...and the printer driver disk the Kinko's clerk helpfully
    offered didn't help, because it only had drivers for OS 9, not OS X.)
    However, the fellow who'd just vacated the laptop station had been using
    wireless, and he said that should work.  And I did a quick scan, found an
    open wireless router labelled "linksys," (the way they didn't even bother to
    change the default name should have warned me, I suppose...but given the
    general lack of computer adroitness I had observed in the staff, that
    carelessness seemed to fit right in) with a Lexmark printer on it, and
    Internet access...so I called up the invoice and hit print, then asked the
    Kinko's clerk where that particular printer was.
    
    Longtime RISKS readers should be able to guess what came next.  "But we
    don't have a wireless network...and we don't have any Lexmark printers
    either."  Further research indicated that the wireless router was hooked
    into a Bellsouth DSL connection, presumably someone's nearby home or
    business.  So I had just printed my credit card invoice to some total
    stranger's printer...and had no way even to find out where it was so I could
    get it back.  Fortunately, the invoice didn't contain any *truly* sensitive
    information, such as my SSN or account number (beyond "ends with ....").
    And I was closing that account anyway.
    
    The risk here is kind of the inverse of the "usual" risk associated with a
    wireless system...instead of "you never know who might be using your
    network," it's "you never know whose network you might be using."  The
    combination of an open wireless network and a location where you would
    expect there to be one can easily enough confuse you into conflating the two.
    
    ------------------------------
    
    Date: Fri, 23 Jan 2004 23:33:08 -0600
    From: "Richard S. Russell" <RichardSRussell@private>
    Subject: Hotel reservation system easily confused
    
    Our science-fiction group in Madison, Wisconsin, runs the world's only
    feminist-oriented SF convention, WisCon. Every year we hold it in the same
    hotel. Our publicity is required to say "Mention WisCon 2004 when making
    reservations to get the group rate.". I asked why the "2004" part was
    necessary and was told that, because of the hotel's automated reservation
    system, the rates for WisCons 2002, 2003, 2005, 2006, etc.  are also in the
    computer, and the reservation-takers apparently can't figure out from the
    dates of the reservation (2004 May 28-31, if you're interested) which one
    you're signing up for. Therefore, instead of building in a single central
    error-checking process, they rely on a distributed network of hundreds of
    naive human beings to each individually get it right -- assuming that the
    convention committee has done ITS part and diligently included the year
    every time it mentions the name of the convention.
    
    Richard S. Russell, 2642 Kendall Av., Madison WI 53705-3736  1-608-233-5640
    
    ------------------------------
    
    Date: Wed, 21 Jan 2004 08:32:18 -0000 (GMT)
    From: "Alistair McDonald" <alistair@private>
    Subject: Browsers, online forms, rendering and opt-in marketing
    
    I completed a _long_ online for for the UK's DTI on information security
    breaches (http://www.infosec.co.uk/page.cfm/Action=Form/ID=13/t=m) if you
    want to complete it. This took me over 10 minutes. At the end, there were
    the usual options to untick the boxes and not have your information shared,
    and so on. There was, however, a strange twist.
    
    My browser (Opera 7.23 for Linux) failed to display the end of the page.  It
    simply stopped halfway through one of the personal information lines.
    
    I didn't want to fill in the form again using another browser, so I had to
    view the source code and use the keyboard to navigate through the various
    tick boxes.
    
    Then, I had another thought: the form had questions like "If you do not wish
    to receive information ... please untick here." The boxes were unchecked by
    default - should I check them or leave them unchecked? The message indicated
    that I should take an action - i.e. toggle the boxes, but perhaps they
    should have been on by default, but my browser failed to do this, perhaps
    due to non-standard HTML or script. By leaving them unticked, I'd be OK -
    but no, I had to take an action.
    
    However, it occurred to me that both of these errors could be used in a
    deliberate way to confuse users and collect more personal information for
    opt-in marketing.
    
    By the way, the form was way too long. It was 266K, had nearly 7000 source
    lines, and 224 input controls (including any hidden ones). It should have
    been broken up into about a dozen smaller pages with Next and Prev buttons
    to navigate between them. Of course, that would be more difficult to code.:-)
    
    ------------------------------
    
    Date: Tue, 13 Jan 2004 20:57:58 -0800
    From: Max <max7531@private>
    Subject: Drunk unlocks police car with own key
    
    Shinichi Kiyono, 32, was arrested on suspicion of car theft after he
    reportedly mistakenly unlocked a police investigation vehicle with his own
    car key while drunk, then drove to an empty lot and fell asleep in the
    vehicle.  He turned himself in when he woke up in a Nissan that was not his,
    although it was the same make and color.  Nissan says it makes more than
    20,000 types of keys.
    
    A spokesman for Nissan Motor Co., the maker of the vehicles, said the firm
    produced more than 20,000 types of keys for its vehicles, and that it was
    almost impossible for separate keys to be used in different cars, even if
    they were the same model, but that it was not impossible for keys to very
    occasionally fit other cars.  Prosecutors subsequently decided not to
    indict him.
    
    [Source: PGN-ed from the Japanese daily *Mainichi Shimbun*, 18 Dec 2003:
     http://mdn.mainichi.co.jp/news/archive/200312/18/20031218p2a00m0dm005000c.html
    See also: "Drunk who unlocked police car with own key escapes prosecution":
     http://www12.mainichi.co.jp/news/mdn/search-news/
     896474/drunk20who20unlocked20police20car20escapes20prosecution-0-1.html]
    
      [I would be interested to see how many other police cars this guy's key
      can open.  Max]
        [Count the number of Nissans on the road, and divide by 20,000, to
        get a very rough estimate.  PGN]
    
    ------------------------------
    
    Date: Thu, 22 Jan 2004 18:40:14 -0500
    From: Steve Summit <scs@private>
    Subject: Re: Happy 2**30'th birthday, time_t! (RISKS-23.12)
    
    Paul Eggert wondered how many time-related problems there might be in 2038
    even though most machines by then will presumably be capable of using 64
    bits.  I'm afraid the answer is: quite a lot.  Even if every CPU and OS is
    using 64-bit time_t's by then, I expect there will still countless instances
    of 32-bit time representations lying around on disk, baked into binary data
    file formats which still reflect the original 32-bit size.  Upgrading CPU's
    and recompiling programs will not, of course, automatically update all of
    the terabytes worth of data files written and maintained by prior versions
    of the programs.  (In other words, it's all too likely that 2038 will be to
    Unix as Y2K was to COBOL.)
    
    For those who use binary data files, a nice exercise is to write a pair of
    functions for reading and writing between in-memory time_t values (however
    big they happen to be today), and 6- or 8-byte on-disk values, making sure
    that the functions are implemented such that they work without change when
    compiled on a system with 32-bit time_t's, or recompiled for a machine with
    64-bit time_t's.  (Of course, decoupling data file representations from
    implementation-defined in-memory representations is almost always a good
    idea; this is merely a timely example.)
    
    ------------------------------
    
    Date: Sat, 24 Jan 2004 19:43:32 GMT
    From: Paul Robinson <postmaster@private>
    Subject: Re: Suing the customers (Scrivner, RISKS-23.12)
    
    > Rockwell, is suing a law firm that is currently suing Rockwell's customers.
    > [...]
    
    I think Rockwell doesn't have a leg to stand on.  A patent gives the holder
    of it the right to prevent others from making, using or selling a patented
    device.  Anyone in the chain of persons not having a license from the patent
    holder can be sued.  If you purchase an ACME refrigerator from Pat's
    Appliance Store, and it turns out that the ACME refrigerator has a
    patent-violating component in the in-door ice maker, the owner of that
    patent can sue ACME, they can sue Pat's Appliance store, and they can sue
    you.  All three of you are jointly and severally violating the patent
    holder's rights under the law and they can sue any or all of you.  Usually
    the manufacturer is the only one who is sued but in theory anyone who
    doesn't have a license, either directly or indirectly, is an infringer and
    can be sued.
    
    There was an incident a few years ago, when the manufacturer for the
    electronic fare collection system implemented in the Washington Metrorail
    system used some components that violated a patent (because the manufacturer
    didn't have a license.)  The patent holder chose to sue the Washington
    Metropolitan Area Transit Authority (WMATA) instead of suing the
    manufacturer.  WMATA simply chose to settle by purchasing a license from the
    patent holder.  I don't know if the transit authority ever got the extra
    cost back from its supplier.
    
    This is the exact same situation the RIAA is dealing with in the case of
    people who are allegedly swapping songs over peer-to-peer networks.  (The
    RIAA's real agenda is obviously control, not money, but suing people to
    scare others is a fairly effective way to influence behavior.  If the RIAA
    were interested in money, they would have taken up the offer of a billion
    dollars in payments from licensing fees through sale of use of the service,
    and Napster - the original one - would still be operating.)
    
    The point is, even if the patent holder is wrong about their product being
    infringed, legally they may choose to target the manufacturer's customers.
    Some of them could conceivably counter sue if the company is intentionally
    misusing the legal process but that's an iffy proposition, as some people
    who tried to sue DirectTV over it's efforts to squeeze money out of anyone
    who purchased a smartcard programmer from certain sites that sold devices
    that allegedly could allow someone to obtain DirectTV's service, whether or
    not the person actually did or could have used the programmer to unlawfully
    obtain their signals, discovered.  A court found the attempts by DirectTV to
    demand (enormous amounts of) money for alleged signal theft (whether or not
    any actually happened) in place of filing suit was a legitimate action by
    DirectTV, and ordered them to pay its costs to defend the case.
    
    N.B. To prevent *me* from being sued in case I have named someone who really
    exists, the name "ACME" and "Pat's Appliance Store" are fictional examples
    not intended to represent any real-life company or organization.  :) But I'm
    not worried anyway because I don't have any money and am unlikely to be
    sued.  :(
    
    >   In Rockwell Automation Inc. v. Schneider Automation Inc., 02-01195,
    >   Rockwell says its technology is not covered by the Solaia patent, and
    >   rather than battling that issue out in court, Niro Scavone and its clients
    >   have sought to "'shakedown' manufacturers through threats of potential
    >   business interruption or catastrophic damages."
    >     http://www.law.com/jsp/article.jsp?id=1039054478800
    
    It's not a 'shakedown' if you use the courts.  If I threaten you if you
    don't pay me for something, that's extortion and a crime.  If I threaten to
    sue you if you don't settle, that's legal.  If I just sue you anyway,
    whether I have a case or not, that's also legal.  As many people are
    relatively upset over in the case of SCO and it's claims it has some rights
    over Linux due to alleged infringement.  It may be relatively slimy but it's
    by the book legal, unfortunately.
    
      ["If the lessons of history teach us anything it is that nobody learns
      the lessons that history teaches us."]
    
    ------------------------------
    
    Date: Tue, 27 Jan 2004 22:01:04 -0600
    From: Ron Bean <rbean@private>
    Subject: Re: Lie-detector glasses, 90% accurate? (Holzworth, RISKS-23.14)
    
    > It may not be long before you hear airport security screeners ask, "Do you
    > plan on hijacking this plane?"
    
    I'd be highly tempted to reply "No, do you plan to stop beating your wife?"
    
    Reading the rest of the article, it sounds like it's detecting people's
    emotional "hot buttons", rather than lies per se. They talk about using it
    as a "love detector" also...  (there should be a joke about lonely airport
    screeners in there somewhere, but I won't attempt it).
    
    The article also says:
    
      "The technology delivers not only a true/false reading, but a range of
      high-level parameters, such as "thinking level," which measures how much
      as subject has thought about an answer they give, and "SOS level," which
      assesses how badly a person doesn't want to talk about a subject."
    
    I bet a good actor could reverse-engineer this, given enough
    time with the machine.
    
    > The company said that a state police agency in the Midwest found the lie
    > detector 89 percent accurate, compared with 83 percent for a traditional
    > polygraph.
    
    What's the rate for false positives vs false negatives?
      [See the next item!  PGN]
    
    ------------------------------
    
    Date: Wed, 28 Jan 2004 11:31:14 +0100
    From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
    Subject: Re: Lie-detector glasses, 90% accurate? (Holzworth, RISKS-23.14)
    
    Steve Holzworth reported that the manufacturer said that "a state police
    agency in the Midwest" had found "lie detector glasses" to be "89%
    accurate".
    
    That figure doesn't tell us anything about the usefulness of the glasses. To
    obtain useful information, one needs to categorise errors as false positives
    (that you are identified as lying when you are in fact telling the truth. I
    shall call these Type 1 errors) and false negatives (that you are identified
    as truth-telling when you are in fact lying. I shall call these Type 2
    errors), and one needs to know the background rate of
    truth-telling/lying. The company spokesman did not offer the classification
    into types, and I doubt that he or the "state police agency" had any
    reliable information about the background rate of lying.
    
    To illustrate, let us interpret the "89% accuracy" statement as meaning that
    the instrument is in error in 1 out of 10 uses. I consider three cases with
    a 1 in 10 error rate.
    
    Case 1: The background rate is also 1 in 10, all errors are Type 2, and the
    instrument identifies no one as lying. Then Steve has zero chance of being
    falsely accused.
    
    Case 2: All errors are Type 1, and the background rate of lying is zero.
    Then Steve has a 1 in 10 chance of being falsely accused.
    
    Case 3: Errors are evenly split between Type 1 and Type 2, and the
    background rate of lying is 1 in 2. Then Steve has a 1 in 20 chance of being
    falsely accused. More worryingly, if he were to be intent on hijacking a
    commercial aircraft, he also stands a 1 in 20 chance of passing the test
    (Type 2 errors are 1 in 20)!
    
    Now, consider what it would take to establish the background rate of
    lying. Cut to the chase: it is difficult to impossible in serious use.
    
    More specifically: This rate is likely dependent on the community, as well
    as the selection procedure for testing, and it is also dependent on the
    social importance of the proposition against which truth-telling/lying is
    assessed. If everyone thinks lying is socially inappropriate, and you ask
    them if they had exceeded the speed limit sometime in the last year, and all
    know you have no possibility of enforcing sanctions given a positive answer,
    then you are likely to obtain a very high rate of truth-telling, maybe even
    perfect. On the other hand, if you sample a community in which more
    importance is attached to getting off the hook than it is to whether one
    tells the truth, but in which ceteris paribus truth-telling is preferred to
    lying, and you ask people whether they have committed specific unsolved
    murders, and sanctions are rigorously enforced, then everyone may well
    answer "no" to each question. In this case, the background error rate is
    identical to the unsolved-murder rate.
    
    If you are Hercule Poirot, and you know the murderer acted alone, then you
    know this rate (for, in his mysteries, there is a closed society, and
    everyone professes innocence at first). Otherwise, one would have to perform
    controlled experiment. Performing a controlled experiment is ipso facto
    selecting one very specific value of community parameter, and is not
    obviously a guide to communities which differ from that one.
    
    In short, in case it wasn't obvious anyway, the company spokesman is BSing,
    as are most people who claim to have measured the accuracy of lie-"detector"
    apparatus.
    
    Peter B. Ladkin, University of Bielefeld, http://www.rvs.uni-bielefeld.de
    
    ------------------------------
    
    Date: Fri, 30 Jan 2004 08:16:43 -0800
    From: Rob Slade <rslade@private>
    Subject: REVIEW: "Biometrics", Woodward/Orlans/Higgins
    
    BKBIOMTC.RVW   20031204
    
    "Biometrics", John D. Woodward/Nicholas M. Orlans/Peter T. Higgins,
    2003, 0-07-222227-1, U$49.99/C$74.95
    %A   John D. Woodward
    %A   Nicholas M. Orlans
    %A   Peter T. Higgins
    %C   300 Water Street, Whitby, Ontario   L1N 9B6
    %D   2003
    %G   0-07-222227-1
    %I   McGraw-Hill Ryerson/Osborne
    %O   U$49.99/C$74.95 905-430-5000 +1-800-565-5758 fax: 905-430-5020
    %O  http://www.amazon.com/exec/obidos/ASIN/0072222271/robsladesinterne
      http://www.amazon.co.uk/exec/obidos/ASIN/0072222271/robsladesinte-21
    %O   http://www.amazon.ca/exec/obidos/ASIN/0072222271/robsladesin03-20
    %P   432 p.
    %T   "Biometrics"
    
    The book is intended for both students and professionals, covering all
    of the aspects and uses of biometrics.  The chapters are written by a
    number of contributing authors.  For example, Richard E. Smith, author
    of "Authentication" (cf. BKAUTHNT.RVW) wrote the introduction found in
    chapter one.  It is an excellent precis of the uses of, and
    requirements for, authentication, paying particular attention to the
    use, strengths, and weaknesses of biometrics.  The functional aspects
    of biometric assessment; feature extraction, storage, error rates, and
    so forth; are covered well in chapter two.  (There is a rather odd
    confusion of genetic and phenotypic sources of biometrics: aside from
    behavioural measures and DNA testing itself, almost all biometrics are
    expressed characteristics, and therefore phenotypic.)
    
    Part two deals with types of biometrics.  Chapter four provides
    fascinating details on the history, technology, storage, indexing, and
    searching of fingerprint records, and a brief mention of hand
    geometry.  After the wealth of technicalities about fingerprints, the
    very basic explanations of enrollment of face and voice recognition
    are disappointing.  The material on iris and retina scanning, in
    chapter five, is slightly better, but signature and keystroke dynamics
    again get minimal coverage in chapter six.  Eleven of the more
    esoteric biometrics are briefly described in chapter seven, ranging
    from standards such as DNA testing to odd entries like sweat pore
    distribution or body odour.
    
    Part three looks at various aspects or factors to consider in
    implementing biometrics.  Chapter eight looks at the question of
    "liveness" testing.  (This is the biometrics topic beloved of students
    the world over: "What if you cut off the guy's finger and used that?" 
    Students tend to be rather gruesome creatures.)  Most of chapter nine
    is devoted to a guide for contracting out, or questions to ask
    contractors or vendors.  Various standards bodies are described in
    chapter ten.  Chapter eleven talks about issues involved in testing of
    biometric systems.
    
    Part four deals with privacy, policies, and legal issues.  Chapter
    twelve examines both the threats and the benefits that biometrics
    holds for privacy.  There is a detailed and interesting look at
    (mostly US) law and decisions relating to privacy, and the
    implications for biometric applications, in chapter thirteen.  Chapter
    fourteen does have brief case studies of the use of biometrics at the
    Super Bowl and in Virginia Beach, but concentrates on the legal
    issues.  Chapter fifteen deals with the American digital signature
    law, and the potential relation to the inclusion of biometrics in the
    process.  Some material is repeated from earlier chapters.
    
    Part five reviews selected biometrics programs.  Chapter sixteen
    covers government and military programs, most related to law
    enforcement.  Searching the FBI files of civil (or non-criminal)
    fingerprint files, in chapter seventeen, reiterates a fair amount of
    content from chapter four.  Private sector programs, in chapter
    eighteen, are primarily concerned with face recognition in casinos or
    a variety of systems for banks, but others are mentioned.  Chapter
    nineteen presents a very detailed and thoughtful analysis of the
    possibilities for a national identity card.
    
    Because this book is essentially a collection of standalone essays by
    a variety of authors, there is a great deal of overlap and duplication
    of material, and at times this repetition becomes annoying.  This is,
    however, the most useful and informative work on biometrics that I
    have reviewed to date, and the analysis, in particular, is
    comprehensive and even-handed.  I would recommend this as both a
    serviceable introduction to anyone who must work with biometrics, and
    as a guide to the controversies surrounding them.
    
    copyright Robert M. Slade, 2003   BKBIOMTC.RVW   20031204
    rslade@private      slade@private      rslade@private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    Date: 28 Jan 2004 (LAST-MODIFIED)
    From: RISKS-request@private
    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@private> with one-line body
       subscribe [OR unsubscribe]
     which requires your ANSWERing confirmation to majordomo@private .
     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.
       .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!
    => The INFO file (submissions, default disclaimers, archive sites,
     copyright policy, PRIVACY digests, etc.) is also obtainable from
       http://www.CSL.sri.com/risksinfo.html
     The full info file may appear now and then in future issues.  *** All
     contributors are assumed to have read the full info file for guidelines. ***
    => SUBMISSIONS: to risks@private with meaningful SUBJECT: line.
     *** NEW: 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 the Lindsay Marshall's Newcastle archive
     http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., 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 23.16
    ************************
    



    This archive was generated by hypermail 2b30 : Tue Feb 03 2004 - 12:14:27 PST