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

[Lucy Lynch <[e-mail]>]

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:[e-mail]]
>> Sent: 08 March 2011 13:20
>> To: Chappelle, Kasey, VF-Group
>> Cc: Ted Hardie; Sean Turner; [e-mail]
>> 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: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Ted Hardie
>>> Sent: 08 March 2011 04:15
>>> To: Sean Turner
>>> Cc: [e-mail]
>>> 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 <[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
>>> _______________________________________________
>>> privacydir mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/privacydir
>>> 
>> 
> _______________________________________________
> privacydir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacydir
>