[risks] Risks Digest 22.12

From: RISKS List Owner (riskoat_private)
Date: Mon Jun 10 2002 - 15:18:52 PDT

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

    RISKS-LIST: Risks-Forum Digest  Monday 10 June 2002  Volume 22 : Issue 12
    
       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/22.12.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Is there a law that says you have to watch commercials? (NewsScan)
    Dim STARS (Peter B. Ladkin)
    Questions about new STARS air-traffic computer system (Ian Macky)
    COTS versus Bespoke ATC Systems (Peter B. Ladkin, Nancy Leveson)
    Re: Swanwick (Peter B. Ladkin)
    *NY Times* new zero-security password system (Martin Ward)
    Tracking subway users by electronic fare card (Ngiam Shih Tung)
    Kazaa users inadvertently share their private files (Nathan Good)
    Web glitch exposed Fidelity accounts (Monty Solomon)
    Hacker threat posed by Excel spreadsheets (Patrick O'Beirne)
    Re: More on typos and homographs (Martin Wheatman, Scott Nicol)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Fri, 07 Jun 2002 09:31:29 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Is there a law that says you have to watch commercials?
    
    Surely there isn't -- says Rep. Rick Boucher (D-Va.) in his support for a
    consumer lawsuit seeking to confirm that users of Sonicblue's ReplayTV
    system have the lawful right to skip commercials when they record TV
    programs for later viewing. The suit has been filed in the same federal
    court in Los Angeles that is hearing a complaint from movie and television
    studios that ReplayTV allows customers to violate their copyrights, arguing
    that skipping commercials amounts to stealing. Sonicblue's position is:
    "Basically we believe that consumers have 'fair-use' rights, and everything
    consumers do with a ReplayTV is covered with 'fair use'."  [Reuters/*USA
    Today*, 6 Jun 2002, http://www.usatoday.com; NewsScan Daily, 7 June 2002] 
    
    ------------------------------
    
    Date: Fri, 07 Jun 2002 19:15:36 +0200
    From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
    Subject: Dim STARS
    
    The US gave up on its Advanced Automation System (AAS) for air-traffic
    control in the mid-90's, for the "usual" reasons: large cost overruns and
    schedule slippages. The UK, however, whose 2MLoC [million lines of code]
    NERC system was approximately half (1MLoC) AAS code, decided to continue
    with development. The US instead went for a series of targeted solutions,
    starting with the Display Replacement System (DRS) for its en-route centers
    (those dealing with traffic en-route) in the late 90's, and continuing with
    new hardware for its HOST system, which drives the en-route displays. Among
    the major systems still under development is the Standard Terminal
    Automation Replacement System (STARS), which was to be installed at some
    170+ (now 160+) locations, for departing and arriving traffic at TRACONS
    (Terminal Area Control facilities, controlling airspace around major
    airports), to replace the aged ARTS systems. A full list of FAA ATC systems
    under development may be found in [1].
    
    STARS was contracted in 1996 to be delivered in 1998. The full software is now
    scheduled to be delivered in 2002. STARS is described as a "commercial 
    off-the-shelf" (COTS) system (see [2]), quite the buzzword nowadays, and was
    the type of thing the US wanted to try instead of the "bespoke" AAS that was
    canceled in 1994. STARS was budgeted at $940m, including installation costs
    at some 170+ TRACONs. John Mica, Chair of the House Aviation Subcommittee, 
    said in March 2001 [2] that the cancellation of the AAS "[cast] aside 11 years 
    of development work and, according to GAO, [wasted] more that $1.5 billion of 
    taxpayer money."
    
    This supposedly COTS system was restructured by the FAA and the supplier,
    Raytheon, into a "major redevelopment program" in 1998, because the COTS 
    system "proved to be inadequate", being "[unable to] handle the high volumes of
    traffic required", with a corresponding $1.4b price tag (Mica [2]). STARS is
    about 960 KLOC of core system i.e., that part of the software that is common
    to other STARS installations, such as in Germany and elsewhere (Marchilena, 
    Executive VP of Raytheon, [2]) and about 400KLOC of "bespoke" code (Mead, DOT
    Inspector General, [2]).
    
    In February 2002, Kenneth Mead, Inspector General of the US Department of
    Transportation, said that STARS "is already 4 years late and is now
    estimated to cost $600 million over the original estimate of about $1
    billion. [...] Delays with STARS causes FAA to take stopgap measures for
    some facilities. FAA spent $85 million to purchase and install Common ARTS
    systems [developed by Raytheon rivals Lockheed Martin Air Traffic Systems,
    formerly Loral, formerly IBM Federal Systems. PBL] at large facilities to
    replace aging equipment. FAA has spent about $660 million on the STARS
    program but has only two Early Display Configuration systems in operation,
    which provide new controller displays, but rely on older software. The Early
    Display Configuration should not be confused with Full Service STARS (Full
    STARS), which includes both new equipment and a complete replacement of
    older software." [1] Inspector General Mead has recently reported that STARS
    will cost at least $1.7 billion, "an 80 percent increase over the initial
    estimate" [3]. Mead had testified before the Transportation Subcommittee of
    the House Appropriations Committee on March 13, 2002 that there were 258
    open critical trouble reports for STARS, having grown from 171 in September
    2001. The FAA indicated, however, that there were only 50 open critical
    trouble reports. Mead reviewed FAA documentation (the STARS Biweekly Report
    for March 7, 2002) and concluded that the figure of 258 was correct [3]. (A
    trouble report is open until closed, meaning a fix has been identified,
    documented, verified and validated.  "Critical" open trouble reports are
    "those that would prevent or preclude the performance of a mission,
    jeopardize safety or security, or adversely affect a mission-essential
    capability." [3])
    
    The FAA is aiming for the first installation of Full STARS at Philadelphia in
    November 2002. They are aiming for a product that is "not perfect, but 
    acceptable", that is, to fix the "potential show-stoppers". As of May 2, 
    there were 221 open critical trouble reports. The FAA now distinguishes 
    between "critical" otr's and "truly critical" otr's. Mead calls the distinction
    "not self-defining and [..] vague" [3, p3]. 
    
    Apparently, to stay on schedule for November 2002 deployment in Philadelphia, 
    the FAA has deferred independent testing. They were going to conduct the tests
    on Full STARS in Memphis in August 2002 to identify and correct glitches before
    installation in Philadelphia. But because of delays in development, Full STARS
    has not been installed in Memphis and independent testing will be performed
    after (!) Full STARS installation in Philadelpia [3].
    
    Further, "in order to stay on schedule for Philadelphia, the contractor 
    increased monthly spending (the "burn rate") in fiscal year 2002 to an
    unsustainable level [....] [to] about $10 million per month on average this
    year [...] an increase from a monthly average of $8 million to $9 million in 
    the 3 prior fiscal years." [3]
    
    Mead concludes "We have little doubt that STARS hardware and software can be 
    "installed" by November, but, in our opinion, it is doubtful that it will be
    operationally suitable by November to control live air traffic in Philadelphia
    and replace ARTS." [3]
    
    One might compare also the news reports by Bruce Nordwall in Aviation Week
    in March 2002 [4], and the AP brief in the International Herald Tribune on
    June 6, 2002 [5]. However, the IHT thinks that Mead said 71 open critical
    trouble reports, rather than the 258 that Mead says he said [3], and Nordwall 
    says Mead said 175. Caveat lector.
    
    References
    
    [1] Status on the Federal Aviation Administration's Major Acquisitions,
    Memorandum from the DoT Inspector General, February 22, 2002.
    http://www.oig.dot.gov/item_details.php?item=701
    
    [2] Minutes of the House Aviation Subcommittee Meeting of March 14, 2001, at
    www.house.gov/transportation/aviation/ 03-14-01/03-14-01memo.html 
    
    [3] Follow-up Memo to FAA on STARS Acquisition,
    Memorandum from the DoT Inspector General, June 3, 2002.
    http://www.oig.dot.gov/item_details.php?item=806
    
    [4] FAA Faulted for Slow Progress In ATC Modernization, Bruce D. Nordwall,
    Aviation Week and Space Technology, 18 March 2002, available to subscribers
    at www.awstonline.com
    
    [5] New air traffic system under fire, Association Press, International
    Herald Tribune, Thursday June 6, 2002, available at www.iht.com
    
    Peter B. Ladkin, University of Bielefeld
    http://www.rvs.uni-bielefeld.de
    
    ------------------------------
    
    Date: Wed, 5 Jun 2002 14:10:15 -0700 (PDT)
    From: Ian Macky <ian.mackyat_private>
    Subject: Questions about new air-traffic computer system
    
    There are some highly scary quotes in this article regarding the new
    STARS (Standard Terminal Automation Replacement System) which is
    supposed to replace the hodge-podge of old air-traffic control systems:
      http://www.cnn.com/2002/TRAVEL/NEWS/06/05/faa.airtraffic.ap/index.html
    
    Players are the FAA Union (representing the flight controllers), the
    FAA technicians who are trying to roll out the new system, the equipment
    builder, Raytheon Co., and the DOT (Department of Transportation). [...]
    
    "DOT Inspector General Kenneth Mead ... said there were 71 specific software
    problems that could prevent the system from operating as designed, or could
    threaten safety or security. "
    
    "Mead said controllers in El Paso had to track airplanes manually because
    the computer system didn't properly display the flights."
    
    Union vice president Tom Brantley: "They don't believe it's operationally
    suitable," Brantley said.  "It's failing.  It has a lot of errors.  They
    can't verify that it works because it fails a lot of the tests."
    
    FAA spokesman Scott Brenner said the only problems are the normal bugs (!)
    that accompany any new technology.  [Ship it!]
    
    "When the [FAA] technicians refused to certify the system in Syracuse,
    New York, the FAA invoked a never-before-used [emergency] clause in its
    contract with its employees and ordered them to approve the equipment.
    The Syracuse system was turned on Monday night."
    
    Brantley: "The emergency clause was never intended for something like this.
    That was intended if there were an actual emergency."
    
    Blanche Necessary (!), a spokeswoman for the equipment builder, Raytheon Co.,
    said the system was working well in El Paso and Syracuse.
    
    etc., etc.  The RISKS are painfully familiar.
    
    Feel safer flying?
    
    ------------------------------
    
    Date: Fri, 07 Jun 2002 19:17:18 +0200
    From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
    Subject: COTS versus Bespoke ATC Systems
    
    I have noticed that people talking about air-traffic control system software
    like to make a distinction between "commercial off-the-shelf" (COTS)
    systems, and bespoke systems (for example, [1]). I have long found this
    distinction unimportant in this domain, because of the amount of bespoke
    tailoring required for any ATC installation. But its usage seems to me to be
    increasingly prevalent.  So I'd like to quantify my view with two examples.
    
    The UK NERC system is an en-route system with 2MLoC software, which is about
    half common software (well, common with the now-defunct US AAS) and half
    bespoke.  Development was budgeted at roughly GBP 500M (roughly $750M) in
    the time frame 1992-1996. It finally came on-line in January 2002, with
    significant cost overruns. (How expensive the development effort really was
    depends on how one does the accounting.  My estimates of 1998 turn out to
    have been fairly accurate. [2]) Schedule slippage was 6 years on 4 years
    planned.
    
    The US STARS system was bought as a "COTS" system. STARS has undergone $660m
    of development work to date and a schedule slippage of 4 years (to an
    original schedule of 2 years until first installation in 1998), and is about
    two thirds code in common with other installations (e.g. in Germany), that
    is, 960 KLOC, and one third bespoke, 400+ KLOC. Full STARS software is thus
    two thirds as large as NERC software. Development has cost $660 million so
    far, for a November 2002 first (full) deployment.
    
    So the difference between "COTS" and "bespoke" appears to be one-sixth (the
    difference between two thirds and one half), and buying "COTS" systems does
    not necessarily save one from comparable cost overruns or schedule
    slippages. The LOC count for STARS is about two thirds that for the NERC
    software; the development costs to first deployment seem also to be
    comparable (NERC has only one installation, compared with STARS's planned
    160+, so total program costs for STARS are higher than for NERC). And
    schedule slippages are roughly the same magnitude (if strict proportionality
    is your thing, total:planned time yields 9:4 for NERC and 6:2 for STARS).
    
    I conclude that "COTS" and "bespoke" is not a helpful predictive distinction
    for ease and comparative cost of development and deployment of ATC systems. 
    
    References
    
    [1] Minutes of the House Aviation Subcommittee Meeting of March 14, 2001, at
    www.house.gov/transportation/aviation/ 03-14-01/03-14-01memo.html 
    
    [2] Memorandum to the Transport Sub-Committee on the Costing of NERC, 26
    November 1998, Memorandum FN 12 in (UK) House of Commons, Session 1998-99,
    Environment, Transport and Regional Affairs Committee, Third Report, The
    Future of National Air Traffic Services, pp52-55. Also available as
    RVS-S-98-02 of 26 November 1998, at www.rvs.uni-bielefeld.de -> Publications
    -> Special Reports
    
    Peter B. Ladkin, University of Bielefeld
    http://www.rvs.uni-bielefeld.de
    
    ------------------------------
    
    Date: Fri, 07 Jun 2002 19:16:26 +0200
    From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
    Subject: Re: Swanwick (Brady, RISKS-22.09)
    
    Chris Brady notes that the UK's New En-Route Center (NERC) at Swanwick, which
    came on-line in January 2002, crashed "yet again" on May 17th. 
    
    Well, it did, but that's the first time, to my knowledge. Other recent
    outages, including one on March 27 in which I was caught, reported in
    RISKS-21.98 by Alistair Macdonald and Simon Waters, involved the National
    Airspace System (NAS) in West Drayton, which processes flight plan data
    which is fed to the NERC (Martyn Thomas, RISKS-22.02). When this data is
    generated and manipulated by hand, as during a NAS failure, many fewer
    aircraft are allowed into the system.
    
    The NERC is an airspace management aid. It is essentially a display system
    for data which comes from other systems (radar feeds, NAS, and so
    forth). The worst kind of outage is one in which the system fails in use. As
    far as I know, this has not happened. The BBC reported that engineers failed
    to bring the system fully back up after a system upgrade. A number of
    controller workstations were inoperative ( http://news.bbc.co.uk and search
    for "Swanwick") and service was restored fairly quickly (a matter of
    hours). As failures go, that is technically relatively benign, and
    completely benign as concerns safety. Of course, one would prefer not to
    have any.
    
    Brady says that the upgrade rendered "half the air traffic controllers'
    computer screens inoperable". The BBC reported that six out of twenty
    displays did not come up.
    
    Brady wonders how much all this outage is costing the airlines. The answer
    is: more than one might think, for the airlines also own and manage NATS.
    
    In a second note concerning difficulties some controllers are having in
    reading data on the screens at the NERC, Brady says "Obviously no-one
    thought to ask the controllers if they could actually read the screens
    clearly".
    
    On the contrary, controllers were evaluating and training on the system for
    at least two years before it went live in January, and it is public
    knowledge that they were very active with their feedback. NATS recognised in
    1998 the need for a transition period more extended than the originally
    planned six months (I suspect they knew it well before that, but there would
    have been constraints on their replanning).
    
    Brady says that the NERC is "a disaster waiting to happen". It is unclear to
    me how he reaches this conclusion. He seems to think that one outage
    portends disaster. The record could equally well be taken as evidence for a
    well-managed and well-functioning system: one glitch in a system build in
    four months, and no live crashes. Reader's choice (along with any position
    in between).
    
    That all said, it is appropriate to wonder, as Brady does, why there is now
    a cluster of system slowdowns and outages, after years of successful NATS
    systems operation, including times when various systems have been strained
    to and even over what was thought to be their capacity and have proved much
    more resilient than most people had imagined. John Stuart Mill's Method of
    Differences would lead us to look for causal factors around what has
    recently changed, and the most obvious recent large change is the
    introduction of the NERC in January into the live airspace management
    system. In so far as there is a risk obvious to everybody, that was it. The
    management of this change will have affected other subsystems of the
    national airspace management, including NAS of course.
    
    One should not underestimate the technical challenge involved in switching
    to this new system. ATC systems are built in an environment in which
    requirements constantly change; they are safety-related and hard-real-time;
    and every one has components adapted from other systems and components
    unique to itself. All the system-engineering bad apples in one basket,
    except one: ATC system design has traditional employed "graceful
    degradation" in the guise of a radio-only reversion mode (which will
    sometime no longer pertain when traffic is allowed to become sufficiently
    dense, whereupon the ATC system will become safety-critical rather than
    safety-related). The airspace NERC covers includes some of the busiest in
    the world, and it is to my knowledge the largest live ATC system anywhere
    (2MLoC), though not the most expensive (that honor belongs to the deployment
    of STARS in the US, as far as I know). I imagine management of this
    enterprise has been learning by doing. And unavoidably so.
    
    For what it's worth, the NERC is a system Brits made work after America gave
    up.  In the last few years, I have found myself puckishly drawn to two
    images. One is Dr. Johnson's "... dog walking upon his hind legs. It is not
    done well; but you are surprised to find it done at all." The other is that
    of old American cars in Cuba (the NERC uses a token ring architecture, after
    all). However, the US got its replacement systems (the 1.3 MLoC STARS, inter
    alia) no more quickly, by no means less expensively, and apparently with no
    less trouble (see [1] and [2]).  Again, reader's choice.
    
    References
    
    [1] Dim STARS, Peter B. Ladkin, 7 June 2002.  [RISKS-22.12]
    
    [2] COTS versus bespoke ATC systems, Peter B. Ladkin, 7 June 2002.
        [RISKS-22.12]
    
    Peter B. Ladkin, University of Bielefeld, Germany
    http://www.rvs.uni-bielefeld.de
    
      [Incidentally, Nancy Leveson reports that she was told STARS has 5MLoC,
      although that may represent different code boundaries from the smaller
      numbers.  PGN]
    
    ------------------------------
    
    Date: Fri, 07 Jun 2002 14:16:12 -0400
    From: Nancy Leveson <levesonat_private>
    Subject: COTS versus Bespoke ATC Systems (Re: Ladkin, RISKS-22.12)
    
    > NERC has only one installation, compared with STARS's planned 160+
         
    This is an important point...  In the U.S., every ATC facility does things
    differently, often significantly differently.  The problem of trying to
    develop and install 160 different systems with each different than the
    others is orders of magnitude more difficult from both a software
    engineering and installation standpoint.
    
    I was involved with a software tool that simply assisted TRACON controllers
    with arrival traffic.  That software (about 500 KLOC of C code) contained
    50,000 KLOC of what was called "adaptation data" that was needed for the
    Dallas/Ft. Worth installation with which I was involved.  The experimental
    software was designed originally for DFW, with the intention of changing the
    adaptation data for other TRACON facilities.  That has proven to be more
    difficult (and expensive!) than expected.
    
    ------------------------------
    
    Date: Wed, 5 Jun 2002 11:33:05 +0100 (BST)
    From: Martin.Wardat_private (Martin Ward)
    Subject: *NY Times* new-zero security password system
    
    *The New York Times* has recently switched their paid user accounts from a
    reportedly hard to use and unreliable password system called Qpass to a new
    system. They then sent an e-mail message to all account holders:
    
      Now enter the following Member ID and password which we have created
      for you and click the "Log In" button.  You will need to use this
      Member ID and Password to access your NYTimes.com premium products
      in the future.
    	
      Member ID: ZZZZ
      Password: Your password is your Qpass User Name.
    
    The member id (ZZZZ above) is in the form firstname_lastname and Qpass user
    names are easily guessable, often repeated across many sites, and often not
    kept as secrets (for instance, message board posts are often tagged by
    username).
    
    *The New York Times* response to complaints about this system was that you
    could always change your password if you found yourself concerned about
    security.
    
    See http://www.oreillynet.com/cs/weblog/view/wlg/1482 for the full story.
    
    Martin.Wardat_private http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
    
      [An item by Marc Hedlund on this problem was noted by Peter Tonoli:
        http://www.nytimes.com/ref/membercenter/help/qpass_redir.html
      PGN]
    
    ------------------------------
    
    Date: Tue, 28 May 2002 22:01:19 +0800
    From: Ngiam Shih Tung <stngiamat_private>
    Subject: Tracking subway users by electronic fare card
    
    *The New York Times* (2 Apr 2002) recently reported that investigators
    trying to determine how a New York woman had contracted Anthrax during last
    year's bioterrorist attack had used subway computer records and her fare
    card to trace her movements in the city prior to her death.
    
    Admittedly, the victim was dead and privacy rights are generally 
    recognised to be extinguished on death, but if a dead person's subway 
    rides can be tracked, so can a live person's.
    
    Does anyone know what is the legal position on fare card records in New 
    York and elsewhere ? Is there any legal barrier or policy that would 
    prevent a transit authority from releasing fare card records to any law 
    enforcement agency, or to anyone ?
    
    None of the media reports mentioned how far back in time the 
    investigators were able to trace Nguyen's movements. Can anyone hazard a 
    guess on how long New York's MTA keeps fare card data ?
    
    ------------------------------
    
    Date: Wed, 5 Jun 2002 17:10:02 -0700 
    From: Nathan Good <ngoodat_private>
    Subject: Kazaa users inadvertently share their private files
    
    We have just finished a study that shows how user interface design flaws
    allow users on Kazaa to share their personal files without their
    knowledge. In a laboratory user study, only 2 out of 12 subjects were able
    to correctly determine that Kazaa was sharing their entire hard drive.  We
    looked at the current Kazaa network and discovered that many users are
    sharing personal information such as email and data for financial programs
    such as Microsoft Money.
    
    To see if other users on Kazaa were aware of this and taking advantage of
    users ignorance, we ran a Kazaa client for 24 hours with dummy personal
    files. During this time, files named "Inbox.dbx" and "Credit Cards.xls"
    where downloaded from our client by several unique users.
    
    The tech report can be accessed here:
      http://www.hpl.hp.com/shl/papers/kazaa/KazaaUsability.pdf
    or from our lab web page at 
      http://www.hpl.hp.com/shl/
    
    Nathan Good, Information Dynamics Lab, HP Laboratories   ngood @hpl.hp.com
    1501 Page Mill Road, Palo Alto, CA 94306, USA  1-650-236-4437 
    
    ------------------------------
    
    Date: Mon, 3 Jun 2002 01:57:08 -0400
    From: Monty Solomon <montyat_private>
    Subject: Web glitch exposed Fidelity accounts
    
    Canadian account holders information was accessible, AP, 29 May 2002
    
    A design flaw at a Fidelity Investments online service accessible to 300,000
    people allowed Canadian account holders to view other customers' account
    activity. The problem was discovered over the weekend by Ian Allen, a
    computer studies professor at Algonquin College in Ottawa. Fidelity said it
    had fixed the problem and was offering customers the option of changing
    account numbers.
      http://www.msnbc.com/news/758979.asp
    
    ------------------------------
    
    Date: Wed, 29 May 2002 15:56:36 +0100
    From: "Patrick O'Beirne" <yg02at_private>
    Subject: Hacker threat posed by Excel spreadsheets 
    
    http://www.silicon.com/a53624
    Tuesday 28th May 2002   11:20am
    
    A security hole in Excel XP spreadsheets which could lead to a hack attack
    has been exposed.  The discovery was made by independent security expert
    Georgi Guninski, who said on his Web site: "Excel XP tries to play with new
    technologies like XML and XSLT. Unfortunately the Excel seem so flawed that
    if the user opens a .xls file and chooses to view it with xml stylesheet
    arbitrary code may be executed. As script kiddies know this may lead to
    taking full control over a user's computer."  Guninski, who has posted a
    sample of the code in his site, said users should not use XML stylesheets.
    
    ------------------------------
    
    Date: Fri, 7 Jun 2002 09:44:20 +0100
    From: Martin Wheatman <martin.wheatmanat_private>
    Subject: Re: More on typos and homographs (RISKS-22.11)
    
    I have been informed by Malcolm Pack that I was wrong about the protection
    of the .co.uk domain, which involves no checks whatsoever.  The protected
    ones with stringent requirements are .ltd.uk and .plc.uk (which are private
    and publicly listed companies in the UK) and .sch.uk for schools and .ac.uk
    for academic institutions.  <http://www.nic.uk/rules/rup1.html>
    
      [This message is a combination of Martin's and Malcolm's items.  PGN-ed]
    
    ------------------------------
    
    Date: Thu, 06 Jun 2002 22:04:38 -0400
    From: Scott Nicol <snicolat_private>
    Subject: Re: More on typos and homographs (Wheatman, RISKS-22.11)
    
    Are you sure [about llyodstsb.com]?  You may want to change your password:
    
    whois lloydstsb.com gives
    Registrant:
        Lloyds Bank Plc (LLOYDSTSB2-DOM)
        Network Services
        64 Hopton Street, London SE1 9JQ
        United Kingdom
    
    whois llyodstsb.com gives
    Registrant Contact:
        FastNet Corporation
        Kwai Wei Suh   (fastnet22at_private)
        852-4326-7127
        339 Huan Shi Dong Road
        Guangzhou, AL 510098
        CN
    
    ------------------------------
    
    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.
       .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 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.12
    ************************
    



    This archive was generated by hypermail 2b30 : Mon Jun 10 2002 - 16:01:48 PDT