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

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

On Mar 7, 2011, at 11:14 PM, Ted Hardie wrote:

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

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.

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

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.

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

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

Alissa

>
> regards,
>
> Ted Hardie
>
>
> On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner <[email-masked]> 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: [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.
>>
>>
>> _______________________________________________
>> privacydir mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/privacydir
>>
>>
> _______________________________________________
> privacydir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/privacydir
>

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 10 Mar 2011 16:22:26 -0500

Actually one of the benefits of the header approach is that since it  
doesn't define an enforcement mechanism, it can apply to Flash  
cookies, HTML5 storage, and any other tracking tool. It gets sent via  
HTTP but the response can affect non-HTTP mechanisms.

Alissa

On Mar 10, 2011, at 4:00 PM, Eric Burger wrote:

> I know we're looking at this from an HTTP/cookie perspective, but I  
> just had the entertaining experience of cleaning out a ton of Flash  
> Cookies.  From a policy perspective, that is a much larger problem  
> than HTTP cookies.
>
> I know, "we have to start somewhere."
>
> On Mar 10, 2011, at 3:55 PM, Alissa Cooper wrote:
>
>> (Moving this to [email-masked]. I suggest future responses  
>> drop [email-masked].)
>>
>> 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.
>>
>>>
>> 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.
>>
>>>
>> 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.
>>
>> Alissa
>>
>>>
>>> regards,
>>>
>>> Ted Hardie
>>>
>>>
>> ietf-privacy mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>

---

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
>>>   Title         : Do Not Track: A Universal Third-Party Web Tracking Opt
>>> Out
>>>  HTTP header-based mechanism that enables users to express preferences
>>>  about third-party web tracking.  It also provides a standard for how

---

From: David Singer <[email-masked]>
Date: Thu, 10 Mar 2011 16:30:21 -0800

Hi

minor comments inline.

> exclude it; these, at least to me, do.

I tend to be in mild agreement.  Stylistically, most HTTP headers are words, not acronyms.  More to the point, I would have thought something more like:
Privacy: DoNoTrack
would be more extensible to other privacy declarations etc. in the future.  But it may not be worth rat-holing on, unless it precludes future development or action, which I doubt (we can make things mean what we want them to mean, after all, so "DNT" could become the general-privacy header, and "1" can mean "Do not track me, pretty please").

On the question of Nth party:  Maybe I am naive, but if I navigate to a web site (as shown in the location bar) "http://www.example.com", I would expect the nomenclature to be:

first party - me!
second party - example.com (the place I think I am talking with, the one reported by the browser as the location)
third party - anyone else listening in or involved in the transaction.

So, a 3rd party server would be e.g. http://www.advert-tracker.net/.  A third-party proxy would be one not operated by 'me' (or at least the place I come from) or example.com, and so on.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Scott W Brim <[email-masked]>
Date: Fri, 11 Mar 2011 17:58:18 -0500

(dropping privacydir)

I want to pop up a level, to a non-technical question.  I continue to
believe that the default setting for any "do not track" indication
must be "on", particularly one that is an indication to services.
We've seen too many times that ordinary people never get around to
changing defaults as shipped.  A "do not track" option that defaults
to "off" satisfies regulators but does nothing for actual privacy.
It's great for the personal information selling industry: they can say
they're complying but still get what they want because the great
majority of users can't conceive of setting the option.  Privacy
should be treated as a right, and rights do not default to "off", or
require a person to explicitly turn them on.

Now bringing that down to technical implications: if "do not track"
mechanisms are required to default to "on", which ones does that
eliminate right away as being too disruptive to current web practice?
For example, it would be very disruptive to suddenly turn off all
cookies, and require users to enable certain cookies -- they would
react strongly against that.  But the header options e.g. HTTP would
default to "on" just fine.

---

From: Nick Doty <[email-masked]>
Date: Fri, 11 Mar 2011 22:08:08 -0800

> require a person to explicitly turn them on.

I can certainly see some advantages for users if browsers default to
opting-out via a Do Not Track mechanism, but I don't think it's absolutely
necessary. The very popular Do Not Call registry, for example, is opt-in but
the process is simple enough and the change popular enough with consumers
that it's widely used in the US. For political reasons (in the US this
includes free speech issues, a fear of squashing innovation and a
Republican-controlled House), insistence on not tracking by default may make
any solution less likely to see adoption by all the players involved.

The draft-mayer spec explicitly distinguishes between opting-in to tracking
and not stating a preference, so that a default unexpressed preference won't
be claimed by industry as everyone opting-in. (They also prohibit setting
the header to opt-in by default.)

> default to "on" just fine.

