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

this interestingly relates to the separate chain between ian and shane on
site specific exceptions -- it appears that it does add a layer of
complexity here which is what necessitates this section. i think it would
be worthwhile to discuss and make sure we really want that added layer of
complexity (of the individual 3p specific exemption).


On Wed, Mar 21, 2012 at 6:33 PM, TOUBIANA, VINCENT (VINCENT) <
Vincent.Toubiana@alcatel-lucent.com> wrote:

>  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> 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]
> *Envoyé :* jeudi 16 février 2012 07:48
> *À :* public-tracking@w3.org (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> 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****
>
>  ****
>
>
>
> ****
>
> ** **
>
> --
> 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