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

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>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]
> Sent: Wednesday, February 08, 2012 5:11 AM
> To: public-tracking@w3.org
> Cc: 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
sharvey@google.com