W3C home > Mailing lists > Public > public-tracking@w3.org > May 2012

Re: explicit-explicit exception pairs

From: Vincent Toubiana <v.toubiana@free.fr>
Date: Tue, 08 May 2012 13:26:00 +0200
Message-ID: <4FA902C8.5080409@free.fr>
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>
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

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:28 UTC