[risks] Risks Digest 22.69

From: RISKS List Owner (riskoat_private)
Date: Tue Apr 15 2003 - 16:51:07 PDT

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

    RISKS-LIST: Risks-Forum Digest  Tuesday 15 April 2003  Volume 22 : Issue 69
       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
    and by anonymous ftp at ftp.sri.com, cd risks .
    NSW forced to hand count poll result (Chris Maltby)
    Web Site for posting local election results crashes after virus attack 
      (Monty Solomon)
    UK Demon ISP suffers three-fold power loss (Walter Roberson)
    Nevada hospital system hack traced to Russia (Monty Solomon)
    Automated denial-of-service attack using the U.S. Post Office 
      (Bruce Schneier via Monty Solomon)
    Risks posed by online systems for college and graduate admissions 
      (Matt Hiller)
    Paypal Meets the Patriot Act (Solveig Singleton via Hanah Metchis)
    Risks of *not* being lost (David Lesher)
    Nova Scotia police track suspect with GPS (M Taylor)
    "Quick Deposit" systems (Gervase Markham)
    Double-barrelled surname costs disabled mother (Nigel Metheringham)
    New,comprehensive Federal rules on privacy of medical information 
      (Jack Goldberg)
    75+ organizations urge FBI NCIC database accuracy (Marc Rotenberg)
    Re: POW Social Security numbers revealed (Crispin Cowan)
    Re: The reality behind these laws (Bill Gunshannon)
    Re: Millennium trains taken off the tracks (Bob Frankston)
    Re: Friendly Fire (Peter B. Ladkin, Allan Goodall)
    Changing Domain Registration info without verification (risksat_private)
    Abridged info on RISKS (comp.risks)
    Date: Mon, 14 Apr 2003 18:24:16 +1000
    From: Chris Maltby <chrisat_private>
    Subject: NSW forced to hand count poll result
      "Computer problems have forced the New South Wales electoral office to
      start manually counting nearly 4 million upper house ballot papers.  NSW
      Electoral Commissioner John Wasson says it will be a mammoth task to have
      all the votes counted and preferences allocated before the declaration of
      the poll at the end of the month.  It is hoped the computer glitches will
      be fixed later this week, but Mr Wasson says he can not afford to delay
      the count any longer.  [...]
    My (slightly informed) guess is that the NSW Electoral Office acquired and
    made changes to the Australian Electoral Commission's election management
    software. The changes are to allow for the new NSW Upper House voting system
    and they have not been a success. This is probably due to inadequate testing
    as the changes to the Electoral Act were made quite some time ago.
    To give them some credit, it's quite a challenge to simulate an election
    with 4 million voters in a realistic way. My experience with testing the AEC
    software in the pre-outsourced mid-1990s was that the stresses imposed by a
    real election were always well in excess of anything that could be simulated
    -- and some elections were conducted with changes to the counting
    requirements made in the last few months before the election...
    I'll bet he's hoping the software starts working though. Mind you, it's hard
    to be all that confident in the results -- even leaving aside that the
    requirement for random sampling of papers in NSW upper house elections
    (unlike the Senate) makes exact reproduction of results problematic.
    The return of the writs is required by 29 Apr 2003 IIRC.
    Date: Sun, 13 Apr 2003 01:30:50 -0400
    From: Monty Solomon <montyat_private>
    Subject: Web Site for posting local election results crashes after virus attack
    A Web site designed to tally and publish the results of a local election in
    Will County, Illinois was unable to perform as expected because it was
    deluged with phony requests.  The Will County Director of Information
    Systems has informed the FBI.
      [Excerpted from SANS NewsBites April 9, 2003 Vol. 5, Num. 14
      along with Eugene Schultz's Editor's Note: 
        Although this news item might superficially appear to not be all that
        important, it is really quite significant.  There is considerable
        apprehension concerning computerized voting systems, and incidents such
        as this one will only increase the level of concern.  ES]
    Date: Tue, 15 Apr 2003 00:24:30 -0500 (CDT)
    From: Walter Roberson <robersonat_private>
    Subject: UK Demon ISP suffers three-fold power loss
    The UK ISP Demon suffered a multiple-failure power loss that left them with
    a backlog to process afterwards. The public grid went down, the backup
    generator had a control problem, and the standby batteries ran out before
    replacement parts for the generator could be located.
    Date: Sun, 13 Apr 2003 01:30:52 -0400
    From: Monty Solomon <montyat_private>
    Subject: Nevada hospital system hack traced to Russia
    The security of a small Nevada hospital's computer system was breached by a
    hacker who has been traced back to Russia.  The hacker routed the attack
    through the al-Jazeera Web site to make it look as if the attack came from
    the Middle East.  The hacker may have accessed employees' social security
    numbers and bank account information.  A Trojan horse program embedded in a
    game some employees had downloaded allowed the attackers access. The
    hospital's payroll system has been removed from the network and employees
    have been instructed never to install software or sign on to streaming
    Internet services.
      [Source: *USA Today*, 7 Apr 2003
      excerpted from SANS NewsBites April 9, 2003 Vol. 5, Num. 14
      along with Eugene Schultz's Editor's Note: 
        Employees installing software or signing on to streaming Internet
        services may have been a problem, but I wonder whether the hospital's
        failing to set requirements for and failing to enforce a baseline level
        of security may have had a lot to do with what happened here.  ES]
    Date: Mon, 14 Apr 2003 03:33:40 -0400
    From: Monty Solomon <montyat_private>
    Subject: Automated denial-of-service attack using the U.S. Post Office
    In December 2002, the notorious "spam king" Alan Ralsky gave an interview.
    Aside from his usual comments that antagonized spam-hating e-mail users, he
    mentioned his new home in West Bloomfield, Michigan.  The interview was
    posted on Slashdot, and some enterprising reader found his address in some
    database.  Egging each other on, the Slashdot readership subscribed him to
    thousands of catalogs, mailing lists, information requests, etc.  The
    results were devastating: within weeks he was getting hundreds of pounds of
    junk mail per day and was unable to find his real mail amongst the deluge.
    Ironic, definitely.  But more interesting is the related paper by security
    researchers Simon Byers, Avi Rubin and Dave Kormann, who have demonstrated
    how to automate this attack.
      [Source: Bruce Schneier's cryptogram]
    Date: Mon, 14 Apr 2003 11:28:52 -0700 (PDT)
    From: Matt Hiller <hillerat_private>
    Subject: Risks posed by online systems for college and graduate admissions
    Late last year, I sent out a number of applications to masters programs in
    computer science. Where possible, I submitted my applications by way of
    online application systems, and had my recommendation providers submit their
    recommendations online. (In fact, a number of programs charge an increased
    application fee to applicants who choose to submit their applications on
    paper rather than using the online system; paper seems to be deprecated.) I
    did not realize that in doing this I was exposing myself to a significant
    computer-related risk, as illustrated by my experience with the University
    of Virginia.
    I applied online to Virginia's MS program in computer science, and had my
    recommendations provided online. When I had yet to hear an admissions
    decision by early April, I called the department to find out when I could
    expect to know. I was informed that my application had not been evaluated
    because the paper file on which the admissions committee was basing its
    decisions seemed to be incomplete; it was missing one of the three required
    I was very confused by this, as I'd been using the online application system
    to track and confirm the successful arrival of all of my application
    materials. To my knowledge, everything was in order, and had been for quite
    some time. The recommendation thought to be missing had been submitted in
    mid-November. I pointed this out, and the "missing" recommendation was
    promptly found and added to the paper file, but by then the damage was
    done. Notices were already out to accepted applicants; the best that could
    be done for me was placement on the waitlist.
    What are the risks here? Generating paper applications from online may
    introduce errors, errors that will not be visible to the applicant. If these
    paper files are treated as authoritative -- if the online application is not
    consulted in the case of seeming incompleteness or inconsistency --
    applications may be passed over for no good reason at all.
    Date: Mon, 14 Apr 2003 14:35:01 -0400
    From: "Hanah Metchis" <hmetchisat_private>
    Subject: Paypal Meets the Patriot Act
    CEI C:\SPIN [Excerpted by PGN]
    Paypal Meets the Patriot Act, by Solveig Singleton, Senior Policy Analyst
      <http://www.cei.org/dyn/view_bio.cfm/163> , 
    Project on Technology and Innovation, CEI <http://www.cei.org/>  14 Apr 2003.
    Paypal has been in the news lately.  In this case, a Missouri prosecutor
    sent eBay a letter
    insisting that its recent acquisition, Paypal, was violating the Patriot Act 
    by processing payments from Internet gambling operations.  Internet gambling
    is illegal in the U.S., but about 5 million Americans use overseas sites;
    eBay discontinued Paypal's gambling operations last fall.  This comes on top
    of troubles Paypal has had with the New York attorney general
      <http://www.auctionbytes.com/pages/abn/y02/m08/i22/s01> and authorities in
    other states. So what's up with Paypal? Is something sinister going on
    there? Far from it.  Prosecutors may get paid by the public, but they don't
    always serve the public.  [...]
    C:\SPIN is produced by the Competitive Enterprise Institute.
    Date: Mon, 31 Mar 2003 10:59:17 -0500 (EST)
    From: David Lesher <wb8fozat_private>
    Subject: Risks of *not* being lost
    Seems many of the ""embedded"" media procured Thuraya brand sat/cell phones
    before departing. These are controlled by a ground station in Abu Dhabi, and
    to optimize performance, the phone locates itself with an on-board GPS and
    reports back that position to the ground station.
    Ooops, current exact location is one thing the US does NOT want the Other
    Guys to know. While you could in theory use triangulation or other schemes
    to locate any EM emitter, including a phone, making it easy for Them is
    hardly ever a good idea. The military has confiscated the phones.
    The competitor, Iridium, may well also do this too, but allegedly the GPS
    reporting can be turned off [how? hardware or ....software?]  and in any
    case, that ground station is in the US. Given that Iridium is running at all
    only because Uncle Sam bought a govt-wide license, one could hope that
    someone has considered the integrity of that aspect beforehand.
    Note that the FBI is mandating tracking of all domestic cell phones as well,
    with the already past due-date being slipped back time and again. Security
    at our myriad providers can not help but be worse than at that single
    Iridium ground station.
    And in both TV and real life, cops and FBI agents carry cell phones.  In the
    future will oh, Willy Sutton | John Brown | Jonathan Pollard | Paul Reubens
    be able to track the FBI agents tracking them?
    Risk: Be careful what you wish for; most swords do have two sides.
    Date: Tue, 15 Apr 2003 18:36:04 +0100
    From: M Taylor <mctaylorat_private>
    Subject: Nova Scotia police track suspect with GPS
    Police in Nova Scotia use the On Star system, a GPS based service included
    in the car to locate the car within minutes of contacting On Star operators
    in United States.  [Source: *Globe and Mail*, 15 Apr 2003]
      It is nice to know that occasionally technology increases risk of getting
      caught to criminals.  M Taylor  http://www.mctaylor.com/
    Date: Mon, 31 Mar 2003 16:13:00 +0100
    From: Gervase Markham <gervat_private>
    Subject: "Quick Deposit" systems
    I wandered into my branch of Barclays Bank in Enfield, UK, this 
    afternoon in order to deposit a couple of cheques. For quite a while, 
    Barclays has had a "Quick Deposit" machine - obviously old tech, green 
    text on a character-mapped screen, no buttons; you just insert your 
    envelope with the cheques and a deposit slip, and it prints a receipt.
    Recently, an additional machine of a newer design has been installed. 
    This one looks much more like a cashpoint - number keypad, buttons on 
    the side of the screen - and has card slots, cheque slots, and all sorts 
    of attachments. It's far harder to use and takes much more time than the 
    original. But its UI flaws are for another mailing list.
    This afternoon I walked up to it, and noticed that the screen said 
    "NTDetect 4.00". I watched in amazement as the NT 4 boot sequence 
    proceeded, via the "Press Space for Last Known Good menu" 
    (unfortunately, pressing of keys only revealed that none were mapped to 
    Space), the Blue Screen of Bootup (NT4 SP6, 128MB RAM), and the splash 
    screen ("with Internet Explorer"), to an NT 4 desktop, complete with 
    "Outlook Express" icon!
    Some startup scripts ran, which showed me that I was logged in as 
    Administrator, and then some sort of debugging application popped up. 
    Because it left me in a text input window in this debugging app, I was 
    able to work out the key mappings of the built-in keypad. The number 
    keys produced numbers, Cancel was Backspace and Enter was return. The 
    other keypad keys seemed to have little effect.
    Pressing the keys on the side of the monitor seemed to trigger 
    something, because several bits of attached machinery began whirring. 
    Shame it's not a cashpoint, I thought. I didn't try feeding bits of 
    paper into it. Other sundry error dialogs and DOS boxes gave me some 
    idea of the filesystem layout, running software and so on.
    After a couple of minutes, the scripts must have finished, because the 
    desktop disappeared to be replaced with "This Terminal is not in use" in 
    Barclays livery.
    The RISKS are many:
    - Using a general-purpose OS for an embedded application
    - Having the input and output devices connected before the embedded app
       is ready to accept input
    - Using an Administrator account to run your app
    - Mapping keys to their obvious equivalents (Return is dangerous;
       mapping "Enter" to e.g. "G" would have been safer)
    - Keeping debugging applications installed on production machines, and
       having them automatically invoked
    Date: 14 Apr 2003 10:54:08 +0100
    From: Nigel Metheringham <Nigel.Metheringhamat_private>
    Subject: Double-barrelled surname costs disabled mother
      A disabled mother of three has been barred from receiving tax credits
      worth 190 pounds a week because she is among hundreds of claimants whose
      double-barrel surnames are not recognised by Government computers.  Sue
      Evan-Jones has fought for more than three months to persuade the Inland
      Revenue that her surname has two parts after she was told the system was
      confused by hyphens.
    The fact that obvious input validation problems, and properly specifying the
    valid forms of input in the original design are still being got horribly
    wrong in 2003 fills me with despair.
    Date: Sat, 12 Apr 2003 22:59:51 -0700
    From: Jack Goldberg <jackgoldbergat_private>
    Subject: New comprehensive Federal rules on privacy of medical information
    The article in the 12 Apr 2003 *San Jose Mercury News*
    is an easy to read summary of the new Federal rules on privacy of medical
    information privacy, just being put into effect.  There is a very large body
    of literature on the general subject and on the development of the
    standards, and the set of rules itself is a huge body of text.  This reader
    sees lots of good intentions, but also lots of problems, such as how medical
    and computer personnel -- and citizens, can understand the complex rules to
    determine what is allowed and what is not, how to help a client know whether
    exercising an option is a good idea or not, whether implementation of the
    rules will be an intolerable burden on health care practice, and how the
    integrity of a given implementation can be verified and preserved.  On the
    last point, there seems to be no provision in the law for certification;
    rather it seems that it will be up to the courts to decide if the rules were
    violated in a particular case.  This development deserves attention.
    Date: Tue, 8 Apr 2003 12:34:55 -0400
    From: Marc Rotenberg <rotenbergat_private>
    Subject: 75+ Organizations urge FBI NCIC database accuracy
    A broad coalition of organizations across the United States has endorsed a
    letter urging the reestablishment of accuracy requirements for the FBI's
    National Crime Information Center (NCIC), the nation's largest criminal
    justice database.
    More than 3,000 individuals from 47 states and the District of Columbia have
    signed an online petition to the Office of Management and Budget (OMB) also
    supporting the Privacy Act accuracy requirements.
    The petition drive will continue until the OMB acts on the request.
    Individuals may sign the petition online at:
        [Excerpted for RISKS.  See RISKS-22.65 and 22.67 for items on the
        termination of the NCIC accuracy requirements.  PGN]
    Date: Fri, 04 Apr 2003 19:32:26 -0800
    From: Crispin Cowan <crispinat_private>
    Subject: Re: POW Social Security numbers revealed (Hirose, RISK-22.67)
    It is often suggested that disclosure of SSN's is a great risk. In the
    current climate, where SSN's are used to *authenticate* an individual ("tell
    us your SSN so we know it is you") that certainly is true.
    However, I suggest an alternate approach to solving the problem of identity
    theft. SSN's are hopelessly easy to obtain; attempting to curtail the
    broadcast of these numbers (e.g. hoping the Iraqi state television will
    control the release) is futile. Instead, I suggest that the US Government
    *prohibit* the use of SSN's as authenticators. If all of the US
    organizations that currently authenticate with SSN's were forced to use
    something else (anything else) the state of the identity theft crisis would
    improve drastically.
    The "*anything* else" part is important to this proposal. It is tempting to
    propose something prescriptive, specifying how organizations should
    authenticate people. However, I suspect that such prescriptions would make
    the law founder on impracticality, as organizations find high quality
    authentication difficult to implement for one reason or anther.
    In contrast, simply forcing organizations to choose something else at least
    has the scattershot effect that they are unlikely to choose all the same
    attributes, making wholesale identity theft much more difficult.
    Just me proposing this idea here and getting a few folks to agree that it
    would be beneficial is fun & all :-) but won't actually change anything.
    More constructive would be if those who do agree with the idea, and have
    more influence in the financial regulation space than I do, would take up
    the idea and start spreading it around.
    Crispin Cowan, Chief Scientist, WireX
    http://wirex.com  http://wirex.com/~crispin/
    Date: Sun, 13 Apr 2003 09:21:39 -0400 (EDT)
    From: Bill Gunshannon <billat_private>
    Subject: Re: The reality behind these laws (Re: Shalunov, RISKS-22.68)
    Assuming that the failure of one of the postulates results in the failure
    of the premise, we can put this one to bed.
    Since when is a NAT box "intended to conceal the actual origin of IP
    traffic"?  The intended purpose of NAT and the use it is put to in every
    case I am aware of is to allow persons with a single IP Address to have more
    than one host on their network that can all access the INTERNET and I am
    certain that is the reason LinkSYS gives for selling the products that have
    NAT built in.  On top of that, NAT hides nothing.  You still need at least
    one valid routable IP address and that address is traceable to a fixed
    location and person responsible.
    If the purpose of NAT were to "conceal the actual origin of IP traffic",
    what then of DHCP?
    The RISK here is that we start chasing after demons that don't exist while
    missing the ones that really do.
    Bill Gunshannon, University of Scranton, Scranton, Pennsylvania
    Date: Sat, 12 Apr 2003 23:31:09 -0400
    From: "Bob Frankston" <bob2at_private>
    Subject: Re: Millennium trains taken off the tracks (Colville, RISKS-22.68)
      "Train signals interfering with the frequency of the underground
      signalling system ... turning lights red for all following trains."
    I can't help but wonder what kind of signaling system was being used.  This
    seems to be an ancient analog system that uses the frequency as part of the
    message rather than a digital signal that has some independence from the
    path and would have some resilience. Turning a signal red in the absence of
    other information is understandable but why is the signal so fragile?
    I might not have commented were it not for the name "Millennium" train which
    would indicate a design that reflects today's understanding of
    signaling. Instead this seems to rely on old techniques such as the use of
    pristine frequencies because that's the only technique we knew a century
    Date: Mon, 14 Apr 2003 13:52:48 +0200
    From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
    Subject: Re: Friendly Fire (RISKS-22.65 to 22.68)
    In RISKS-22.68, I gave some figures from [1, Figure 1.1, p1-2] suggesting
    that the number of fratricide incidents in recent conflicts (from WW II) lay
    around 1% of casualties. The figure for Desert Storm/Shield that I gave was
    mistaken. The figures from FM 100-14 Figure 1.1 are:
                    World War II     Korea     Vietnam     Desert Storm/Shield
                       (1942-45)      (1950-53)  (1965-72)       (1990-1991)
    Accidents        56%            44%        54%               75%
    Friendly Fire     1%             1%         1%                5%
    Enemy Actions    43%            55%        45%               20%
    Paul Marks of the *New Scientist* pointed out to me that the UK National
    Audit Office takes a different view. It says that "American research shows
    that, historically, fratricide accounts for between ten and 15 per cent of
    friendly casualties during operations." [2, paragraph 1.5]
    FM 100-14 speaks simply of "losses". The UK NAO defines fratricide as
    "destruction of friendly or allied forces". It is possible that these are
    two different concepts. But it is also possible that people aren't counting
    very precisely. It's a shame that one cannot tell from either of these
    documents what the figures actually represent.
    [1] U.S. Army Field Manual 100-14, Risk Management, 23 April 1998,
    available from http://www.irwin.army.mil/g3/tacticalsafety.html
    [2] National Audit Office, UK, Combat Identification,
    Report by the Comptroller and Auditor General,
    HC661 Session 2001-2002: 7 March 2002, available from
    Peter Ladkin, University of Bielefeld, Germany http://www.rvs.uni-bielefeld.de
    Date: Mon, 14 Apr 2003 14:50:41 -0500
    From: Allan Goodall <agoodallat_private>
    Subject: Re: Friendly Fire (Van Meter, RISKS-22.68)
    Mr. Van Meter explains that the term "casualty" refers to persons "killed or
    injured". This is not correct. Casualties refer to persons killed, injured,
    or *missing*.
    "Missing" includes anyone whose whereabouts are unknown. The soldier may have
    been captured by the enemy, or they may have run away to -- possibly -- turn
    up later, or they may have been killed but their remains hadn't been
    identified or their remains were unidentifiable.
    I agree with Mr. Van Meter that confusion over the term "casualty" has
    caused much misinformation. In September 2002, on the 140th anniversary of
    the American Civil War battle of Antietam (the single bloodiest day in
    American history), CNN Headline News mentioned that there were 23,000 men
    killed in the battle. The total casualties were just less than 23,000, 3600
    of whom were killed (though many of the 1700 missing men were likely dead
    and buried in unmarked graves, and many of the wounded would die sometime
    later). This error is particularly ironic as Ted Turner is a Civil War buff.
    Allan Goodall  agoodallat_private  http://www.hyperbear.com
    Date: Sun, 30 Mar 2003 16:41:51 -0500
    From: risksat_private
    Subject: Changing Domain Registration info without verification
    I found a reference to a USPS Web site allowing anyone to issue a change of
    address via the web in a 1997 issue of RISKS.
      [Actually, it allowed you to print a form that you could mail in.
      See RISKS-19.18 to 19.20.  PGN]
    Here's a twist I recently noticed, as conveyed in a message I just sent
    Network Solutions:
      I just tried to login to my ******** account for the first time in a long
      time, and it is trying to force me to accept a service agreement before I
      can access my account.
      I don't know if it was in the previous service agreement, but this
      provision is UNACCEPTABLE:
      #  4) You agree that VeriSign is authorized, but not obligated,
      #  to use Coding Accuracy Support System (CASS) certified software
      #  and/or the National Change of Address program (and/or such other
      #  systems or programs as may be recognized by the United States
      #  Postal Service or other international postal authority for
      #  updating and/or standardizing address information) to change
      #  any address information associated with your account (e.g.,
      #  registrant address, billing contact address, etc.), and you agree
      #  that VeriSign may use and rely upon any such changed address
      #  information for all purposes in connection with your account
      #  (including the sending of invoices and other important account
      #  information) as though such changes had been made directly by you. 
      This USPS change-of-address can be done BY ANYBODY WITHOUT VERIFICATION at
      I DO NOT authorize that my contact information be changeable by anyone via
      this process. (The USPS site even lets the e-mail address be changed.)
      If you cannot remove this clause from my agreement to service, I will
      transfer my registration to Register.com, which does not have this
    Date: 29 Mar 2002 (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 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.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 21" for volume 21]
     http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
       Lindsay Marshall has also added to the Newcastle catless site a
       palmtop version of the most recent RISKS issue and a WAP version that
       works for many but not all telephones: http://catless.ncl.ac.uk/w/r
     http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
     http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
    ==> PGN's comprehensive historical Illustrative Risks summary of one liners:
        http://www.csl.sri.com/illustrative.html for browsing,
        http://www.csl.sri.com/illustrative.pdf or .ps for printing
    End of RISKS-FORUM Digest 22.69

    This archive was generated by hypermail 2b30 : Tue Apr 15 2003 - 17:20:38 PDT