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

Ted Hardie <ted.ietf@gmail.com> Tue, 08 March 2011 15:35 UTC

Return-Path: <ted.ietf@gmail.com>
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 D74663A67A8 for <privacydir@core3.amsl.com>; Tue, 8 Mar 2011 07:35:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.525
X-Spam-Level:
X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 HWLIYPLikvsu for <privacydir@core3.amsl.com>; Tue, 8 Mar 2011 07:35:29 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 29E933A63CB for <privacydir@ietf.org>; Tue, 8 Mar 2011 07:35:29 -0800 (PST)
Received: by qyk29 with SMTP id 29so2750081qyk.10 for <privacydir@ietf.org>; Tue, 08 Mar 2011 07:36:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QLsTIdswGDVvBv/MnPyXp80SRbUz56UXHe9622O8IxA=; b=VGQ9rdbLfWyDPcjMHqCz4F9uggMfoFzJarN3cChLQNboQeUAFQSVOCwRzHdorIRBym gtLL17pbpdXdkXp6B6MjTralXb0ZEO7iuVFh3XdcKONNhntgdCOyhDABFGB6YxnfYqs0 2b97A9EXUqNkCQJr2e5rqcx4Q9urln9mRkFJg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KOBl0dRg7v3RXoGT5bmdeWEd0fhGJU5w12u17XoaZ8SfYQc2xOtK08M17+hplprw62 QcAFOaJrU3XiiIGlClciHn+Wbf9okDGeAWnnepzbCI1GTlSZexVglIN/5NpnSV6Kw/i3 NXNnI720/pWYnABlChZs4WowvFxUkSkq82rKw=
MIME-Version: 1.0
Received: by 10.229.41.70 with SMTP id n6mr2944408qce.252.1299598603623; Tue, 08 Mar 2011 07:36:43 -0800 (PST)
Received: by 10.229.11.74 with HTTP; Tue, 8 Mar 2011 07:36:43 -0800 (PST)
In-Reply-To: <DED01886A1779C459E4D5C8985C8D3DE0261181A@VF-MBX19.internal.vodafone.com>
References: <4D759595.60809@ieca.com> <AANLkTinv7bmd98pbfhEjzkKURyW7vpRPx+EDjfTW6BB_@mail.gmail.com> <DED01886A1779C459E4D5C8985C8D3DE0261181A@VF-MBX19.internal.vodafone.com>
Date: Tue, 8 Mar 2011 07:36:43 -0800
Message-ID: <AANLkTimzwTfCvKmfFYiJaG6BezCVEL+HY0nU+V=XEJ-z@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: "Chappelle, Kasey, VF-Group" <Kasey.Chappelle@vodafone.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: privacydir@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: Tue, 08 Mar 2011 15:35:31 -0000

On Tue, Mar 8, 2011 at 5:14 AM, Chappelle, Kasey, VF-Group
<Kasey.Chappelle@vodafone.com> wrote:
> 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.
>
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.


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


> -----Original Message-----
> From: privacydir-bounces@ietf.org [mailto:privacydir-bounces@ietf.org] On Behalf Of Ted Hardie
> Sent: 08 March 2011 04:15
> To: Sean Turner
> Cc: privacydir@ietf.org
> 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 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 <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
>