RE: ACTION-75: Write-up a hybrid of Do Not Profile and Do Not Cross-Site Track

A suggested friendly edit- perhaps an explanation that the prohibitions are subject to exceptions set forth elsewhere in the document?

Sorry to be a bit slow on the collection front, but I am not sure I get how the recipient can control what information is being transmitted to it in the header request. Would this be changing rules for communication between browser and server?

I also have a question about how the collection definition and exceptions would work in the following basic scenario:

I operate a blog on Wordpress platform. I use an analytics company, and also have a contract with an ad network for ads on my blog, because I'd like to get some compensation for my time writing blog posts. Leaving aside the Wordpress issue for a moment, in order to facilitate providing information to both the analytics company and the ad network, I have inserted code on my blog page to facilitate redirects. Am I sharing information with 3rd parties? Do I need to take any action whatsoever when I receive a DNT signal (other than not selling my data)?

Thanks in advance,

Amy

Sent from my Windows Phone
________________________________
From: Jonathan Mayer
Sent: 2/7/2012 12:48 PM
To: JC Cannon
Cc: Shane Wiley; Nicholas Doty; Tracking Protection Working Group WG
Subject: Re: ACTION-75: Write-up a hybrid of Do Not Profile and Do Not     Cross-Site Track

Our current analytical structure begins with a very broad conception of collection.  One of the chief reasons for the approach is that it mandates clarity—we have to be extraordinarily explicit about what is allowed in exceptions.  I believe your proposal would muddle the standard's handling of protocol information (and logs) by unnecessarily conflating it with the high-level definition of "collection."  I much prefer the current course of providing an exception for protocol information, subject to some limits.

Jonathan

On Feb 7, 2012, at 10:51 AM, JC Cannon wrote:

It seems that we are still conflating collection with receipt of logs by a server and processing of those logs for placement in a profile or otherwise.

I believe we all agreed that web servers must be able to receive logs in order for the Internet to work as it does. I would like to propose that the mere receipt of logs by a web server should not be considered collection or be constrained by the rules of collection.

However, any processing of the logs should be considered collection and be governed by our DNT standard.

Inasmuch as the logs will include a DNT signal, any retention policy that comes out of our standard should apply to those logs.

JC

From: Shane Wiley [mailto:wileys@yahoo-inc.com]
Sent: Monday, February 06, 2012 7:33 AM
To: Nicholas Doty
Cc: Tracking Protection Working Group WG
Subject: RE: ACTION-75: Write-up a hybrid of Do Not Profile and Do Not Cross-Site Track

Nicholas,

There is the “general rule” and then there is the list of “operational exceptions”.  I believe I’ve been responding to the “general rule” and am relying on the “operational exceptions” to allow for the use of cross-site data that’s been collected for narrow purposes (such as security or general financial reporting, for example).

- Shane

From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: Friday, February 03, 2012 4:28 PM
To: Shane Wiley
Cc: Tracking Protection Working Group WG
Subject: Re: ACTION-75: Write-up a hybrid of Do Not Profile and Do Not Cross-Site Track

Hi Shane,

Sorry for the confusion, but this gives me more questions, as I didn't realize the Service Provider concept was important for this proposal.

Do you mean "Service Provider" in the sense of the outsourcing exception currently defined in 3.6.1.2 http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#TypesofTrackingOutsourcing? I thought the Cross-Site Track proposal allowed third parties to collect siloed data for their own purposes (targeting advertising, etc.) which would be contrary to the current text as I understand it.

If this proposal is compatible with the current outsourcing exemption, then that's great news and I think we're one step closer to consensus.

On Feb 3, 2012, at 12:22 PM, Shane Wiley wrote:
3rd parties MUST NOT collect data across multiple, non-affiliated or branded websites.
<Non-Normative> Data collected by a 3rd party MUST be segregated according to the 1st party from which it was collected.  A 3rd party MUST NOT aggregate, correlate or use together data that was collected on different 1st party sites.

Do these next three statements only apply to data collected across multiple sites? Or to any data that a third party collects about a user?  [Correct – only data collected across multiple sites – as profiling only for a single site falls under the 1st party definition (as a Service Provider with no independent rights to use this data elsewhere).]

3rd parties MUST NOT add collected data to a "profile" of a user.

3rd parties MUST NOT leverage previously collected data to profile a user or to alter a user's experience.

3rd parties MUST NOT attempt to personally identify a user.

If these only apply to data collected across multiple sites, I'm not sure the first at least is necessary. If I can't collect data about a user across sites, it would be impossible to use that not-collected data to add to a profile of them, right?

[Logically you could argue it that way but we added this statements to make the prohibition very clear and to lower the risk of logic entanglement arguments.]

I see now, thanks. I still find the language confusing per the below, but I'm all for making statements clear even if it requires some level of redundancy.

Also, if that assumption is right, then the language seems confusing to me; 3rd-parties would be allowed to add data to profiles, leverage previously collected data to alter a user's experience or identify a user, as long as they were doing so with data they hadn't combined across sites, right?

[Correct – as a Service Provider to a 1st party with no independent rights to use this data elsewhere.]

Thanks,
Nick