[risks] Risks Digest 21.93

From: RISKS List Owner (riskoat_private)
Date: Tue Mar 05 2002 - 15:38:30 PST

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

    RISKS-LIST: Risks-Forum Digest  Tuesday 5 March 2002  Volume 21 : Issue 93
    
       FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
       ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
    
    ***** See last item for further information, disclaimers, caveats, etc. *****
    This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.93.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Malfunction shuts down computer-controlled amusement park ride (Chuck Hardin)
    A$ 22,000 in fines for missing car-toll transponder (Peter Trei)
    Air Transat emergency landing (John Johnson)
    Nick Petreley: Identity theft (Anthony W. Youngman)
    Metro: Time runs out for Domesday discs (Chris Leeson)
    RISKS to computers from society (Arthur J. Byrnes)
    Corporate Web sites leave cold steely feeling (Dan Jacobson)
    Tunneling too close to the person you're trying to protect: SafeWeb
      (David Martin)
    Privacy risk in Netscape 6 (Sim IJskes)
    Electronic Voting in Ireland (Peter Thornton)
    Re: Miami-Dade OKs touchscreen voting (Les Barstow, Mark Nelson)
    Re: The homograph problem (Partha)
    Re: Dangerous Characters (Dick Botting, Darrell Fuhriman, Bill McGonigle)
    REVIEW: "Security Fundamentals for E-Commerce", Vesna Hassler (Rob Slade)
    Abridged info on RISKS (comp.risks)
    
    ---------------------------------------------------------------------
    
    Date: Sat, 02 Mar 2002 08:57:38 -0600
    From: Chuck Hardin <chardinat_private>
    Subject: Malfunction shuts down computer-controlled amusement park ride
    
      http://news.bbc.co.uk/hi/english/uk/england/newsid_1850000/1850592.stm
    
      It was a perfect day in the capital for viewing the skyline from the giant
      London Eye.  But a computer problem made the 450-ft-high structure rotate
      too fast, and it was halted amid safety fears.  Engineers have been
      brought in to get the attraction, officially known as the British Airways
      London Eye, up and running again.
    
    This calls to mind Ben Morphett's narrative in RISKS-21.50 about a carnival
    ride which gave him a bad moment by displaying a blue screen of death just
    before it began its (planned?) rapid descent.  The difference is that in his
    case, the computer was merely providing some graphical effects and was not
    apparently responsible for controlling the ride.  Not so in this case.
    
    Four hundred and fifty feet is a long way to fall, or to be hurled, due to
    an ill-considered RISK.
    
    ------------------------------
    
    Date: Tue, 26 Feb 2002 15:20:10 -0500
    From: "Trei, Peter" <ptreiat_private>
    Subject: A$ 22,000 in fines for missing car-toll transponder
    
      A man used City Link more than 220 times without an e-tag, attracting at
      least $22,000 in fines, because he did not know it had become a toll road,
      the Melbourne Magistrates Court was told yesterday. [...]
      http://theage.com.au/articles/2002/02/26/1014704951335.html
    
    Some highways in Australia cannot be legally used without a radio tag.  This
    poor soul hadn't updated his address with the DMV.  The RISK lies in
    building systems which automatically rack up charges without limit, and no
    backup notification system.  A big flashing sign saying 'E-Tag missing!'
    might have helped.  Peter Trei
    
    ------------------------------
    
    Date:   Mon, 4 Mar 2002 15:36:27 -0500
    From: john.johnsonat_private
    Subject: Air Transat emergency landing
    
    I thought RISKS readers would be interested in a developing story in the
    news about a computer problem on the Canadian Air Transat flight that made
    an emergency landing in the Azores last summer.  Apparently, as early
    reports describe, a "computer program" incorrectly reported a fuel leak as
    an "imbalance".  To correct the "imbalance" the "computer program" diverted
    fuel from a good tank to the tank that was leaking thus both tanks were
    emptied.  Inflight.  The skill of the pilot and the availability of an
    island with an airport in the Atlantic Ocean averted a disaster.
    
    Source: Canadian Press, *Toronto Globe and Mail*, *Toronto Star*, & other
    Canadian newspapers
    
    ------------------------------
    
    Date: Thu, 21 Feb 2002 13:05:11 -0000
    From: "Anthony W. Youngman" <Anthony.Youngman@ECA-International.com>
    Subject: Nick Petreley: Identity theft
    
      http://www.computerworld.com/cwi/story/0,1199,NAV47-74_STO68446,00.html
    
    Nick Petreley's *Computerworld* column (18 Feb 2002) describes how some
    unknown person hijacked his phone account and made loads of long-distance
    calls "at his expense".  The saga goes from bad to worse as poor security
    and company incompetence frustrates his attempts to stop the fraud.
    
      [After noticing the frequent calls to Germany, Nick canceled his calling
      card and switched his long-distance carrier.  The person who had been
      piggybacking on his old card then managed to switch his new account back to
      the old carrier and make more calls.  It turns out that person had created
      a Web account for him, so that he no longer received statements.  The
      entire saga is a real horror story, and very well worth reading.  Lots of
      lessons to be learned.  PGN]
    
    ------------------------------
    
    Date: Mon, 4 Mar 2002 09:51:50 -0000 
    From: "LEESON, Chris" <CHRIS.LEESONat_private>
    Subject: Metro: Time runs out for Domesday discs
    
    The BBC's 1986 Domesday Project (a time capsule containing sound, images,
    video and data defining life in Britain) is now unreadable. The data was
    stored on 12-inch video discs that were only readable by the BBC Micro, of
    which only a handful still exist.  The time capsule contains "250,000 place
    names, 25,000 maps, 50,000 pictures, 3,000 data sets and 60 minutes of
    moving pictures.".  The article notes that the original Domesday Book
    (compiled in 1086 for tax purposes) is still in "mint condition".
    [Source: London *Metro*, 01 Mar 2002]
    
    Additional comments of my own:
    
    The BBC Micro, along with the original Sinclair Computers, was the computer
    that sparked off the "computer revolution" in the UK. The BBC Micro was
    especially popular in schools, whereas the Sinclair computers were more
    popular in the home.
    
    To be fair, the 1986 Domesday Project was in the days before the really
    rapid changes in technology came into force - the BBC Micro was not a bad
    choice of platform then, especially when you consider that there were very
    few other choices available (50,000 pictures alone take up a lot of space).
    
    Moral/Risk: If you are wanting long-term data storage, the format is just as
    important as the materials.
    
    This is not a new problem - It has appeared in Risks before (RISKS-21.56:
    'NASA data from 1970s lost due to "forgotten" file format' for one...), but
    is worth keeping in mind. I still have an old Commodore 64/128 disk with my
    (very) old account details on it - not that I have a C64/128 any more.  My
    permanent records, however, are the printouts.
    
    PS: "Domed... We are all Doomed..."
    
    ------------------------------
    
    Date: Sat, 23 Feb 2002 20:53:21 -0500
    From: "Arthur J. Byrnes" <arthurat_private>
    Subject: RISKS to computers from society
    
    Reading the various articles about buffer overflow and WiFi security
    problems, makes you think that Society has to worry about risks from
    computers.
    
    Then I have two incidents in one week that remind me that computers are the
    ones at risk.
    
    First a I get a misdirected plain-text e-mail from a major insurance company
    with login IDs, passwords, and usage instructions, (that seemed to come
    from one of those "Dummies" books).  As much as my curiosity wanted to try
    them out, my ethics stopped me.  A note to the company got an auto reply, no
    thanks, or inquiry about how/why I ended up with this seemingly important
    e-mail.
    
    Then later in the week I added a new Web site to my Microsoft Central
    account.  The welcome plain-text e-mail contained my login name and password,
    which is also my .Net login.  They made clients sign up for .Net in order to
    continue using their service.  (I'm glad I don't use it for anything else!)
    
    Two major companies that should have known better, put Society's computers
    at Risk, with a practice that is unpardonable.  Never send login IDs and
    passwords together...
    
    Arthur J. Byrnes  http://www.ajb.com
    
    ------------------------------
    
    Date: 28 Feb 2002 03:56:16 +0800
    From: Dan Jacobson <jidanniat_private>
    Subject: Corporate Web sites leave cold steely feeling
    
    Now that I have traded my corporate life for "back to nature", every once in
    a while there is a long term bond from my past life or something that is
    about to expire, hence I must log on to some corporate site, wherein right
    off the bat:
    
    Browser Upgrade                        
       Thank you for visiting Jackson National Life Insurance Company's
       Web site. We have noticed you are using an earlier version of null.
    
    Also, aren't those little lock symbols supposed to lock when asking for SS#,
    passwd, etc.?
    
    And don't you hate those Web sites that after filling in a long form, you
    are to pick which of the 50 states you live in... I get stuck here.  I would
    have used the toll free phone # but it is not toll free for me.
    
    OK, now turning to the AT&T Universal card site... Ah, AT&T, equal
    opportunity employer... OK, but still, cant use the Lynx browser... what if
    I was vision impaired?  And, why after establishing that I am not spam,
    cannot I have an e-mail conversation with these corporate giants about
    compatibility issues with their Web sites without having to "login to
    send/receive secure e-mail"... takes half of my modem session.
    
    http://www.geocities.com/jidanni/ Taiwan(04)25854780
    
    ------------------------------
    
    Date: Thu, 14 Feb 2002 16:50:52 -0500
    From: "David Martin" <dmat_private>
    Subject: Tunneling too close to the person you're trying to protect: SafeWeb
    
    A tunnel is the prototypical example of a security mechanism that doesn't
    compose well: it creates an end-to-end connection that can bypass
    intermediate scrutiny.  SafeWeb, the Web anonymizing service, fell into this
    trap by attaching the browser end of its tunnel too closely to the user and
    thereby bypassing meaningful browser protections.  The result is that users
    of the service are at higher risk of some types of privacy attacks than
    those who refrain from using the service.
    
    Note that SafeWeb's anonymizing service was shut down in December for
    business reasons.  However, its technology was licensed to In-Q-Tel (the
    venture capital firm funded by the CIA) and PrivaSec LLC.  PrivaSec is
    currently offering a public beta test of its service based on SafeWeb's
    technology at its Web site http://www.privasec.com.  For simplicity, we'll
    pretend the system is still running at safeweb.com in the rest of this
    article.
    
    First a quick SafeWeb overview: a SafeWeb user types in a URL.  It goes to
    safeweb.com within an SSL connection; SafeWeb sanitizes the requested
    content and delivers it back to the browser.  The origin server Web site
    only sees a connection from safeweb.com, and eavesdroppers near the user
    only see an encrypted connection to safeweb.com On-screen, SafeWeb uses
    frames to separate the SafeWeb controls from the requested content.  Let's
    call them the "control" and "content" frames.
    
    Now let's meet the protections: (1) simultaneously open windows or frames
    can only communicate with each other if they're from the same domain, (2)
    scripts stop running when a new page is displayed, and (3) cookies are
    available only to the domain that set them.
    
    The problem is that both of SafeWeb's frames are served from the same tunnel
    (https://www.safeweb.com/) even though their content comes from radically
    different sources: the trusted SafeWeb site on the one hand, and the
    untrusted third party site on the other.  Since both frames come from the
    same domain, the Web browser exposes each Document Object Model to the
    other: protection #1 is gone.
    
    Since the control frame is basically static, it's a great place for an
    attacker to tuck away any code that needs to persist throughout the browsing
    session -- like spyware.  So protection #2 is gone too.
    
    SafeWeb also wanted to support pseudonymous persistent cookies.  Since the
    content frame is always associated with a single privacy domain, they
    aggregated all of the pseudonymous cookies from sites a user might visit
    through SafeWeb into one "master cookie" associated with the fixed domain
    safeweb.com.  That way, the individual cookies all get stored on the user's
    computer in a slightly different form, and SafeWeb doesn't have to maintain
    any persistent state on their servers (and users don't have to log in to
    SafeWeb, etc.).  But this approach discards protection #3 as well.
    
    To exploit these lost protections, an attacker has to take control of one of
    the frames: the content frame is the obvious choice.  That turns out to be
    not too hard.  SafeWeb *requires* that JavaScript be enabled in the browser.
    Recognizing the risk, SafeWeb tried to sanitize scripts delivered to the
    content frame, but they didn't go nearly far enough.  The result?  By
    choosing to use this privacy enhancing system, users become vulnerable to
    having their IP address revealed, *all* of their cookies stolen, and the
    remainder of their privacy-"enhanced" browsing session silently transmitted
    to an attacker in spite of the layer of SSL protection.  This is not
    speculation; we have tested several effective exploits against the system.
    
    Discarding protection mechanisms is only justified if those protections are
    replaced by something stronger, or by something more valuable to the end
    users.  SafeWeb's system did keep its users' identities out of routinely
    gathered Web server logs.  But the cost was increased vulnerability to
    targeted attacks, and it's hard to say whether the system's users would
    consider this a good tradeoff.  There's no reason to think they would be
    aware of the tradeoff at all.
    
    Adding to the weirdness, we are told that this privacy enhancing service was
    subjected to a "stringent" technological review by the CIA.
    
    Details (24 pages, PDF) are available at
    http://www.cs.bu.edu/techreports/pdf/2002-003-deanonymizing-safeweb.pdf.
    
    In response to our observations, SafeWeb points out that their own service
    is no longer in operation, that their new products didn't inherit these
    problems, that the system was effective at resisting passive attacks, and
    that the adversaries they had in mind wouldn't have been willing to use
    attacks such as ours for fear of bad publicity.  They have also announced
    that they are developing a fix for their licensees, In-Q-Tel and PrivaSec.
    
    David Martin -- dmat_private
    Andrew Schulman -- undocat_private
    
    ------------------------------
    
    Date: Thu, 21 Feb 2002 21:05:43 +0100
    From: Sim IJskes <simat_private>
    Subject: Privacy risk in Netscape 6
    
    I just installed the Netscape browser version 6.2. I changed 'Internet
    search' options so that Netscape performed searches through Google instead
    of the Netscape search engine.
    
    Some browsing in the files that were installed led me to this line:
    
    action="http://info.netscape.com/fwd/lksidus_gg/http://www.google.com/search"
    
    in a file "SBWeb_02.src". It looked as if Google directed search requests
    are first sent to info.netscape.com. A quick look in the proxy server log on
    the server confirmed my suspicion.
    
    I guess that Netscape allows you to search other search engines than their
    own, but still wants to know what you are searching....
    
    P.S. a similar mechanism was also used in the 'SmartDownload manager' 
    some years ago, as i seem to remember (maybe still is).
    
    Sim IJskes, Leiderdorp, The Netherlands      |   simat_private
    
    ------------------------------
    
    Date: Mon, 25 Feb 2002 14:48:22 -0000
    From: "Peter Thornton" <Peter.Thornton@emr-radio.ie>
    Subject: Electronic Voting in Ireland
    
    Further to recent contributions on electronic voting, this is from the
    Web site of the Irish department of the environment:
      http://www.environ.ie/press/electvote02.html
    The "forthcoming general election" they refer to will be taking place in
    the next three months. I note that they will be using "an industry
    standard PC system". I presume that this means a Wintel box. 
     
    Green Light For Electronic Voting In Dublin North, Dublin West And Meath
    
    Mr Noel Dempsey TD, Minister for the Environment and Local Government has
    announced today (19 February) that the constituencies of Dublin North,
    Dublin West and Meath have been chosen as the pilot constituencies for the
    introduction of electronic voting.  "Subject to final testing of software,
    my intention is that the voters in Dublin North, Dublin West and Meath will
    be the first in the country to cast their ballots electronically. Thus, the
    forthcoming General Election should usher in a new age of efficiency in the
    voting process," said Minister Dempsey. "Electronic voting will dramatically
    speed up the counting process with results for the constituencies likely to
    be available within a half an hour of the final module, on which the cast
    votes are stored, being delivered to the counting centres."
     
    The electronic voting system to be used has been developed by the Dutch/UK
    company, Nedap/Powervote. The Nedap/Powervote solution will provide a
    'fullface' (large screen) machine which is successfully used in the
    Netherlands and in the German cities of Cologne and Dusseldorf.  Election
    preparation will be run from an industry-standard PC system and the
    completion of the count will also be carried out on a standard PC and
    programming unit.
     
    In the run up to the introduction of electronic voting, there will be an
    intensive public information campaign in the constituencies concerned to
    ensure that all voters will be familiar with the new method of voting.
     
    Peter Thornton, EMR Radio & Telemetry, Unit 11 Dunboyne Business Park
    Dunboyne Co. Meath  Tel: +353-1-8013161
    
    ------------------------------ 
    
    Date: Thu, 21 Feb 2002 07:03:28 -0700
    From: Les Barstow <lbarstowat_private>
    Subject: Re: Miami-Dade OKs touchscreen voting (Price/PGN, RISKS-21.90)
    
    With physical access to voting machines and/or the software used to
    control them, the only sure way to provide security is a paper record.
    
    Especially with OpenSource software, it becomes possible to recompile
    (and hence alter) any electronic-only record.  Closed Source software
    isn't any better - it lacks public accountability and scrutiny.  Someone
    could always create a new ROM, OS, or software image if given sufficient
    knowledge, bypassing any security system that has been put in place.
    
    So:  Print an OCR paper record when the voter finishes his vote.  He
    gets to check the paper copy and put it in a standard secured voting
    box.  The best parts are:
    
      (a) Since it's printed on demand, only the voter's candidate appears
          on the printout - the voter sees only who or what he voted for,
          or that he made no vote, and can easily check the paper before
          dropping it in the box.
      (b) Using OCR, independent auditing becomes easy.  The auditor needs
          little in the way of custom hardware or software to do the job;
          they only need to tweak their OCR readers.  Auditors could be
          chosen by mutual agreement of the candidates after the vote is
          completed (and only if a candidate determines he wants to have
          a recount), removing any temptation to bribe the auditing firm.
    
    Les Barstow, System Administrator, VR1, Inc. 
    http://www.vr1.com  lbarstowat_private
    
      [We've been talking about such schemes before here.  See Rebecca Mercuri's
      PhD thesis for a detailed analysis:
        http://www.notablesoftware.com/~evote  
      noted in RISKS-21.10,13,14,61.  PGN]
    
    ------------------------------
    
    Date: Fri, 22 Feb 2002 15:56:57 -0500
    From: Mark Nelson <mcnels1at_private>
    Subject: Re: Miami-Dade OKs touchscreen voting (Brain, RISKS-21.92)
    
    > The risks for vote-rigging on COTS systems [include]:
    
    e) Someone tweaks the compiler of the compiler of the compiler of the...
    
    See Ken Thompson's "Reflections on Trusting Trust"
      http://www.acm.org/classics/sep95/
    
    ------------------------------
    
    Date: Thu, 28 Feb 2002 19:16:12 +0530
    From: Partha <algologat_private>
    Subject: Re: The homograph problem (RISKS-21.91 and 92)
    
    I am a victim of one such problem. Our Indian bureaucrats in the Govt.
    owned ISP called VSNL decided to create domain names using a mixture of
    alphas and Arabic numerals. Resultant: I have an e-mail address containing a
    "one". It is impossible to make out the "one" from "lower case L", and as
    result of which I lose many many e-mails destined for me.  I have mitigated
    the problem to a certain extent, by adding a descriptive note in my
    signature box, but it is impossible to print such things on my visiting
    cards.  Notice that there is also a "lower case L" in the second field of my
    domain name "v-s-n-L". We (Indians) are perhaps the only ones in the world
    to have such confusing combinations of alphas and numerals in their domain
    names.
    
    When will we ever learn?
    
    PS: VSNL has now been "privatised". They changed the owners but they
    kept the brilliant employees who created this mad domain name.
    
    Dr. S. Parthasarathy, Algologic Research & Solutions, 78 Sancharpuri Colony, 
    Bowenpally, Secunderabad 500 011 - INDIA  Phone: + 91 - 40 - 775 1650
    
    ------------------------------
    
    Date: Thu, 21 Feb 2002 13:41:31 -0800
    From: Dick Botting <rbottingat_private>
    Subject: Re: Dangerous Characters (Lomas, RISKS-21.92)
    
    This looks like the "sanitization" procedures for user supplied data that is
    recommended for the Perl language.  Perl is used by many Webmeisters.
    Typically, it has to call other programs and uses a "shell escape" to do so.
    On UNIX boxes it does this in such a way that the shell interprets the
    passed data as a command.  An apostrophe is a string delimiter and so a
    stray blip can play havoc with string data...  A smart user can easily make
    the server execute any command.  Hence User data is sanitized by removing
    certain characters.
    
    Another solution is to avoid Perl. Scripts written in Bourne/Korn/Born Again
    SHell do not have this problem.  Care is still needed, but the removal of
    the usual suspect characters is not necessary.
    
    ------------------------------
    
    Date: 21 Feb 2002 13:49:09 -0800
    From: Darrell Fuhriman <darrellat_private>
    Subject: Re: Dangerous characters (Lomas, RISKS-21.92)
    
    I regularly have perfectly valid e-mail addresses rejected by Web forms
    because they contain a '+' sign.  Most Web sites seem to assume that anything
    not in the set [A-Za-z1-9_-] is invalid, even though the valid set defined
    in RFC 2822 is much larger than that.
    
    I wonder what's going to happen when, inevitably, e-mail addresses are
    allowed to be in Unicode.  I fully suspect that we'll suddenly find a large
    portion of the population unable to use their nifty new language appropriate
    addresses.
    
    ------------------------------
    
    Date: Thu, 21 Feb 2002 11:46:48 -0500
    From: Bill McGonigle <mcgonigleat_private>
    Subject: Re: Dangerous characters (Lomas, RISKS-21.92)
    
    Probably Waitrose is storing their orders in a SQL database.  In most SQL
    statements, apostrophes need to be escaped, typically as '' (that's two
    single quotes).  I've met so-called Web-site programmers to whom the notion
    of an escape character suggests something out of a prison-break movie.
    Often they notice a problem, with the database of course, when trying to
    store text with an apostrophe, so they put some 'error checking' code in to
    prevent those errors.
    
    ------------------------------
    
    Date: Mon, 4 Mar 2002 07:44:27 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Security Fundamentals for E-Commerce", Vesna Hassler
    
    BKSCFUEC.RVW   20020108
    
    "Security Fundamentals for E-Commerce", Vesna Hassler, 2001,
    1-58053-108-3, U$83.00
    %A   Vesna Hassler hasslerat_private
    %C   685 Canton St., Norwood, MA   02062
    %D   2001
    %G   1-58053-108-3
    %I   Artech House/Horizon
    %O   U$83.00 800-225-9977 fax: 617-769-6334 artech@artech-house.com
    %P   409 p.
    %T   "Security Fundamentals for E-Commerce"
    
    "The purpose of this book is to give an in-depth overview of all the basic
    security problems and solutions that can be relevant for an e-commerce
    application."  I'm sorry, but "in-depth overview" sounds a bit like "jumbo
    shrimp": it's an oxymoron.  And "all the basic security problems and
    solutions that can be relevant for an e-commerce application" covers a lot
    of ground.  (Which is, I suppose, why this text has twenty two chapters.)
    
    Part one explains the basics of information security.  Chapter one defines
    some of the basic jargon, but misses a number of the important fundamental
    terms.  For example, the relationship between threats, vulnerabilities and
    exploits is fairly basic to security and risk analysis, and yet all security
    problems seem to be lumped together as threats.  The examination of security
    mechanisms, in chapter two, is limited to cryptography.  Key management is
    restricted to X.509 certificates and Diffie-Hellman in chapter three.
    
    Part two looks specifically at security of electronic payment systems.
    Chapter four briefly lists a wide variety of payment systems.  A terse set
    of payment security problems is given in chapter five, while some seemingly
    random cryptographic solutions are given in six.  A little bit of math for
    functions directed at electronic cash and cheques is presented in chapters
    seven and eight, respectively.  Chapter nine describes the Internet Open
    Trading Protocol.
    
    Part three deals with communications security.  Chapter ten is a general
    look at networking.  Chapters eleven to fourteen examine different systems
    for security at different layers, but the depth of coverage is very
    inconsistent: extremely terse in some cases, with many gaps, and yet delving
    into minute detail in others.
    
    Part four examines Web security.  Chapter fifteen details the HyperText
    Transfer Protocol (HTTP), which is good, since few texts bother to do.
    Random topics related to Web servers make up chapter sixteen.  Web client
    security topics are dealt with somewhat better in chapter seventeen,
    although cookies aren't given any significant discussion.  Active content
    does get its own chapter: eighteen concentrates almost exclusively on Java.
    Chapter nineteen contains miscellaneous topics.
    
    Part five covers some special issues for mobile or agent computing.  Agent
    technology is described in chapter twenty, some cellular phone topics are
    reviewed in twenty one, and smart card security is discussed in twenty two.
    
    Well, overview it is.  The book does cover a variety of topics, although
    there are a great many gaps and holes.  However, "in-depth" can't be
    supported, except in a very few cases.  There are some topics that are
    discussed in excruciating detail, but they are definitely in the minority.
    As a college text this undoubtedly has its uses, but professionals or
    businesspeople will find the inconsistent coverage problematic.
    
    copyright Robert M. Slade, 2002   BKSCFUEC.RVW   20020108
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    Date: 12 Feb 2001 (LAST-MODIFIED)
    From: RISKS-requestat_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-requestat_private> with one-line body
       subscribe [OR unsubscribe]
     which requires your ANSWERing confirmation to majordomoat_private .
     [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-requestat_private> (Dennis Rears).
       .UK users should contact <Lindsay.Marshallat_private>.
    => 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 risksat_private with meaningful SUBJECT: line.
    => ARCHIVES are available: ftp://ftp.sri.com/risks or
     ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
       [volume-summary issues are in risks-*.00]
       [back volumes have their own subdirectories, e.g., "cd 20" for volume 20]
     http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
       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 21.93
    ************************
    



    This archive was generated by hypermail 2b30 : Tue Mar 05 2002 - 17:07:50 PST