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

This discussion of servers that cannot gauge consent in real time has (inadvertently?) been taking place on the editors' list for some time.  Some other messages may have been lost as well; Roy, David, Nick, feel free to forward your responses as well.

Reading from the bottom may help . . .

Begin forwarded message:

> From: Ronan Heffernan <ronansan@gmail.com>
> Subject: Re: Moving "C"onsent from Tracking Status to Permitted Use?
> Date: April 15, 2013 7:52:49 PM EDT
> To: Justin Brookman <jbrookman@cdt.org>
> Cc: Matthias Schunter <mts@schunter.org>, team-tracking-editors <team-tracking-editors@w3.org>
> 
> The discussion so far has been that the user could choose to visit the control link, at which point the user could be informed that they need to allow a 72-hour expiring cookie if they want to come back and get a meaningful response.
> 
> As to not shaping the user experience, I agree that the data should not be allowed to be used (except for the security, fraud, and operation uses), so of course the data could not be used to target ads or otherwise shape the user experience while it is siloed, waiting for OOBC determination.
> 
> I also agree that if a server signals that it has to check for OOBC, that that is a clear indication that the server does follow DNT.  I don't have a problem with requiring real-time response for conditions for which that is possible, such as not honoring requests from non-compliant UAs. 
> 
> I am fine with the discussion continuing on the main list.
> 
> --ronan
> 
> 
> 
> On Mon, Apr 15, 2013 at 6:06 PM, Justin Brookman <jbrookman@cdt.org> wrote:
> Could you explain how this delayed response would work?  Non-consenting users aren't authenticated to most third parties, so how would the response eventually be delivered?  Where would the third-party reach me or my user agent?  Would UAs have to be configured to revisit every server that responds "C" 36 hours later to get a definitive determination, and have that site check against a unique cookie?  What if cookies aren't enabled?
> 
> Even assuming this is possible and necessary, I think this proposal needs (at least) two additional changes to be worthy of consideration.
> 
> (1) The third-party taking advantage of this delayed notification gambit cannot be personalizing the user experience.  Presumably this is not controversial, since the party wouldn't know whether it has consent or not in real time to deliver targeted ads or content.
> 
> (2)  The third-party cannot reject particular DNT:1 signals unless that communication is made in real time.  It should not be possible to signal C and then say 36 hours later, "no wait, I didn't have consent, but I don't respect this particular user agent."  Presumably servers that cannot assess consent in real time could however be configured to reject particular UAs however . . .
> 
> (Like Nick, whose response I just read, I'm fine with this being shared with the general group, and think the discussion should migrate there.)
> 
> On Apr 15, 2013, at 3:27 PM, Matthias Schunter <mts@schunter.org> wrote:
> 
> > Hi David,
> >
> >
> > I agree that a immediate and definively correct response would be optimal.
> >
> > The background on a non-zero delay is that enterprises often use database synchronisation for such web-facing sites (e.g., nightly sync of the web-facing mysql with the internal oracle DB). This has a consequence, that the mysql data is not always accurate.
> >
> > 1.  If a user retrieves the "control" URI, he usually gets the right result
> > 2. If he recently changed things, he needs to wait for 24h to ensure that the correct result is displayed.
> >
> > If we keep the text vague like "the control link allows a user to invesigate out of band consent." then these technical implementation details would not affect our standard.
> >
> > Opinions?
> >
> > Regards,
> > matthias
> >
> >
> >
> > On 15/04/2013 08:42, David Singer wrote:
> >> On Apr 11, 2013, at 15:13 , Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
> >>
> >>> Hi Ronan,
> >>>
> >>>
> >>> thanks for the interesting discussion on out-of-band consent.
> >>>
> >>> Could you try to convert our discussions into proposed text changes and proposed additions for the TPE spec?
> >>>
> >>> Items we IMHO seem to converge on:
> >>> - Data can be retained for a while (say 24h) and cleansed based on the out of band consent collected
> >>> - Out of band consent is signaled with the "C" (data processed under out of band consent)
> >>> - If "C" is signaled to the user, then the user can retrieve whether out-of-band consent has been used within 36hours from the URL
> >> s/within 36hours/immediately/
> >>
> >> I can't see how 'come back in a day and a half' is any meaningful disclosure, or control.
> >>
> >> It's a hole the mis-behaved could (and would) drive a truck through.  How do I even identify the transaction 36 hours later?
> >>
> >> David Singer
> >> Multimedia and Software Standards, Apple Inc.
> >>
> >>
> >
> >
> 
> 
>