RE: Goals and Procedures

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.

What does widget.com do then? It should ignore the UID, i.e. follow "operational and administrative procedures" to deal with the fact that DNT is 1.

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

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.

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. 







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

Received on Tuesday, 7 February 2017 12:48:36 UTC