Re: TPE sec 6.11 on clearing granted exceptions

On Apr 26, 2013, at 5:25 PM, Nicholas Doty wrote:

> (Might not have responded to these points before when the thread title was changed.)
> 
> On Apr 26, 2013, at 1:31 AM, "Roy T. Fielding" <fielding@gbiv.com> wrote:
> 
>> On Apr 25, 2013, at 4:40 PM, Nicholas Doty wrote:
>> 
>>> I think in-band user-granted exceptions have at least two advantages over use of cookies in storing exception consent:
>>> * DNT:0 can be sent even when there is no cookie or cookies are not sent
>> If a
>> user agent is not sending any cookies, sending DNT:0 is not going
>> to help much.
> 
> We had a specific request (last June in Seattle) from companies like Google that it would be useful to receive DNT:0 even in contexts (like a Safari user loading a doubleclick ad) where cookies wouldn't be sent by the browser's cookie policy. It might be that services would use tracking based on other mechanisms (fingerprinting, say) in those situations, or that they would respond with a Set-Cookie header and certain browser implementations would store the header when it was in response to a request with DNT:0.

The browser's cookie policy is an algorithm in the browser.
Which is easier:  Implementing a small adjustment to that algorithm
to allow the set and send of a specific cookie name with a limited
value set, or implementing an entirely new storage mechanism with
APIs for access and separate lookups per domain?

The fact that the exception is signaled via a Cookie does not in any
way limit how managing that cookie might be implemented within new
browsers.  It only impacts how it is processed by browsers that have
not implemented any special handling. From a protocol perspective,
it doesn't matter where we send the exception signal because the
server will know where to look for it.

I feel a need to reiterate this point: We already implement the cookie
mechanism using nonstandard names.  We need to in order to support
consent from existing browsers.  We will need to continue to do so
until all deployed browsers are updated to some newer mechanism.
If we have to implement two mechanisms for managing consent, which
seems unlikely given the pushback for even one of them, that means
both will be set and sent from browsers on every request.

>>> I think perhaps the SHOULD text is a little too specific; browsers are taking different approaches to clearing client-side state and while I think there probably always should be an option to clear all client-side state simultaneously, there will also very likely be implementations that clear cookies or other caches separately. I think the general principle of clearing state set and then subsequently accessible by JavaScript is an important one, and worth noting in the spec.
>>> 
>>> That would be a third advantage for using in-band exceptions: exceptions may be retained when a user chooses to clear cookies but not other client-side state.
>>> 
>>> Thanks,
>>> Nick
>> 
>> I don't think I was clear.  Currently, the only advantage the UGE
>> framework has is that it doesn't get cleared when cookies get cleared.
>> If that isn't true, we should delete the entire framework and replace
>> it with a named cookie that is sent along with the DNT:1 signal.
>> Then we wouldn't have to wait until all browsers implement UGEs
>> and we wouldn't have to implement two different opt-in consent
>> mechanisms.
> 
> I believe there are other advantages beyond just persistence beyond cookies. (Users can configure their agents to control consent; users can manage all exceptions in a single place; first parties can make requests to change DNT communication to third parties without relying on non-standard means; third parties don't have to second guess signals.)

The first two are also true for standard cookie names.  The notion that
first parties can store a signal for third parties would be an advantage
of the UGE framework, if anyone implements it, but there are many reasons
to believe it won't be implemented at all (and is only being allowed in
the spec because we have no requirement on its implementation).

The notion that third parties would second-guess signals just doesn't
reflect reality. The third parties already get most of their information
from the link through which they are embedded in a page/auction, and
they will continue to do so until the UGE mechanism reaches almost
universal deployment (until failing to implement the cookie mechanism
would not impact site revenue).  They might second-guess a DNT:1
because it costs them revenue; they won't second-guess a cookie that
overrides the DNT:1 (or a signal directly from the first party that
they have already been granted consent for a given purpose) because
it gains them revenue.

....Roy

Received on Saturday, 27 April 2013 19:04:00 UTC