RE: [Action-106][Issue-32] Sharing of data between entities via cookie syncing / identity brokering

Shane,

I believe that case it is covered by the existing exemptions. I put a note specifically for that.

Vincent

________________________________
De : Shane Wiley [mailto:wileys@yahoo-inc.com]
Envoyé : mercredi 21 mars 2012 16:11
À : TOUBIANA, VINCENT (VINCENT); Sean Harvey
Cc : Aleecia M. McDonald; public-tracking@w3.org (public-tracking@w3.org)
Objet : RE: [Action-106][Issue-32] Sharing of data between entities via cookie syncing / identity brokering

There may be situations where cookie mapping is leveraged only for 3rd party audit services or for providing financial reporting of a non-targeted ad served through an Exchange.  If cookie mapping is performed only for a purpose not allowed through operational purpose exceptions, then the DNT:1 signal should halt the practice (i.e., behavioral profiling and targeting).

- Shane

From: TOUBIANA, VINCENT (VINCENT) [mailto:Vincent.Toubiana@alcatel-lucent.com]
Sent: Wednesday, March 21, 2012 3:34 AM
To: Sean Harvey
Cc: Aleecia M. McDonald; public-tracking@w3.org (public-tracking@w3.org)
Subject: RE: [Action-106][Issue-32] Sharing of data between entities via cookie syncing / identity brokering

Sean,

Thanks for your rapid answer. You're right; this text is mostly covered by what is already in the document. So far, there is just one use case I can think of that may not be covered:

