[risks] Risks Digest 22.45

From: RISKS List Owner (riskoat_private)
Date: Wed Jan 01 2003 - 20:17:46 PST

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

    RISKS-LIST: Risks-Forum Digest  Weds 1 January 2003  Volume 22 : Issue 45
    
       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.45.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Hard-coded calendar dates (Dave Stringer-Calvert)
    Somebody stole backup tapes containing citizen's private information (Ishikawa)
    Poor encryption: Transportation Security Administration (M Taylor)
    Browser incompatibilities cost business (Geoff Kuenning)
    No such thing as "knowing that a check has cleared?" (Daniel P.B. Smith)
    Re: O Big Brother, where art thou? (Edward G. Nilges)
    Re: Why you should read or should not read... (Fred Cohen)
    REVIEW: "Software Engineering", Ian Sommerville (Rob Slade)
    REVIEW: "Trusted Computing Platforms", Siani Pearson (Rob Slade)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Wed, 01 Jan 2003 12:45:28 -0800
    From: Dave Stringer-Calvert <dave_scat_private>
    Subject: Hard-coded calendar dates
    
    The front page of the *Yorkshire Evening Press* Web site
    (http://www.thisisyork.co.uk) is declaring today to be 
    Wednesday, January 1 2002.  The JavaScript on the page is:
    
    document.write(dayNames[day] + ", " + monthNames[month] + " " + date + ", 2002");
    
    Happy *NEW* year!
    
    Dr Dave Stringer-Calvert, Assistant Director, Computer Science Laboratory
    SRI International, Menlo Park CA 94025-3493  1-650-859-3291 
    
    ------------------------------
    
    Date: Tue, 31 Dec 2002 00:50:48 +0900
    From: Ishikawa <ishikawaat_private>
    Subject: Somebody stole backup tapes containing citizen's private information
    
    I would like to report an incident which made me feel dizzy at this
    otherwise tranquil days at the end of the year.
    
    In Japan, a national system to coordinate citizen's private information
    stored in government computer is being prepared amid vocal opposition from
    various parties.
    
    Basically, a single number, 11 decimal digits number is assigned to each
    individual and this will be used as the search key in accessing various data
    bases.  (Some kind of mapping table would be prepared by local government
    agencies with this nationally unique number to access individual's record in
    local government databases .)  There would be a nation-wide network where
    the key would be used as the primary key for accessing various databases
    scattered across the nation.
    
    The danger for abuse is obvious and the fear is so much that some cities and
    jurisdictions decided to challenge the national policy by declaring that
    they would not be online with the system, etc. when the final preparation
    for the full-scale deployment began this summer.  (The city of Yokohama
    where I live decided to allow the citizen to decide if the personal number
    assigned to them would be delivered to the prefectural level data center or
    not unless sufficient assurance for protection is forthcoming from the
    national government.  About 30% of the population asked the number not be
    sent, and this popular demand made national newspaper headlines : Yokohama
    has about 3 million population and is a big city in Japanese scale of
    things.  Obviously the government agency which is pushing the national
    policy and the construction of the network has PR problems now.
    
    The risk is now huge since the diet (national parliament) failed to enact a
    privacy protection law which should have been prepared along with such a
    numbering system.
    
    Anyway, the national government has been trying to assure that the system
    would be safe with computer security protection, etc..
    
    However, it has already been criticized for such mundane thing as slow
    anti-virus data update which would take place once a few months(!) [makes me
    wonder where on earth they have been living in the last few years.], which
    the government agency claims is not a serious threat since the network in
    question is not directly connected to Internet, etc..  But, of course, some
    town offices seem to use the same computer for internal LAN and accessing
    the national network in question. (There must be some form of physical
    switches in place, but we never know what happens. Murphy's law always
    strikes.)
    
    Probably the last straw which might break the pro-numbering support is the
    theft of backup magnetic tapes that happened in a town north east of Tokyo.
    
    There, five backup DAT tapes of the town office computer systems containing
    privacy data of approximately 9600 were stolen from a parked car of a
    computer maintenance service company. The tapes were on the way for off-site
    storage, and were in a metalic attache case.  It seems that whoever stole
    the case mistook it for one containing money or some other valuables.  (On
    the other hand, since the parking lot belongs to the computer maintenance
    company, we should not rule out that a serious cracker (or two?) stole the
    tapes to gain foothold into the national network.)
    
    The newspaper articles aren't clear what are on the tapes and in what form,
    but the city spokesman stated that the data did include the national numbers
    for the citizens and privacy data such as address, name, gender, birth date,
    qualification status for the various national health insurance plans, and
    pensions.  The data is claimed to be in encrypted form (but no detail) and
    won't be easy to read according to the statement.  However, given the risks,
    the city officials decided to ask the permission of each citizen to change
    the numbers assigned to them so that the numbers themselves won't be used
    for some malicious tampering in the future.  (The law requires that the
    change of numbers needs the consent of the citizen.)
    
    Numbers aside, the rest of the information, if decrypted, would be the
    staggering source for privacy theft, etc.
    
    I can't say for sure but some say that backups were made using ARCserver
    backup software or something. I have no idea what type of cryptography it
    supports, but I surely hope the algorithm is a good one and the key length
    is long enough if ARCserver is indeed used for this national network.
    
    The tapes were stolen on 26th, and found scattered on a river bank on 30th.
    Three tapes were found outside the opened metallic case.  The lock to the
    attache case was forced open.  (So two of the DATs were still missing, it
    seems.  Again the newspaper article that I read was not very clear on this
    point.)
    
    Using encryption for backup data is a common sense.  But then I have no idea
    how the key for the encryption is managed and what type of algorithms are
    used in this particular case, and if I were the citizen of the town of
    Iwashiro, I would have been disturbed very much.
    
    One thing I don't like about this national network being built is the
    apparent lack of security policy.
    
    Since there is no clearly written national security policy, this type of
    problems, like the maintenance person leaving the valuable data tape in an
    attache case inside a car parked at company parking lot, may happen in the
    future.  The way the network is built and the apparent lack of nation-wide
    security policy of this network force me to think that information leak
    caused by computers that are linked to the network and also have outside
    connection inside the town/city office LAN, which in turn, may have
    unexpected Internet link via somebody's modem, or even caused by simple
    eavesdropping via wireless LAN may happen not in the distant future.
    
    I hate to think that the government has to go through such incidents before
    learning the basic of security management.
    
    After writing this, I realize the above may look unbelievable to security
    consultants who read Risks today, but is true and is happening now in Japan.
    
    Only in the last few months, some government agencies learned the danger of
    wireless LAN: some drive-by inspection caught the contents of the unencrypted
    traffic easily.
    
    I hate to think about the mess caused by large-scale identity theft, etc..
    This incident of stolen tapes wiped out the last trust I had in this
    national numbering system and I am no longer in the mood of festive holiday
    season.
    
    ------------------------------
    
    Date: Tue, 31 Dec 2002 16:07:21 +0000
    From: M Taylor <mctaylorat_private>
    Subject: Poor encryption: Transportation Security Administration
    
    TSA Documents' Protection Easily Circumvented
    
    Several restricted U.S. Transportation Security Administration (TSA)
    documents are accessible to anyone with an Internet connection. While
    they are password protected within Microsoft Word, once they are
    downloaded, they can be attacked with password cracking software at
    the user's leisure.
      [Source: reuters 24 Dec 2002, in SANS NewsBites, 30 Dec 2002, Vol 4 no 53]
      http://reuters.com/newsArticle.jhtml?type=internetNews&storyID=1958544
    
    So how risky is it to provide insecure "encryption", that misleads uses into
    thinking that their documents are safe? It appears to be RISKy for the user,
    to rely on such labelled "features" in the software they choose to use.
    
    M Taylor  http://www.mctaylor.com/
    
      [Geoff Kuenning noted this quote in the article:
        "We think it's safe," a spokesman said. "From our
        standpoint it's very workable and secure."  
      PGN]
    
    ------------------------------
    
    Date: Mon, 30 Dec 2002 04:13:25 -0800 (PST)
    From: Geoff Kuenning <geoffat_private>
    Subject: Browser incompatibilities cost business
    
    I have noticed a trend in the past 6 months of increasing numbers of
    Web sites that will not work correctly with my browser.  The most
    common symptom is a blank page, presumably because some bit of
    JavaScript failed to execute the way they assumed it would.  (In one
    case, I took the trouble to diagnose the failure and found that a null
    URL was expected to load the referring page; replacing it with a
    proper URL cured the problem.)
    
    What amazes me is that most of these bugs are caused by unnecessary
    use of new (i.e., not widespread) features, and that they cost
    companies business.  For example, this evening I tried to buy Kevin
    Mitnick's book, as recommended by Don Norman in RISKS.  Try as I
    might, I could not get buy.com's site to allow me to enter an updated
    credit-card number.  I finally gave up, started the search over, and
    purchased the book elsewhere.
    
    One has to wonder how much business has been lost because gadget-loving
    programmers are more fascinated with the latest features than with
    compatibility.
    
        Geoff Kuenning   geoffat_private   http://www.cs.hmc.edu/~geoff/
    
    ------------------------------
    
    Date: Mon, 30 Dec 2002 07:05:40 -0500
    From: "Daniel P. B. Smith" <dpbsmithat_private>
    Subject: No such thing as "knowing that a check has cleared?" (Re: RISKS-22.44)
    
    In reference to a Nigerian scam, "Sidney Markowitz" <sidneyat_private> says
    that "It is common for check transactions to be held until the check clears,
    to ensure that the check is good. Now we see that the time it takes for a
    check to clear is determined by US law that sets a limit on how long a bank
    can delay paying for a deposited check. But that limit does not make it any
    faster for the bank to really determine if the check is good. The unintended
    consequence of the law is that a cleared check may not be a cleared check."
    
    Some years ago I once was in a situation where I wanted to be certain that a
    check "was good" and "had cleared."
    
    I had a lengthy discussion with a bank vice-president, and I understood him
    to say that the clearinghouse system does not provide any way to ever know
    for certain that any particular check has cleared.  If a check FAILS to
    clear, everyone finds out about it.  But when a check clears successfully,
    there is no traceable information about the transaction.  He said that,
    theoretically, there was no way to know that a particular check had cleared.
    
    I was told that it "was safe to ASSUME" that if the check had not bounced
    within two weeks, that it "must have cleared," but that there was no
    positive guarantee and no way to check the status of any particular check.
    
    Daniel P.B. Smith  dpbsmithat_private   dpbsmithat_private
    
      [Similar comments from Brian Reynolds ("This is not a new scam."), Tony
      Lima, Ron Bean ("Could be a big risk for banks as well, given their
      Clinton-esque definition of the word "cleared").  PGN]
      
    ------------------------------
    
    Date: 1 Jan 2003 12:33:12 -0800
    From: spinoza1111at_private (Edward G. Nilges)
    Subject: Re: O Big Brother, where art thou? (RISKS-22.44)
    
    I would strengthen Dorothy Denning's objections, for they redescribe
    terrorist surveillance as a "daunting task."
    
    Unfortunately this shares with the TIA the assumption that the task, of
    surveillance, is one that can be solved at all.
    
    The literary critic, and Palestinian moderate activist, Edward Said, has
    pointed out that the US State Department tends to hire people with easily
    measured skills in development economics to work on Mideast problems.  He
    has contrasted this with the older practice of Britain's foreign and
    colonial desks, which was to hire literary dons who had specialized in
    topics such as Persian poetry.
    
    The most recent example of this mindset was the termination of several
    Arabic speakers at the Defense Language Institute because of their sexual
    orientation; for there is a linkage between hatred of "soft" skills and
    homophobia.
    
    There are drawbacks to both practices, but Said does point to a bias...in
    favor of the technological quick fix of which the Total Information
    Awareness program is an example.
    
    Furthermore, solid technical arguments lead one to conclude that the TIA
    will not work.
    
    First of all, Groove is a commercial software product, and, if my guess
    (that the TIA is in part a bit of a bailout for Bush's friends in the IT
    industry, suffering as it is in a depression), the design of the TIA will
    emphasise commercial and off-the-shelf solutions.
    
    The problem is that this MEANS that the ill-defined "enemy" can acquire the
    same software being used to surveille him, run it to detect what it, in
    turn, detects, then change his patterns.  In a sense, a Turing machine (the
    Groove system running on TIA computers) is examining a social Turing machine
    (the bad guys and their copy of Groove) to see whether it will arrive at a
    "halt" state (an attack.)
    
    This Turing problem is independent of hardware and software.  We can be
    certain that terrorists will no longer try to carry box cutters on board
    airplanes and overwhelm the passengers and crew in what seems a
    "conventional" hostage situation but what is a suicide attack, for such
    behavior will now be coded, by the passengers, as a suicide attack.
    
    Unfortunately, Professor Denning's objection, that it's a "daunting" task,
    can be met by the language of go-ahead problem-solving in which the person
    who says it's a "daunting" task is placed at a disadvantage, rhetorically.
    She makes it sound as if we're not up to it.
    
    Unfortunately, negative results (such as Turing's) stay true and are not
    disproved by technical progress, any more than perpetual motion becomes
    true.
    
    In algorithmic terms, a "computer" (the US defense establishment) is
    examining another "computer" (al-Qaeda) to find its halt state, and, to
    complicate matters, the examinee knows of the monitoring.
    
    Even if a data base existed with full optics and sound that replicated ALL
    activity in Eurasia alone, any one action could, or might not, be an
    encoding of terrorist intelligence and for this reason, interpretation would
    become the job of the same people who failed to bring in the "twentieth
    highjacker" for questioning.  Our government would have to refute, at the
    level of basic science, Alonzo Church's thesis to the effect that all
    computers are Turing machines, and it would have to make or buy a Turing+n
    system that could defeat other Turing+0 systems.
    
    Nor can our government "scale up" for adding cycles doesn't change the math.
    The near-demise of supercomputing as big iron shows us that the bad guys can
    use networks in place of centralized big iron.
    
    Of course, this is the point at which truly rational men and women throw
    down their gear and advance across wastelands with ancient symbols of peace.
    This is the point at which Ronald Reagan, a quite ordinary man, abandoned
    the equivalent insanity of Mutual Assured Destruction and went to Reykjavik.
    
    However, what American politician has the courage to solve the Mideast
    problem by raising our gasoline taxes, and announcing that the US should be
    considered an alternate homeland for Jews worldwide (boy, that was easy)?
    
    The problem is that the United States is engaged (like it or not) in a
    dialogue with terrorists.  If like Sharon in Israel and Cheney here, our
    statesmen play to the gallery, and "refuse" to "dialog" with "terrorists",
    they discover that violence becomes the language of choice.
    
    "Hackerz" already change the spelling of code words faster than they can be
    defeated by scanners.  Unless the US develops (at considerable expense) a
    proprietary technology-of-surveillance which cannot be reverse engineered,
    the TIA is at best a boon doggle and at worst a replacement for a needed
    dialog.
    
    ------------------------------
    
    Date: Mon, 30 Dec 2002 08:23:25 -0800 (PST)
    From: Fred Cohen <fcat_private>
    Subject: Re: Why you should read or should not read... (Norman, RISKS-22.44)
    
    Why not read the book?
    Because the author is a con artist and you are sending him $s?
    
    OK - so Don makes the point that:
    	"I'm a student of human psychology...
    	I read books by ex-criminals:...
    	I learn a lot."
    
    Fair enough.  If you are studying criminal behavior, reading books by
    crooks is probably a good idea.  But if you want to know about cons,
    far better books are:
    
    	"Flim-Flam" by James Randi
    	"Scam School" by Chuck Whitlock
    and	"Rip-Off" by Fay Faron
    
    All three are by legitimate researchers who present results taken from
    scores to hundreds of incidents and present how and why scams work, the
    techniques used, the different plots, and so forth.  They present many
    excellent examples of how these sorts of crimes work, how they impact
    the victims, the psychology of the criminals, and so forth.
    
    > I learned a lot from ... I was impressed by his approaches. They
    > are not as simple and easy to do as a quick reading would make them
    > appear. After the fact, everything always looks obvious. But I, for
    > example, would find it difficult to even think of the schemes, let alone
    > carry them out successfully.
    
    One of the major problems we face in information protection is people who
    just don't think cleverly of bad things that could happen.  It might serve
    Don well to take an introductory course in the subject matter.  He will
    learn a lot more than from a book by a crook and he will be supporting
    defenders rather than attackers.
    
    Fred Cohen - http://all.net/ - fcat_private - fcat_private
    tel/fax: 925-454-0171 Fred Cohen & Associates - University of New Haven 
    
    ------------------------------
    
    Date: Tue, 24 Dec 2002 08:17:04 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Software Engineering", Ian Sommerville
    
    BKSFTENG.RVW   20020916
    
    "Software Engineering", Ian Sommerville, 2001, 0-201-39815-X, C$104.95
    %A   Ian Sommerville ian@software-engin.com
    %C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
    %D   2001
    %G   0-201-39815-X
    %I   Addison-Wesley Publishing Co.
    %O   C$104.95 416-447-5101 fax: 416-443-0948
    %O  http://www.amazon.com/exec/obidos/ASIN/020139815X/robsladesinterne
    %P   693 p.
    %T   "Software Engineering, Sixth Edition"
    
    Part one is an overview.  Chapter one is an introduction, a FAQ
    (Frequently Asked Questions list), definitions, and, interestingly, a
    section on ethics.  A broad review of system development concepts
    (such as emergent properties) is presented as computer based software
    engineering, in chapter two.  Stages in the software development
    process, none detailed, are listed in chapter three.  Project
    management is discussed in chapter four.
    
    Part two looks at software requirements.  Chapter five examines
    different types of requirements.  Requirements engineering is software
    engineering in miniature, as chapter six points out.  There is a heavy
    emphasis on the Universal Modeling Language (UML) in chapter seven's
    explanation of system models.  The benefits and dangers of software
    prototyping are examined in chapter eight.  Chapter nine points out
    that formal specification does require special training on the part of
    users, but can identify problems in requirements specifications. 
    (More extensive examples would be helpful in making this point more
    convincing.)
    
    Part three reviews design, and the chapters are mostly divided by
    system type.  Chapter ten explains architectural design, and reviews
    tools and models.  (Security, and other concerns, are addressed
    throughout the book: an example in this chapter points out that
    interrupt driven architectures are complex and difficult to validate.) 
    Distributed systems architecture itself gets oddly short shrift in
    chapter eleven, which concentrates on client/server and CORBA (Common
    Object Request Broker Architecture).  Object-oriented design is shown
    to be very much like modular design in chapter twelve.  (The stated
    objective of the text is to introduce UML, but the explanations are
    not very clear.)  Chapter thirteen looks at real-time software design
    but does not seem to be as complete as other topics.  Design with code
    reuse is a good overview, but chapter fourteen starts out with the
    statement that electrical and mechanical engineers rely on component
    reuse, ignoring the lack of a broad range of standard components in
    the software environment.  There are good, basic suggestions for user
    interface design, in chapter fifteen, although the discussion is
    limited.  For example, the recommended principles suggest confirmation
    of destructive actions, but don't note the fact that even such
    confirmations become automatic over time, and therefore are not
    particularly useful.
    
    Part four deals with critical systems.  Chapter sixteen looks at
    dependability in terms of availability, reliability, safety, and
    security.  Critical systems specification, in chapter seventeen,
    examines dependability (and failure) metrics.  Risk analysis is
    discussed, but not in the usual combination of probability and
    severity.  Critical systems development is examined both in terms of
    fault avoidance and fault tolerance in chapter eighteen.
    
    Part five covers verification and validation.  Chapter nineteen
    concentrates on code inspection and the Cleanroom process.  Software
    testing, in chapter twenty, looks at types, cases, and procedures. 
    Critical systems validation, in chapter twenty one, is basically the
    same process as the previous chapter, but more important.
    
    Part six, on management, is mostly a precis or list of principles from
    other sections.  Chapter twenty two deals with managing people,
    looking at limits, motivation, group dynamics, recruiting, and
    keeping, as well as a quick overview of the People Capability Maturity
    Model (P-CMM).  It's not a large section, but it is nice to see the
    importance of personnel recognized in this way.  Software cost
    estimating, in chapter twenty three, is interesting, but possibly not
    terribly useful.  Quality management is dealt with in chapter twenty
    four.  Chapter twenty five reviews process improvement and the
    Capability Maturity Model (CMM), mentioning the work of Walter Deming
    but not, intriguingly, dealing with the fact that Deming's later work
    suggested that business had gone overboard in the pursuit of quality.
    
    Part seven deals with evolution and change.  Chapter twenty six
    discusses legacy systems with a description of mainframe program
    structures and guidelines for the assessment of the possibilities for
    updating the system.  Software change is reviewed in chapter twenty
    seven, with maintenance and re-architecting leading to a description
    of re-engineering in chapter twenty eight.  Chapter twenty nine
    finishes off with configuration management, emphasizing version
    documentation more than change control.
    
    The book is written as a textbook, with a summary of key points and a
    very decent set of exercises at the end of every chapter.  It
    certainly stands above the other systems development texts that I have
    experienced.  However, this work also has value beyond the classroom. 
    A great many professionals, such as information security officers,
    need to know the operations, procedures and concepts of software
    engineering without necessarily being programmers themselves.  For
    these people, this volume makes a clear and excellent reference.
    
    copyright Robert M. Slade, 2002   BKSFTENG.RVW   20020916
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    Date: Fri, 27 Dec 2002 08:02:27 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Trusted Computing Platforms", Siani Pearson
    
    BKTRCMPL.RVW   20020916
    
    "Trusted Computing Platforms", Siani Pearson, 2003, 0-13-009220-7,
    U$49.99/C$77.99
    %E   Siani Pearson
    %C   One Lake St., Upper Saddle River, NJ   07458
    %D   2003
    %G   0-13-009220-7
    %I   Prentice Hall
    %O   U$49.99/C$77.99 +1-201-236-7139 fax: +1-201-236-7131
    %O  http://www.amazon.com/exec/obidos/ASIN/0130092207/robsladesinterne
    %P   322 p.
    %T   "Trusted Computing Platforms: TCPA Technology in Context"
    
    Part one introduces trusted platform technology, as a kind of public
    key infrastructure implemented in hardware.  (Which begs the question:
    what do you do about key revocation?)  Chapter one, an overview of the
    trusted computing platform concept, is not very clear on basic ideas
    beyond hardware implementation involvement and the notion of
    measurement, or assurance.  There are usage scenarios of applications
    that can be done, or done better, with trusted platforms, in chapter
    two.  Not all of these cases are convincing evidence that trusted
    platforms are better.  The cryptographic underpinnings of trusted
    platforms are examined in chapter three, but it would be clearer if
    the basics of asymmetric cryptography were covered and standard
    cryptographic and certificate authority terms were used.
    
    Part two concerns trust mechanisms in a trusted platform, but is
    basically a list of commands.  Chapter four deals with access control,
    to do with physical presence requirements, ownership, and
    authorization.  Platform identification and endorsement is covered in
    chapter five.  Chapter six discusses integrity recording, reporting,
    and secure boot.  Protected storage of keys is in chapter seven,
    migration and maintenance methods in chapter eight, and other assorted
    functions in chapter nine.
    
    Part three reviews trusted platforms in practice and operation. 
    Chapter ten describes the setup of a new trusted platform, chapter
    eleven deals with what would elsewhere be known as trust
    relationships, and challenging a trusted platform--authentication of a
    server--is in chapter twelve.
    
    Part four presents the benefits of trusted platforms, first to
    organizations and corporations, in chapter thirteen, and then to
    individuals and users, in chapter fourteen.
    
    This book is not clear, either about what TCPA (Trusted Computing
    Platform Alliance) technology is, nor how it can effectively be used. 
    Although the authors occasionally admit that there may be problems
    with the system, there seems to be a kind of background arrogance in
    operation, that assumes everyone will have to use this technology, so
    they might was well learn the commands.
    
    copyright Robert M. Slade, 2002   BKTRCMPL.RVW   20020916
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    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.45
    ************************
    



    This archive was generated by hypermail 2b30 : Wed Jan 01 2003 - 23:46:27 PST