- From: Vincent Toubiana <v.toubiana@free.fr>
- Date: Tue, 08 May 2012 22:01:56 +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: <4FA97BB4.4040901@free.fr>
So the only difference I see between the two proposals is for subsequent visits when third parties have been added and new exceptions are required. I'd suggest to use cookies to call the JS when third parties have been added. For instance, the first party could set in one cookie value the timestamp of the latest addition of a "required" third party. Hence, if no third party has been added, the first party does not have to add new exceptions and the JS is not called. Vincent > If we have a mechanism that allows (and only allows) site wide > exceptions, it's trivial to indicate the presence or absence of such > an exception in the request header. > > So, on the first visit to the website, the site would receive an > indication in the header that it does not have a site-wide exception > (DNT:1). As such, rather than serving content, it can decide to serve > something to the user explaining a request for an exception. > > On subsequent visits, the site would receive in the header an > indication that it does have a site-wide exception (DNT:0 or some > other indication in the header, exact details less important) and it > could thus know all its third parties are covered and serve content. > > If you're calling the JS API on every pageload, you're doing it wrong :) > > On Tue, May 8, 2012 at 4:26 AM, Vincent Toubiana <v.toubiana@free.fr > <mailto:v.toubiana@free.fr>> wrote: > > 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 20:02:33 UTC