Re: ACTION-202 Alternative to explicit/explicit API

On May 23, 2012, at 6: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
> 

I agree;  the title of the email is mis-leading, in that this is simply a different way to establish explicit-explicit pairs - this proposal merely moves a parameter from the API to the well-known resource, which makes the API less clear, and the well-known resource becomes mandatory for anyone wanting explicit-explicit pairs.

> 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
> 

David Singer
Multimedia and Software Standards, Apple Inc.