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

From: Sean Turner <[email-masked]>
Date: Mon, 07 Mar 2011 21:33:57 -0500

FYI

-------- Original Message --------
Subject: I-D ACTION:draft-mayer-do-not-track-00.txt
Date: Mon, 07 Mar 2011 17:45:01 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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:
http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 7 Mar 2011 20:14:47 -0800

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 <[email-masked]> wrote:
>    Title         : Do Not Track: A Universal Third-Party Web Tracking Opt
> Out
> _______________________________________________
> privacydir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/privacydir
>
>

---

From: "Chappelle, Kasey, VF-Group" <[email-masked]>
Date: Tue, 8 Mar 2011 14:14:05 +0100

Think of all the basic web functions you'd be breaking if first-party tracking weren't allowed. 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: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: 08 March 2011 04:15
To: Sean Turner
Cc: [email-masked]
Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt

regards,

Ted Hardie

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Mar 2011 13:19:45 +0000

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. 
>

---

From: "Chappelle, Kasey, VF-Group" <[email-masked]>
Date: Tue, 8 Mar 2011 14:31:28 +0100

Good question - perhaps someone with more technical expertise than I
have can help. 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. 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: 08 March 2011 13:20
To: Chappelle, Kasey, VF-Group
Cc: Ted Hardie; Sean Turner; [email-masked]
Subject: Re: [privacydir] Fwd: I-D
ACTION:draft-mayer-do-not-track-00.txt

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. 
>>    Title         : Do Not Track: A Universal Third-Party Web Tracking
Opt

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Mar 2011 13:54:31 +0000

On 08/03/11 13:31, Chappelle, Kasey, VF-Group wrote:
> have can help. 

That'd be good.

> But there are lots of reasons why site owners would need

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.

However, I don't know, so that's why I asked.

S.

---

From: "Chappelle, Kasey, VF-Group" <[email-masked]>
Date: Tue, 8 Mar 2011 15:09:28 +0100

That could be true - for example, certain third-party cookies can
masquerade as first-party. But privacy is going to be about intent a lot
of times, and there will always be those who attempt to circumvent
protections. That's why the enforcement piece is so important (as Lorrie
has been pointing out). 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: 08 March 2011 13:55
To: Chappelle, Kasey, VF-Group
Cc: Ted Hardie; Sean Turner; [email-masked]
Subject: Re: [privacydir] Fwd: I-D

That'd be good.

S.

>> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Ted Hardie

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Mar 2011 08:30:16 -0700

We should probably have this discussion on some open list. 

On Mar 7, 2011, at 7:33 PM, Sean Turner wrote:

