Re: explicit-explicit exception pairs

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.

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