[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [209.85.222.191]) 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 10.141.12.6 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 [209.85.221.181]) by mx.google.com with ESMTPS id k17sm4483385rvh.7.2010.04.07.14.34.35 (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 10.231.177.225 with HTTP; Wed, 7 Apr 2010 14:34:14 -0700 (PDT)
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 07 Apr 2010 14:34:14 -0700
Received: by 10.224.26.83 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> <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 nonetheless.</t> </section> </section>
- [http-state] Privacy considerations Adam Barth