RE: Approach to ISSUE-167: Multiple site exception

Matthias,

There is a question of timing and what the current draft already supports.  If UAs in the WG are already implementing the current draft, then we have the TSV of "1" from a 3rd party covering some of our needs here (UA -> DNT:1, Server -> Tk:1;URI).  While technically, to covers Ed's points, the domain will be seen as a 3rd party domain, as long as the Server appropriately replies it's indeed a 1st party, then both the UA and the user know that domain considers itself within the 1st party context.

The issue here is to try to ensure the co-1st party receives the DNT:0 signal to start versus always needing to reply with Tk:1 to correct a disconnect (outside of EU use cases which are still being discussed).  In the "same-party" field, we have the tools to convey, at the time of exception setting, that the co-1st party is part of the "same-party" definition.  What we miss here is a link to 3rd party's resource - which could be conveyed in the 1st party's resource but would be better conveyed independently (your 'StoreMultiSiteException' example).  This is what I'm drafting text around now.   

I believe the risk of gaming in this context is relatively low as there is a recorded event that cannot be hidden from an observer (read - regulator) whereas the DNT:1 signal allows any party to pass the signal in a hidden fashion in the current spec <ISSUE-143>.  If we feel gaming is a real concern (also something that can be measured during initial testing), then a cross same party URI listing method could be implemented but not required for UAs to interrogate (as we discussed in Cambridge).

- Shane
  
-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
Sent: Monday, March 18, 2013 9:50 AM
To: Shane Wiley; public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: Approach to ISSUE-167: Multiple site exception

Hi Shane,


thanks a lot  for the feedback. Maybe I misinterpreted the minutes (which I read as "let's gather implementation experience first" after final call).

Note that as discussed at the F2F, backward compatibility is important since we had to choose between user agents starting to implement the current API (broader support) and having full flexibility of later modifying the API in new (non-compatible) ways. One approach we discussed was to later add a function "StoreMultiSiteException" while leaving existing functions unchanged.

btw: What was your proposal to avoid fraud (i.e., that I ask for an exception for a site that I do not own)? Do I remember correctly that you only allow this iff the same-party fields are consistent (i.e.,,
site1 includes site2 and site2 includes site1)?


Regards,
matthias



On 18/03/2013 17:10, Shane Wiley wrote:
> Matthias,
>
> I disagree and believe we can cover the multi-1st party (co-controller) use case with very little modification.  As this is critical to many of the larger companies within the working group, I would recommend we keep this on the table for discussion.
>
> - Shane
>
> -----Original Message-----
> From: Matthias Schunter (Intel Corporation) 
> [mailto:mts-std@schunter.org]
> Sent: Monday, March 18, 2013 8:37 AM
> 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 Monday, 18 March 2013 17:58:49 UTC