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

"Chappelle, Kasey, VF-Group" <> Tue, 08 March 2011 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 833F43A68CB for <>; Tue, 8 Mar 2011 07:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y9g3bALdHiM4 for <>; Tue, 8 Mar 2011 07:21:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3AC523A689A for <>; Tue, 8 Mar 2011 07:21:06 -0800 (PST)
Received: from mailint01 (localhost []) by mailout01 (Postfix) with ESMTP id D72814A3D for <>; Tue, 8 Mar 2011 16:22:19 +0100 (CET)
Received: from ( []) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint01 (Postfix) with ESMTPS id BB9FD49DA; Tue, 8 Mar 2011 16:22:19 +0100 (CET)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Mar 2011 16:22:19 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 8 Mar 2011 16:22:18 +0100
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.tx
Thread-Index: AcvdoaNE0X94E9YBTZ66sRAeMeBLkQAAnFFw
References: <>
From: "Chappelle, Kasey, VF-Group" <>
To: "Lucy Lynch" <>, <>
X-OriginalArrivalTime: 08 Mar 2011 15:22:19.0353 (UTC) FILETIME=[9D4B6490:01CBDDA4]
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 15:21:08 -0000

One of the things we've identified a few times in these workstreams as a
necessary step is reaching a conclusion about what is and should be
"business as usual" online and what has privacy implications. Fraud
prevention, content control obligations (like meeting child safety
requirements) state management and other basic functions should be
outside the scope, but where to draw the lines is key. 

Several organisations are doing research right now into consumer
attitudes, which should definitely drive decisions - what is perceived
by the general public as a privacy threat (which it may be important to
keep in mind we are not exactly representative of)?

-----Original Message-----
From: []
On Behalf Of Lucy Lynch
Sent: 08 March 2011 15:01
Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.tx

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
>> put things like state management? Maintaining shopping carts from
>> 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
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

This is shaping up as one of the possible counter arguements to

- 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
>> 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
>> you've actively engaged with knowing what you're doing while you
>> interact with them, vs. the third party you have no relationship
>> There's a very real privacy threat here we need to address, but
>> all tracking together may not be the way to do it. Emerging
>> structures around this, even in the most restrictive regimes, have
>> acknowledged the difference.
>>> Also, anonymous data linked to an individual should and would still
>> covered. But what about data collection that occurs without any
>> identifiers at all. The Narayanan papers talk about deanonymization
>> individually identifiable data sets. Let's make sure we understand
>> full privacy implications in either case before we jump to
conclusions -
>> is frequency-capping actually a privacy-impacting process? I'd say
>>> One of the problems of data protection law is that it treats all
>> collection similarly, without acknowledging degrees of harm. Let's
>> 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
>>> about user preferences is sufficient in this case.  Having
>>> bits which describe user preferences around tracking by first
>>> seems to me necessary.
>>> In particular, the document appears to assume that 1st party
>>> and 3rd party tracking done on behalf of a 1st party (see Exception
>>> 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
>>> mechanism by which third parties are distinguished from first
>>>  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,
>>> opposite tack, a "Know This" header which explicitly states the
>>> information the user is willing to reveal seems to give far more
>>> control.  This seems to ask the browser to  set a "Don't be evil"
>>> on its requests, but to leave the real control over what that means
>>> underspecified that reasonable people could conclude wildly
>>> things.
>>> regards,
>>> Ted Hardie
>>> On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner <>
>>>> 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
>> 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
privacydir mailing list