Re: TPE sec 6.11 on clearing granted exceptions

I think this is a good discussion, maybe formally or maybe over coffee, for the f2f.

Site-exceptions are rather different from cookies -- they cause something to be sent to someone else (3rd parties get a DNT:0).

Web-wide exceptions are just like cookies now, as far as I can tell.  Is there any functional difference at all?


On Apr 27, 2013, at 12:03 , Roy T. Fielding <fielding@gbiv.com> wrote:

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

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Monday, 29 April 2013 18:41:46 UTC