[http-state] Privacy considerations

Adam Barth <ietf@adambarth.com> Wed, 07 April 2010 21:34 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 03DC33A69B5 for <http-state@core3.amsl.com>; Wed, 7 Apr 2010 14:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.623
X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id yS5vAMHqvh9U for <http-state@core3.amsl.com>; Wed, 7 Apr 2010 14:34:43 -0700 (PDT)
Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com []) by core3.amsl.com (Postfix) with ESMTP id 3E7F63A6956 for <http-state@ietf.org>; Wed, 7 Apr 2010 14:34:43 -0700 (PDT)
Received: by pzk29 with SMTP id 29so1431296pzk.29 for <http-state@ietf.org>; Wed, 07 Apr 2010 14:34:37 -0700 (PDT)
Received: by with SMTP id p6mr5621808rvi.195.1270676077549; Wed, 07 Apr 2010 14:34:37 -0700 (PDT)
Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com []) by mx.google.com with ESMTPS id k17sm4483385rvh.7.2010. (version=SSLv3 cipher=RC4-MD5); Wed, 07 Apr 2010 14:34:36 -0700 (PDT)
Received: by qyk11 with SMTP id 11so840036qyk.13 for <http-state@ietf.org>; Wed, 07 Apr 2010 14:34:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 7 Apr 2010 14:34:14 -0700 (PDT)
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 7 Apr 2010 14:34:14 -0700
Received: by with SMTP id d19mr307428qac.321.1270676074418; Wed, 07 Apr 2010 14:34:34 -0700 (PDT)
Message-ID: <z2m5c4444771004071434x2649253rf93397a03281b669@mail.gmail.com>
To: http-state <http-state@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [http-state] Privacy considerations
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2010 21:34:44 -0000

At IETF77, some folks expressed interset in adding a Privacy
Considerations section along side the Security Considerations section.
 I've added a first draft of this section to the working copy of the
draft.  As always, comments welcome:

    <section anchor="privacy-considerations"
             title="Privacy Considerations">
        <t>The cookie protocol is often criticized for letting servers track
        users. For example, a number of "web analytics" companies use cookies
        to recognize when a user returns to a web site or visits another web
        site. Although cookies are not the only mechanism servers can use to
        track users across HTTP requests, cookies facilitate tracking because
        they are persistent across user agent sessions and can be shared
        between host names.</t>

        <section anchor="third-party-cookies" title="Third-Party Cookies">
          <t>Particularly worrisome are so-called "third-party" cookies. In
          rendering an HTML document, a user agent often requests resources
          from other servers (such as advertising networks). These third-party
          servers can use the cookie protocol to track the user even if the
          user never visits the server directly.</t>

          <t>Some user agents restrict how third-party cookies behave. For
          example, some user agents refuse to send the Cookie header in
          third-party requests. Other user agents refuse to process the
          Set-Cookie header in responses to third-party requests. Among user
          agents, there is a wide variety of third-party cookie policies. This
          document grants user agents wide latitude to experiment with
          third-party cookie policies that balance the privacy and
          compatibility needs of their users. However, this document does not
          endorse any particular third-party cookie policy.</t>

          <t>Third-party cookie blocking policies are often ineffective at
          achieving their privacy goals if servers attempt to work around
          their restrictions to track users. In particular, two collaborating
          servers can often track users without using cookies at all.</t>
        <section anchor="user-controls" title="User Controls">
          <t>User agents SHOULD provide users with a mechanism for managing
          the cookies stored in the cookie store. For example, a user agent
          might let users delete all cookies received during a specified time
          period or all the cookies related to a particular domain. In
          addition, many user agent include a user interface element that lets
          users examine the cookies stored in the cookie store.</t>

          <t>User agents SHOULD provide users with a mechanism for disabling
          cookies. When cookies are disabled, the user agent MUST NOT include
          a Cookie header in outbound HTTP requests and the user agent MUST
          NOT process Set-Cookie headers in inbound HTTP responses.</t>

          <t>Some user agents provide users the option of preventing
          persistent storage of cookies across sessions. When configured
          thusly, user agents MUST treat all received cookies as if the
          persistent-flag were set to false.</t>

          <t>Some user agents provide users with the ability to approve
          individual writes to the cookie store. In many common usage
          scenarios, these controls generate a large number of prompts.
          However, some privacy-conscious users find these controls useful