RE: ePrivacy & DNT

I think on balance it would be more of an enabler of functionality than a stopper. Privacy related APIs constraints like WebRTC mode switching, Firefox & Safari style third-party cookie and local storage blocking, referrer header restrictions etc. are often configured for the whole web rather than specific origins because the UI would be too complex. Having a consent signal a la DNT:0 allows permissions to be automatically assumed for an origin without having to invent new UI. It also avoids regulatory action by motivating web applications to respect the user's preferences e.g. by declaring a TSR, asking for consent and using the API.

-----Original Message-----
From: David Singer [mailto:singer@mac.com] 
Sent: 20 December 2016 17:42
To: Mike O'Neill <michael.oneill@baycloud.com>
Cc: Walter van Holst <walter@vanholst.com>; public-tracking@w3.org
Subject: Re: ePrivacy & DNT

Hi Mike

expanding “non-tracking mode” to include not only DNT but other actions is a possibility, of course.

But the thesis (yet to to proven) was that DNT was a “co-operative” measure, not a unilateral one; that instead of being in an arms race of blocking/counter-blocking, we could work out a middle ground where we all agreed.  Maybe this was Pollyanna thinking.


> On Dec 20, 2016, at 1:39 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> One thing to consider is who a compliance spec is directed at. Of course there should be requirements on server (i.e. web application) implementations but the "elephant in the room" is how user agents should react to DNT. It is not only a signal to applications, browsers can react to it also, as they must do for a host of other signals, e.g. cache headers. 
> 
> We have assumed a passive role for user agents in delivering and configuring DNT but assumed only servers would act on it, which partly led to the separation of the TCS from the TPE.
> 
> But why not ask user agents to have  a role in enforcing user consent by implementing different actions according to the value of the DNT header?
> 
> I know from building and using bouncer that just foreshortening the life of cookies when DNT is set stops most tracking. There would still have to obligations on servers not to retain IP addresses (except solely to avoid DDNS attacks etc.) or do fingerprinting, but the vast majority of tracking in the wild uses long persistence UID cookies.
> 
> Both the GDPR and the new (leaked) ePrivacy regulation refer specifically to Privacy by Design and default settings, see A.25 of GDPR and more directly A.10 of ePrivacy. A.10 suggests default blocking of "third-party" cookies but this immediately gets us into the first-party cookie rat hole (think Google Analytics). 
> 
> The trouble with blocking cookies is that it is hard to enforce without killing the web, but restricting cookie durations for origins where DNT:1 while not for DNT:0  (as long as the DNT API is available) works fine. We could say this in the TPE, then maybe there is no need for a separate TCS because ePrivacy/GDPR already spells out the other obligations.
> 
> Mike
> 
> 
> -----Original Message-----
> From: Walter van Holst [mailto:walter@vanholst.com] 
> Sent: 20 December 2016 06:12
> To: public-tracking@w3.org
> Subject: Re: ePrivacy & DNT
> 
> On 2016-12-20 01:11, David Singer wrote:
> 
>> it does seem that what you wrote is, in some sense, a compliance spec.
>> (albeit in draft state). Perhaps the EU could write a spec. and assign
>> it a URL, so that sites can say “I respect DNT when interpreted as the
>> EU does”?
> 
> And it is so much easier to push for such a thing with for example WP29 
> or the Commission if we have a TPE that is at least at recommendation 
> stage. And the issues I have raised are there because I have tried to 
> re-read the TPE from a hypothetical EU compliance spec writer's 
> perspective.
> 
> Regards,
> 
>  Walter
> 
> 
> 

Dave Singer

singer@mac.com

Received on Tuesday, 20 December 2016 18:19:56 UTC