Re: ACTION-202 Alternative to explicit/explicit API

Matthias,

I'm not quite sure what you mean by "[t]he proposal that seemed to emerge as acceptable from all sides."  You first made this suggestion some months ago.  Participants objected.  You made the suggestion again in Bellevue.  Participants objected again.

Jonathan


On Monday, July 9, 2012 at 9:08 AM, David Singer wrote:

>  
> On Jul 9, 2012, at 0:35 , Matthias Schunter (IBM) wrote:
>  
> > 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.
>  
> but that's an independent question.
>  
> > 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.  
>  
> Moving the list from being a parameter to being at the WKU doesn't change the model at all; it just makes the API less obvious. I don't see any advantage.
>  
> > 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.  
> >  
>  
>  
> Obviously, since I wrote it, I don't think the TPE spec. presents a convoluted design at all, and is quite clear about how it works. If there are aspects that are not clear, I am happy to try to address them.
>  
> >  
> >  
> > Regards,  
> > Matthias  
> >  
> > --- Ursprüngl. Mitteilung --- Von: Jonathan Mayer Gesend.: 09-07-2012, 03:58 An: Matthias Schunter Cc: public-tracking@w3.org (mailto: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
> >  
>  
>  
> David Singer
> Multimedia and Software Standards, Apple Inc.
>  
>