[risks] Risks Digest 22.13

From: RISKS List Owner (riskoat_private)
Date: Thu Jun 27 2002 - 09:11:07 PDT

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

    RISKS-LIST: Risks-Forum Digest  Thursday 27 June 2002  Volume 22 : Issue 13
    
       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.13.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Secret American spy photos broadcast unencrypted over satellite TV 
      (Duncan Campbell via Tim Finin via Dave Farber)
    Software problem kills soldiers in training incident (Steve Bellovin)
    Safety and human factors in ATC (via Hayley Davison and Nancy Leveson)
    Car repair shops often can't crack diagnostic code (Monty Solomon)
    Qui audit ipsos auditors? (Rob Slade)
    Tools gauging blood pressure raise questions (Monty Solomon)
    Microsoft's secret plan to secure the PC (Monty Solomon)
    Risks to your privacy from using MSN Messenger 4.6? (Michael Weiner)
    Microsoft sent Nimda worm to developers (Mike Hogsett)
    Microsoft's Allchin: API disclosure may endanger U.S. (Brien Webb)
    Identity theft site (Conrad Heiney)
    Randomly generated 4-letter words in sendmail queue-ids (Earle Ake)
    New virus can infect picture files (NewsScan)
    Norwegian history database password lost and retrieved (Lillie Coney)
    Calculators vs. handheld computers (NewsScan)
    England halts distribution of bad money (Monty Solomon)
    E-mail address parsing (William Colburn)
    Risks subscription problem (Ethan Benatan)
    Re: NERC + token ring (T Panton)
    Re: US Navy suffers domain hijacking (Jay R. Ashworth)
    Re: Please ignore the anti-shoplifting device! (Scott Peterson)
    REVIEW: "Developing Trust", Matt Curtin (Rob Slade)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Thu, 13 Jun 2002 22:39:31 +0900
    From: Dave Farber <daveat_private>
    Subject: Secret American spy photos broadcast unencrypted over satellite TV
    
      [from Tim Finin, Prof Computer Science & Electrical Eng, Director Inst. for
      Global Electronic Commerce, U Maryland Baltimore County, 1000 Hilltop,
      Baltimore MD 21250  fininat_private 410-455-3522 http://umbc.edu/~finin/
        Dave's IP archives at:
          http://www.interesting-people.org/archives/interesting-people/]
    
    Now showing on satellite TV: secret American spy photos;
      Security lapse allows viewers to see sensitive operations
    Duncan Campbell, Thursday June 13, 2002, *The Guardian*
    
    European satellite TV viewers can watch live broadcasts of peacekeeping and
    anti-terrorist operations being conducted by US spyplanes over the Balkans.
    Normally secret video links from the American spies-in-the-sky have a
    serious security problem - a problem that makes it easier for terrorists to
    tune in to live video of US intelligence activity than to get Disney
    cartoons or new-release movies.  For more than six months live pictures from
    manned spy aircraft and drones have been broadcast through a satellite over
    Brazil.  The satellite, Telstar 11, is a commercial TV relay. The US
    spyplane broadcasts are not encrypted, meaning that anyone in the region
    with a normal satellite TV receiver can watch surveillance operations as
    they happen.  The satellite feeds have also been connected to the Internet,
    potentially allowing the missions to be watched from around the globe.
      http://www.guardian.co.uk/international/story/0,3604,736462,00.html
    
    ------------------------------
    
    Date: Thu, 13 Jun 2002 09:38:10 -0400
    From: Steve Bellovin <smbat_private>
    Subject: Software problem kills soldiers in training incident
    
    According to a U.S. Army report, a software problem contributed to the
    deaths of two soldiers in a training accident at Fort Drum.  They were
    firing artillery shells, and were relying on the output of the Advanced
    Field Artillery Tactical Data System.  But if you forget to enter the
    target's altitude, the system assumes a default of 0.  (A Web site I found
    indicates that (part of) Ft. Drum is at 679 feet above sea level.)  The
    report goes on to warn that soldiers should not depend exclusively on this
    one system, and should use other computers or manual calculations.
    
    Other factors in the incident include the state of training of some of 
    the personnel doing the firing.  [Source: AP]
    
    Steve Bellovin, http://www.research.att.com/~smb (me)
    http://www.wilyhacker.com ("Firewalls" book)
    
    ------------------------------
    
    Date: Fri, 14 Jun 2002 11:03:25 -0400
    From: Peter Neumann <neumannat_private>
    Subject: Safety and human factors in ATC (via Hayley Davison and Nancy Leveson)
    
    Air control safety complaints soar
    By Paul Marston Transport Correspondent
    *Daily Telegraph* (Britain), 14 Jun 2002 [PGN-ed]
    
    The number of formal complaints of over-work from air-traffic controllers
    has more than doubled since the Swanwick national control centre opened in
    January 2002.  National Air Traffic Services (NATS) said staff had filed 30
    "overload" reports in the last five months, compared with 12 during the same
    period in 2001.  [Computer-related problems related to Swanwick and UK ATC
    are noted in RISKS-22.02,03,09,12.]  Planning staff at Swanwick have also
    complained about the legibility of some flight levels and airport codes on
    their terminal displays.
    
    ------------------------------
    
    Date: Tue, 25 Jun 2002 01:32:16 -0400
    From: Monty Solomon <montyat_private>
    Subject: Car repair shops often can't crack diagnostic code
    
    At least a couple of times a week, mechanic Ernie Pride tells customers at
    his independent repair shop he can't fix their cars because he doesn't know
    what's wrong with them. Go to the dealer, he advises.  He has the experience
    and knowledge to service vehicles but lacks the closely guarded information
    needed to diagnose problems with today's high-tech cars.  Automakers refuse
    to make much of it available to independent shops that compete with
    higher-priced dealerships. The practice is raising hackles in Congress and a
    vigorous defense by the industry.  ...  [AP, June 24, 2002]
      http://www.cnn.com/2002/TECH/ptech/06/24/diagnosing.cars.ap/
    
    ------------------------------
    
    Date: Wed, 19 Jun 2002 14:25:37 -0800
    From: Rob Slade <rsladeat_private>
    Subject: Qui audit ipsos auditors?
    
    The Enron/Anderson debacle is fading as news, but it has some reverberations
    for those of us in the info tech fields.
    
    Anderson is not alone in engaging in questionable audit practices.  Others
    of the "Big 5" are under scrutiny, in at least two cases involving,
    ironically, high tech companies.  For the past decade or more, there have
    been pressures to reduce regulatory oversight, and we are now seeing the
    results.
    
    So, what is the relation to IT?  Well, these are the same firms who hold the
    major contracts for auditing information security and assurance.
    
    (In relation to the subject line: yes, "ISACA," I know.)
    
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    Date: Fri, 21 Jun 2002 23:00:04 -0400
    From: Monty Solomon <montyat_private>
    Subject: Tools gauging blood pressure raise questions
    
    Gina Kolata, *The New York Times*, 16 Jun 2002
    
    Across the nation, hospitals and doctors' offices are returning blood 
    pressure cuffs to their manufacturers to comply with a federal 
    environmental initiative to cut down on the use of mercury, a toxic 
    metal that can pollute the air and water when disposed of improperly.
    But leading medical experts, joined by the American Heart Association 
    and the National Heart, Lung and Blood Institute, say the mercury 
    gauges are being replaced by newer devices that may be unreliable, 
    and they warn that inaccuracies may be leading to false diagnoses and 
    inappropriate treatments.  [...]
      http://www.nytimes.com/2002/06/16/health/16BLOO.html
    
    ------------------------------
    
    Date: Tue, 25 Jun 2002 01:40:54 -0400
    From: Monty Solomon <montyat_private>
    Subject: Microsoft's secret plan to secure the PC
    
    You've heard of Trustworthy Computing, and the massive corporate remodeling
    going on at Microsoft where every developer, product manager, and executive
    assistant has been asked to rethink everything they do in the context of
    security. Well, that's just the tip of the iceberg.  Secretly, the company
    has been working on a plan to rearchitect the PC from the ground up, to
    address the security, privacy, and intellectual property theft issues that
    dog the industry today. Inexplicably, the company pulled an Apple and chose
    to detail its plans solely to Newsweek, so we only have that one report to
    work from. But if Newsweek's take on the plan is correct, and consumers and
    businesses buy into the new devices that would result, the PC landscape will
    soon change forever.  [...]
      http://www.ntsecurity.net/Articles/Print.cfm?ArticleID=25681
    
    ------------------------------
    
    Date: Tue, 18 Jun 2002 17:44:11 +0200
    From: "Michael Weiner" <michael_weinerat_private>
    Subject: Risks to your privacy from using MSN Messenger 4.6?
    
    Since I installed MS Messenger 4.6 (4.6.0082) on my machine, my firewall is
    going wild: In addition to numerous Microsoft sites, Messenger is contacting
    the following sites each time I log in: expedia.com, xp.mcafee.com,
    carpoint.msn.com and port-64-1956779-zzt0prespect.devices.datareturn.net. No
    way to know what information MS Messenger is transmitting to these sites, I
    did not find any meaningful information on it on the Microsoft website...
    
    ------------------------------
    
    Date: Fri, 14 Jun 2002 17:26:34 -0700
    From: Mike Hogsett <hogsettat_private>
    Subject: Microsoft sent Nimda worm to developers 
    
    Microsoft accidentally sent the virulent Nimda worm to South Korean
    developers when it distributed Korean-language versions of Visual Studio
    .Net that carried the virus, the company acknowledged Friday.
    
    http://news.com.com/2100-1001-935994.html
    
    ------------------------------
    
    Date: Fri, 14 Jun 2002 12:09:43 -0700
    From: Active Quality Software <activequalityswat_private>
    Subject: Microsoft's Allchin: API disclosure may endanger U.S.
    
    >From a 2002/05/13 article by Caron Carlson in eweek.com:
    
    http://www.eweek.com/article/0,3658,s%253D701%2526a%253D26875,00.asp
    
      "A senior Microsoft Corp. executive [Jim Allchin] told a federal court
      last week that sharing information with competitors could damage national
      security and even threaten the U.S. war effort in Afghanistan. He later
      acknowledged that some Microsoft code was so flawed it could not be safely
      disclosed."
    
    and later, directly quoting Allchin...
    
      "Computers, including many running Windows operating systems, are used
      throughout the United States Department of Defense and by the armed forces
      of the United States in Afghanistan and elsewhere."
    
    Microsoft proposes to withhold details of the MSMQ protocol (TCP port 1801
    and UDP port 3527), the Windows File Protection API, as well as APIs for
    anti-piracy protection and digital rights management under the security
    carve-out.
    
    I recall that the Windows NT family of operating systems was designed to
    meet DOD's C2 security criteria, including the Orange Book (standalone,
    which they passed), as well as Red Book (networking) and Blue Book
    (subsystems) criteria which they started working on at least 4 years ago; I
    don't know if they've yet passed, but I suspect not if it's so flawed that
    they don't want to disclose the protocol or API!  See
    http://msdn.microsoft.com/library/default.asp?  url=/library/en-
    us/dnproasp2/html/windowsntsecuritysystems.asp
    
    So, one risk of flawed software might be that you have to publicly invoke
    national security (read patriotism) as a last refuge from legal process.
    
    --Brien Webb http://www.LA.com/
    
    --------------------------------
    
    Date: Wed, 26 Jun 2002 15:32:48 -0700
    From: "Conrad Heiney" <conradat_private>
    Subject: Identity theft site
    
    According to CNN's website today
      http://www.cnn.com/2002/TECH/internet/06/26/identity.theft.ap/index.html
    a nongovernmental organization called CardCops is providing a service in
    which consumers can check to see if their credit cards have been abused in
    some way.
    
    The check is done by visiting the website and entering your credit card
    number.
    
    The RISKS here are bad enough to be humorous. Although CardCops themselves
    appear to be a legitimate organization (at least at time of press) , and do
    not themselves ask for the expiration date required to complete a
    transaction, there's no protection against copycat websites whose intent is
    entirely evil, or telephone scams based on the CardCops publicity.  The
    quality of the data is another obvious minefield.
    
      [And as of today, their site is also down due to high volume.]
    
    Conrad Heiney  conradat_private  http://fringehead.org
    
    ------------------------------
    
    Date: Mon, 17 Jun 2002 16:59:38 -0400 (EDT)
    From: Earle Ake <earle.akeat_private>
    Subject: Randomly generated 4-letter words in sendmail queue-ids
    
    I was checking the sendmail queue today when I noticed a message with a
    certain 4-letter word as part of the queue id that ends in "uck".  I checked
    the sendmail logs further and there was another 4 letter word as part of
    another queue id that also ends in "uck" and another that ends in "ock" with
    a certain letter before it.  I wonder how many people pay attention to queue
    IDs and would raise an eyebrow on those.  I also wonder if any of the
    filtering software out there might filter out legit mail messages just
    because certain random 4 letter words were contained in the queue-id that
    are inserted into the mail headers as they pass through each system.
    
    ------------------------------
    
    Date: Fri, 14 Jun 2002 08:32:37 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: New virus can infect picture files
    
    McAfee Security is reporting that a new virus called "Perrun" is the first
    ever to infect picture files, which, along with other data files, have long
    been considered safe from such threats. Researchers at McAfee received the
    virus from its creator and say it's what's called a proof-of-concept virus
    and does not cause any damage. Up until now, viruses infected and were
    spread through program files; data files might be deleted or damaged, but
    Perrun is the first to infect them by inserting portions of the virus code
    into the picture file. When a .JPG picture is viewed, the virus installs a
    file on the victim's hard drive that can infect other pictures. Because the
    original picture looks fine, the victim won't know that anything's amiss.
    [AP, 13 Jun 2002; NewsScan Daily, 14 June 2002]
      http://apnews.excite.com/article/20020613/D7K4F4EG1.html
    
    ------------------------------
    
    Date: Tue, 11 Jun 2002 11:37:02 -0400
    From: Lillie Coney <lillie.coneyat_private>
    Subject: Norwegian history database password lost and retrieved
    
    After the password for accessing a Norwegian history museum's database
    catalog for 11,000 books and manuscripts had been lost when the database's
    steward died, the museum established a competition to recover it.  Joachim
    Eriksson, a Swedish game company programmer, won the race to discover the
    password (ladepujd, the reverse of the name of the researcher who had
    created the database).  How he arrived at it was not disclosed.  [Source:
    Long-lost password discovered: Norwegian history database cracked with help
    from the Web, By Robert Lemos, MSNBC, 11 Jun 2002; PGN-ed]
    
    Lillie Coney, Public Policy Coordinator, U.S. Association for Computing
    Machinery Suite 510 2120 L Street, NW Washington, D.C. 20037 1-202-478-6124
    
    ------------------------------
    
    Date: Wed, 12 Jun 2002 08:01:42 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Calculators vs. handheld computers
    
    As handheld computers become increasingly competitive with Texas Instrument
    (TI) calculators for mathematical graphing, TI has been busy adding features
    such as address books, organizers, and a large variety of spreadsheet
    programs. The main advantage of handhelds, of course, is that they are
    general-purpose devices.  Nelson Heller, who publishes the Heller Report
    newsletter on education technology, says that both calculators and handheld
    computers are getting better but adds: "The question I see is whether a
    specialized appliance like the graphing calculator will in the long run lose
    out to a more generalized appliance like a PDA."  Calculators, however, still
    have two advantages: lower cost (about half of a PDA's cost) and
    acceptability in testing situations, in that students are permitted to use
    calculators but not handheld computers when taking the Scholastic Aptitude
    Test.  The reason? Fear that some students might use the infrared messaging
    capability of handhelds to cheat on the test. (AP/*San Jose Mercury-News*,
    12 Jun 2002; NewsScan Daily, 12 June 2002)
      http://www.siliconvalley.com/mld/siliconvalley/3453135.htm
    
      [And exam proctors will be able to determine that the so-called
      "calculator" is not surreptitiously a general-purpose device?  PGN]
    
    ------------------------------
    
    Date: Tue, 28 May 2002 13:01:11 -0400
    From: "monty solomon" <montyat_private>
    Subject: England halts distribution of bad money 
    
    The Bank of England asked banks Monday to stop issuing its new
    anti-counterfeit 5-pound notes after discovering that serial numbers on the
    currency could be rubbed off.  [AP, 27 May 2002]
      http://news.lycos.com/news/story.asp?section=World&storyId=423067
    
    ------------------------------
    
    Date: Fri, 21 Jun 2002 14:23:45 -0600
    From: "Schlake (William Colburn)" <"@ @"@nmt.edu>
    Subject: E-mail address parsing
    
    About the same time PGN posted to the list about RISKS SPAM, I got a call
    from someone who was going through corporate-education on e-mail addresses.
    She had been given a test, and she had to identify which e-mail addresses
    were valid.  She was told that half of them were invalid.  The purpose of
    the test was to train employees to be able to properly harvest the e-mail
    addresses of their elderly customers.  As far as I can tell, all of them
    were valid.
    
    The very next day, I made myself a new e-mail address, "@ @"@nmt.edu.  I
    like this address, it has been a lot of fun so far.  No
    customer-relations software seems able to accept that this is a valid
    e-mail address.  People seem pretty trusting, and are willing to try and
    (and are surprised when it works).
    
    The risk is that the customer-relations programmers are living in a
    world of [a-z0-9_] for mailbox names, while the standard has long
    allowed for virtually any character (including NULL).  More and more
    services are unavailable if you "don't have an e-mail address", and
    usually even the web form to submit a bug won't process because it wants
    your e-mail address, so they never even know.  Even if I wasn't taunting
    them with "@ @", I'd be giving out my address with a "+" and then the
    name of their company to help me sort out where my SPAM is really coming
    from. Few pieces of software will allow even the harmless  little "+"
    character in an address.
    
    ------------------------------
    
    Date: Thu, 13 Jun 2002 16:32:40 -0700
    From: Ethan Benatan <ethan.benatanat_private>
    Subject: Risks subscription
    
      [In attempting to confirm a subscription request, Ethan's mail system
      responded to RISKS and not to majordomo.  This seems to happen from other
      e-mail systems as well.  PGN]
    
    Eudora's recent MacOS X version is broken and ignores reply-to headers;
    older versions didn't used to do that.
    
    ------------------------------
    
    Date: Tue, 11 Jun 2002 17:06:14 +0000 (GMT)
    From: tpantonat_private
    Subject: Re: NERC + token ring (Ladkin, RISKS-22.12)
    
    In RISKS-22.12, Peter Ladkin mentions NERC's use of a token ring as if this
    were obviously a bad thing.  If I remember correctly, a token ring has
    better behaviour at high load (as compared to ethernet), because it
    implements a round-robin allocation and thus does not waste capacity in
    collisions.
    
    Indeed a precursor (the Cambridge ring) had the endearing characteristic
    that high loads made the PLL clock drift fast, upping the capacity by a few
    percent.  The risk is in assuming the dominant technology is best for all
    situations.  URL: http://www.westpoint.ltd.uk/ - Internet recon.
    
    ------------------------------
    
    Date: Tue, 11 Jun 2002 12:46:25 -0400
    From: "Jay R. Ashworth" <jraat_private>
    Subject: Re: US Navy suffers domain hijacking (Brent, RISKS-22.10)
    
    Thank you, Geoffrey, for you've given me a hook on which to hang one of my
    *favorite* rants.  
    
    "navydallas.com" (the proper spelling, for the DNS is case-insensitive by
    design) is *not* a "trusted domain", in any remote sense of the word.  Nor
    is "myflorida.com" (an alias for www.state.fl.us, which apparently is too
    complicated for people) or "largo.com".
    
    I have a *real* dislike for municipal and government web teams who have *so*
    little faith in their audience's mentalities that they feel they have to
    spurn the TLDs in which they *would* be protected -- and could be trusted
    (the ".gov" and ".us" domains which have -- or perhaps in the latter case
    "had" -- restrictions on registration) -- for ".com", just because "that's
    the only thing people understand".  <sigh>
    
    At least it turned around and bit Largo Florida in the ass about a year ago
    when their mail server melted down under the load of 60K+ *bounce* and
    complaint messages when someone used "largo.com" as a forged return address
    on some spam.
    
    I've seriously thought about registering "yourflorida.com" and putting up a
    website that looks very much like myflorida.com, but is parody (when you
    look closely enough), and which explains exactly why I think they are doing
    wrong... but while that wouldn't even *be* civil disobedience, much less
    copyright infringement (based on the Skyywalker Music case), the fact that no
    less a legal luminary than Lawrence Lessig thinks that civil disobedience is
    no longer a useful approach
      http://www.reason.com/0206/fe.jw.cyberspaces.shtml
    scares me to death.
    
    Jay R. Ashworth, Baylink, Member of the Technical Staff, The Suncoast Freenet
    Tampa Bay, Florida  +1 727 647 1274  http://baylink.pitas.com  jraat_private
    
    ------------------------------
    
    Date: Thu, 06 Jun 2002 19:21:10 -0700
    From: Scott Peterson <scottp4at_private>
    Subject: Re: Please ignore the anti-shoplifting device! (Hendricks, R-22.12)
    
    > I also realized that the alarm would likely sound as I exited at the other
    > end of the store.
    
    Which also points out a whole series of other problems.  I worked with 
    corporate security for a large supermarket chain in So. Calif. several 
    years ago.
    
    I don't think the law has significantly changed, but at the time, you, as 
    an individual, could not stop someone for a misdemeanor (like shoplifting) 
    unless you saw them take the item and followed them until they exited.  If 
    you did, it was quite possible for you to be charged with unlawful 
    detention getting both yourself and the company in big trouble. Having an 
    alarm go off as you walk through it was not a good enough reason to stop 
    someone.  Only a sworn peace officer could stop someone in those 
    circumstances.
    
    For this reason and the safety of the employees, they were required to know
    the store policy and follow it.  If they suspected someone of shoplifting
    they were to call someone in management and let them deal with it. Under no
    circumstances were they to take any action on their own.
    
    Bottom line: Those alarm units are often more a psychological barrier than a
    legal one.
    
    ------------------------------
    
    Date: Mon, 17 Jun 2002 08:00:56 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Developing Trust", Matt Curtin>
    
    BKDEVTRS.RVW   20020514
    
    "Developing Trust", Matt Curtin, 2002, 1-893115-72-0, U$39.95
    %A   Matt Curtin cmcurtinat_private
    %C   175 Fifth Ave., New York, NY   10010
    %D   2002
    %G   1-893115-72-0
    %I   Springer-Verlag/Apress
    %O   U$39.95 212-460-1500 800-777-4643 orders@springer-ny.com
    %P   282 p.
    %T   "Developing Trust: Online Privacy and Security"
    
    The title, foreword, preface, and introduction aren't terribly clear
    about the purpose of the book.  Ultimately, the key word seems to be
    not trust, but privacy: the work appears to be directed at providing
    tips for developers, of all stripes, to help maintain the
    confidentiality of information.
    
    Part one is a generic introduction to security and privacy.  Chapter
    one, entitled "Why Privacy," seems, ironically, to move us even
    further away from the topic of privacy.  The emphasis of the chapter
    is on intrusions, although the reconnaissance phase does get the most
    space.  (The subtitle, "Why This Book," does not appear to be
    addressed.)  The discussion of privacy theory, in chapter two, flips
    back and forth between the technical issues of identity authentication
    and access control, and the social concepts of privacy, failing to
    make hard relations between the two ideas.  A partial list of basic
    conceptual security terms are reasonably well defined in chapter
    three.  Chapter four does start to get into privacy issues, specifying
    a number of notions important to protecting confidentiality in an
    online (generally Web based) environment.  A number (but not an
    exhaustive list) of threats to privacy are discussed in chapter five.
    
    Part two looks at the problem.  Chapter six provides a concise list of
    the basic principles of development of secure applications. 
    (Interestingly, Curtin uses the principle of least common mechanism as
    an argument for the adoption of modular code, where others might say
    that it was a reason to avoid modularity.)  Background concepts for
    the Internet and Web, the basic development environment assumed for
    the book, are given in chapter seven.  Some specific examples of
    privacy problems on the Web are presented in chapter eight.
    
    Part three outlines the cure.  Chapter nine reviews some basic
    security protections, such as firewalls and constrained systems.  Opt
    out systems are criticized in chapter ten.  "Earning Trust," in
    chapter eleven, points out that providing privacy for customers is not
    just a cost and a nuisance, but good business.  A structure for
    analyzing and designing secure Web systems is proposed in chapter
    twelve.
    
    Strangely, while the book is disjointed and difficult to pin down as
    to the central theme, ultimately it could be quite valuable.  In the
    end, the title is appropriate, albeit in a punning fashion: the
    content is directed at developing trustworthy applications.  The
    literature in the field of developing secure applications is not
    extensive, and much of it is either ethereally academic or completely
    language specific.  This book attempts to be practical, and, while
    hardly ever touching on implementation, the precepts suggested are a
    sound foundation.  Security professionals would find the general
    background limited, but developers will neither be snowed under by
    esoteric discussions nor left with too many vulnerabilities uncovered. 
    The specifics in the book deal with the Web, but the tenets of secure
    design are applicable to all systems.
    
    copyright Robert M. Slade, 2002   BKDEVTRS.RVW   20020514
    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.13
    ************************
    



    This archive was generated by hypermail 2b30 : Thu Jun 27 2002 - 09:52:19 PDT