RE: ACTION-98: Bring input on ISSUE-111 to the group

Nick,

Now you have me even more confused (but that's easy to do :-).

If a publisher is granted a site-wide exception ("*") then I would expect that publisher would also receive DNT:0.  If they receive DNT:1, then will believe an exception was not granted and prompt the user to provide one.  This appears to be very circular.  Your argument appears to force the need for something like DNT:2.

And while I understand the finger-printing concerns, I don't believe we should limit publisher options by forcing the use of cookies and then syncing their purging with exceptions.  As user purge cookies at a heavy clip, this will mean a never ending situation for users continually need to re-provide exceptions to publishers - not a great outcome for publishers or users - all in the name of stopping Bad Actors.  I believe the perspective is backwards here.

- Shane 

-----Original Message-----
From: Nicholas Doty [mailto:npdoty@w3.org] 
Sent: Sunday, March 18, 2012 10:32 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

Hi Shane,

On Mar 18, 2012, at 8:42 PM, Shane Wiley wrote:

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

Great, I didn't realize that was our conclusion on the last call, but I'm all for dropping DNT:2 in that case. As I understand it, DNT:0 would be sent to each third party once a "*" request had been granted (and would always signify that an exception was granted), but that the first party site would still receive DNT:1 ('don't share data about this request with arbitrary third parties').

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

In this example, clearing stored exceptions and cookies at the same time is beneficial to the publisher as it means that a stored cookie doesn't get out of sync with the exception list.

In general, I think it's beneficial to everyone (except bad actors) to decrease the potential for malicious fingerprinting, or rather, not to increase fingerprintability with this standard. We can increase user confidence in the privacy of their online activity and decrease the call for blocking technologies - both of which I think would be welcomed by publishers and advertisers. 

For us, it can improve adoption - it would be unfortunate if advocates told their users not to use browsers with Do Not Track because it enabled trivial fingerprintability. And it won't make our jobs harder when we try to get future Web standards to decrease fingerprinting risk; I'll have much more trouble making that case if it's pointed out that even in a standard focused on privacy we wouldn't guard against fingerprinting.

In any case, I'm all for giving implementers flexibility and options (hence my suggestion of use of cookies below); maybe these justifications can help you in selling the idea to publishers and advertisers.

Thanks,
Nick

> -----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 05:39:05 UTC