RE: Moving "C"onsent from Tracking Status to Permitted Use?

> OOB response headers might not be good enough, except for the first time, because it is not as transparent or as simply revocable.

I think we should look at how we resolve that issue versus relying on an API, which may or may not be there.

JC

-----Original Message-----
From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
Sent: Thursday, March 28, 2013 6:41 AM
To: 'Matthias Schunter (Intel Corporation)'; public-tracking@w3.org
Subject: RE: Moving "C"onsent from Tracking Status to Permitted Use?

I think this also solves Adrian's use case, as far as I understand it,  of establishing consent across devices, i.e. by a user clicking a link in an email.

If the server can recognise it has OOB consent for this user (using a cookie probably or a unique URI ) then it can convert it in-band as soon as it can.
i.e. by calling the API if the response is HTML or encouraging the user to go the domain as a 1st party. There will need to be a way to get round third-party default blocking (which is becoming the norm) and the consent API is the best way to do that. OOB response headers might not be good enough, except for the first time, because it is not as transparent or as simply revocable.

There should be non-normative text recommending this so OOB consent is positioned as a transitory mechanism rather than a replacement for the API.

Mike


-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
Sent: 28 March 2013 11:48
To: public-tracking@w3.org<mailto:public-tracking@w3.org> (public-tracking@w3.org<mailto:public-tracking@w3.org>)
Subject: Moving "C"onsent from Tracking Status to Permitted Use?

Hi Team,


I discussed our approach to consent (in-band and out of band) with Rigo.

We observed that the fact that you have consent is orthogonal to the overall tracking status.
As a consequence, we believe that "C"onsent should be signaled as a qualifier (similar to a permitted use).

If we introduce this change, the scenario/flow for in-band exceptions would not change:
    1. - The site has an exception and has therefore received DNT;0 from the browser
    2. - The site responds with "1" or  "3" to indicate that they comply with DNT

However, the flow for out-of-band exception would get clearer:

OLD:
    1. - The site receives DNT;1
    2. - The site (somehow) reliably determines _in real time_ that it has out of band consent
    3. - The site responds with "C" thus indicating that it has out of band consent
          and provides a control link.

NEW:
    1. - The site receives DNT;1
    2. - The site (somehow) reliably determines _in real time_ that it has out of band consent
    3. - The site responds with "3C" thus indicating that
             - It acts as a 3rd party
             - It will use the data in ways that are beyond the usages permitted by DNT;1 since
               it has obtained out of band consent. A  control link is still required.

I think that modeling out of band consent as a permitted us is cleaner than the current approach that models it as a special tracking status.

Note: This discussion is orthogonal to the discussion what to do if the site cannot determine the consent in real time.


Opinions/Feedback?


Regards,
matthias