Suppose that we have a chain of third parties A => B => C where A and C are granted an exception but B is not. In that case, B can not sync its own cookie with the cookie emitted by A, yet it can forward to C the user ID set by A (indicating that it is associated to A's domain). B would not have to keep track of this transaction, yet the chain could keep working.

In fact that would also support the exception system.

Does that make sense? If so, I may have to add a few sentences to cover this specific use case.

Thanks,

Vincent



________________________________
De : Sean Harvey [mailto:sharvey@google.com]
Envoyé : mercredi 21 mars 2012 11:06
À : TOUBIANA, VINCENT (VINCENT)
Cc : Aleecia M. McDonald; public-tracking@w3.org (public-tracking@w3.org)
Objet : Re: [Action-106][Issue-32] Sharing of data between entities via cookie syncing / identity brokering

Vincent thanks so much for your work on this.

I certainly see no harm in including explicit language around this behavior, and there may be benefit, but for clarity's sake can you comment on what use case(s) exactly would not have been covered in the document should we not have this language included? My initial thought is that this sort of behavior would be prohibited already in a DNT-on scenario, but am curious for your take on this.

thanks!

sean



On Wed, Mar 21, 2012 at 5:59 PM, TOUBIANA, VINCENT (VINCENT) <Vincent.Toubiana@alcatel-lucent.com<mailto:Vincent.Toubiana@alcatel-lucent.com>> wrote:
I slightly updated the text on identity brokering to address the two first notes. The text is no longer focused on cookie syncing.

Vincent

In an ID brokering procedure a Demand-Side Platform (DSP) aims to match the ID XYZ it assigned to a user in its domain to the ID ABC set by the Supply Side Platform (SSP) for the same User-Agent U. ID brokering can be done via  "Cross-origin resource sharing" or through a cookie syncing procedure which requires that the SSP adds a 1x1 pixel from the DSP domain. The SSP has then to pass the string "cookieABC" corresponding to its domain to the DSP through the URL of this 1x1 pixel. The DSP parses the "cookieABC" in the URL and associates it to the cookieXYZ assigned on its domain. Once the cookies have been matched, the DSP will be able to re-target U on the SSP affiliated sites.

The solution consists in not allowing ID brokering when the SSP receives DNT:ON. If it did not, the SSP may start the ID brokering process but the DSP must not synchronize the ID if it received DNT:ON (this may happen if the SSP is granted an exception but not the DSP). The reason is that if the SSP publishes ads on a limited number of websites, the DSP would know that the client visited at least one of these websites.

4.4.2 Normative text

The operator of domain acting as a third party (SSP) on a website and receiving [DNT-ON] must not load content from a second unaffiliated third party domain (DSP) to transmit a user ID to this third party. When a third party receives [DNT-ON] it must ignore any user ID transmitted by an unaffiliated entity acting as a third party.

Note: Both collection and transmission of ID by third parties may be covered by exemptions defined in Section 4.5.


________________________________
De : Aleecia M. McDonald [mailto:aleecia@aleecia.com<mailto:aleecia@aleecia.com>]
Envoyé : jeudi 16 février 2012 07:48
À : public-tracking@w3.org<mailto:public-tracking@w3.org> (public-tracking@w3.org<mailto:public-tracking@w3.org>)
Objet : Re: [Action-106][Issue-32] Sharing of data between entities via cookie syncing / identity brokering

Noting as:

            "Would rather not have discussion of specific technology, and isn't this already prohibited? This section may be redundant."

[personally, I suspect things that are obvious to us are not obvious to others who do not spend as much time on DNT. I'm ok wasting some pixels from time to time, provided we do not introduce confusion in the process. But that's just my opinion.]

            Aleecia

On Feb 15, 2012, at 9:30 PM, Sean Harvey wrote:

that said, looking this over i don't see anything potentially problematic either -- it's more that it's repetitive and i don't think expands coverage or scope of compliance. if we want to keep it in for a working draft i don't have an issue -- let's keep in mind to discuss, though, as I believe it may not be adding anything.

On Thu, Feb 16, 2012 at 12:19 AM, Sean Harvey <sharvey@google.com<mailto:sharvey@google.com>> wrote:
I'm still unclear as to why we are documenting a particular technical instance/implementation of data sharing across domains or parties. Regardless of whether or not the spec says anything about cookie synching, such behavior would be covered in the compliance draft without this text, and disallowed in a DNT-ON context. In particular with respect to the normative text, the third party is already being disallowed in a DNT-ON scenario from identifying a user and therefore has no allowed mechanism for cookie synching. Before Aleecia summarily adds this to the editors' draft i would like to understand what exactly this text adds. Aleecia do you have thoughts on this?




On Thu, Feb 16, 2012 at 12:06 AM, Aleecia M. McDonald <aleecia@aleecia.com<mailto:aleecia@aleecia.com>> wrote:
For the moment, I've included Vincent and Heather's text in the draft, plus added two notes to reflect comments from Rob and Shane --

Open issues:

 1.  This text does not cover Cross-Origin Resource Sharing (CORSE) and perhaps should.
 2.  Ad Exchanges use cookie synching for business purposes, including third-party auditing to verify ad impressions. However, this might be resolved with a service provider exemption.
If I failed to capture issues correctly, please let me know. Otherwise, we will leave this as pending review and resolve these after publishing the second public working draft.

Aleecia

On Feb 12, 2012, at 1:32 PM, Shane Wiley wrote:

Vincent,

Cookie syncing may be necessary for basic financial tracking across the Ad Exchange model - especially when 3rd party auditors are involved (each keeps a separate record of the ad impression and then leverages the Exchange cookie map to compare the number of impressions and where diverging results may be occurring, if any).

I agree that cookie syncing should be ceased for users with DNT:1 for the purposes of profiling and the use of profiles to modify a users experience.  I wanted to call out that a strict halting of the practices altogether will not be possible for much of the ad ecosystem for the serving of a very generic ad but this is done only in situations where a neutral technology vendor is being used and they have no independent right to use the information themselves (Service Provider exception).

- Shane

-----Original Message-----
From: TOUBIANA, VINCENT (VINCENT) [mailto:Vincent.Toubiana@alcatel-lucent.com<mailto:Vincent.Toubiana@alcatel-lucent.com>]
Sent: Wednesday, February 08, 2012 5:11 AM
To: public-tracking@w3.org<mailto:public-tracking@w3.org>
Cc: heatherwest@google.com<mailto:heatherwest@google.com>
Subject: [Action-106][Issue-32] Sharing of data between entities via cookie syncing / identity brokering

The title might be misleading; it is not in fact about cookie-syncing between different browsers but different domains. Please find bellow the text that Heather and I drafted.
Vincent


Background:
In a cookie syncing procedure a Demand-Side Platform (DSP) aim to match a cookieXYZ (corresponding to its domain) to the cookieABC set by the Supply Side Platform (SSP) for the same User-Agent U. Cookie syncing requires that the SSP adds a 1x1 pixel from the DSP domain. The SSP has to pass the string "cookieABC" corresponding to ids domain to the DSP through the URL of this 1x1 pixel. The DSP parses the "cookieABC" in the URL and associates it to the cookieXYZ for its domain. Once the cookies have been matches, the DSP will be able to re-target U on the SSP affiliated sites.
The solution consists in not allowing cookie syncing when the SSP receives DNT:ON. If it did not, the SSP may start the cookie syncing process but the DSP must not synchronize the cookies if it received DNT:ON.
*The reason is that if the SSP publishes ads on a limited number of websites, the DSP would know that the client visited at least one of these websites.*

Pseudo-normative
The operator of domain acting as a third party (SSP) on a website and receiving [DNT-ON]  MUST not load content from a second unaffiliated third party domain (DSP) to transfer a user ID to this third party.
A third party receiving [DNT-ON] and a user ID through the URL loaded from an unaffiliated entity acting as a third party
MUST NOT associate the ID of the cookie sent in the request to the user ID transmitted in the URL and
MUST NOT collect or use other information related to that communication and not covered by the 3rd party exemption.



--
Sean Harvey
Business Product Manager
Google, Inc.
212-381-5330<tel:212-381-5330>
sharvey@google.com<mailto:sharvey@google.com>



--
Sean Harvey
Business Product Manager
Google, Inc.
212-381-5330<tel:212-381-5330>
sharvey@google.com<mailto:sharvey@google.com>




--
Sean Harvey
Business Product Manager
Google, Inc.
212-381-5330
sharvey@google.com<mailto:sharvey@google.com>