W3C home > Mailing lists > Public > public-tracking@w3.org > February 2012

RE: ACTION-110: Write proposal text for what it means to "not track" (ISSUE-119)

From: Kevin Smith <kevsmith@adobe.com>
Date: Wed, 15 Feb 2012 09:48:19 -0800
To: Chris Pedigo <CPedigo@online-publishers.org>, "Roy T. Fielding" <fielding@gbiv.com>, Nicholas Doty <npdoty@w3.org>
CC: Ninja Marnau <nmarnau@datenschutzzentrum.de>, "<public-tracking@w3.org> (public-tracking@w3.org)" <public-tracking@w3.org>
Message-ID: <6E120BECD1FFF142BC26B61F4D994CF3064CAB5525@nambx07.corp.adobe.com>
I agree with some of the sentiment expressed.  I think this would make the standard confusing.  What does it mean if you are compliant but do not send in "I absolutely do not track".  It means you do not track according to the doc, but you do track according to absolutely not tracking?  Very confusing.  Calling this thing DNT was bad enough.  Now we are suggesting variable levels of "not tracking"?

-----Original Message-----
From: Chris Pedigo [mailto:CPedigo@online-publishers.org] 
Sent: Tuesday, February 14, 2012 7:28 AM
To: Roy T. Fielding; Nicholas Doty
Cc: Ninja Marnau; <public-tracking@w3.org> (public-tracking@w3.org)
Subject: RE: ACTION-110: Write proposal text for what it means to "not track" (ISSUE-119)

It seems to me that if a company didn't engage in any "tracking" then that company could just claim that.  They don't need a DNT standard to say so.  But, building such language into this standard would put compliant companies in a no-win situation.  This group has generally agreed to carve out first party activities.  Let's just call it a win and move on to other more important issues.

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com]
Sent: Monday, February 13, 2012 7:00 PM
To: Nicholas Doty
Cc: Ninja Marnau; <public-tracking@w3.org> (public-tracking@w3.org)
Subject: Re: ACTION-110: Write proposal text for what it means to "not track" (ISSUE-119)

This is regarding ISSUE-5

On Feb 13, 2012, at 3:32 PM, Nicholas Doty wrote:
> On Feb 13, 2012, at 3:04 PM, Roy T. Fielding wrote:
>> On Feb 13, 2012, at 1:09 PM, Nicholas Doty wrote:
>>> Hi Roy,
>>> On Feb 13, 2012, at 12:49 PM, Roy T. Fielding wrote:
>>>> Please be aware that this would require Apache httpd to respond 
>>>> that it is always tracking, by default, regardless of how the 
>>>> underlying services are implemented.  Likewise for Squid, 
>>>> TrafficServer, haproxy, and all other HTTP servers that I am aware of.
>>>> If we can't find a definition that allows HTTP access logs and 
>>>> normal retention for fraud control, then let's give up.  I will not 
>>>> implement DNT if it can be used as a bypass for fraud and security controls.
>>> As I believe Ninja noted, this is *not* intended as a set of requirements for compliance with a DNT header, just a meaningful and entirely optional description that a site can use if it absolutely isn't tracking.
>> I do not believe that is helpful.  It implies that anything in that 
>> list is tracking, which is false, and it implies that any site doing 
>> those things can't claim it is absolutely not tracking, which is not 
>> a desirable result (it makes this standard useless).
> I'm confused, why would that make the standard useless? I thought the group had largely agreed on compliance as a broad prohibition of tracking with an enumerated list of exceptions for business purposes where tracking is allowable.

No, the group has not even remotely agreed to any definition of tracking.
It wasn't even close -- five different ideas, each with distinct groups interested in that idea.

> If a site doesn't need any of those exceptions and simply isn't retaining data about users, why would it be unhelpful for them to have a way to say so?
> Maybe you're concerned about the terminology of "absolutely not tracking" as opposed to 'complying with the DNT preference'? Better terminology would be great. Personally, I just honestly can't see why it's harmful for sites to be able to say that they're going above and beyond a compliance standard.

It is harmful to place that text in the specification because there are many other sites that are absolutely not tracking and those sites will also be sending a response that says they are absolutely not tracking.  Adding text in the spec that excludes those sites is a contradiction in terms.

>>> If there is an alternate definition that could accommodate common httpd configurations and still communicate to the user that to a more complete level no tracking is occurring, it would be great to see that option.
>> Here is an alternative:
>> A party may claim that it is not tracking if
>> 1) the party does not retain data from requests in a form that might 
>> identify a user except as necessary to fulfill that user's intention 
>> (e.g., credit card billing data is necessary if the user is making a 
>> purchase) or for the limited purposes of access security, fraud 
>> prevention, or audit controls;
>> 2) when user-identifying data is retained for purposes other than to 
>> fulfill the user's intention, the party maintains strict 
>> confidentiality of that data and only retains that data for a limited 
>> duration that is no longer than is necessary to accomplish that 
>> purpose, thereafter destroying or otherwise clearing the 
>> user-identifying data; and,
>> 3) the party does not combine or correlate collected user-identifying 
>> data with any other data obtained from prior requests, 
>> user-identifying profiles, or data obtained from third parties unless 
>> specifically directed to do so by the user (e.g., when a user 
>> initiates a login request) or for the limited purposes of inspection 
>> for access security, fraud prevention, or audit controls.
> Is this alternative just a re-statement of one outcome of the compliance doc or do you think this is an optional level beyond compliance? (I believe we're aiming for the latter in ISSUE-119.) I personally would think "absolutely not tracking" wouldn't include retaining identifying data for business purposes outside of the user's intent for an indeterminate length of time.
> Thanks,
> Nick
Received on Wednesday, 15 February 2012 17:48:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:34 UTC