W3C home > Mailing lists > Public > public-tracking@w3.org > November 2012

RE: Propose to close issue-32 (Re: [Action-106][Issue-32] Sharing of data between entities via cookie syncing / identity brokering)

From: TOUBIANA, VINCENT (VINCENT) <Vincent.Toubiana@alcatel-lucent.com>
Date: Wed, 14 Nov 2012 15:23:36 +0100
To: Thomas Roessler <tlr@w3.org>
CC: "public-tracking@w3.org" <public-tracking@w3.org>, "heatherwest@google.com" <heatherwest@google.com>
Message-ID: <4D30AC7C2C82C64580A0E798A171B4445D2C477235@FRMRSSXCHMBSD1.dc-m.alcatel-lucent.com>
Hi Thomas,

I agree that the current text is no longer needed. I would personally prefer if identity syncing were not permissible without UGEs but that's another issue.

From: Thomas Roessler [tlr@w3.org]
Sent: Tuesday, November 13, 2012 11:57 AM
Cc: public-tracking@w3.org; heatherwest@google.com
Subject: Propose to close issue-32 (Re: [Action-106][Issue-32] Sharing of data between entities via cookie  syncing / identity brokering)

ISSUE-32 didn't have much momentum over the past 10 months.

I checked in with Vincent off-list, and the following seems to be where we have ended up with this:

* If cookie synching (the technique) is used for data sharing that is permissible in the context of accomplishing a permitted use, then that should be fine without specific text.
* If, on the other hand, cookie synching (the technique) was used to share data *outside* the scope of the permitted use, then that should be prohibited by the existing spec, without specific text.

The conclusion is that we should be able to close issue-32 without having to add text to the specification.

I'll leave it to Vincent to confirm on-list that he's ok with this conclusion.

If we have no other objections, I'd propose to close this issue without further action.

Thomas Roessler, W3C <tlr@w3.org> (@roessler)

On 2012-02-08, at 13:11 +0100, "TOUBIANA, VINCENT (VINCENT)" <Vincent.Toubiana@alcatel-lucent.com> wrote:

> 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.
Received on Wednesday, 14 November 2012 14:24:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:39:13 UTC