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

Alissa Cooper <acooper@cdt.org> Thu, 10 March 2011 20:54 UTC

Return-Path: <acooper@cdt.org>
X-Original-To: privacydir@core3.amsl.com
Delivered-To: privacydir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12EA93A699C; Thu, 10 Mar 2011 12:54:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Level:
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTrnyuZcPLoU; Thu, 10 Mar 2011 12:54:15 -0800 (PST)
Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 9E47E3A67F8; Thu, 10 Mar 2011 12:54:14 -0800 (PST)
Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 10 Mar 2011 15:55:26 -0500
Message-Id: <D06B789B-1414-4D5F-B74E-F17EA5DEBC18@cdt.org>
From: Alissa Cooper <acooper@cdt.org>
To: Ted Hardie <ted.ietf@gmail.com>
In-Reply-To: <AANLkTinv7bmd98pbfhEjzkKURyW7vpRPx+EDjfTW6BB_@mail.gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 10 Mar 2011 15:55:15 -0500
References: <4D759595.60809@ieca.com> <AANLkTinv7bmd98pbfhEjzkKURyW7vpRPx+EDjfTW6BB_@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: privacydir@ietf.org, ietf-privacy@ietf.org
Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt
X-BeenThere: privacydir@ietf.org
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." <privacydir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/privacydir>, <mailto:privacydir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/privacydir>
List-Post: <mailto:privacydir@ietf.org>
List-Help: <mailto:privacydir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/privacydir>, <mailto:privacydir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2011 20:54:16 -0000

(Moving this to ietf-privacy@ietf.org. I suggest future responses drop privacydir@ietf.org 
.)

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 <turners@ieca.com> 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: Internet-Drafts@ietf.org
>> Reply-To: internet-drafts@ietf.org
>> To: i-d-announce@ietf.org
>>
>> 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
>> privacydir@ietf.org
>> https://www.ietf.org/mailman/listinfo/privacydir
>>
>>
> _______________________________________________
> privacydir mailing list
> privacydir@ietf.org
> https://www.ietf.org/mailman/listinfo/privacydir
>