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

Lucy Lynch <llynch@civil-tongue.net> Tue, 08 March 2011 14:59 UTC

Return-Path: <llynch@civil-tongue.net>
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 DB6853A68B3 for <privacydir@core3.amsl.com>; Tue, 8 Mar 2011 06:59:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.141
X-Spam-Level:
X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=0.458, 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 uioVqLb15bAp for <privacydir@core3.amsl.com>; Tue, 8 Mar 2011 06:59:33 -0800 (PST)
Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by core3.amsl.com (Postfix) with ESMTP id BA1063A689A for <privacydir@ietf.org>; Tue, 8 Mar 2011 06:59:32 -0800 (PST)
Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id p28F0kiS039154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <privacydir@ietf.org>; Tue, 8 Mar 2011 07:00:46 -0800 (PST) (envelope-from llynch@civil-tongue.net)
Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id p28F0khL039151 for <privacydir@ietf.org>; Tue, 8 Mar 2011 07:00:46 -0800 (PST) (envelope-from llynch@civil-tongue.net)
Date: Tue, 8 Mar 2011 07:00:46 -0800 (PST)
From: Lucy Lynch <llynch@civil-tongue.net>
X-X-Sender: llynch@hiroshima.bogus.com
To: privacydir@ietf.org
Message-ID: <alpine.BSF.2.00.1103080700150.26896@hiroshima.bogus.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.tx
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 14:59:34 -0000

On Tue, 8 Mar 2011, Stephen Farrell wrote:

> 
> 
> On 08/03/11 13:31, Chappelle, Kasey, VF-Group wrote:
>> Good question - perhaps someone with more technical expertise than I
>> have can help.
> 
> That'd be good.
> 
>> 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.
> 
> 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.

One of the key arguments I've heard advanced re: first party
tracking of authenticated users has to do with fraud prevention.
At the recent RSA in San Francisco several panels dealt with user
profiling for security, see for example:

https://cm.rsaconference.com/US11/catalog/modifySession.do?SESSION_ID=3210&back=true

It isn't clear to me how much users know/understand about this kind of data 
collection and how they would feel about it if they did. It also isn't clear to 
me if these organizations are out-sourcing the analysis of customer data.

This is shaping up as one of the possible counter arguements to do-not-track.

- Lucy


> However, I don't know, so that's why I asked.
> 
> S.
> 
>> 
>> -----Original Message-----
>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>> Sent: 08 March 2011 13:20
>> To: Chappelle, Kasey, VF-Group
>> Cc: Ted Hardie; Sean Turner; privacydir@ietf.org
>> Subject: Re: [privacydir] Fwd: I-D
>> ACTION:draft-mayer-do-not-track-00.txt
>> 
>> 
>> 
>> 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.
>>> 
>>> 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: 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
>>> _______________________________________________
>>> 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
>