[risks] Risks Digest 21.53

From: RISKS List Owner (riskoat_private)
Date: Thu Jul 19 2001 - 15:08:35 PDT

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

    RISKS-LIST: Risks-Forum Digest  Thursday 19 July 2001  Volume 21 : Issue 53
       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.53.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    Dashboard can fire water at sleepy drivers (John Arundel)
    Polarized sunglasses and car LCD displays don't mix (Henry Baker)
    Missile defense test radar glitch (PGN)
    Historical Risk: KORD, and N-1 Engine Failures (Ami Abraham Silberman)
    Software gives erroneous air navigation reading (Bill Hopkins)
    Even a fatal error can't kill it (Jim Haynes)
    Gaffe gives away minister's secrets (Paul Cornish)
    SSL encryption that isn't (Ron)
    FBI arrests Russian hacker visiting U.S. for alleged DMCA breach
      (Declan McCullagh)
    Savings Bank software upgrade goes awry (Jonathan Kamens)
    Risk when using "Cut and Paste" (Enrique G. Sauer)
    Re: The computer is taking over the train (Mark Lomas)
    Re: Unexpected network congestion: remote consequences of Seti@Home 
      (Eric J. Korpela)
    Re: "It's public data, so why not a public database"? (Geoff Kuenning)
    Abridged info on RISKS (comp.risks)
    Date: Thu, 19 Jul 2001 16:35:48 +0100
    From: John Arundel <johnat_private>
    Subject: Dashboard can fire water at sleepy drivers
    Annova notes an IBM system to stop drivers falling asleep at the wheel. It
    asks you questions and if you fail to respond promptly, it shoots a jet of
    cold water over you.  http://www.ananova.com/news/story/sm_355015.html
    In the time-honoured phrase, "the RISKS are obvious".  I wouldn't like
    to imagine the consequences if a driver was unexpectedly soaked with ice
    water during a high-speed overtaking manoeuvure on a motorway...
      [FORDing the flood?  CHEVY to the levee?  NOVAcaine mutiny?  PGN]
    Date: Wed, 18 Jul 2001 19:16:25 -0700
    From: Henry Baker <hbaker1at_private>
    Subject: Polarized sunglasses and car LCD displays don't mix
    I just got some new (linearly polarized) sunglasses, and got an unpleasant
    surprise -- I can't read the LCD displays on either my car or my wife's car
    without cocking my head to one side!  On my car, I have to cock my head to
    one side by about 15 degrees, while with my wife's car I have to cock my
    head to the other side by about 40 degrees.
    Luckily, the same angle of cocking seems to work for all of the LCD gauges
    at the same time.
    (I just tested my sunglasses on my laptop, and I have to cock my head left
    by 45 degrees to get the brightest image.)
    Considering the fact that polarized sunglasses are often better than
    unpolarized sunglasses, because they do a better job of filtering out glare
    (highly likely to be polarized), we actually have one safety item
    interfering with another.
    Why can't car manufacturers install LCD's in such a manner that the
    polarization is compatible with polarized sunglasses?
    Henry Baker <hbaker1at_private>
      [We all hope you do not go off half-cocked.  This reminds us of the
      problem of pilots on Viagra seeing various colors (including green)
      as blue.  Blue who?  PGN]
    Date: Tue, 17 Jul 2001 22:16:19 -0700 (PDT)
    From: "Peter G. Neumann" <neumannat_private>
    Subject: Missile defense test radar glitch
    The missile defense test on 14 Jul 2001 was declared a success.  However,
    the Pentagon initially failed to note that the prototype radar had actually
    indicated that the interceptor had missed the dummy warhead.  This omission
    was considered unimportant because the glitch was a minor computer
    programming error that could easily be fixed in time for the next test.  Is
    that reassuring to RISKS readers?
    Date: Tue, 17 Jul 2001 10:50:19 -0400
    From: Ami Abraham Silberman <silberat_private>
    Subject: Historical Risk: KORD, and N-1 Engine Failures
    The following is forwarded with permission of the author, Patrick Flannery
    <flannerat_private>. It originally appeared in sci.space.history
    The N-1 was the Soviet equivalent to the U.S. Saturn V, it was to have
    launched the first Soviet manned lunar missions. It used a cluster of 32
    rocket engines on the first stage. To handle automatic shutdown in case of
    emergency or failure, they used an automatic system named KORD.  - Ami
    Silberman (silberat_private)
    What KORD was designed to do, and what KORD did, in detail: KORD was
    designed to shut down a maximum of four motors on the first stage- i.e. two
    malfunctioning motors, and the two motors 180 degrees opposite of them; and
    increase burn time of the affected stage to compensate; if more than four
    motors needed to be shut down, then KORD shuts all motors down.(On the
    second stage KORD would shut down a maximum of two motors of the eight, in
    the same way. On the third, four engined stage, only the defective motor was
    shut down, and the other three gimbaled to compensate.)  This would have
    been good for an on-pad abort during motor startup, and could have saved the
    Flight #1 Feb.21,1969- Within seconds of liftoff, two of the first stage
    motors (#12&24) were shut down erroneously by KORD; the flight continued,
    but at 66 seconds a Lox line ruptured, starting a fire, and KORD shut the
    stage down at 70 seconds, and fired the escape tower on the spacecraft
    successfully! Go KORD! KORD had begun to work it's "special" magic....
    Flight #2 July 3rd, 1969- Day of The Big Fireworks- Almost immediately on
    ignition, motor #8 eats something-a bolt, welding slag, temperature sensor-
    stories vary; the result doesn't- turbopump blades come flying out of the
    housing like bullets, and sever electrical lines, and fuel and oxidizer
    lines on nearby engines, starting a large fire in the base of the first
    stage. At only a few hundred feet altitude, KORD attempts to shut down all
    motors...and is 29/30ths successful in this endeavor, leaving one motor
    running, to neatly tip the booster 90 degrees before impact on, and
    destruction of, it's launch pad. The escape tower is again fired
    successfully! Go KORD! Some stories state that another N-1, on the other
    pad, gets caught in the ensuing explosion's shock waves, and has to be
    Flight #3 June 27,1971- With preternatural cunning, the Soviets have decided
    that it might be wise to PLAN for having the N-1 fail, and have programmed
    in a maneuver to get it clear of the launch pad immediately after liftoff-
    this maneuver is performed- and promptly overstresses the airframe, and
    control system, causing the rocket to fall apart in midair, and crash- but
    it does NOT crash on the launchpad- Success! KORD dutifully shuts down the
    first stage motors... a while after the third stage, and lunar spacecraft
    assembly, have already fallen off. The escape tower? Comrade, it was a
    mock-up. Boom.
    Flight #4 Nov.23, 1973-With an augmented control system to allow it to do
    the pad clearing maneuver before it explodes, the N-1 once again vaults
    skyward....and keeps on going! Fifty seconds- all systems go!! 70
    seconds-still go!!! 90 seconds- shut down of the center six motors, as
    planned!!!! 95 seconds- the center six motors are now on fire!!!!! 110
    seconds-Boom.  But the escape system worked! Go KORD!  Later it is
    discovered that if KORD had shut down the first stage motors when the
    trouble started, and fired the second stage at that time, then the mission
    would have reached orbit. Go KORD!  This then, was the apex of Soviet 1960's
    electronic...or at least electric, design- a safety system that both causes,
    and worsens, disasters.  Who says we can learn nothing from Soviet
    spacecraft design? The KGB wants to know, comrade...who specifically said
    that; and what's their address?
    The MITRE Corporation;W078 - C2 Systems Architecture and Integration
    12 Christopher Way;Eatontown;New Jersey;07724 (732)578-6645
    Date: Mon, 16 Jul 2001 19:32:50 -0400
    From: "Bill Hopkins" <whopkinsat_private>
    Subject: Software gives erroneous air navigation reading
    AVweb (www.avweb.com), a news service for general aviation, reported July 9
    that the FAA has issued an Emergency Airworthiness Directive (AD) on one
    model of Apollo NAV/COM (a combined navigation and communication radio) with
    a specific DSP Software Version Number, because its bearing indication was
    found to be off by as much as 14 degrees.  The Emergency AD prohibits any
    flight in an aircraft equipped with the radio until it is marked "Use
    ... for navigation prohibited."
    The navigation function relies on special ground stations that (simplifying
    a bunch) transmit a signal that varies the phase of the modulation with
    azimuth, allowing the radio to infer its bearing from a station within a
    degree or two.  An aircraft flying a circle around a station sees the
    modulation change smoothly.
    For many aircraft, this is the primary navigation system when flying by
    instruments, in clouds.  Fifty miles out and 14 degrees off could put you in
    conflict with FAA airspace rules (bad, takes explaining) or mountains
    (worse, takes a funeral).  In comparison, suddenly not being able to fly by
    instruments doesn't look so bad.
    The AD text suggests that some stations do not adhere to the nominal 30 Hz
    modulation frequency, but the DSP software depends on the assumption that
    they do.  I would guess that bench-testing was done only with nominal
    generated signals, and certification flight testing (if needed) only with
    stations that happened to be nominal.  So, no problems showed up until a
    technician happened to test a new installation in the presence of a
    non-standard signal.
    Risks: assuming, testing within assumptions, having software in the gauges,
    Bill Hopkins (whopkinsat_private)
      [We need a too-fazed commit with 14 degrees of separation.  PGN]
    Date: Mon, 16 Jul 2001 23:58:01 -0500 (CDT)
    From: <jhaynesat_private>
    Subject: Even a fatal error can't kill it
    or "night of the living dead"
    I just made an airline reservation using the web page.  When I got all the
    way to the end, having put in the credit card information, it said "Fatal
    error in backend" and gave an error number and dumped me out.  So I
    assumed (foolish assumption) that the thing had failed and started all
    over.  The second time everything worked as it should.  Then I read my
    email and found I had email confirmations for both of the reservations.
    So I called the airline and got connected to a tech support person and he
    said yep, I've got two reservations on the same flight and he would cancel
    one of them and they would issue a refund to my credit card for it.  He
    said the software is supposed to catch cases of the same person making two
    reservations on the same flight but in this case that didn't work either.
    For me, this is a case of deja vu all over again.  Some ten or more years
    ago I reported using an online banking money transfer system where I put
    in all the data and then the computer voice said "system error, session
    terminated"  So I put the transaction in a few more times over the space
    of a few days, until I got the normal "data accepted, thank you" message.
    And soon after got a call from the bank about the account being way
    overdrawn, because in fact each of the transactions had gone through.
    No doubt there are other systems out there which have the possibility of
    completing a transaction and then telling the user that there has been a
    fatal error.  Maybe a whole lot of them.
    Date: Tue, 17 Jul 2001 10:03:53 +0000
    From: Paul Cornish <paul.cornishat_private>
    Subject: Gaffe gives away minister's secrets
    A series of government initiatives have been accidentally made public after
    the "wrong" version of a speech by cabinet minister Stephen Byers was
    released.  Civil servants unintentionally circulated an electronic copy to
    interested bodies which can be opened to reveal which passages have been
    removed or added during drafting.  For more information see
    The Guardian Newspaper, Society Section, Thursday July 12, 2001.
    Paul Cornish <Paul.cornishat_private>
    Date: Tue, 19 Jun 2001 10:02:51 -0400
    From: Ron <ron1at_private-abuse.org>
    Subject: SSL encryption that isn't
    If you submit your information to an SSL protected web page you're
    protected, right?  Not always.
    Check the EAA (Experimental Aircraft Association) web page that lets you
    join online.  You can find it at
    It looks good, and the browser indicates that it's 128-bit encryption.  It
    inspires confidence until you look at the page source.  Here's a couple of
    relevant lines [NOTE: I've modified the Email address to avoid spambots]:
      form METHOD="POST" ACTION="..\send_email.asp"
      input type="hidden" name="EMAILTO" value="joineaaat_private"
    It certainly appears that this 128-bit encrypted SSL form proceeds
    to send out your sensitive information via Email in cleartext.  I
    verified this by modifying the form to send mail to me.  I then tried
    it.  Sure enough, the entire form is sent in clear, including credit
    card number.
      [ADDED NOTE, 17 Jul 2001: I notified the site owner at the same time I
      mailed RISKS.  The site is still unchanged.  Ron]
    Date: Tue, 17 Jul 2001 10:57:48 -0400
    From: Declan McCullagh <declanat_private>
    Subject: FBI arrests Russian hacker visiting U.S. for alleged DMCA breach
    Russian Adobe Hacker Busted
    By Declan McCullagh (declanat_private), 17 Jul 2001
    LAS VEGAS -- FBI agents have arrested a Russian programmer for giving away
    software that removes the restrictions on encrypted Adobe Acrobat files.
    Dmitry Sklyarov, a lead programmer for Russian software company ElcomSoft,
    was visiting the United States for the annual Defcon hacker convention,
    where he gave a talk on the often-flawed security of e-books.  This would be
    the second known prosecution under the criminal sections of the
    controversial Digital Millennium Copyright Act, (DMCA) which took effect
    last year and makes it a crime to "manufacture" products that circumvent
    copy protection safeguards.  [...]
    POLITECH -- Declan McCullagh's politics and technology mailing list
    You may redistribute this message freely if you include this notice.
    To subscribe, visit http://www.politechbot.com/info/subscribe.html
    This message is archived at http://www.politechbot.com/
    Date: Mon, 16 Jul 2001 23:05:46 -0400
    From: Jonathan Kamens <jikat_private>
    Subject: Savings Bank software upgrade goes awry
    My bank, Peoples Federal Savings Bank in Brighton, Massachusetts, "upgraded"
    its computer software on the weekend of June 9.  No explanation of the
    purpose of this upgrade or description of the changes customers might see as
    a result of it was distributed, either before or after the upgrade).  The
    only notice given was a few signs posted at the bank, stating that the bank
    would be closed over the weekend for the upgrade.
    To say that the upgrade went poorly would, from my point of view, be a huge
    understatement.  Here's some of what went wrong (but, alas, not all of it;
    I'm omitting some of the minor screw-ups):
    * All customers' telephone-banking (TB) PINs were reset as part of the upgrade.
      As I noted previously, customers were not informed about this in advance.
    * The new, default TB PIN chosen for all customers is the last four digits of
      the primary account holder's social security number.  I'm sure I don't have
      to go into how monumentally stupid this is from a security point of view,
      especially considering that many Massachusetts residents have their social
      security numbers on their driver's licenses.
    * Since the upgrade, the TB system tells you to enter the last four digits of
      your SSN as your PIN if this is your first time using the system, or your the
      PIN you've selected otherwise.  However:
      * It doesn't make it clear to previous customers of the bank that "the
        system" means the new TB system after the upgrade, i.e., that PINs set in
        the old TB system were no longer valid.  You just had to figure that out by
        trial and error.
      * The system doesn't force you to change your PIN from the default to
        something else.  So the "if this is your first time using the system"
        prompt is completely wrong, since the PIN will remain the default until you
        navigate about three levels deep in obscure menus to change it.  And I'm
        sure I don't have to go into how monumentally stupid it is from a security
        point of view that the system doesn't make people change the default PIN.
    * When you requested a transfer in the old TB system and it read the
      information back to you for confirmation before performing the transfer, it
      read the amount of the transfer first, followed by the account numbers.  This
      is logical, considering that (a) the amount of the transfer is the item most
      likely to have been entered incorrectly and (b) the account numbers have
      already been verified as valid by the system.  The new system, on the other
      hand, reads both the "from" and "to" account numbers first, v-e-r-y
      s-l-o-w-l-y, before reading the amount of the transfer.
    * The old TB system's transfer confirmation numbers were eight digits long,
      which was already pushing it.  The new system's confirmation numbers are ten
      digits long.  There is no excuse for forcing people to write down random
      strings of ten digits which could just as easily have been half that length
      if the UI had been designed properly.
    * I can no longer access my money market account from SUM ATM machines (see
      www.sum-atm.com) run by banks other than Peoples.  Before the upgrade, my
      money market account was accessible as my "savings" account from these ATMs.
    * Before the upgrade my money market account was also accessible as a "savings"
      account from Peoples ATMs.  Now, however, People's ATMs think that my money
      market account is a "checking" account, which means that I have two checking
      accounts.  Therefore, when I need to access my money market account, I select
      "checking" and get a menu to choose which checking account I want.  The menu
      looks like this:
    	1. CHECKING
    	2. CHECKING
      That makes it intuitively obvious which one to select, eh?  I had to figure
      out through trial and error that "1" is my old checking account and "2" is my
      money market account.
    * That same menu screen tells me to press Enter after using the keypad to
      indicate which account I want to access.  But Enter doesn't work -- it gives
      the low "error beep."  I had to figure out by trial and error that when they
      say "Enter", what they really mean is "the unlabeled button at the bottom of
      the column of buttons to the right of the screen."
    * When I made a deposit shortly after the conversion, the printed receipt for
      the deposit showed the same amount for both "balance" and "available
      balance," even though the deposit I had just made was supposed to show up
      immediately in "available balance" (that's how the system behaved before the
      upgrade).  I complained to the bank about this through their Web site (well,
      actually, I complained to the bank about *all* the problems listed above, but
      this is the only one about which they responded), and I got back a pointless
      E-mail message from the bank's Operations Officer describing to me how the
      system was supposed to work (which is what I had just described to him in my
      complaint).  I wrote back to him and emphasized again that the system was
      *not* working that way, and he never responded.
      However, two days later when I made another deposit, *no* balances showed up
      on the receipt.  Shortly after that, when I made another deposit, the
      balances were back and the "available balance" correctly reflected the
      deposit I had just made.  So it would seem that the bank is capable of
      correcting these problems, albeit not acknowledging and apologizing for them.
    * When my first statement after the upgrade arrived, I saw that I had been
      charged a $.75 ATM fee, even though I had only used Peoples and SUM ATMs all
      month, and those are supposed to be free.  When I called the bank about this,
      I was informed that "everyone was charge 75 cents because the upgrade messed
      everything up," and that the 75 cents would be credited back to my account in
      my next statement.  We'll see.
    * Before the upgrade, they sent out a final statement under the old system with
      a closing date of June 8.  No interest was paid on that statement.  After the
      upgrade, the next statement they sent out closed on June 30.  The interest
      paid out in that statement correctly covered the period of the previous
      statement (i.e., they paid about 30 days of interest instead of 22).
      However, the average daily balance used to calculate the interest payment
      took into account only daily balances from June 9 through June 30.
      In other words, the bank underpaid interest to any customers whose average
      daily balance was higher June 1-8 than it was June 9-30.  Of course,
      conversely, the bank paid extra interest to customers whose averages were
      lower before the upgrade, but that doesn't help the customers who were
    As I'm sure you can imagine, after this debacle I'm not too keen on continuing
    to patronize Peoples.  However, my fear is that when I look for alternatives,
    I'm going to discover that there isn't anybody better.
    Jonathan Kamens
    Date: Wed, 18 Jul 2001 10:30:48 +0000 (GMT)
    From: enrique.g.sauerat_private (esauer)
    Subject: Risk when using "Cut and Paste"
    I just became aware of a serious security risk involving the combined use of
    WinWord and Excel in Office 2000.
    While writing a report in WinWord, I incorporated a graph generated via
    Excel via "cut and paste". Later on, using a different computer, I decided
    to edit the title of the graph by double clicking on it. To my dismay, the
    *entire* content of the Excel file which was not residing in the computer
    where I was doing the editing, became available to me.
    Say you have the unclassified "Graph 1" in sheet 1 of an Excel file and the
    classified "Graph 2" in sheet 2 of the same file. When you incorporate Graph
    1 in the unclassified portion of your report you are inadvertently making
    Graph 2 available to the user.
    To avoid this problem use "paste special", you will not be able to edit your
    graphs by double clicking on it, but you will avoid potentially embarrassing
    Date: Tue, 17 Jul 2001 12:39:15 +0100
    From: "Mark Lomas" <mark.lomasat_private>
    Subject: Re: The computer is taking over the train (Cohen, RISKS-21.51)
    I am reminded of a journey on Thameslink (for those outside the UK, this
    company runs trains between Bedford and Brighton via London).  The driver
    decided to brake suddenly - I don't know why, however I remember his
    subsequent announcement to passengers: "You may be wondering why we have to
    wait here.  This train is fitted with a safety system which prevents the
    driver from accelerating following sudden braking.  The computer will give
    me back control of the train in another minute".
    This is probably a sensible (but not infallible) safety precaution.
    Mark Lomas <r21.51@absent-minded.com>
    Date: Tue, 19 Jun 2001 18:39:47 -0700 (PDT)
    From: "Eric J. Korpela" <korpelaat_private>
    Subject: Re: Unexpected network congestion: remote consequences of Seti@Home
    > The article closes by saying the problem was "solved" by increasing the
    > number of available NAT addresses, although of course that didn't fix the
    > problem, merely caused it to 'go away'. A real solution would be to have the
    > screen-saver software implement incremental backoff and other mechanisms
    > designed to gracefully handle a complete loss of remote server access.
    > One would hope that the authors of the next generation of distributed
    > computation applications take heed of the lessons of the current batch.
    One of the risks of developing any software is that problems experienced by
    users will be associated with the design of the software, not the failure of
    other components.  The GUI version of SETI@home, upon connection failure,
    retries the connection twice at 45 second intervals.  After the third
    failure the program waits 60 minutes before retrying.  The UNIX version
    waits 60 minutes between connection failures.  Apart from this report, I am
    unaware of any TCP/IP implementation that is unable to support 3 connection
    attempts per hour.
    That each computer involved ended up with 10 NAT translations meant that the
    router was maintaining NAT translation for failed connections for 120
    minutes or more.  The router apparently releases translations promptly when
    connections succeed, but maintains them when connections fail.  I'm not sure
    that the SETI@home software could have anticipated that.
    There is another possibility.  Many SETI@home users use "work unit" caching
    software to contact the server.  We don't have much control over the coding
    standards used by developers of third party software that interacts with
    Eric Korpela <SETI@home>
    Date: Tue, 17 Jul 2001 14:21:52 -0700
    From: Geoff Kuenning <geoffat_private>
    Subject: Re: "It's public data, so why not a public database"?
    In the recent flap over 2600/1600 Pennsylvania Avenue, some readers
    have pointed out:
    > this kind of database provides publicly available information, so what are
    > the risks, and why are we running this in RISKS in the first place?
    PGN's relevance criteria did not slip up on this one.  It has often been
    noted in RISKS that a difference in quality is a difference in kind.
    In the current example, accessing the information in the databases once
    required physical travel to a number of different locations, laborious
    removal of heavy books from shelves, and endless page-turning to locate the
    desired data.  These physical barriers served to winnow out all but the most
    motivated people, mostly those who had a legitimate need.
    Placing the same information online, in an easily correlated fashion, has
    many advantages for legitimate users, not the least of which is the
    elimination of the necessity of breathing dust.  But it also provides new
    opportunities to the illegitimate.  It is suddenly easy to produce lists of
    property owned by the wealthy, the elderly, or the vulnerable.  I am not a
    criminal, so my creativity in this area is limited.  But I recognize that
    there are new RISKS caused simply by changing the method of access to the
    The foregoing is not intended to be an immovable argument against placing
    such databases online.  We must weigh the advantages against the drawbacks.
    But it is incorrect to claim that there are no RISKS issues.  -- Geoff
    Kuenning geoffat_private http://www.cs.hmc.edu/~geoff/
    In any large population, there are some people who aren't very bright.
    That's not their fault, it's just in their genes.  As an engineer, I have a
    responsibility to design things that won't kill off the slower ones, just as
    I have a responsibility to design things that won't harm my neighbor's dog.
    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 DIRECT E-MAIL REQUESTS to <risks-requestat_private> with one-line, 
     which now requires confirmation to majordomoat_private (not to risks-owner)
     [with option of E-mail address if not the same as FROM: on the same line,
     which requires PGN's intervention -- to block spamming subscriptions, etc.] or
       INFO     [for unabridged version of RISKS information]
     .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.53

    This archive was generated by hypermail 2b30 : Thu Jul 19 2001 - 16:13:27 PDT