AW: Re: ACTION-202 Alternative to explicit/explicit API

Hi Jonathan, 


thanks a lot for your note. 

I agree that there are multiple use cases. Sorry for just picking one as an example. 

The proposal that seemed to emerge as acceptable from all sides ('can live with') was to publish the list of third parties at the well-known URI. Besides implementors accepting it, is has the advantage of easier discovery.  We now would like to update the spec to reflect this discussion.

If you can no longer live with this approach, please tell us. I would also like to learn why, i.e. What is the exact usecase that you need that can be implemented with the old approach (list in the api) and can not be implemented once the list is posted at the well-known URI. 

In any case, if your goal is to untangle the 'convoluted design', then proposing an update 
to the spec once the proposed design exists in writing is probably the best approach. 


Regards,  
 Matthias 

--- Ursprüngl. Mitteilung --- Von: Jonathan Mayer Gesend.: 09-07-2012, 03:58  An: Matthias Schunter Cc: public-tracking@w3.org Betreff: Re: ACTION-202 Alternative to explicit/explicit API  
 
As we've discussed in several threads now, there are a number of compelling use cases for explicit-explicit exceptions.  The motivations for those use cases go far beyond transparency, and include first-party  competition, third-party competition, and regulatory compliance. 

  
The objections to explicit-explicit exceptions have largely rested on implementation and user experience concerns.  I believe my prototype demonstrates that those challenges are surmountable.  If objections  persist, I'm listening. 

  
Jonathan 

  

 
On Saturday, July 7, 2012 at 6:01 AM, Matthias Schunter wrote:   
 
 
Hi Jonathan, 

  

  
the goal of publishing at the third parties at the well-known URI is to 
make them discoverable. 

  
AFAIK, having explicit/explicit in the Javascript API means that a user 
agent will only 'see' the third parties once the server has called this 
function. I believe that this is a benefit for transparency. 

  
If nobody likes snapshotting the list, I agree that we should omit it to 
reduce user agent complexity. In this case, the list of third parties 
would be informational and we would require that the third parties 
currently in use are a subset of the published list. 

  
Actually, after some considerations, I would prefer such an simplified 
design where user agents would be free in how they use this information: 
Some user agents may still issue warnings like 'the list has changed 
since you have last OKed it'; however, we do not mandate how the list is 
used by user agents. 

  

  
Regards, 
matthias 

  

  

  

  

  
On 23/05/2012 06:21, Jonathan Mayer wrote:
  
 
Could you explain how this approach might be preferable to the 
explicit-explicit API we've been discussing? The "snapshot" mechanism 
seems non-intuitive, more difficult for browsers and websites to 
properly implement, and quite limiting. Moreover, it doesn't 
ameliorate the concerns that Ian and others have raised, which in 
their view arise from the very existence of explicit-explicit 
exceptions. (I've noted a number of times that I believe they're 
completely wrong.) 

  
Jonathan 

  
On Tuesday, May 22, 2012 at 3:06 PM, Matthias Schunter wrote: 

 
  
 
Hi Folks, 

  
as promised, I enclosed and outline how to resolve the issue of 
explicit/explicit exceptions. 
The goal is to allow for transparency (what third parties are used) and 
control (what third parties did I consent to) while simplifying the 
approach. 

  
Comments/feedback is welcome! 

  
Regards, 
matthias 
------------------------8<---------- Outline explicit/explicit approach 
V01 -------------- 
1. JAVASCRIPT API: We only allow site-wide and web-wide exceptions. 
I.e., a server mysite can ask for exceptions for all its third parties 
or ask for an exception for itself (as third party) on all 1st party 
sites. 

  
2. Well-known URL: OPTIONAL List of direct third parties (maybe also any 
and/or responsibilities) [Empty means that no specifics are promised] If 
a site decides to post a list, then they bind themselves to the list. 
Subsequent enlargements to the list requires calling the javascript API 
again. 

  
3. Semantics: What does this mean? 
a) When a server asks for a site-wide exception and has posted a 
list of third parties, then at least these third parties must 
receive DNT;0 from this point on. This means that a user may 
snapshot the parties at the time of the API call. 
b) When a server asks for a site-wide exception and has not posted a 
list of third parties, then no promises are made 
and DNT;0 will be sent to all third parties on this site. 

  
4. Telling the server what exceptions are stored on the client 
a) If the client has no site-wide exception for this site, then it 
sends DNT;1 
b) If the client has a site-wide exception for a site, then it sends 
DNT;0 to the site and its third parties 
c) I suggest not to include a case for finding out whether the URL 
promise is still unchanged. 
If a site expands the list of third parties, it may require 
polling via the Javascript API

Received on Monday, 9 July 2012 07:36:17 UTC