- From: David Singer <singer@apple.com>
- Date: Mon, 09 Jul 2012 09:05:34 -0700
- To: Jonathan Mayer <jmayer@stanford.edu>
- Cc: Matthias Schunter <mts-std@schunter.org>, "public-tracking@w3.org" <public-tracking@w3.org>
- Message-id: <2090B71D-C479-4AC4-B034-C427068766D6@apple.com>
On Jul 8, 2012, at 18:57 , Jonathan Mayer wrote: > 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. I agree. I think what is written in the TPE spec. is implementable, and desirable. I also think what Matthias writes below is flawed. > > 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.
Received on Monday, 9 July 2012 16:06:07 UTC