- From: Vincent Toubiana <v.toubiana@free.fr>
- Date: Tue, 08 May 2012 13:26:00 +0200
- To: ifette@google.com
- CC: "public-tracking@w3.org Group WG" <public-tracking@w3.org>, Jonathan Mayer <jmayer@stanford.edu>, Kevin Smith <kevsmith@adobe.com>, Nicholas Doty <npdoty@w3.org>, Rigo Wenning <rigo@w3.org>, Matthias Schunter <mts-std@schunter.org>, Shane Wiley <wileys@yahoo-inc.com>
- Message-ID: <4FA902C8.5080409@free.fr>
The issue remains the same for site-wide exceptions: the first party can not assume that the user granted the exception the first time he visits the website. I must be missing something here, because I don't see how the first party could serve content dependent of the exception status when the call is asynchronous. > > The whole point is that the first party might not want to serve > content independent of the exception status of the third parties. > > On May 7, 2012 6:52 PM, "Vincent Toubiana" <v.toubiana@free.fr > <mailto:v.toubiana@free.fr>> wrote: > > My response is inline >> The call is asynchronous, I don't think we would want to change >> that. What you propose seems like it would pause pageload until >> the user acts on the exception, I don't think you would find much >> support for making the API synchronous. > I'm not sure I follow you here. I don't see how this is different > than for site-wide exceptions: browser can load the page content > but may have to wait before loading content from third parties. If > the required exceptions were not granted the browser would leave > the page. > I'd expect the same behavior for site-wide exceptions. >> >> It also doesn't solve the problem as best I can tell of knowing >> _at the time you receive the original request_ whether you have >> all the exceptions you need. By moving this to javascript, you're >> adding a necessary round-trip back to the server to say "Yup, we >> have our exceptions, send the content." Please see my earlier >> emails, it's not just the issue of UI complexity, it's also a >> site knowing at the time it receives a request whether or not >> it's covered. This is trivial with * and nontrivial otherwise. > > I believe this would solve the problem for the first visit to the > first party (you're assured to have all the required exceptions). > It may leave the issue open for the next visit but using first > party cookies might solve the problem then. > >> >> >> In that case, the checkbox corresponding to such third party >> would be disabled. If a user does not want to grant that >> exception he can click on “cancel” to be redirected to >> another page (i.e. a paywall). Thus a first party can make >> sure that all the required third parties are granted an >> exception before delivering content.Once exceptions have been >> granted, this should not cause any additional delay. >> >> Vincent >> >> >> >> On 5/4/2012 6:35 PM, Ian Fette (イアンフェッティ) wrote: >>> On Fri, May 4, 2012 at 12:30 AM, Rigo Wenning <rigo@w3.org >>> <mailto:rigo@w3.org>> wrote: >>> >>> Shane, >>> >>> lets imagine a site A uses services of P1, P2 and P3. My >>> browser hits the >>> site A and realizes that it has a web - wide exception >>> DNT;0 for P3. It >>> sends DNT;0 in GET requests to P3. This is what You have >>> been pursuing since >>> quite a while now. Correct me, if the above is wrong. >>> >>> Nick and Tom present a javascript API allowing my >>> browser to discover that >>> site A is using services P1,P2 and P3. The API would >>> allow the browser to >>> get an exception from the user for either P1,P2 or P3. >>> >>> Ian and You tell me that we can not distinguish between >>> P1,P2 and P3 because >>> it is too burdensome. >>> >>> >>> >>> I think you are misunderstanding. The complexity comes from >>> having to allow a given first party request à la carte third >>> party exceptions on its first party site. The browser is >>> capable of recognizing that a given third party has a >>> web-wide exception and sending that third party DNT:0 and >>> realizing that other third parties do not have a web-wide >>> exception and sending them DNT:1. That is not the complex >>> part. The complex part is >>> >>> a) having a UI that would allow for this à la carte granting >>> of exceptions >>> b) having a management UI that allows users to change >>> their à la carte selections later >>> c) a first-party figuring out whether all the third parties >>> it cares about are covered by an exception. >>> >>> I really don't think that in the common case a first party >>> will care at all about whether third parties have a web-wide >>> exception. In my mind, how this would work is that the first >>> party site will care primarily about revenue generating >>> third parties (e.g. ads) which are not likely to have a >>> web-wide exception from users... >>> >>> Now let's come back to that cake. Either you can have >>> a web-wide exception and distinguish between P1,P2 and >>> P3. In this case you >>> would also distinguish between P1,P2 and P3 in the >>> javascript API. Or you >>> can't have a web-wide exception as it is too burdensome >>> to distinguish >>> between P1,P2 and P3. In this case, the javascript API >>> will only recognize >>> "*" as "all the third parties of site A. But it looks >>> surprising to defend >>> that in one situation the browser can distinguish >>> parties and in the other >>> it can't. Which brings us back to the cake. >>> >>> In the meantime, having "*" as the only possible >>> expression damages the >>> consent mechanism. While in the common-law context, >>> rather unclear and open >>> terms by parties are accepted for "agreements" and while >>> it is accepted to >>> figure out later what the content of the agreement >>> actually is, this is not >>> allowed in most other legal systems. This is why all the >>> software bags that >>> are so nicely decorated with 3point font artwork do not >>> have any legal >>> meaning in e.g. french or german law. Because all the >>> nice clauses have no >>> "object". It has no object because the content of the >>> agreement can't be >>> determined at agreement time. Legal spoken, "*" is a >>> blank check to the site >>> A. The user hitting site A has "*", but no information. >>> Even if -in >>> extremis- we would assume a consent, such a consent >>> would not be "informed" >>> as "*" has a non discoverable meaning. Because only site >>> A knows what "*" >>> means. The user can't know. And the user can't consent >>> to things she doesn't >>> know. >>> >>> Consequently, avoiding explicit/explicit gives 3rd >>> parties some bundling- >>> gains at the edge but introduces a logic break and >>> damages the consent >>> mechanism. The latter has IMHO a much higher value than >>> the little bundling >>> gains as it allows to communicate with the user to get >>> an exception. >>> >>> Best, >>> >>> Rigo >>> >>> >>> >>> On Thursday 03 May 2012 13:27:17 Shane Wiley wrote: >>> > Rigo, >>> > >>> > Disagree on granularity. If I say "the 3rd parties I >>> work with = '*' " >>> > then it is defined and consent has been reached. >>> > >>> > - Shane >>> > >>> > -----Original Message----- >>> > From: Rigo Wenning [mailto:rigo@w3.org >>> <mailto:rigo@w3.org>] >>> > Sent: Thursday, May 03, 2012 1:26 PM >>> > To: Shane Wiley >>> > Cc: Kevin Smith; Matthias Schunter; Jonathan Mayer; >>> ifette@google.com <mailto:ifette@google.com>; >>> > Nicholas Doty; public-tracking@w3.org >>> <mailto:public-tracking@w3.org> Subject: Re: >>> explicit-explicit >>> > exception pairs >>> > >>> > Shane, >>> > >>> > I'm surprised to hear that from you because in order >>> to get a web-wide or >>> > even a site-wide exception, you need this granularity >>> anyway. I also not >>> > that a consent mechanism could not work that way as >>> the object of the >>> > consent would be open ended and thus undefined. If you >>> only say * and >>> > don't tell what it means, there can't be any consent >>> or agreement. >>> > >>> > Best, >>> > >>> > Rigo >>> > >>> > On Thursday 03 May 2012 10:44:34 Shane Wiley wrote: >>> > > I know we're not supposed to add "+1" but I do want >>> to pile on a bit >>> > > here >>> > > to support Kevin and Ian in that I can't see the >>> value in overloading >>> > > the >>> > > standard to add such a high-level of complexity to >>> meet a very small >>> > > percentage of likely use cases. >>> > > >>> > > From a web browser vendor perspective, this is going >>> to become fairly >>> > > complex quickly and will likely deter all but the >>> most advanced users >>> > > attempting to manage preferences at this level of >>> granularity. Those >>> > > very same users are probably savvy enough to simply >>> reset or block 3rd >>> > > party cookies already -- AND/OR -- go into "Privacy >>> Mode" in their >>> > > browser -- AND/OR -- leverage 3rd party tools that >>> already solve much >>> > > (all?) that is attempting to be solved here. >>> > > >>> > > From a publisher perspective, attempting to support >>> a static list of >>> > > known 3rd parties is going to be significantly >>> difficult to impossible. >>> > > And the rate of change will require continuous >>> repermissioning of >>> > > users to gain a "user granted exception". I >>> understand there are a >>> > > very small sub-set of publishers that could find >>> value in the >>> > > origin/origin approach, but appears this weight >>> comes to bear on larger >>> > > publishers to some degree -- all depending on how >>> the UA UI is built >>> > > (which as we've already discussed is going to be >>> fairly complex). >>> > > >>> > > - Shane >>> >>> >> >> >
Received on Tuesday, 8 May 2012 11:26:38 UTC