[risks] Risks Digest 23.06

From: RISKS List Owner (risko@private)
Date: Tue Dec 09 2003 - 12:12:54 PST

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

    RISKS-LIST: Risks-Forum Digest  Tuesday 9 December 2003  Volume 23 : Issue 06
       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
    The current issue can be found at
    Electronic car doors trap man in Australian flood, nearly drown him 
      (Tony Healy)
    New official self-service litigation system available in England/Wales
      (Tony Ford)
    Software paraphrases sentences (Justine Roberts)
    The Eight Fallacies of Distributed Computing (Peter Deutsch via Roger Z)
    Human Factor? (Dave Brunberg)
    This number's ready for prime time (NewsScan)
    Re: Another large gas bill (Tom Hayhurst)
    Big money on the line, but no source code... (D G Rossiter)
    Nevada to apply slot-machine security to e-voting hardware? (David Brunberg)
    Re: Diebold ATMs hit by Nachi worm (Russ Cooper, Elinor Mills Abreu via 
      Lillie Coney)
    Voter-verified breadcrumb trail? (Dave Brunberg, PGN)
    Voting machines (William Ehrich)
    Re: "In-Security clearance" (Eric Dobbs)
    Re: Real purpose behind In-Security clearance program (Daniel Suthers)
    Nigerian scams (Ted Lemon)
    The Internet and the right to communicate (Monty Solomon)
    The Structure of an Accident (William Langewiesche via Monty Solomon)
    REVIEW: "Linux Security Cookbook", Barrett/Silverman/Byrnes (Rob Slade)
    Abridged info on RISKS (comp.risks)
    Date: Thu, 4 Dec 2003 12:06:39 +1100
    From: Tony Healy
    Subject: Electronic car doors trap man in Australian flood, nearly drown him
    The driver of a Honda CRV 4WD found himself trapped in his stranded vehicle
    in recent floods in Melbourne, Australia. The electrically driven windows
    would not wind down since the electrical system was underwater and, for some
    reason, he couldn't open the doors either. This might have been due to the
    pressure of the water outside or to other artifacts of the electrical system
    Date: Sat, 26 Jan 2002 15:43:09 +0000
    From: Tony Ford <tony.ford@private>
    Subject: New official self-service litigation system available in England/Wales
    Today's *Daily Telegraph* carries a *potentially* disturbing report
    describing a new service, "Money Claim Online", whereby individuals and law
    firms (solicitors) can issue most simple legal proceedings (where a sum less
    than UK pounds 100,000 is claimed, = US$140K)) and enforce judgments via a
    Web browser. The new service has been set up without publicity by the Lord
    Chancellor's Department, which runs the courts system in England and
    Wales. It seems that the system is accessible to the public now, although it
    has not been officially launched.
    People using the service are (oddly) referred to as "customers" .... and
    there is a Customer Help Desk ...
    The newspaper report is also viewable at this Daily Telegraph link on-line:
    The service can be seen on-line at:
    No details are apparent of what measures are taken to validate the identity
    of the claiming party or prevent other gross miscarriages of justice ....
    but it would appear that the potential exists for significant trouble ....
    even though the site warns that "vexatious litigants" are not allowed to us
    it (these are people who have abused the litigation system in the past to
    such an extent that they have been declared "vexatious litigants",
    restricting their ability freely to issue legal proceedings).
    PS: I am a lawyer myself, although I don't practise in this area .. but do
    work in-house for a large IT company ... these comments are offered purely
    in a personal capacity.
    Tony Ford, Guildford, Surrey, UK  MailTo:tony.ford@private
    Date: Fri, 05 Dec 2003 07:48:00 -0800
    From: Justine Roberts <jr4939@private>
    Subject: Software paraphrases sentences
    "Software paraphrases sentences" is the headline of a long story by Kimberly
    Patch in the 3/10 Dec 2003 issue of Technology Research News.  Worth a look.
    Although the research is presented as entirely benign and useful, I find its
    implications & goals rather scary, starting, perhaps, with the problem of
    student plagiarizers.
    Date: Tue, 09 Dec 2003 09:33:10 -0800
    From: "r z" <roger@private>
    Subject: The Eight Fallacies of Distributed Computing
    The Eight Fallacies of Distributed Computing
    Peter Deutsch
    Essentially everyone, when they first build a distributed application, makes
    the following eight assumptions. All prove to be false in the long run and
    all cause big trouble and painful learning experiences.
    1.  The network is reliable
    2.  Latency is zero
    3.  Bandwidth is infinite
    4.  The network is secure
    5.  Topology doesn't change
    6.  There is one administrator
    7.  Transport cost is zero
    8.  The network is homogeneous
    Date: Wed, 3 Dec 2003 09:35:42 -0500
    From: Dave Brunberg <DBrunberg@private>
    Subject: Human Factor?
    Seeing Mike Smith's review of "The Human Factor" reminded me of a phrase we
    have in the municipal water and wastewater treatment industry--we refer to
    "The Bubba Factor."
    Bubba is not merely human, he is the incarnation of Murphy's Law.  Bubba
    doesn't bother to check that the tank's too full.  Bubba caps off a
    pneumatic control line to a valve because he likes to operate it manually.
    Bubba figures that it's a good idea to change the plant's operating rate
    from 10% of capacity to 95% by manually making a step change in the feed
    pump setpoint.  Bubba forgets that when the clarifier sludge overflows into
    the reverse osmosis system that you can't just let the daylight shift take
    care of it.
    Most water/wastewater plants are not yet highly automated, and frequently,
    operators resist the trend to automate.  Bubba's clever, and he always finds
    a way to break the fail-safe.  In these situations, you walk a very fine
    line between making the plant so inflexible that operators cannot respond to
    unforeseen problems and giving Bubba a little too much latitude.
    Date: Wed, 03 Dec 2003 09:08:52 -0700
    From: "NewsScan" <newsscan@private>
    Subject: This number's ready for prime time
    Michigan State University grad student Michael Shafer has succeeded in
    identifying the largest known prime number to date, using a distributed
    computer network of more than 200,000 computers located around the world.
    The new number is 6,320,430 digits long and is only the 40th Mersenne prime
    to have ever been discovered (Mersenne primes are an especially rare breed
    that take the form of 2-to-the-power-of-P, where P is also a prime number).
    Shafer was taking part in the Great Internet Mersenne Prime Search (GIMPS)
    project, when the new number popped up. "I had just finished meeting with my
    advisor when I saw the computer had found a new prime. After a short victory
    dance, I called up my wife and friends involved with GIMPS to share the
    great news," said Shafer.  [*New Scientist*, 2 Dec 2003; NewsScan Daily, 3
    Dec 2003]
      [I suppose all of the contributors of machine time would be known as
      Mersenne-aries -- oxymoronically, because they were most likely unpaid.
    Date: Thu, 04 Dec 2003 13:25:52 +0800
    From: tom.hayhurst@private
    Subject: Re: Another large gas bill (Shapir, RISKS-23.05)
    > It's possible Mr Purdey has been charged for the gas used up
    > during the explosion that destroyed his house."  (*The Daily Telegraph*)
    Good joke, but sadly not true. While there are many web pages that attribute
    this story to the *Telegraph*, it doesn't appear in their archives.  A search
    of the Factiva news archives finds six references to Arthur Purdey in print,
    all in the comedy clippings sections of newspapers ("Girl floats out to sea
    on inflatable teeth; is rescued by man on giant lobster" and the like). The
    earliest reference, from a York local paper, in February 2003, gives no
    source, although the same publication attributes it to an unnamed Lancashire
    newspaper three months later.  Subsequent appearances give the original
    source as the *Telegraph* three times and the *Bangkok Post* once.
      [So it got more Bangkok for the buck in the latter paper.  PGN]
    Date: Thu, 4 Dec 2003 08:10:04 +0000
    From: D G Rossiter <drossite@private>
    Subject: Big money on the line, but no source code...
    Not quite as important as electronic voting programs, but still with
    big consequences.
    "In the College Bowl Race, the Crucial Players Are the Programmers".
    Apparently, the Bowl Championship Series rankings, which determine which
    lucrative post-season games a college can play, are partly determined by
    computer rankings.  The programmers refuse to give their algorithms, let
    alone their source code.  One complains: ""Now you want to look under the
    hood of my car" when asked about this; another says "The more you specify,
    the more you annoy the readers."
      [*The New York Times*, 04 Dec 2003]
    Date: 04 Dec 2003 19:43:27 -0500
    From: David Brunberg <brunberg@private>
    Subject: Nevada to apply slot-machine security to e-voting hardware?
    According to *The Reno Gazette-Journal* (link below), Nevada Secretary of
    State Dean Heller "plans to enlist the expertise of the Nevada Gaming
    Control Board to ensure the machines are secure and accurate."  The state
    maintains strict control and oversight of slot machines, presumably because,
    as the state's most visible industry, gambling must be seen by the public to
    be untainted.  One hopes that people will consider that getting a fair shake
    at the election box is at least as important as whether the quarter slots
    are on the up-and-up.  Avi Rubin (Johns Hopkins University) said he found
    major security flaws with the system used by one of the companies that is in
    the running for a contract to provide voting machines across Nevada.
    Date: Sat, 29 Nov 2003 00:31:01 -0500
    From: "Russ" <Russ.Cooper@private>
    Subject: Re: Diebold ATMs hit by Nachi worm (RISKS-23.04)
    Lest we forget, this is the "Risks Forum", not some weekday morning kids show.
    Steve Summit is "astonished" that a commercial product running on a Windows
    platform was affected by Nachi. This after how many months? This despite the
    fact that I could attribute problems with an infinite number of commercial
    IT products to the effect Nachi created? Oh, I'm sorry, but this is the
    "Risks Forum".
    Are many here surprised that Diebold sold "default installations" of its
    product on a Windows platform which was improperly designed? Are many here
    surprised that people bought the equivalent of the "off-the-shelf" version?
    Since they affirm the ATM was "infected", that means it accepted an inbound
    connection to TCP135. Now maybe some don't know, but I can see no reason why
    anything should be querying an ATM, for any reason, least of all via such a
    sensitive protocol. Now if you didn't know before, you may have learned from
    recent discussions about the August 2003 blackout, you don't query the
    endpoint. It either tells you its status, or you assume its dead. Either
    way, you're in control. Do I want to control an ATM's status, or do I want
    it to explain its status to me? If I'm not getting expected information from
    such a front line device, I, as a backend server, am simply going to stop
    listening to it and page a tech. Not sending expected info, or sending
    unexpected info, denote a problem...send the technician. I can't think of a
    reasonable design that involves the backend sending uninitiated queries to
    the ATM, ergo, there's no reason the ATM was left listening for inbound
    TCP135 queries. That's a design problem, not a problem with the OS or its
    That such devices are now placed on the same network as devices to which can
    be attached Nachi infected systems is, well, a problem. Its one thing to
    shut down ATMs because their backend servers can't be reached due to network
    congestion, its another thing to have an ATM compromised directly. Diebold's
    designed default installation clearly isn't intended to minimize risk, its
    intended to minimize support problems from customers who attempt to
    implement their product insecurely.
    Imagine if they disabled inbound TCP135 attempts. During implementation
    they'd get a surge of support calls from less than qualified implementers
    claiming they couldn't connect to the ATM remotely in order to configure
    Bottom line, is the risk here just not the unfortunately common risk that if
    I'm stupid I can blame someone else for not telling me I was stupid? If that
    isn't the risk, then the risk is that commercial vendors still allow me to
    shoot myself in the foot, and the media could make such wounds fester.
    Russ - NTBugtraq Editor
    Date: Tue, 09 Dec 2003 11:00:36 -0500
    From: Lillie Coney <lillie.coney@private>
    Subject: Re: Diebold ATMs hit by Nachi worm (RISKS-23.04)
    Computer security experts predicted more problems to come as Windows
    migrates to critical systems consumers rely on.  Bruce Schneier is quoted:
    "Specific purpose machines, like microwave ovens and until now ATM machines,
    never got viruses.  Now that they are using a general purpose operating
    system, Diebold should expect a lot more of this in the future."  John
    Pescatore, an analyst at Gartner, agreed.  "It's a horrendous security
    mistake," he said, of specific-purpose machines like ATMs running Windows,
    written for general purpose computers and for which Microsoft Corp. releases
    security fixes on a regular basis. "I'm a lot more worried about my money
    than I was before this."  Diebold switched from using IBM's OS/2 on its ATMs
    because banks were requesting Windows, said Steve Grzymkowski, senior
    product marketing manager at Diebold.  [Source: Experts Worried After Worm
    Hits Windows-Based ATMs, Elinor Mills Abreu, Reuters, 8 Dec 2003; PGN-ed]
    Date: Wed, 3 Dec 2003 09:23:42 -0500
    From: Dave Brunberg <DBrunberg@private>
    Subject: Voter-verified breadcrumb trail?
    The subject of e-voting has been hot of late (for very good reason) and many
    have pressed for the voter-verified paper trail.  This may be a good first
    step, but could also be a serious insecurity of the false-sense-of-security
    type.  When one votes for Joe Blow and gets a paper saying her vote went to
    Joe Schmo, she knows something went wrong.  Neglecting the fact that
    election officials may not be required to address the discrepancy, this at
    least gives the voter the knowledge that the system is broken.
    But what happens when you vote for Joe Blow and get a paper that says "Joe
    Blow"?  Is there any guarantee that the vote for J.B. is registered on the
    disk, or over the network?  What guarantee is there that no alterations
    occurred between the touchscreen station and the recording station?  Or that
    the software in the station hasn't been compromised to change 10% of the
    votes for J.B. to J.S. before recording but after printing?
    Once you get out of the actual voting station and the printer, what, if
    anything, guarantees that votes aren't swapped or dropped?  And, for areas
    where physical intimidation may be a factor, how can the voter be assured of
    anonymous voting when the printer spits out the name of their selections for
    anyone to see?
    The next obvious solution will be to require independent auditing of open
    operating code for all voting systems.  Can we do this without ensuring that
    we must have one programmer from each political party (and there are many)
    go over every single voting system?  Can we be sure that the auditors are
    honest?  Can we have multiple vendors or should we have a single, open
    design for every precinct in the country?
    Why not just admit that e-voting cannot be made secure without adding in so
    much complexity that it becomes prohibitively expensive or self-defeating?
    For simple punch-card systems, you could have a reader on site through which
    the electors would feed their cards.  The reader would report their choices
    back to them through a private interface (e.g., the video replay hoods used
    at U.S. football games).  If there was a problem, the voter would be given a
    new card to punch again.  Certainly, the readers could be compromised as
    well, but they could not actually change the punched votes.  If enough
    voters found discrepancies, that precinct would be deactivated until the
    cause was found.
    Date: Wed, 3 Dec 2003 14:42:46 PST
    From: "Peter G Neumann" <neumann@private>
    Subject: Voter-verified breadcrumb trail? (Re: Dave Brunberg, RISKS-23.06)
    Responding to the above message by Dave Brunberg:
    ONE.  COUNT THE PAPER, and let the electronics appease the media only for an
          UNOFFICIAL PRELIMINARY count.  The official count would be paper.
          (Vendor arguments that paper is unreliable are largely bogus.  Vendor
          arguments that their systems CANNOT have erroneous results are of
          course COMPLETELY BOGUS, ignoring insider fraud, programming screwups,
          and configuration errors.  Instead, they tend to argue that no
          "hackers" can break in, which is not the primary concern for polling
          place voting -- although it would be a serious concern for Internet
          for the duration of the election.  No fooling around with machines
          that indicate on the screen that your vote has been recorded for a
          candidate you did not vote for, where you are told that it is an error
          on the screen but is correct in memory -- as happened in Florida in
    THREE.  Why have electronic voting machines at all?  GOOD QUESTION.  The
          most compelling arguments are providing a nice voter interface and
          avoiding overvotes -- although we have reported cases of blank
          positions being counted as votes by miscalibrated optical scanners (or
          tampered ballots?), and there are also reports of chad knocked out of
          punchcards because of too-deeply-prescored chad slots, suggesting that
          some of the card-system overvotes are not the voters' faults.  But see
          the next message from William Ehrich, which has been said before but
          is worth saying again.  PGN
    Date: Tue, 2 Dec 2003 02:59:53 -0600
    From: William Ehrich <ehrich@private>
    Subject: Voting machines
    All the technical people seem to agree that a voting machine has to produce
    a piece of paper for audit trail, and some feel that that piece of paper
    should be the primary record of the vote.
    It seems an obvious extension of this idea to have the voter simply mark the
    piece of paper with a felt marker.
    That is in fact how we have been voting here.  [Minnesota.  PGN]
    It works well.
    There is a counting machine at the voting place to count the ballots.  If I
    don't trust that machine I can (in principle) recount them with a different
    machine or count them by hand.
    There is a RISK in using a computer where it is not needed and can do more
    harm than good.
    Date: Tue, 2 Dec 2003 15:23:20 -0500 (EST)
    From: "Eric Dobbs" <edobbs@private>
    Subject: Re: "In-Security clearance" (RISKS-23.04)
    Since I've had to use the EPSQ program that the author of the "In-Security
    clearance" article talks about, I understand his frustration.  The process
    of finding, downloading and installing the program is rather Byzantine.
    In its defense, though, there's some rather carefully-thought-out access
    control and encryption used to protect the personal data that's entered
    into the program - see the link below for details.
    It's a pain to use, however; the interface was designed using 16-bit Windows
    controls, so it looks horrid on anything newer than Windows 3.11, it can be
    rather unstable under Windows NT 4.0 and 2000 (better under XP), and the
    whole rigamarole of a website is a classic example of government IT in
    Date: Sun, 30 Nov 2003 12:59:45 -0800
    From: Daniel Suthers <dbs__usenet@private>
    Subject: Re: Real purpose behind In-Security clearance program (RISKS-23.04)
    An unknown poster detailed the process for applying to the US government for
    a security clearance.  After he followed all the steps, he was required to
    run a program on his PC which did.... nothing.
    It's not to hard to imagine that the program was assisting the clearance
    process by scanning the hard drive for signs of illicit activity or setting
    up a back door so the Feds could check it later.  Of course, one would have
    to be paranoid to even imagine the US government doing such a thing in the
    name of national security.
    I've noticed this trend in Federal programs.  They expect us to accept the
    risk of running unverified programs on our PCs as a requirement for doing
    business with them.  The have produced several "infection detection"
    programs that were released in executable form only.
    Since the Patriot Act was passed, there is a very real risk that some of the
    computer programs supplied by government agencies are, in some way, spyware.
    I can imagine wording in the "acceptance agreement" that would waive your
    rights to privacy upon installation of the various programs.
    I don't have a security clearance, and don't expect to need one, so you can
    include my name.  :-)
    Date: Sat, 29 Nov 2003 23:03:28 -0600
    From: Ted Lemon <mellon@private>
    Subject: Nigerian scams
    I think that many of the younger readers of RISKS are unaware that there is
    no need for an "addiction" or "mental illness" in the usual sense for
    someone to fall prey to these scams.  All you really need is to be old, and
    to have the maladies of old age.  A stroke, incipient Alzheimer's, whatever,
    and suddenly your mom or dad has been taken by the scammers, probably for
    everything they're worth.  This really could happen to someone you love, and
    it's no joke.
    Date: Mon, 1 Dec 2003 22:51:18 -0500
    From: Monty Solomon <monty@private>
    Subject: The Internet and the right to communicate
    by William J. McIver, Jr., William F. Birdsall, and Merrilee Rasmussen
    The development of the Internet challenges traditional conceptions of
    information rights. The discourse surrounding these rights and the Internet
    typically deals with each right in isolation and attempt to adapt long
    established understandings of each right to the new technological
    environment. We contend there is a need to address information rights within
    a comprehensive human rights framework, specifically, a right to
    communicate. This paper examines the development of a right to communicate
    and how it can be defined and implemented.
    Basis for a human right to communicate
    Satellites and communication rights
    Mass media mentality
    UNESCO and the right to communicate
    Politics and policy
    National initiatives
    Soft law
    Communicative law
    Opposition to a right to communicate
    Date: Sun, 30 Nov 2003 04:30:47 -0500
    From: Monty Solomon <monty@private>
    Subject: The Structure of an Accident
    The Structure of an Accident
    Atlantic Unbound, 22 Oct 2003
    William Langewiesche, the author of "Columbia's Last Flight," talks
    about the fundamental problems within NASA that led to the space
    shuttle's demise.
    Date: Tue, 9 Dec 2003 08:31:39 -0800
    From: Rob Slade <rslade@private>
    Subject: REVIEW: "Linux Security Cookbook", Barrett/Silverman/Byrnes
    BKLNSCCB.RVW   20031019
    "Linux Security Cookbook", Daniel J. Barrett/Richard E.
    Silverman/Robert G. Byrnes, 2003, 0-596-00391-9, U$39.95/C$61.95
    %A   Daniel J. Barrett dbarrett@private
    %A   Richard E. Silverman res@private
    %A   Robert G. Byrnes byrnes@private
    %C   103 Morris Street, Suite A, Sebastopol, CA   95472
    %D   2003
    %G   0-596-00391-9
    %I   O'Reilly & Associates, Inc.
    %O   U$39.95/C$61.95 707-829-0515 fax: 707-829-0104 nuts@private
    %O  http://www.amazon.com/exec/obidos/ASIN/0596003919/robsladesinterne
    %O   http://www.amazon.ca/exec/obidos/ASIN/0596003919/robsladesin03-20
    %P   311 p.
    %T   "Linux Security Cookbook"
    In the introduction, the authors state that this is not a security text, but
    a list of practical and individual pointers for improving security in
    specific areas.
    Chapter one covers how to take system snapshots with Tripwire, in order to
    detect changes that might indicate an intrusion or a virus.  The
    establishment of a firewall, using the iptables and ipchains utilities, is
    dealt with in chapter two.  Chapter three examines the control of access to
    various network services.  Authentication techniques and infrastructures are
    detailed in chapters four and five.  Protecting outgoing network
    connections, files, and e-mail are described in chapters six, seven, and
    eight respectively.  The material on testing and monitoring, in chapter
    nine, is the most extensive in the book, and provides a good introduction to
    Snort as well.
    This is good, practical advice, and makes an excellent reference for anyone
    dealing with the security of Linux in a networked environment.  In one sense
    the authors are right, for they stick to the nuts and bolts, without
    discussing security frameworks or theories.  In another sense they are
    wrong: this text does what the "hacking" books only pretend to do.  The
    authors of the genre of "Teach Total Idiots How to Hack and They Will
    Automatically Turn Into Security Experts" texts all imagine that they teach
    you how to harden/secure a system, but don't.  This does.
    copyright Robert M. Slade, 2003   BKLNSCCB.RVW   20031019
    rslade@private      slade@private      rslade@private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    Date: 7 Oct 2003 (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  ftp://www.CSL.sri.com/pub/risks.info
     The full info file will appear now and then in future issues.  *** All
     contributors are assumed to have read the full info file for guidelines. ***
    => SUBMISSIONS: to risks@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: http://www.sri.com/risks
     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/ .
     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 23.06

    This archive was generated by hypermail 2b30 : Tue Dec 09 2003 - 12:59:38 PST