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

[Ted Hardie <[e-mail]>]

Hi Alissa,

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

On Thu, Mar 10, 2011 at 12:55 PM, Alissa Cooper <[e-mail]> wrote:
> (Moving this to [e-mail]. I suggest future responses drop
> [e-mail].)
>
> 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.
>
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.


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

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.

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

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

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