Re: ACTION-98: Bring input on ISSUE-111 to the group; otherwise it's closed

Hi Shane,

(Following up on an older thread, though it still seems relevant to our current questions on this topic.)

On Mar 7, 2012, at 4:40 AM, Shane Wiley wrote:
> Exception Use Case:
> -  If DNT:2, publisher will know they were provided a previous site-specific exception for some or all of their 3rd parties (in this use case, this publisher always requests exceptions for ALL of its current 3rd parties)
> -  Taking on the risk of the user possibly manually editing their site-specific exceptions for said publisher, the publisher can now proceed with treating the user the same as DNT:0 but may decide to also poll for the site-specific exceptions again to confirm any "new" 3rd parties they support have been added to the exceptions list.
> -  Like most publishers, we don't add 3rd parties very often (a few per quarter at most, and we're removing just as many typically at the same time) so the decision to re-poll will be rare and would be beneficial to occur from the server side (understood that this causes a slight delay in serving the page but will again be rare so hopefully not as noticeable to a user)
> -  If after polling it becomes clear a number of 3rd parties require site-specific exceptions, the user can be redirected (server-side) to the site-specific exceptions experience 

I think I understand the use case here. A publisher wants to make a decision about what kind of experience to give the user based on their past response to a request for tracking exceptions for particular parties. As you note, you'd be willing to make an assumption based on that past request even though the user might have manually (or automatically) changed their exception preferences since then. In particular, for your implementation you want to make this determination on the server side, though I think Roy is suggesting that in some ways this might be faster on the client-side.

My suggestion, which I've mentioned in passing but I thought was worth writing out, is that publishers could use HTTP cookies for this purpose. If you request on the client-side a list of exceptions and the user grants them, you could set some generic cookie via JavaScript like trackingrequests=granted and then that cookie would by default be sent on future requests to your site. Publishers could customize this solution to their particular needs -- maybe one publisher really wants to separately remember whether social widgets were granted an exception or whether an advertising block was and could use separate cookies for those.

These cookies could of course be cleared, or they could be retained even when the tracking exception is persisted, although we're giving guidance that cookies and exception lists should be cleared at the same time to avoid evercookies.

Do you think this would work for your use case? This allows server-side access, customization for different publishers and uses the existing cookie mechanism rather than additional DNT header values.

Thanks,
Nick

Received on Monday, 19 March 2012 02:03:35 UTC