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