Re: Goals and Procedures

> On Feb 7, 2017, at 4:47 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> I agree we should not fundamentally redesign stuff, unless we have to. 
> 
> So we should leave cookie based DNT:0 unless we are told that no way will the browsers support the API. Similarly  I will keep my qualified web-wide proposal away from the list for now.
> 
> But I would like to carry on discussing how site-specific consent can be implemented because it will come up later.
> 
> To reiterate:
> 
> If sitespecific.com is granted a site-specific exception for some or all of its embedded subresources, say one is widget.com, then DNT:0 is sent in future requests to them (but only when they are referred to by example.com). Similarly if the exception has not been given, DNT:1 is sent in requests, so that is all good.
> 
> The problem arises when widget.com receives DNT:0. Because it cannot tell the difference between site-specific and web-wide consent it could place a UID cookie (or use one already there). This means if the user goes to another site which refers  to widget.com the user identifying UID is sent in the request to it, even though DNT will be 1 in this case.

That is NOT a problem. widget.com can know in a myriad ways who the user is. But if it gets a DNT:1 and promises to respect it, it can’t *record* data about that transaction. It *can* act on data it was allowed to record.

So, there is no contradiction here.

> 
> What does widget.com do then? It should ignore the UID

No, it can act in the moment on that data it was allowed to record.  DNT:1 does NOT mean “please ignore you what you know about me”, it means “please don’t track this transaction, i.e. add to what you know about me”.

> , i.e. follow "operational and administrative procedures" to deal with the fact that DNT is 1.

and do what DNT:1 means: don’t track this transaction.

> 
> It cannot just erase the cookie because there might be a site-specific grant elsewhere (in fact there is, for sitespecific.com).

Why should it erase the cookie? It was allowed to remember that data. Another later transaction that it was not allowed to record does not negate the prior permission for the prior transaction.

> 
> If we want a system that is externally verifiable then having to rely on O&A procedures is not good. More to the point users are unlikely to trust it.

Now you have lost me.  The whole thrust of DNT is trust-based: we trust that you won’t ‘track’ (record in some way, possibly in a database I never see).

> 
> Shane and Aleecia suggested the confirmSiteSpecificTrackingException call could be used by code in widget.com to detect site-specific consent, but using it for this purpose has not been defined in the TPE text.  This describes it as being called by code in the top-level browsing context of the origin that requested the grant, not in the browsing context of the subresource that is a target of the grant.
> 
> We could change the text to say the function has this double meaning, but that still does not cover subresources that do not return HTML (like an image, CSS etc.)
> 
> We may not have to go the whole hog (as my proposal does) in implementing site-specific identifiers, but we should make it possible for developers (say of libraries that do not rely on O&A procedures)  to implement them themselves. 

I still do not see a problem to solve here.

> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
> Sent: 07 February 2017 08:36
> To: public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
> Subject: Goals and Procedures
> 
> Hi Folks,
> 
> 
> thanks a lot for the productive discussion during yesterday's call.
> It is nice to actually start closing issues and progress towards our
> goal of a stable final draft.
> 
> What I realized (since time is short) is that we should constrain
> ourselves on a minimal spec that is good enough.
> 
> What this means:
> - We should focus on helping EU compliance
> - We should improve implementability
> - We should try to abstain from fundamental redesigns and
>  substantial new features.
> 
> What does this mean for the group?
> 
> I suggest we focus only on substantial concerns backed by evidence. This
> means that we should focus on issues that:
> - Substantially simplify or improve implementation.
>  Evidence could be implementation experiences/reports.
>  (e.g. Mike stating that it is useful for a site to receive a call-back
>        is in this category).
> - Substantially help EU enterprises to manage opt-in for compliance
>  Evidence could be enterprise/site feedback or regulator requirements.
>  (e.g. Rob saying that the Javascript exception API is
>   essential for managing opt-in and should be kept is in
>   this category).
> - Are required by W3C to reach recommendation state
> 
> As indicated, the goal is to deliver  a "good enough" TPE in time and
> ideally simple enough to be widely implemented. Ideally, I would hope
> that no other changes are required at this point.
> 
> Does everyone agree with this procedure? Any feeback or objections?
> 
> 
> 
> Regards,
> matthias
> 
> 
> 

Dave Singer

singer@mac.com

Received on Tuesday, 7 February 2017 17:59:26 UTC