Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.tx

Lucy Lynch <> Tue, 08 March 2011 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB6853A68B3 for <>; Tue, 8 Mar 2011 06:59:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.141
X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uioVqLb15bAp for <>; Tue, 8 Mar 2011 06:59:33 -0800 (PST)
Received: from ( [IPv6:2001:418:1::80]) by (Postfix) with ESMTP id BA1063A689A for <>; Tue, 8 Mar 2011 06:59:32 -0800 (PST)
Received: from (localhost []) by (8.14.3/8.14.3) with ESMTP id p28F0kiS039154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Tue, 8 Mar 2011 07:00:46 -0800 (PST) (envelope-from
Received: from localhost (llynch@localhost) by (8.14.3/8.14.3/Submit) with ESMTP id p28F0khL039151 for <>; Tue, 8 Mar 2011 07:00:46 -0800 (PST) (envelope-from
Date: Tue, 8 Mar 2011 07:00:46 -0800 (PST)
From: Lucy Lynch <>
Message-ID: <>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.tx
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Mar 2011 14:59:34 -0000

On Tue, 8 Mar 2011, Stephen Farrell wrote:

> On 08/03/11 13:31, Chappelle, Kasey, VF-Group wrote:
>> Good question - perhaps someone with more technical expertise than I
>> have can help.
> That'd be good.
>> But there are lots of reasons why site owners would need
>> to track their own visitors. Just off the top of my head, where would we
>> put things like state management? Maintaining shopping carts from page
>> to page or on subsequent visits, for example, requires you to track a
>> visitor to your site across pages and sessions.
> Fair enough. However, I suspect that site owners, (like all of
> us really) perhaps didn't pay so much attention to privacy in the
> past, so it could well be that some of those 1st party tracking
> practices are also privacy-invasive and perhaps not as necessary
> as they're assumed to be.

One of the key arguments I've heard advanced re: first party
tracking of authenticated users has to do with fraud prevention.
At the recent RSA in San Francisco several panels dealt with user
profiling for security, see for example:

It isn't clear to me how much users know/understand about this kind of data 
collection and how they would feel about it if they did. It also isn't clear to 
me if these organizations are out-sourcing the analysis of customer data.

This is shaping up as one of the possible counter arguements to do-not-track.

- Lucy

> However, I don't know, so that's why I asked.
> S.
>> -----Original Message-----
>> From: Stephen Farrell []
>> Sent: 08 March 2011 13:20
>> To: Chappelle, Kasey, VF-Group
>> Cc: Ted Hardie; Sean Turner;
>> Subject: Re: [privacydir] Fwd: I-D
>> ACTION:draft-mayer-do-not-track-00.txt
>> On 08/03/11 13:14, Chappelle, Kasey, VF-Group wrote:
>>> Think of all the basic web functions you'd be breaking if first-party
>> tracking weren't allowed.
>> Just wondering. Do we have a good list of those somewhere?
>> S.
>>> Also consider the very different privacy implications between a party
>> you've actively engaged with knowing what you're doing while you
>> interact with them, vs. the third party you have no relationship with.
>> There's a very real privacy threat here we need to address, but lumping
>> all tracking together may not be the way to do it. Emerging regulatory
>> structures around this, even in the most restrictive regimes, have
>> acknowledged the difference.
>>> Also, anonymous data linked to an individual should and would still be
>> covered. But what about data collection that occurs without any unique
>> identifiers at all. The Narayanan papers talk about deanonymization of
>> individually identifiable data sets. Let's make sure we understand the
>> full privacy implications in either case before we jump to conclusions -
>> is frequency-capping actually a privacy-impacting process? I'd say no.
>>> One of the problems of data protection law is that it treats all data
>> collection similarly, without acknowledging degrees of harm. Let's not
>> fall into the same trap.
>>> -----Original Message-----
>>> From: []
>> On Behalf Of Ted Hardie
>>> Sent: 08 March 2011 04:15
>>> To: Sean Turner
>>> Cc:
>>> Subject: Re: [privacydir] Fwd: I-D
>> ACTION:draft-mayer-do-not-track-00.txt
>>> I've read this draft, and I think it warrants discussion.
>>> The most basic question for me is whether a single bit of information
>>> about user preferences is sufficient in this case.  Having additional
>>> bits which describe user preferences around tracking by first parties
>>> seems to me necessary.
>>> In particular, the document appears to assume that 1st party tracking
>>> and 3rd party tracking done on behalf of a 1st party (see Exception 2)
>>> are permitted even if DNT is set to "do not track".  That is, DNT is
>>> really "No third party tracking" and it expects that there is a simple
>>> mechanism by which third parties are distinguished from first parties.
>>>  I personally have my doubts.  If I get content used to construct a
>>> web page from source X and source Y are both X and Y first parties?
>>> The single-pixel image may look like an obvious 3rd party, but the
>>> protocol mechanics by which I distinguish that from and embedded RSS
>>> feed are not clearly described in the document.  I can infer that I
>>> use the public suffix list and the FQDN of either the link or the
>>> browser bar, but this really needs to be spelled out.
>>> The description of interaction with proxies needs to explain whether
>>> the header has any impact on whether the response should be cached
>>> and, if so, whether returns from the cache should be limited to
>>> requests with the same DNT state.
>>> I also find the exception for data which is "not linkable to a
>>> specific user or user agent" somewhat hard to work through.  As the
>>> two Narayanan papers cited show, anonymized data has been shown to
>>> allow later identification.  How can we be certain that advertising
>>> frequency capping or sequencing data has no similar issue without
>>> specifying their format? Even if this is not intended as a loophole,
>>> it seems likely to be exploited as one.
>>> I have the haunting feeling that starting from this position is
>>> inherently weak.  If we are truly interested in user control here, the
>>> opposite tack, a "Know This" header which explicitly states the
>>> information the user is willing to reveal seems to give far more real
>>> control.  This seems to ask the browser to  set a "Don't be evil" bit
>>> on its requests, but to leave the real control over what that means so
>>> underspecified that reasonable people could conclude wildly different
>>> things.
>>> regards,
>>> Ted Hardie
>>> On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner <> wrote:
>>>> FYI
>>>> -------- Original Message --------
>>>> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt
>>>> Date: Mon, 07 Mar 2011 17:45:01 -0800
>>>> From:
>>>> Reply-To:
>>>> To:
>>>> A new Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>    Title         : Do Not Track: A Universal Third-Party Web Tracking
>> Opt
>>>> Out
>>>>    Author(s)     : J. Mayer, et al
>>>>    Filename      : draft-mayer-do-not-track-00.txt
>>>>    Pages         : 6
>>>>    Date          : 2011-03-07
>>>> This document defines the syntax and semantics of Do Not Track, an
>>>>   HTTP header-based mechanism that enables users to express
>> preferences
>>>>   about third-party web tracking.  It also provides a standard for
>> how
>>>>   web services should comply with such user preferences.
>>>> A URL for this Internet-Draft is:
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> Below is the data which will enable a MIME compliant mail reader
>>>> implementation to automatically retrieve the ASCII version of the
>>>> Internet-Draft.
>>>> _______________________________________________
>>>> privacydir mailing list
>>> _______________________________________________
>>> privacydir mailing list
>>> _______________________________________________
>>> privacydir mailing list
> _______________________________________________
> privacydir mailing list