Re: ACTION-202 Alternative to explicit/explicit API

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 Saturday, 7 July 2012 13:47:08 UTC