RE: Approach to ISSUE-167: Multiple site exception

Mike,

Perhaps there are no issues at all then and the current spec covers us.  I believe you're saying that if the 1st party that is requesting the co-1st party exception is the origin domain (and always will be in this situation), then the arrayOfDomainStrings works for this co-1st party pairing (basically the co-1st party simply looks like another domain of the same party).  If the co-1st party were to interact with the UA outside of this context, it would revert back to not having an exception as its origin did not directly register an exception.  Correct?  Worst case the co-1st party can reply to a DNT:1 with tk:1;URI without an exception so everything is still very clear to the UA/User.

- Shane

-----Original Message-----
From: Mike O'Neill [mailto:michael.oneill@baycloud.com] 
Sent: Monday, March 18, 2013 11:55 AM
To: 'Matthias Schunter (Intel Corporation)'; Shane Wiley
Cc: public-tracking@w3.org
Subject: RE: Approach to ISSUE-167: Multiple site exception

Shane,

As I understand the use-case, getting consent for multi first-parties can be handled by the existing API. Script in the top-level domain just calls the API with the additional parties in arrayOfDomainStrings. I thought the problem with multi first-parties was the DNT:1 case,  and (otherwise) third-party servers wanted to claim first party status and so respond with
Tk: 1.

This is different from the situation where you want to simultaneously register tracking consent to other (actual) first-parties, each perhaps with their own retinue of third-parties, which hits the same-origin restriction.

Or have I not understood your use-case?  Can you give an example?

Mike

-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
Sent: 18 March 2013 15:37
To: Shane Wiley; Mike O'Neill
Cc: public-tracking@w3.org (public-tracking@w3.org)
Subject: Approach to ISSUE-167: Multiple site exception

ISSUE-167: Multiple site exceptions
http://www.w3.org/2011/tracking-protection/track/issues/167


Hi Team (and in particular Shane and Mike),


I have re-read the minutes and it seems to be that the right approach forward to ISSUE-167 (albeit not perfect) is to leave the API as it is for final call and then understand the implementation experiences.

We can then design a backward compatible way to add MultiSiteExceptions later.
One challenge to overcome is that we need to ensure that the envisioned method is secure, i.e., that one can only ask for exceptions for sites that one owns/controls.

Formally, I suggest to document this and mark ISSUE-167 as POSTPONED. 
Are you OK with this way forward?


Regards,
matthias

Received on Tuesday, 19 March 2013 04:30:38 UTC