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

Nick,

I believe there is an open question on whether a DNT:2 signal is even needed when reviewed against the use of "*" with site-specific exceptions and if DNT:0 always means an exception has been granted.  I believe the answer to both is "yes" and if this is true, then I believe we're beyond this question (several open questions remain from that chain and discussion at last week's meeting).

That said, it appears along several pathways we're disadvantaging Good Actors in the name of defending against Bad Actors (disallow server-side queries for fear of another digital fingerprinting data element, "giving guidance that cookies and exception lists should be cleared at the same time to avoid evercookies").  It's a difficult sell (in my opinion) to tell web site publishers and 3rd parties to implement a standard that goes out of its way to remove their options due to protections aimed at parties that will never implement the standard.  How do we re-balance the equation to give Good Actors more options even with the knowledge that Bad Actors may use these same tools for what they are already aiming at doing - bad things?

- Shane

-----Original Message-----
From: Nicholas Doty [mailto:npdoty@w3.org] 
Sent: Sunday, March 18, 2012 7:03 PM
To: Shane Wiley
Cc: Roy T. Fielding; Tracking Protection Working Group WG
Subject: 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 03:43:15 UTC