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

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> 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
> > 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
>



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