Re: explicit-explicit exception pairs

On Mon, May 7, 2012 at 3:56 PM, Vincent Toubiana <v.toubiana@free.fr> wrote:

>  Ian,****
>
> To answer a) and b), I believe that explicit/explicit UI should not be an
> issue at this stage. I can imagine at least two UI that could be used to
> manage these exceptions:****
>
> -          A list based UI where all the first parties are listed, when a
> user click on a first element he sees the exceptions granted on this site.
> He can check/uncheck a box to grant or deny an exception.****
>
> -          A collusion based UI where exceptions are represented by edges
> between parties. Clicking on an edge grant/remove an exception.
>


As I have said earlier, those UIs don't necessarily scale, and are
sufficiently complex that we would not implement them. I apologize, but I
do feel like I am starting to repeat myself.

> ****
>
> I believe both interfaces could be used to add and manage exceptions.****
>
> ****Regarding c), maybe we could add another optional parameter to a
> “requestSiteSpecificTrackingException” which would be a Boolean called
> “requiredException”. If this value were true, then the user would have to
> grant the exception to the third party to visit the website.
>


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.

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.




> 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
>>
>
>
>