[risks] Risks Digest 21.88

From: RISKS List Owner (riskoat_private)
Date: Tue Jan 22 2002 - 16:55:06 PST

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

    RISKS-LIST: Risks-Forum Digest  Tuesday 22 January 2002  Volume 21 : Issue 88
       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.88.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    Bulgarian parliament against weight loss (Jonathan Larmour)
    Pope loves Internet, but wants "anti-depravity regulation" (Declan McCullagh)
    Unshredders (PGN)
    Newspaper archives (Roger Needham)
    Virginia county recalls student laptops (NewsScan)
    Software uncovers e-mail untruths (NewsScan)
    Georgia Tech anti-cheating software (Walter Roberson)
    Anthrax mail irradiation can affect electronic devices in postal mail
      (Thomas Dzubin)
    Health insurer computer changes delay payments... (Don Mackie)
    Excel cut-and-pasting behaviour (Geoffrey Brent)
    Lotus Notes silently losing data (Erling Kristiansen)
    Woman says telephone makes unsolicited calls (Carl Fink)
    Answering machine provides door entry code (Benjamin Elijah Griffin)
    Microsoft using predictable passwords for Passport? (Rodger Donaldson)
    Re: Other blunders (Brett)
    Re: Kaiser Permanente exposes medical record numbers (George C. Kaplan)
    Re: Bogus dates for McAfee virus alerts (David Blakey)
    Re: AOL's spam filters (Jay Levitt)
    Call for Participation Open Source Software Development Workshop
      (Cliff Jones)
    Abridged info on RISKS (comp.risks)
    Date: Tue, 22 Jan 2002 21:46:47 +0000
    From: Jonathan Larmour <jlarmourat_private>
    Subject: Bulgarian parliament against weight loss
    According to the (UK) Daily Telegraph, the Bulgarian parliament has a system
    of electronic voting, whereby Members vote with cards using a machine
    attached to their seats.
    Unfortunately, the designers didn't anticipate that more enterprising MPs
    would swap seats and also slip a voting card into absent neighbouring
    colleague's machines!
    I would have thought the (surely obvious) solution to this problem would
    have been personalised cards. But instead the parliament is introducing
    weighing scales set into the seat so that the votes will not be counted
    unless the weight of whoever is sitting there matches that of the MP whose
    seat it is.
    The risks of the initial design are obvious. There appears to have been
    absolutely no consideration of security or checking whatsoever. The risks of
    the "solution" are more interesting, including the possibility of preventing
    someone voting in the afternoon by making sure they have a large lunch!
    Date: Tue, 22 Jan 2002 14:11:58 -0800 (PST)
    From: Declan McCullagh <declanat_private>
    Subject: Pope loves Internet, but wants "anti-depravity regulation"
    Pope John Paul says that the Internet caters to the best and worst of human
    nature and needs regulation to stop depravity flooding cyberspace.  He
    warned that while it offered access to immense knowledge, the Internet did
    not necessarily provide wisdom and could easily be perverted to demean human
    dignity.  ``Despite its enormous potential for good, some of the degrading
    and damaging ways the Internet can be used are already obvious to all.
    Public authorities surely have a responsibility to guarantee that this
    marvelous instrument serves the common good and does not become a source of
    harm.''  Although the Pope does not have an e-mail address, the Vatican has
    an active Web site (www.vatican.va) and the Church is reportedly searching
    for a patron saint of Internet users.
      [Source: Pope Says Internet 'Wonderful' but Needs Regulating, by Crispian
      Balmer 22 Jan 2002, via Reuters; PGN-ed after DM's snipping]
    Date: Tue, 22 Jan 2002 9:27:13 PST
    From: "Peter G. Neumann" <neumannat_private>
    Subject: Unshredders
    The recent Enron/Anderson shredding frenzies suggest that it is time for
    UNSHREDDING software tools to come out of the closet.  It is certainly
    feasible to restore a boxful of shreds, particularly for ordinary
    course-grain linear shredders.  The effort for cross-cut shredders would be
    significantly more difficult, but still possible -- although probably less
    acceptable in court.  Anything with some natural language or graphical
    context is likely to be recoverable, using digram, trigram, etc., statistics
    for the likely linguistic base(s) and other context.  However, in general,
    it is probably easier to start out with backup tapes and incompletely
    deleted disks.  Easiest of all would be to install scanners and transmitters
    (or local storage) in the shredder mechanisms, because that would capture
    precisely the interesting materials deemed worth shredding.
      There once was a swindler named Fred
      Whose enterprise went in the red.
      The lawmen he dreaded,
      So papers were shredded,
      And off to the races he fled.
    Date: Tue, 22 Jan 2002 07:52:55 -0800
    From: "Roger Needham" <needhamat_private>
    Subject: Newspaper archives
    It is a principle in many jurisdictions that a jury should not know about
    prior charges or convictions of the accused.  In a Scottish court a man was
    accused of a particularly revolting crime, he having been acquitted of a
    similar offence on a technicality a number of years ago.  The judge ruled
    that the editor of a newspaper was in contempt of court by leaving reports
    of the earlier trial on line in his archive, because he had made it too easy
    for jurors to find out what they were not meant to know.  The judge
    apparently believed that the greater ease of access of the on line archive
    as compared to a paper archive was a difference not of degree but of kind.
    Roger Needham
    Date: Mon, 21 Jan 2002 09:07:30 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Virginia county recalls student laptops
    Henrico County, Va. school officials are recalling all 11,000 laptop
    computers that it distributed to its high school students in order to
    retrofit them with security software that will prevent students from using
    the devices for accessing pornography or changing their grades -- abuses
    that reportedly have occurred since the machines were handed out last fall.
    Game and music downloading capabilities will also be eliminated or heavily
    restricted and instant messaging will be limited to home use. Teachers have
    complained that in-class use of entertainment file-sharing and messaging are
    disruptive. (AP/*Wall Street Journal*, 20 Jan 2002; NewsScan Daily, 21 Jan
    2002) http://interactive.wsj.com/articles/SB1011563803808773240.htm
    Date: Mon, 21 Jan 2002 09:07:30 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Software uncovers e-mail untruths
    SAS Institute has developed software that it says can sift through e-mails
    and other electronic text to discern falsehoods. "The patterns in people's
    language change when they are uncertain or lying," says Peter Dorrington,
    business solutions manager at SAS. "We can compare basic patterns in words
    and grammatical structures versus benchmarks to detect likely lies." For
    instance, over-use of the word "or" and too many adjectives can be
    giveaways, according to Aldert Vrij's book, "Detecting Lies and Deceit."
    SAS says its software can also be used to detect inaccuracies in resumes and
    job applications.  (*Financial Times*, 20 Jan 2002; NewsScan Daily, 21 Jan
    2002)  http://news.ft.com/news/industries/internet&e-commerce
      [Risks?  What risks?  PGN]
    Date: Sun, 20 Jan 2002 16:18:14 -0600 (CST)
    From: Walter Roberson <robersonat_private>
    Subject: Georgia Tech anti-cheating software
    A recent CNN article describes a computer program that Georgia Tech
    has employed to detect cheating in its "Introduction to Computing"
    and "Object Oriented Programming" programming courses. 186 possible
    violations were found (over ~1700 enrolled students.) 
    I found this paragraph particularly interesting:
      But for the most part, the degree of similarity that this program is
      looking for -- the commas are in the same place, the semicolons are in the
      same place, the spacing is the same, they've made the same mistakes -- the
      only explanation, and what most students will eventually concede, is they
      actually did it," Eislet says.
    It seems to me that placement of commas, semicolons and spacing would tend
    to be the same for the more experienced programmers who have adopted coding
    standards -- or for anyone who runs their program through a "code
    beautifier". (Unless perhaps Eislet was referring to the -comments- rather
    than the code!)
    I gather from my readings and discussions with teachers of introductory
    programming classes, that, year after year, beginning programmers tend to
    make the same -kind- of mistakes. Gross syntactic mistakes are rejected by
    compilers, and modern compilers that would be used in teaching environments
    usually remark on error markers such as using assignment instead of
    comparison in an "if" statement; or use of a variable before it is
    initialized. This filtering that takes place in the compiler would tend to
    concentrate the errors more and more into common problem areas such as
    incorrect handling of boundary conditions, and failure to test return codes
    on I/O operations and library calls, so coding errors are -not- likely to be
    uniformly randomly distributed.
    I would also note that every submitted program is being compared to every
    other submitted program for the same class, as "cheating" is pair-wise, not
    something that is in reference to an absolute standard.  Any-time you have
    pairwise interactions, the number of pairs goes up as the square of the
    number of samples. If the marker variables are discrete and are limited in
    range, then one encounters "the birthday paradox", wherein it takes an
    unexpectedly small number of samples in order to find -some- pairwise match.
    My calculation is that the probability of an accidental match would have to
    be less than 1 in 721292 in order for there to be less than a 50% chance
    that the program will deem at least two innocent students in a class of 1000
    to have copied from each other.
    Considering that Eislet is quoted as saying that for a match, "the only
    explanation" is that the students cheated, I would have to question whether
    the program authors undertook a proper statistical analysis.
    Date: Tue, 8 Jan 2002 09:05:18 -0800 (PST)
    From: Thomas Dzubin <dzubintat_private>
    Subject: Anthrax mail irradiation can affect electronic devices in postal mail
    Story at: http://uk.news.yahoo.com/020108/80/cnoy6.html
    "Compact flash memory cards used to store data on many name-brand digital
    cameras and handheld computers face not just data loss but become entirely
    inoperable when subjected to electron beam irradiation, the CompactFlash
    Association said on Tuesday"
    (I just checked the CompactFlash Association web site at
    www.compactflash.org and didn't see any related news-release about
    this, so I don't know how much research has gone into this assertion or
    if this is a potential birth of a new "urban legend")
    It does bring up an interesting technology related risk
    I think most (North-American) people make the following two assumptions:
    1. postal service will generally deliver anything small & non-dangerous.
    2. postal service doesn't alter contents of things it delivers.
    When you add "technology" to either of these in isolation, there is no
    problem.  However the technology-related risk here is that when you
    add "technology" (irradiation & flash cards) to BOTH of these
    assumptions, the result can be unexpected and damaging.
    Thomas Dzubin  Network Analyst & PDP-11 enthusiast
    Vancouver, Saskatoon, or Calgary  CANADA
    Date: Sun, 20 Jan 02 11:19:06 +1300
    From: Don Mackie <donaldat_private>
    Subject: Health insurer computer changes delay payments...
    Southern Cross Healthcare, New Zealand's largest health insurer, bought out
    Aetna locally. At the time, acquisition of Aetna's patient and practitioner
    database was one of the Southern Cross's goals. Since before Christmas
    Southern Cross has run into increasing delays in paying claims.  This has
    caused cash flow difficulties for some private hospitals.  Southern Cross
    published ads saying it was all due to difficulties with their new computer
    system. More recent articles tell us the predictable story - that the
    transition to a different system has, once again, been poorly handled.
    Date: Fri, 18 Jan 2002 14:52:51 +1100
    From: Geoffrey Brent <g.brentat_private>
    Subject: Excel cut-and-pasting behaviour
    Some time back, I was doing work that involved a lot of cut-and-pasting data
    between Excel files. Open source file, select cells, Ctrl-C, select
    destination file, Ctrl-V, repeat for dozens of source files.
    I got tired of having lots of source files open at once, so I changed this
    slightly: open source file, select cells, Ctrl-C, close source file, select
    destination file, Ctrl-V, repeat.
    At first this looked like it was accomplishing exactly the same thing, with
    exactly the same numbers appearing in the target cells, but when I tried
    further processing of the data (examining differences between adjacent
    cells) it became obvious that something was wrong - the results were much
    too 'grainy'.
    Eventually I discovered the cause of the problem. When pasting from an open
    file, Excel correctly pastes the full contents of the selected cells. But if
    the source file is closed before pasting, it does not paste the full
    contents - only the *displayed* contents. The result of this is to
    automatically round pasted data at the display precision (so with a
    precision of two decimal places, a value of 1.59835 would be pasted as
    1.59835 from an open file, but as 1.60 if the file was closed before
    pasting.)  And because the rounding precision here _is_ the display
    precision, the pasted data looks correct until you change the precision to
    examine it...
    Fortunately, the display precision I was using was low enough to make for
    very large errors, so it was obvious that there was a problem. At a slightly
    higher precision, I could quite easily have ended up with significant but
    non-obvious errors.
    The risk here: one operation with two modes of behaviour that _look_
    identical, but aren't.
    Geoffrey Brent
    Date: Fri, 11 Jan 2002 21:19:14 +0100
    From: Erling Kristiansen <ekristiaat_private>
    Subject: Lotus Notes silently losing data
    I have experienced several, apparently unrelated, incidents where Lotus
    Notes is quietly losing data.
    * I printed a mail message before I sent it. Some of the cc: addresses were
    quietly and permanently removed. (Did anybody say buffer overflow recently?
    Maybe it is more like buffer truncation, but certainly member of the same
    * Trying to reply to a mail I received, I discovered that 3 out of the about
    10 cc: addresses in the incoming message had been truncated, rendering them
    invalid. No addresses were lost completely, but the amount of truncation
    that occurred suggests that a short address might be "truncated into
    extinction" if it is in the right place in the list of addresses. I checked
    the original RFC-822 header that is accessible.  It was correct.
    By the way, correcting the addresses in place and re-sending had a very
    strange effect: The corrected addresses, and only those, were turned into an
    X.400-like address with a number of attributes pointing to my local
    environment. I had to remove and re-type the "sick" addresses to have them
    * I copied and pasted about 100 addresses from a spreadsheet into the bcc:
    field of a mail. Everything looked OK, the pasted addresses appeared neatly
    in the address window, I could scroll through them, etc.  But the message
    was only sent to the first address. No warning of any kind appeared that a
    good hundred addresses had been discarded. I only discovered the error
    because I had asked for delivery notification, and got very few. Had I not
    discovered this, only a handful of people would have been invited to a
    presentation. (there were a few other addressees that had not been pasted in
    - those worked OK even though some were entered AFTER the skipped
    * Notes allows you to format messages, with facilities more or less
    equivalent to an HTML editor. If a message is sent outside the Notes domain,
    ALL formatting is removed, even things like indentation and paragraph
    numbers. So a nicely formatted message may become rather unreadable, even
    ambiguous (indentation may imply a lot about the meaning of a text). No
    warning is given that formatting information is being removed.
    The RISK of all this is that Notes accepts instructions to do something,
    does not complain about the input, and then goes ahead and does something
    else than what could reasonably be expected. You can obviously check for any
    of these events, but they are rare enough, and different enough, that you
    don't really know when to expect a problem, and what to look for in order to
    make sure everything went as expected.
    Erling Kristiansen
    Date: Fri, 18 Jan 2002 13:17:49 -0500
    From: Carl Fink <carlat_private>
    Subject: Woman says telephone makes unsolicited calls
    According to the *Detroit News*, Becky Sivek doesn't even have long distance
    service.  Nevertheless, "thousands" of long distance calls all over the USA
    are being made.  The calls disconnect as soon as someone picks up.  Some
    people are getting this same call dozens of times a day.
    Although Sivek isn't making the calls, and they don't appear on her bill,
    caller ID shows her number, meaning that she's now getting many angry and/or
    threatening calls from people demanding she stop harassing them.
    Phone phreaks, maybe?
    Carl Fink, I-Con's Science and Technology Programming  http://www.iconsf.org/
    Date: Mon, 21 Jan 2002 14:32:33 -0500 (EST)
    From: Benjamin Elijah Griffin <eliat_private>
    Subject: Answering machine provides door entry code
    On a recent Sunday, walking past an office building in my area a woman asked
    me for help getting into the building. She explained she had an appointment
    with a tenant in the building but couldn't get in. She had dialed the
    company's extension on an outside phone and gotten a recorded message to
    'enter #2000 to come in, if you have an appointment'. The phone used '##' to
    hang up calls, and it was the number of #s required that caused the problem
    for the woman, but I find it baffling that an answering machine is
    considered acceptable weekend security.
    Date: Sun, 20 Jan 2002 09:03:01 +1300
    From: Rodger Donaldson <rodgerdat_private>
    Subject: Microsoft using predictable passwords for Passport?
    An organisation I am familiar with has a Microsoft support contract for the
    Microsoft components of their infrastructure; in order to access Microsoft's
    on-line resources, a Passport account is required.  Microsoft has allocated
    the company a Passport account, with a numeric login whose password is set
    to the surname of their primary contact in the company.
    The risk?  This is a totally predictable scheme.  It would be trivial to
    scan the numeric Passport logins looking for passwords set to common
    Rodger Donaldson <rodgerdat_private>
    Date: Thu, 10 Jan 2002 14:03:29 -0600
    From: brettat_private
    Subject: Re: Other blunders (La Fetra, RISKS-21.86)
    In RISKS-21.86, Skip La Fetra ('Other blunders on "secure" Web sites')
    claims that request parameters contained in a URL are not protected
    (encrypted) when the request is sent via a HTTPS GET.
    This is a misunderstanding regarding the actual risk of using the GET method
    instead of the POST method. The traffic in an HTTPS session is always
    encrypted, whether the GET or POST method is used. However, use of the GET
    method encodes the parameters (including e.g. credit card numbers) into the
    request URL.  This exposes such info in your browser history and in the site
    logs of the web server (rendering it vulnerable to the electronic equivalent
    of 'dumpster diving') -- the info is not, however, transmitted in cleartext.
    Date: Thu, 10 Jan 2002 13:48:35 -0800
    From: "George C. Kaplan" <gckaplanat_private>
    Subject: Re: Kaiser Permanente exposes medical record numbers
    j debert <jdebertat_private> writes in RISKS 21.86
    > Kaiser Permanente has a Web site for members at http://www.kponline.org/ .
    > The first page here is the signon page, where one enters a medical record
    > number and their region to enter the site.
    > A statement concerning online security ... indicates in the first 
    > paragraph that the medical record number will be sent via SSL:
    > ...
    > However no SSL connection is possible. Every attempt to obtain a secure
    > connection gets redirected to the non-secure page.
    It's not *quite* this bad.  True, if you try to go to 
    https:/www.kponline.org, you invariably get redirected back to the 
    unprotected page.  However, the ACTION part of the sign-on form points
    to https://kponline.kp.org/signon/signonmember, which is SSL-protected.
    All further interaction with the Kaiser site after signing on appears 
    to be through SSL via kponline.kp.org.
    But they make the same mistake mentioned by Skip La Fetra earlier in the
    same RISKS digest: the medical record number is transmitted in the URL.  So
    Kaiser's claim is incorrect; the medical record number is not protected by
    Once you've registered, you need a PIN to sign-on, and that *is* sent via
    SSL, so the PIN and the rest of your session apper to be reasonably well
    protected.  But in order to *get* a PIN, the only "authentication" data
    required (besides the record number) is your full name.
    I guess if you're a Kaiser member you should register on this site before
    someone else does it for you.
    George C. Kaplan, Communication & Network Services
    University of California at Berkeley  1-510-643-0496 gckaplanat_private
    Date: Tue, 08 Jan 2002 11:33:43 +1300
    From: David Blakey <djbat_private>
    Subject: Re: Bogus dates for McAfee virus alerts (Colburn, RISKS-21.85)
    This is familiar to Web designers, and should be known by someone like McAfee.
    First, many people have JavaScript turned off.  If the script is not going 
    to be completed, then the designer should have more sense than to write out 
    the "This page current as of ".  This should be included in the script as 
    well, so that people with JavaScript turned off will not see anything at all.
    Second,  the JavaScript date may be presented by a source that is 
    unreliable - such as the client's system date - or unsupported - such as 
    "date modified" in some browsers.
    The site seems to lack a good "sniffer" to find out (1) if JavaScript is on 
    and (2) if the "date modified" function is supported.  There is little risk 
    presented by this site, but one wonders if the people who designed it have 
    since moved on to emergency services or air traffic or defence sites.
    Date: Sat, 19 Jan 2002 21:59:26 -0500
    From: "Jay Levitt" <jayat_private>
    Subject: Re: AOL's spam filters (Burstein, RISKS-21.85)
    > Also note that a "bounce" message would take this whole saga out of the
    > "risks" venue (or at least move it to the margin). 
    Would that that were true, but bouncing spam merely introduces new risks.
    I was intimately involved in AOL's mail system for most of the past decade,
    and our motto was It's Not That Simple.
    AOL hasn't always had spam filters.  Years ago, we would see huge numbers
    of bounce messages generated for spam runs, since spammers often send to e-
    mail addresses that are no longer valid.  One spammer actually sued us for
    delivering his bounces back to him - he said we were trying to overload his
    small mail server!  (Apparently the huge volume crashed it.)  And once
    spammers started forging return addresses, these bounces began causing no
    end of trouble for the poor site that found itself receiving millions of
    undeliverable e-mail reports from AOL.  Additionally, we had to make sure
    that these huge queues of bounce e-mails didn't interfere with the delivery
    of legitimate communications, or even bounces of legitimate communications.
    Far from taking minutes to deliver, these bounce queues can quickly back up
    to infinity without constant babysitting.
    With SMTP, if you can detect that a message is undeliverable early enough
    in the process, you can simply refuse it, rather than bounce it back.  But
    that presumes that the machine sending to you is the originator of the
    message.  Spammers often relay their e-mail off unsuspecting third-party
    mail servers that are configured to accept mail from anywhere and deliver
    it to anywhere. (This was the default configuration of all mail servers
    until just a few years ago; remember, the Internet began as a cooperative
    effort.)  If you refuse mail from a third-party relay, THEY then have to
    deliver the bounce messages, which again can crash or hobble their systems.
    Of course, if you simply turn off spam filters on a system as target-rich
    as AOL, you're left with a fairly useless mail system - we've often
    estimated that 30-50% of all the incoming messages are spam.
    I've since left AOL, but I know that the folks there were doing everything
    they could to detect spam as early in the transaction as possible, and
    refusing it rather than bouncing it whenever they could.
    The real risk is taking a protocol designed to cooperatively exchange
    messages within a small community, and using it for worldwide, mission-
    critical communications, sometimes from hostile senders.  The rest is
    imperfect band-aids.
    Date: Sun, 20 Jan 2002 17:29:17 +0000
    From: Cliff Jones <cliff.jonesat_private>
    Subject: Call for Participation Open Source Software Development Workshop
                     Newcastle upon Tyne, UK
    The focus of the Open Source Software Development workshop is on
    dependability and open-source software development. Dependability is a
    deliberately broad term which, among others, covers reliability, security,
    safety and availability.
    We have put together an exciting programme and would welcome further
    participation from the community. Participation would be particularly
    welcomed from any of those engaged in, or affected by, the design,
    development or operation of open source software. An important objective of
    this workshop is a greatly improved understanding of the complete
    organisational and cultural context of complex systems of which computers
    are a part. To this end, we especially encourage participation from
    interdisciplinary researchers and practitioners, since we believe that such
    research is crucial for progress towards the safe deployment of new
    Those interested in participating in this event should send an e-mail
    stating their interest to Cristina.Gacekat_private, preferably by 15th
    February 2002.
      Cristina Gacek, Centre for Software Reliability (Bedson Building)
      Department of Computing Science, University of Newcastle upon Tyne
      NE1 7RU  -  United Kingdom    Telephone: (44 191) 222 5153
      FAX: (44 191) 222 8788  cristina.gacekat_private
    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.88

    This archive was generated by hypermail 2b30 : Tue Jan 22 2002 - 18:25:45 PST