view release on metacpan or  search on metacpan

rfc/rfc2964.txt  view on Meta::CPAN

   browsing habits can be tracked.  Indeed, it is difficult to imagine
   how the HTTP protocol or an HTTP client could actually prevent a
   service from disclosing a user's "click trail" to other parties if
   the service chose to do so.  Protection of such information from
   inappropriate exposure must therefore be the responsibility of the
   service.  HTTP client implementations inherently cannot provide such
   protection, though they can implement countermeasures which make it
   more difficult for HTTP State Management to be used as the mechanism
   by which such information is exposed.



Moore & Freed            Best Current Practice                  [Page 5]

RFC 2964              Use of HTTP State Management          October 2000


   It is arguable that HTTP clients should provide more protection in
   general against inappropriate exposure of tracking information,
   regardless of whether the exposure were facilitated by use of HTTP
   State Management or by some other means.  However, issues related to
   other mechanisms are beyond the scope of this memo.

3.1.  Capabilities Required of an HTTP Client

   A user's willingness to consent to use of HTTP State Management is
   likely to vary from one service to another, according to whether the
   user trusts the service to use the information appropriately and to
   limit its exposure to other parties.  The user therefore SHOULD be
   able to control whether his client supports a service's request to
   use HTTP State Management, on a per-service basis.  In particular:

   (1)   Clients MUST NOT respond to HTTP State Management requests
         unless explicitly enabled by the user.

   (2)   Clients SHOULD provide an effective interface which allows
         users to review, and approve or refuse, any particular requests
         from a server to maintain state information, before the client
         provides any state information to the server.

   (3)   Clients SHOULD provide an effective interface which allows
         users to instruct their clients to ignore all requests from a
         particular service to maintain state information, on a per-
         service basis, immediately in response to any particular
         request from a server, before the client provides any state
         information to the server.

   (4)   Clients SHOULD provide an effective interface which allows a
         user to disable future transmission of any state information to
         a service, and/or discard any saved state information for that
         service, even though the user has previously approved a
         service's request to maintain state information.

   (5)   Clients SHOULD provide an effective interface which allows a
         user to terminate a previous request not to retain state
         management information for a given service.

3.2.  Limitations of the domain-match algorithm

   The domain-match algorithm in RFC-2965 section 2 is intended as a
   heuristic to allow a client to "guess" whether or not two domains are
   part of the same service.  There are few rules about how domain names
   can be used, and the structure of domain names and how they are
   delegated varies from one top-level domain to another (i.e. the
   client cannot tell which part of the domain was assigned to the



Moore & Freed            Best Current Practice                  [Page 6]

RFC 2964              Use of HTTP State Management          October 2000


   service).  Therefore NO string comparison algorithm (including the
   domain-match algorithm) can be relied on to distinguish a domain that
   belongs to a particular service, from a domain that belongs to
   another party.

   As stated above, each service is ultimately responsible for ensuring
   that user information is not inappropriately leaked to third parties.
   Leaking information to third parties via State Management by careful
   selection of domain names, or by assigning domain names to hosts
   maintained by third parties, is at least as inappropriate as leaking
   the same information by other means.

4.  Security Considerations

   This entire memo is about security considerations.

5.  Authors' Addresses

   Keith Moore
   University of Tennessee Computer Science Department
   1122 Volunteer Blvd, Suite 203
   Knoxville TN, 37996-3450

   EMail: moore@cs.utk.edu


   Ned Freed
   Innosoft International, Inc.
   1050 Lakes Drive
   West Covina, CA 81790

   EMail: ned.freed@innosoft.com

6.  References

   [RFC 1123] Braden, R., "Requirements for Internet Hosts --
              Application and Support", STD 3, RFC 1123, October 1989.

   [RFC 2965] Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2965, October 2000.

   [RFC 2109] Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2109, February 1997.