Re: explicit-explicit exception pairs

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> 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> 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]
>>> > Sent: Thursday, May 03, 2012 1:26 PM
>>> > To: Shane Wiley
>>> > Cc: Kevin Smith; Matthias Schunter; Jonathan Mayer; ifette@google.com;
>>> > Nicholas Doty; 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
>>>
>>
>>
>>
>
>