A blocking list (as proposed by Microsoft) wouldn't be as disruptive as
blocking all cookies but could be dramatic if a default list were set very
broad to meet your proposed requirement of opting-out by default. I believe
IE9 is intended to ship without any blocking list included, probably to
separate the decision of which sites ought to be blocked from the browser
vendor. Instead, users would have to actively choose some list, from TRUSTe,
privacychoice.org or whatever other organization they choose to trust for
this decision.

---

From: Eric Burger <[email-masked]>
Date: Thu, 10 Mar 2011 16:00:52 -0500

I know we're looking at this from an HTTP/cookie perspective, but I just had the entertaining experience of cleaning out a ton of Flash Cookies.  From a policy perspective, that is a much larger problem than HTTP cookies.

On Mar 10, 2011, at 3:55 PM, Alissa Cooper 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.
> 
>> 
> 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.
> 
>> 
> 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.
> 
> Alissa
> 
>> 
>> regards,
>> 
>> Ted Hardie
>> 
>>

---

From: Mischa Tuffield <[email-masked]>
Date: Tue, 15 Mar 2011 15:24:41 +0000

> I know we're looking at this from an HTTP/cookie perspective, but I just had the entertaining experience of cleaning out a ton of Flash Cookies.  From a policy perspective, that is a much larger pr…

FWIW,

Ashkan Soltani [1] has done some good work looking at Flash Cookies [2] and issues surrounding them.

Cheers, 

Mischa

[1] http://www.ashkansoltani.org/
[2] http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1446862 

>>>> implementation to automatically retrieve the ASCII version of the

___________________________________
Mischa Tuffield PhD
Email: [email-masked]
Homepage - http://mmt.me.uk/
Garlik Limited, 1-3 Halford Road, Richmond, TW10 6AW
+44(0)845 652 2824  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

---

From: Sid Stamm <[email-masked]>
Date: Tue, 15 Mar 2011 09:17:01 -0700

On the flash cookies topic:

The NPAPI has been updated[0] to support connections to browsers'
general clear history functions.  Firefox 4 will ship with the
capabilities[1] and from what I've heard, so will an upcoming version
of Adobe Flash[2].  This means when you clear cookies in Firefox 4
with Flash 10.2+, it should clear your Fash cookies too.  As far as I
know, Chrome will or already does have support for this too[3].

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=508167
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=625496
[2] https://bugs.adobe.com/jira/browse/FP-6044
[3] http://downloadsquad.switched.com/2011/01/13/adobe-working-with-mozilla-and-google-to-bring-clear-flash-cook/

-Sid Stamm

On Tue, Mar 15, 2011 at 8:24 AM, Mischa Tuffield
<[email-masked]> wrote:
> I know we're looking at this from an HTTP/cookie perspective, but I just had
> the entertaining experience of cleaning out a ton of Flash Cookies.  From a
> policy perspective, that is a much larger problem than HTTP cookies.
>
> FWIW,

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 16 Mar 2011 18:24:20 +0000

Hi Ted,

A few thoughts in-line:

On Mar 10, 2011, at 10:09 PM, Ted Hardie wrote:
>> attempt at

Agreed, the syntax could definitely be improved.

>> between

I agree, which is why I think the branding idea is promising, because  
it requires the line-drawing to approximate user expectation.

>> whereas

The protocol does not do anything to prevent cookie sharing (or to  
enforce the header any other way). Thus the protocol need not detect  
the brand. If the protocol were doing anything other than signaling  a  
user preference to anyone who would listen, the notion of using brands  
to draw lines wouldn't work. But as it is, all semantics and usage are  
defined outside the protocol itself.

> the naive user will think happens when there UI asks them whether to

I'm certainly not opposed to richer or more granular controls, but I  
don't think they're mutually exclusive from a blanket binary choice.  
For people who just don't want to participate in passive tracking on  
the web, I think they should have that simple choice available to them.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 16 Mar 2011 18:27:47 +0000

On Mar 11, 2011, at 12:30 AM, David Singer wrote:
> On the question of Nth party:  Maybe I am naive, but if I navigate  
> to a web site (as shown in the location bar) "http:// 
> www.example.com", I would expect the nomenclature to be:
>
> first party - me!
> second party - example.com (the place I think I am talking with, the  
> one reported by the browser as the location)
> So, a 3rd party server would be e.g. http://www.advert- 
> tracker.net/.  A third-party proxy would be one not operated by  
> 'me' (or at least the place I come from) or example.com, and so on.

The nomenclature is a relic of the online ad industry.

First party = example.com
Second party = me
Third party = anyone else

Whether it makes sense or not, it's probably best to stick with it.

Alissa