[risks] Risks Digest 21.94

From: RISKS List Owner (riskoat_private)
Date: Mon Mar 11 2002 - 15:03:57 PST

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

    RISKS-LIST: Risks-Forum Digest  Monday 12 March 2002  Volume 21 : Issue 94
    
       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.94.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Runaway remote-controlled coal train (PGN-ed from Dan Swinehart)
    LED lights can reveal computer data  (NewsScan)
    Yet another case of a program changing your input (Vassili Prevelakis)
    Loosing It's Grammer Skill's (Greg Searle)
    .org.au, .gov.au, .edu.au domain hijacking through lax security (Grant Bayley)
    Amendment to add life prison terms for reckless hacking (Len Lattanzi)
    The computing battlefield (Jon P)
    Military palmtop will direct air strikes using WinCE (David Wagner)
    The next step in malicious spam (Joe Faber)
    The RISK of ignoring permission letters (Timothy Knox)
    Re: Air Transat Incident, Aug 24, 2001 (Peter B. Ladkin)
    Re: Malfunction shuts down ... amusement park ride (Stanislav Meduna)
    Re: PayPal's tenuous situation  (Max)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Mon, 11 Mar 2002 11:57:53 PST
    From: "Peter G. Neumann" <neumannat_private>
    Subject: Runaway remote-controlled coal train
    
    Operating with a less-than-a-year-old remote-controlled system, a runaway
    train plowed through NIPSCO's Michigan City Generating Station on the
    morning of 7 Mar 2002, hitting another locomotive before the second
    locomotive's engineer narrowly jumped to safety.  The unmanned eastbound
    diesel-electric engine, known as Big Blue, was pushing six coal cars when it
    approached the coal drop-off area at about 30 m.p.h. at 7:15 a.m.  However,
    the train (in excess of 1.5 million pounds, including the coal) did not
    respond to radio controls and smashed through the enclosed thaw shed and
    coal rotary dumper, before smashing into the other train, Old No. 12.  (Big
    Blue should have been going only about 1 mph for the last 100 yards entering
    the dumper.)  The impact sent the other train through a fence, uprooted a
    bumper post, and ripped up track.  A spokesman blamed it on a switch
    malfunction.  But the system was supposedly designed so that if the
    remote-controlled engine receives no signal, its brakes should automatically
    engage.  Employees reportedly said that the system was not designed for the
    engines currently in use.  Two other accidents occurred in the past month.
    Also noted was what sounds like a serious lack of receptivity from NIPSCO in
    responding to safety complaints from the workers' union over the past four
    or five years.  [Source: No injuries in power station crash, by Jeff Tucker,
    *The News Dispatch* (thenewsdispatch.com), 8 Mar 2002, PGN-ed, contributed
    to RISKS by Dan Swinehart.]
    
    ------------------------------
    
    Date: Thu, 07 Mar 2002 09:19:26 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: LED lights can reveal computer data 
    
    Scientists in the U.S. and the U.K. have found a way to remotely eavesdrop
    on a computer by monitoring the flashes of LED lights on electronic
    devices. Optical signals from the light-emitting diode lights found in
    computer modems and keyboards can be captured with a telescope and processed
    to reveal all the data passing through the device, says Joe Loughry, a
    computer programmer at Lockheed Martin. "It requires little apparatus, can
    be done at a considerable distance, and is completely undetectable. In
    effect, LED indicators act as little free-space optical data transmitters,
    like fiber optics without the fiber." Loughry says the most vulnerable
    devices are equipment used in low-speed, long-distance networks, such as
    ATMs (automatic teller machines). Corporate LANs and home Internet
    connections are generally not susceptible to the spying technique.  Loughry
    says his interest in LEDs dates back to his days in graduate school: "I was
    working very late one night and waiting for a long file transfer to complete
    and I was just staring at these lights on the front of the modem and started
    to wonder if there was anything there." Loughry recommends locating
    equipment away from windows, putting black tape over the LEDs or
    deactivating when not in use. (Reuters 7 Mar 2002, NewsScan Daily, 7 Mar 2002)
      "http://story.news.yahoo.com/news?tmpl=story&cid=581&u=/nm/20020307/tc_nm/tech_snooping_dc_1"
      http://story.news.yahoo.com/news
        ?tmpl=story&cid=581&u=/nm/20020307/tc_nm/tech_snooping_dc_1
    
    ------------------------------
    
    Date: Sun, 10 Mar 2002 07:18:39 -0500 (EST)
    From: vassilipat_private
    Subject: Yet another case of a program changing your input
    
    I was entering grades in an Excel spreadsheet and realized that although in
    my notes I had a mix of A's and A-'s, the spreadsheet had changed all the A
    grades to A-'s. Why?
    
    I was entering grades looking at my notes and not the screen. So I typed A-
    followed by ENTER, then A at which point Excel suggested A- as a possible
    input.  Without looking I pressed ENTER, thus entering A- instead of A.
    
    This only works if the longer input precedes the shorter in the original
    list (i.e., the list you are typing from), since if there is ambiguity about
    the suggestion, Excel shuts up.
    
    Next time I think I will use vi.
    
    ------------------------------
    
    Date: Wed, 6 Mar 2002 13:17:20 -0500
    From: "Greg Searle" <greg_searleat_private>
    Subject: Loosing It's Grammer Skill's
    
    It seems that with the advent of cheap publishing technology such as the
    Web, e-mail, and the laser printer, anybody can publish an electronic
    article or print up hundreds of signs.  This has created an accelerating
    downhill trend as to the quality of the print material that we are exposed
    to every day.  Back in the old days when only professionals with expensive
    equipment could create signs, flyers, and the like, these materials were
    proofread by skilled experts before they were published.  The occasional
    error in grammar or spelling was very rare.  Now, with the average Joe being
    able to mass-create signage and flyers easily, there is no professional
    between Joe and the printer to protect us from Joe's bad grammar.
    
    For example, a local taxi company has printed bumper stickers and signs that
    boldly state on every single taxi, "Driver's Wanted".  Tell me, what of such
    a driver do they want?  Signalling skills?  Sure, I know what they really
    mean, but this error is now so common as to be annoying.  How often do you
    see something like, "loose those extra pounds" exclaimed from a cheap ad?
    I'd rather get rid of them altogether, thank you, instead letting those
    pounds run loose.
    
    Many businesses lose potential customers before they even make them, because
    of stupid mistakes in their literature, and they often wonder why.  Who
    wants to do business with a company that can't even get its documents right?
    To a business looking to hire out some work, sloppy errors on a potential
    contractor's literature are telltale signs that something else may be wrong
    at that business, and are a cue to look elsewhere.
    
    Lax proofreading standards are becoming more common as corporations look
    toward the bottom line, and want to save a buck.  Why hire an expensive
    publishing company to compile and print your manuals, when an internal
    employee can hand a disc to Copy Cop and turn out a few hundred nicely-bound
    copies?  The end result is a lot of lower-quality documentation.  I took a
    Java class recently, and the training agency's course documents were riddled
    with stupid errors.  Some of these were even in the code examples.  This is
    supposed to be a professional training agency.  They need to train their
    documentation department on higher proofreading standards.
    
    English is defined by its common usage over an extended period of time.  Are
    we doomed to accept bad grammar as the official standard?  Sure, computers
    make publishing easier, but the integrity of our language is at risk.
    
    ------------------------------
    
    Date: Wed, 6 Mar 2002 22:45:52 +1100 (EST)
    From: Grant Bayley <gbayleyat_private>
    Subject: .org.au, .gov.au, .edu.au domain hijacking through lax security
    
    A colleague of mine recently came across a disturbing lack of security in
    the recently set up AUDA/AUNIC Registration Services for all .org.au,
    .gov.au and .edu.au domain names.
    
    To cut to the chase on what the problem is, as of 6th March, 2002, you could
    enter any .org.au, .edu.au or .gov.au domain, any NIC handle and any
    password, and the system would accept, redelegate and makes the changes live
    in an average of less than 10 minutes.  It didn't even check the password at
    all.
    
    No doubt the hole will have been plugged by the time this makes it into
    RISKS, and no doubt any genuinely radical and unauthorised changes will have
    been reversed, but the scope of this vulnerability should be obvious.
    
    Feel like picking up all the Web traffic and e-mail for your favourite
    federal law enforcement or communications intelligence agency for maybe 12
    hours? (afp.gov.au or dsd.gov.au)?  Perhaps an entire state? (nsw.gov.au)
    
    Scary.  Very scary.
    
    Yet another indictment of the flimsy DNS system on which we all rely.
    
    ------------------------------
    
    Date: Wed, 6 Mar 2002 11:27:15 -0800
    From: Len Lattanzi <Len.Lattanziat_private>
    Subject: Amendment to add life prison terms for reckless hacking
    
    >From SANS NewsBites Vol. 4 Num. 10, 27 Feb 2002  
    Life Sentences Proposed for Reckless Hacking
    
      A US House subcommittee voted unanimously to propose lifetime jail sentences
      for hackers who knowingly attempt "to cause death or serious bodily injury"
      through electronic means.
        http://www.wired.com/news/politics/0,1283,50708,00.html
    
    What should the punishment be for recklessly allowing remote access to
    critical machinery and data?
    
    ------------------------------
    
    Date: Wed, 06 Mar 2002 17:59:25 -0500
    From: "Jon P" <cjmailat_private>
    Subject: The computing battlefield
    
    On 5 Mar 2002, National Public Radio aired a segment talking about the
    effort to put technology onto the battlefield.
    
      "Anthony Brooks of the WBUR program "Inside Out Documentaries," reports on
      efforts by the United States Army to create a lighter more streamlined
      fighting force.  Soldiers at Fort Lewis in the state of Washington are
      developing an "Interim Brigade Combat Force," which would have the agility
      of light infantry, combined with some of the punch of heavy armor. The
      idea is to make the force deployable anywhere in the world within 96
      hours."
      http://search.npr.org/cf/cmn/cmnpd01fm.cfm?PrgDate=03%2F05%2F2002&PrgID=2
    
    The most chilling quote comes from an executive officer talking about how
    battlefield data is distributed and presented to soldiers in Humvees and
    armored vehicles: "We use nothing but Windows NT systems, that are hardened,
    to provide HTML products, which are nothing but homepage products, to
    disseminate the information via regular Internet protocols."  (At 5:05 into
    the audio segment at http://www.npr.org/ramfiles/atc/20020305.atc.02.ram)
    
    Gives new meaning to "Blue Screen of Death".
    
    The full documentary report is available at 
    http://insideout.wbur.org/documentaries/reshapingmilitary/
    
    ------------------------------
    
    Date: Sun, 10 Mar 2002 00:05:00 -0800 (PST)
    From: David Wagner <dawat_private>
    Subject: Military palmtop will direct air strikes using WinCE
    
    *New Scientist* is reporting that the US military is planning to deploy
    palmtops for ground troops to use in transmitting targeting information for
    air strikes and the like.  The application software will be running on top
    of Windows CE.
    
      http://www.newscientist.com/news/news.jsp?id=ns99992005
    
    ------------------------------
    
    Date: Sat, 09 Mar 2002 11:28:46 
    From: Joe Faber <joefaberat_private>
    Subject: The next step in malicious spam (From Dave Farber's IP)
    
    I'm used to ignoring spam, but this morning I woke up to find that I
    received no fewer than three 160K+ .exe attachments in my inbox purporting
    to be from Microsoft.  They were from the "Microsoft Corporation Security
    Center" and used "Internet Security Update" as their subject heading.  The
    e-mail explains that the attached patch is the "5 Mar 2002 Cumulative Patch
    that eliminates all MS Outlook/Express as well as six new vulnerabilities"
    [sic].  It goes on to list some of the specific vulnerabilities and system
    requirements.  They even provide a link to a Microsoft security Web site
    (where I couldn't find any mention of the patch).
    
    Aside from the issue of mailing 3 copies of a 160K attachment, I can't begin
    to think of the trouble this might cause with the number of people running
    Windows who would just think that this is benevolent Microsoft looking out
    for them and would promptly open the attachment.  I'm no spam hunter, but I'm
    keeping the e-mails around should anyone want to see the header information.
    
    For IP archives see:
    http://www.interesting-people.org/archives/interesting-people/
    
      [Bogosity alert!  This kind of seemingly helpful message could easily be
      used to do enormous damage.  Although some of the alleged vulnerabilities
      are legitimate, the message itself is indeed a hoax, as noted subsequently
      in various media -- including Dave Farber's IP, to which Ari Ollikainen
      contributed an article by Robert Vamosi, Gibe worm poses as a Microsoft
      update, ZDNet Reviews & Solutions, 6 Mar 2002.  BEWARE!  Always book a
      gift (Trojan) horse in the south.  PGN]
    
    ------------------------------
    
    Date: Sun, 10 Mar 2002 01:53:14 -0600
    From: Timothy Knox <tdk-freshmeatat_private>
    Subject: The RISK of ignoring permission letters
    
    I received the following e-mail recently. The subject certainly sounded
    encouraging: We request your permission (presumably to start sending me
    spam). Great, thought I, I can just ignore this, and they will go away.
    However, when I got to the last sentence of the main paragraph, I found
    that their idea of requesting permission differs from mine. It reads:
    
    If you do not wish to have HelloDirect.com contact you via e-mail, please
    click the link below and your name will be deleted from our e-mailing
    lists immediately.
    
    This is NOT requesting permission. This is warning you that by NOT
    responding, you are implicitly consenting to them sending you spam. With
    UCITA, this might even become legally acceptable (like click-wrap licenses).
    
    Finally, note how they try to play it cool in the last paragraph, talking
    about how I 'requested' to be notified of special offers. This is an
    outright lie. The e-mail address they sent to was only ever given to one
    Web site, which is a company that does order fulfillment for some other
    software companies. I did NOT give that company permission to send me ANY
    special offers (I always decline), so this is a lie. I don't know if the
    software fulfillment folks sold my address, or if they had their database
    illegally copied, or if this address was harvested years ago (it has been
    inactive for that long) and just now used.
    
     - --------------- Begin Forwarded Message ----------------
    Subject: Hello Direct requests your permission.
    Date Sent: Friday, 8 March 2002 10.09
    From: Hello Direct <welcomeat_private>
    To: tdk+drat_private
    
    For over 14 years, Hello Direct has been recognized and respected as the
    leading resource for telecom products, solutions and information.
    HelloDirect.com is seeking your permission to send you up-to-date
    information on current industry news, cutting edge telecom products and
    services, special offers and product reviews via its electronic newsletter,
    The Newswire. All of this valuable information delivered efficiently and
    electronically, to your e-mail inbox!!! If you do not wish to have
    HelloDirect.com contact you via e-mail, please click the link below and your
    name will be deleted from our e-mailing lists immediately.
    
    drat_private&pn=4002152103-C">http://mt.directqlick.com/u/?e=tdk+drat_private&pn=4002152103-C
    
    Sincerely,
    
    Your friends at HelloDirect.com
    
    ****Hello Direct respects your privacy. This message was delivered to you
    because you requested previously from another website to be notified of
    special offers from preferred partners like Hello Direct.
    
      - ---------------- End Forwarded Message -----------------
    
    ------------------------------
    
    Date: Wed, 06 Mar 2002 11:05:44 +0100
    From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
    Subject: Re: Air Transat Incident, Aug 24, 2001 (Johnson, RISKS-21.93)
    
    Whatever the status of the recent press commentary, John Johnson's brief
    account of the Air Transat incident [RISKS-21.93] is misleading in various
    respects, and I think it appropriate to set the record straighter.
    
    Johnson says:
        Apparently, [...] 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. 
    
    First, the "imbalance" report was not "incorrect". A fuel leak in the main
    fuel tanks, in the engines, or in between, on this model aircraft can lead
    to a fuel imbalance warning. In circumstances such as this, a fuel
    imbalance warning can be the first sign of a fuel problem. That a fuel
    imbalance warning can be sign of a leak is specifically noted in the
    relevant section of the operating handbook. Section 2.09, "Abnormal
    Procedures", under "Fuel Imbalance" says, first "Caution: Do not apply this
    procedure if a fuel leak is suspected. Refer to FUEL LEAK procedures."
    
    Second, digital avionics systems are not just "computer programs". They
    have many independent, dedicated programmable digital components.
    There are over ten interconnected digital systems on this aircraft which
    deal with the fuel, most of which are duplicated for redundancy. These
    systems contain programmed digital hardware.
    
    Third, the systems involved in reporting a fuel imbalance are not 
    identical with the systems involved in transferring fuel, although the
    major digital component, the Fuel Control and Monitoring System (FCMS), 
    is involved in both. The FCMS is not a "computer program". It is two
    dedicated digital computers.
    
    Fourth, fuel transfer between imbalanced tanks has been de rigeur in heavy
    aircraft for a half century, and automated in new designs for a quarter
    century now. The automation mostly saves pilots a lot of work and worry.
    
    Fifth, the leak was not in the wing tank, but on the engine itself.
    
    All of this information has been publicly or semi-publically available since
    the incident over six months ago.
    
    Some more background.
    
    The A330 is a twin-engined aircraft. Its main fuel tanks are in the
    wings, as on most aircraft. Engines burn fuel at differential rates
    simply because of individual differences. Such differential fuel burn
    means that there is more fuel on one side of the aircraft than the
    other after a while, which unbalances the aircraft. It is inefficient to
    correct this by aerodynamic control inputs; the standard procedure 
    in large aircraft for the last half-century has been to transfer fuel
    between tanks to regain balance. Since the late 1970's, new aircraft
    have been designed to perform such transfers automatically or
    semi-automatically, and such aircraft have been in service since the
    early 1980's. On the A330, this control is performed by the Fuel Control
    and Monitoring System (FCMS). 
    
    The fuel leak was on the engine, upstream of the control and monitoring
    of the fuel burn. On a non-leaky system, integrating the fuel burn since
    engine start ("total fuel burn"), and adding this quantity to the measured
    fuel in the tank ("fuel on board"), one should obtain the same figure as
    measured in the tanks at engine start ("ramp fuel"). All these quantities
    are available continuously to pilots of all transoceanic aircraft, and it
    has been good practice since transoceanic flying began to perform this
    standard check. On earlier generation aircraft, this was the main method
    of detecting a fuel leak. 
    
    The fuel leak was caused by a break in a fuel supply line on the engine,
    itself caused by chafing of the line, which in turn was enabled by
    improper installation of the engine. Why the engine had been improperly
    installed is a non-trivial matter with no apparent computer involvement.
    
    The major question is why the pilots did not detect the fuel leak earlier
    than they did. Another question is as follows. Suppose the pilots had 
    discovered the fuel leak at the earliest possible moment; suppose,
    further, that it had occurred at the most inopportune moment (at their
    furthest point from suitable landing, which was allowed to have been as
    much as two hours flying time away). Would the information available to the
    pilots have enabled them, even in theory, to attain a suitable landing site
    anyway without running out of fuel? You could shut down an engine and
    isolate a leaking tank, maybe even transfer fuel away from a leak, but most
    pilots are reluctant, for good reason, to shut down a working engine at
    night over ocean, especially when they do not possess complete information
    about the situation (in-flight real-time analysis of such a problem is
    notoriously difficult and unreliable).
    
    Concerning the first question, in September 2001, shortly after the
    incident, I saw two ways in which presentation of information made
    available to the pilots in such a case could be improved, and presented
    these ideas to colleagues, the manufacturer, and the Bluecoat 2001
    conference.  However, information available already in October showed that
    the features that concerned me played either no role, or at most a very
    minor role, in the incident. I should note that the fuel system automation
    makes available to pilots (and investigators) much more, and more accurate,
    information about the fuel state of the aircraft than is available on
    aircraft with lower levels of automation. 
    
    The second question concerns the practice of flying over water significant
    time away from suitable landing. So-called Extended Range Operations, or
    ETOPS, permission is granted to airlines for specific aircraft and crew,
    depending on the demonstrated reliability of equipment, personnel and
    maintenance. The incident aircraft was operating under "120-min" ETOPS,
    allowing it to fly up to 120 minutes away from a suitable landing site.  The
    maintenance snafu caused Air Transat's ETOPS permissions to be
    prophylacticly reduced to 60 minutes. The incident itself caused some to
    question the very basis of ETOPS, not just its assessment, along the lines
    which I indicated above. After an initial flurry of worry, the issue has all
    but disappeared from the aviation technical press. However, it is still
    unclear to me whether it can be satisfactorily answered.
    
    Finally, whatever their performance during the earlier phases of the
    incident, the crew glided their aircraft, without engines, at night,
    some 85 nautical miles (98 statute miles, 156 km) to an essentially 
    perfect "dead stick" landing on an aerodrome they had never seen before,
    a US military base. It was the world's first dead-stick landing of a
    fly-by-wire aircraft, and a significant achievement. 
    
    Besides the passengers and their family, safety engineers also have a
    lot to thank the crew for. Had the aircraft and crew been lost, either
    in the ocean or on a landing attempt, almost all the information needed
    to reconstruct this highly significant incident and learn from it would
    also have been irretrievably lost. 
    
    ETOPS or no ETOPS, running out of thrust on a modern airliner is just
    not supposed to happen. The lessons to be learned from this incident
    are incomparably rich, and in many ways unique. Thank heavens, and
    skillful pilots, that no one was hurt.
    
    Peter B. Ladkin Faculty of Technology, University of Bielefeld, Germany.
    
    ------------------------------
    
    Date: Wed, 6 Mar 2002 21:13:01 +0100 (CET)
    From: Stanislav Meduna <stanoat_private>
    Subject: Re: Malfunction shuts down ... amusement park ride (RISKS-21.93)
    
    I work in the area of process control systems. The systems capable of BSOD
    (blue screen of death) are normally *not* used to control safety critical
    parts of a system. These functions are usually implemented in the
    programmable logic controllers, which are hard-realtime systems with much
    less ways to crash. The traditional operating systems are used for the
    higher level controlling, data storage and human-machine interface.
    
    Software-based PLCs using e.g. NT (often with some realtime extensions) as a
    underlying system do exist, but I doubt that they are used where safety of
    humans is at risk. Nobody with a sane mind would risk that, regardless of
    the claims of the vendors of these extensions that a realtime task continues
    to run or at least performs a clean shutdown in the case of BSOD (but can be
    technically completely messed up due to a runaway third-party driver).
    
    The article doesn't mention how much faster the wheel was turning.  My
    speculation is that maybe the controlling computer did indeed instruct the
    wheel to turn too fast, but then a safety task in the PLC kicked in and
    halted the machine. This is how these things are supposed to work - the
    event was probably not really a "safety scare", as the BBC titled it.
    
    Stanislav Meduna
    
    ------------------------------
    
    Date: Thu, 21 Feb 2002 14:14:16 +0000
    From: <max7531at_private>
    Subject: Re: PayPal's tenuous situation  (Jonas, RISKS-21.92)
    
    After using PayPal to buy something, I learned something. I recently made a
    direct purchase from a web site through PayPal.  After it became clear that
    the transaction would not take place, I issued a complaint through PayPal's
    complaint service.  Not being satisfied at the short explanation of the
    complaint process, I decided to give them a call to see where I stood.
    After much cajoling, the operator told me that the person I transferred
    money to had had her account frozen due to a fraud investigation! Of course,
    PayPal never prevented her account from continuing to receive money after it
    had been frozen. When questioned further, the operator said that it was
    PayPal's policy to allow frozen accounts to continue to receive funds so
    they could continue to payoff claimants!  It seems that PayPal has a
    fundamental flaw in the way it "protects" users. With normal credit cards,
    the credit card company must guarantee the transaction to the merchant,
    since he takes a risk by accepting a flimsy piece of plastic instead of cash
    for his valuable merchandise. With PayPal, the opposite should be true. They
    need to protect the buyer, since the money is paid before she receives the
    goods.  I can see how millions of dollars in fraud could be committed by
    exploiting this flaw (as long as PayPal is willing to reimburse complaint
    issuers. :)I'm still waiting on resolution, but I have no fear. Since I made
    the payment with an actual credit card, I plan on challenging the purchase
    through them if PayPal's response is unsatisfactory.  Must have been
    something I read on RISKS about layered security.)
    
    ------------------------------
    
    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.94
    ************************
    



    This archive was generated by hypermail 2b30 : Mon Mar 11 2002 - 16:25:20 PST