> 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
> <draft-mayer-do-not-track-00.txt><Attached Message Part.txt>_______________________________________________
> privacydir mailing list
> [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Mar 2011 07:36:43 -0800

> Think of all the basic web functions you'd be breaking if first-party tracking weren't allowed. Also consider the very different privacy implications between a party you've actively engaged with kn…
I think your post highlights something important: the line between
tracking and maintaining state is very blurred, because the tracking
mechanics reuse the mechanics for maintaining state across multiple
HTTP requests/responses.

A technical user could express this pretty easily:  maintain state on
my session for no more than N hours.  That same technical user could
likely say:  do not share data on my requests/responses with anyone I
have not explicitly listed (with a default list of the fqdn in the
link/browser bar).

Going from that to useful defaults for the average user is going to be
tough, in my opinion, but it starts from user preference rather than
site behavior.  There are some clear advantages there.

> 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.
A single bit of information seems to me to force us into that trap;
that's one of the reasons I suggested richer semantics are needed.

regards,

Ted

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Mar 2011 08:37:19 -0800

> We should probably have this discussion on some open list.

Fair enough. Which one?

Regards,

Ted

---

From: Sean Turner <[email-masked]>
Date: Tue, 08 Mar 2011 11:52:58 -0500

How about websec?

spt

On 3/8/11 11:37 AM, Ted Hardie wrote:
> On Tuesday, March 8, 2011, Cullen Jennings<[email-masked]>  wrote:
>>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 9 Mar 2011 05:01:18 -0500

Or maybe ietf-privacy? Not sure which is better, but there may be some  
folks new to the IETF who are primarily interested in this draft and  
not the rest of what is going on in websec.

On Mar 8, 2011, at 11:52 AM, Sean Turner wrote:

>>>> <draft-mayer-do-not-track-00.txt><Attached Message  
>>>> Part.txt>_______________________________________________
>>>> privacydir mailing list
>>>> [email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 10 Mar 2011 15:55:15 -0500

(Moving this to [email-masked]. I suggest future responses drop [email-masked] 
.)

Hi Ted, couple responses inline --

> bits which describe user preferences around tracking by first parties

I would suggest that the proposal in this draft be viewed as an  
attempt at incremental change. We start with one bit, which has the  
potential to be an improvement over the status quo. It doesn't  
foreclose having additional bits in the future. But even standardizing  
the one bit and getting people to honor it would be a significant  
improvement IMO.

> browser bar, but this really needs to be spelled out.

I don't think the draft expects that there is a simple line to draw  
between first and third parties. Indeed, section 9.1 reveals some of  
the complexity involved in making this distinction. But just because  
it's hard doesn't mean that it's impossible.

One way that CDT has thought about tackling this one is by branding:  
entities with common branding are considered to be the same party,  
whereas entities with different branding are different parties [1].  
This makes the distinction subjective and not based on public suffix/ 
FQDN/anything else observable by a UA, but it tries to match user  
expectation.

> it seems likely to be exploited as one.

I would again be thinking about this incrementally -- right now some  
opting out of tracking for some services doesn't even result in any de- 
identification. If this proposal can serve to reduce the  
identifiability of opted out users, even if it does not eliminate all  
identifiable data stored about them, I think that would be a positive  
step.

> underspecified that reasonable people could conclude wildly different

I would hope that one of the benefits of standardization here would be  
to build out the specificity of the semantic.

Alissa

---

From: Ted Hardie <[email-masked]>
Date: Thu, 10 Mar 2011 14:09:49 -0800

Hi Alissa,

Dropping privacydir, as requested.  Some further discussion in-line.

On Thu, Mar 10, 2011 at 12:55 PM, Alissa Cooper <[email-masked]> wrote:
> (Moving this to [email-masked]. I suggest future responses drop
> [email-masked].)
>
> I would suggest that the proposal in this draft be viewed as an attempt at
> incremental change. We start with one bit, which has the potential to be an
> improvement over the status quo. It doesn't foreclose having additional bits
> in the future. But even standardizing the one bit and getting people to
> honor it would be a significant improvement IMO.
>
First, web headers tend to be chatty ascii things, and using an opaque
single bit rather than a semantically useful statement seems to me a
poor optimization choice.  Second, if you are expecting extensibility,
you need to be really sure that the initial choices don't seem to
exclude it; these, at least to me, do.

> I don't think the draft expects that there is a simple line to draw between
> first and third parties. Indeed, section 9.1 reveals some of the complexity
> involved in making this distinction. But just because it's hard doesn't mean
> that it's impossible.
>

But this is absolutely critical.  If someone including a single pixel
image gets to be treated as a first party, *any* mechanism based on
third party tracking is toothless.

> entities with common branding are considered to be the same party, whereas
> entities with different branding are different parties [1]. This makes the
> distinction subjective and not based on public suffix/FQDN/anything else
> observable by a UA, but it tries to match user expectation.
>

How does the protocol detect the brand?  cnn.caching-cdn.com is
branded in a way to allow it to share cookies with .cnn.com?

> I would again be thinking about this incrementally -- right now some opting
> out of tracking for some services doesn't even result in any
> de-identification. If this proposal can serve to reduce the identifiability
> of opted out users, even if it does not eliminate all identifiable data
> stored about them, I think that would be a positive step.
>
>>
> I would hope that one of the benefits of standardization here would be to
> build out the specificity of the semantic.

I think this argues for a much richer semantic than a single bit then,
especially when third and first party entities are hard to tease
apart.

It is much easier to know what is desired if you say:

know this: I want a maximally private interaction--don't store, share,
or analyze this interaction except as needed to maintain state

know this:  I'm okay with you doing anything with the data I provide you

know this:  I'm okay with you keeping my data "live" for up to 24
hours so I can pick up where I left off; I'm okay with you sharing
data I gave you with a financial institution I name in purchases; I'm
okay with you sharing my data as part of your analysis of purchase
patterns, provided my name, address, customer number, and financial
identifiers are removed; I'm okay with you sharing my data with other
parties you own, but not with other parties you pay for services.

The effect of a 3rd party "Do not track" clearly isn't the first in
your  draft, but where it falls between the 2nd and the 3rd is not yet
clear, because the server has to infer to much from a single bit.  If
the server's organization as a first party does all the work, they can
do *anything* according to this proposal.  Somehow I doubt that's what
the naive user will think happens when there UI asks them whether to
turn on "Do not Track".

regards,

Ted Hardie