view release on metacpan or  search on metacpan

rfc/rfc2964.txt  view on Meta::CPAN

         otherwise available to an eavesdropper.

   This last point is important because cookies are usually sent in the
   clear and hence are readily available to eavesdroppers.

   An example of such a recommended use would be a "shopping cart",
   where the existence of the shopping cart is explicitly made known to
   the user, the user can explicitly "empty" his or her shopping cart
   (either by requesting that it be emptied or by purchasing those





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


   items) and thus cause the shared state to be discarded, and the
   service asserts that it will not disclose the user's shopping or
   browsing habits to third parties without the user's consent.

   Note that the HTTP State Management protocol effectively allows a
   service provider to refuse to provide a service, or provide a reduced
   level of service, if the user or a user's client fails to honor a
   request to maintain session state.  Absent legal prohibition to the
   contrary, the server MAY refuse to provide the service, or provide a
   reduced level of service, under these conditions.  As a purely
   practical consideration, services designed to utilize HTTP State
   Management may be unable to function properly if the client does not
   provide it.  Such servers SHOULD gracefully handle such conditions
   and explain to the user why the full level of service is not
   available.

2.2.  Problematic Uses

   The following uses of HTTP State Management are deemed inappropriate
   and contrary to this specification:

2.2.1.  Leakage of Information to Third Parties

   HTTP State Management MUST NOT be used to leak information about the
   user or the user's browsing habits to other parties besides the user
   or service, without the user's explicit consent.  Such usage is
   prohibited even if the user's name or other externally-assigned
   identifier are not exposed to other parties, because the state
   management mechanism itself provides an identifier which can be used
   to compile information about the user.

   Because such practices encourage users to defeat HTTP State
   Management mechanisms, they tend to reduce the effectiveness of HTTP
   State Management, and are therefore considered detrimental to the
   operation of the web.

2.2.2.  Use as an Authentication Mechanism

   It is generally inappropriate to use the HTTP State Management
   protocol as an authentication mechanism.  HTTP State Management is
   not designed with such use in mind, and safeguards for protection of
   authentication credentials are lacking in both the protocol
   specification and in widely deployed HTTP clients and servers.  Most
   HTTP sessions are not encrypted and "cookies" may therefore be
   exposed to passive eavesdroppers.  Furthermore, HTTP clients and
   servers typically store "cookies" in cleartext with little or no
   protection against exposure.  HTTP State Management therefore SHOULD




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


   NOT be used as an authentication mechanism to protect information
   from being exposed to unauthorized parties, even if the HTTP sessions
   are encrypted.

   The prohibition against using HTTP State Management for
   authentication includes both its use to protect information which is
   provided by the service, and its use to protect potentially sensitive
   information about the user which is entrusted to the service's care.
   For example, it would be inappropriate to expose a user's name,
   address, telephone number, or billing information to a client that
   merely presented a cookie which had been previously associated with
   the user.

   Similarly, HTTP State Management SHOULD NOT be used to authenticate
   user requests if unauthorized requests might have undesirable side-
   effects for the user, unless the user is aware of the potential for
   such side-effects and explicitly consents to such use.  For example,
   a service which allowed a user to order merchandise with a single
   "click", based entirely on the user's stored "cookies", could
   inconvenience the user by requiring her to dispute charges to her
   credit card, and/or return the unwanted merchandise, in the event
   that the cookies were exposed to third parties.

   Some uses of HTTP State Management to identify users may be
   relatively harmless, for example, if the only information which can
   be thus exposed belongs to the service, and the service will suffer
   little harm from the exposure of such information.

3.  User Interface Considerations for HTTP State Management

   HTTP State Management has been very controversial because of its
   potential to expose information about a user's browsing habits to
   third parties, without the knowledge or consent of the user.  While
   such exposure is possible, this is less a flaw in the protocol itself
   than a failure of HTTP client implementations (and of some providers
   of HTTP-based services) to protect users' interests.

   As implied above, there are other ways to maintain session state than
   using HTTP State Management, and therefore other ways in which users'
   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