Re: proposed TSV for potential consent

Matthias,
  I agree that non-real-time determination of OOBC is a standalone issue
that is not tied to those other issues.

--ronan


On Tuesday, April 23, 2013, Matthias Schunter (Intel Corporation) wrote:

> Hi Rob,
>
> thanks for the clarification.
>
> Note that we currently intermingle three independent discussions:
>  (a) The pixel that cannot talk Javascript
>       [This has been resolved by saying: The pixel has to collaborate with
> a page that has Javascript to get an in-band exception]
>       [For OOBC it does not need Javascript]
>
>  (b) OOBC that cannot be retrieved reliably in real-time (e.g., due to
> remote storage or database synchronisation)
>
>  (c) the permitted use of "short-term retention" (e.g., you can store
> everything for XX hours and after those XX hours, the compliance
> constraints on collection must be satisfied).
>
>
> While Nielsen indicates a desire to resolve all three issues, they are
> nevertheless independent from each other.
> I believe that we should focus on (b), which is the core of the OOBC
> concern.
>
> In its core, it does not affect collection but only notice/transparancy:
> The question is whether it is OK to tell a user
>   "I process your data based on the OOBC stored; visit [link] for details."
>  and [link] says
>   "According to our data, our databases currently indicates that we [do/do
> not] have OOBC from you.
>     If you changed your preferences recently, please come back in 36h to
> get an definitive answer".
>
> I do not see a problem with collection/use since data is never stored/used
> without sufficient consent
>
> The privacy concerns I see are:
> - The DNT response is not in real-time (an extra visit to [link] and some
> waiting may be required)
>
> What is your opinion on (b)?
>
> Regards,
> matthias
>
>
>
> On 23/04/2013 15:30, Rob van Eijk wrote:
>
> Hi Matthias,
>
>  btw: Pixels can talk DNT (request and response headers are included).
> They only cannot trigger the JS-based exception API.
>
> Got that, so let's call it partial DNT. Alex put this on the table in
> Washington and much of it relates to his proposal from back then (
> http://lists.w3.org/Archives/**Public/public-tracking/**2012Apr/0076.html<http://lists.w3.org/Archives/Public/public-tracking/2012Apr/0076.html>
> )
>
>  Could you further clarify your concern? Would you like to
>  (a) Disallow out-of-band consent altogether?
>
> No, but if you are putting OOBC on the table and are not sure about it in
> real-time, it it not proportinal to the privacy intrusion.
>
>   (b) Disallow out-of-band consent that cannot be retrieved in real-time?
>
> Indeed. The rationale behind it is collection limitation as a meaningful
> added value of a W3C DNT standard.
>
>   (c) Disallow DNT for pixels?
>
> Indeed, if a server can not talk full DNT (incl JS-based exeptoin API) AND
> is not able to know in real-time if OOBC trumps the tracking request, it
> sould not be allowed IMHO.
>
>   (d) somethine else?
>
>
>
> Matthias Schunter (Intel Corporation) schreef op 2013-04-23 11:15:
>
> Hi Rob,
>
>
> thanks for the feedback!
>
> I believe that out of band consent goes beyond the pixel-problem and
> audience measurement.
>
> Could you further clarify your concern? Would you like to
>  (a) Disallow out-of-band consent altogether?
>  (b) Disallow out-of-band consent that cannot be retrieved in real-time?
>  (c) Disallow DNT for pixels?
>  (d) somethine else?
>
> btw: Pixels can talk DNT (request and response headers are included).
> They only cannot trigger the JS-based exception API.
>
>
> Regards,
> matthias
>
>
> On 23/04/2013 10:07, Rob van Eijk wrote:
>
>
> Counterproposal: Silence i.e. no text.
>
> OOBC for panel members and the problem of the pixels not being able to
> talk DNT is an innovation problem for audience measurement industry. Making
> the problem go away by not calling it a problem under DNT anymore is not
> acceptable for me and probably more privacy advocates.
>
> Rob
>
> Roy T. Fielding schreef op 2013-04-23 08:03:
>
> Bah, resend with a fixed subject ...
>
> I think this is related to ISSUE-195, but really should have been
> raised as a separate issue.
>
> There was a long discussion about a new tracking status for systems
> that only track by consent but do not actually determine consent
> during request time, originally requested by Alex and more recently
> by Ronan.  Unfortunately, the discussion kept going in the weeds,
> at least partly because people mistook the request as an expansion
> on the existing consent (C) response.
>
> So, I have written a proposal within the editors' draft as a new
> option with a TSV of P for potential consent.
>
> ....Roy
>
> Begin forwarded message:
>
>  Resent-From: public-tracking-commit@w3.org
> From: "CVS User rfieldin" <cvsmail@w3.org>
> Subject: CVS WWW/2011/tracking-protection/**drafts
> Date: April 22, 2013 4:11:49 PM PDT
> To: public-tracking-commit@w3.org
> Archived-At: <http://www.w3.org/mid/**E1UUPtl-0006gx-Ok@gil.w3.org<http://www.w3.org/mid/E1UUPtl-0006gx-Ok@gil.w3.org>
> >
>
> Update of /w3ccvs/WWW/2011/tracking-**protection/drafts
> In directory gil:/tmp/cvs-serv25723/drafts
>
> Modified Files:
>     tracking-dnt.html
> Log Message:
> ISSUE-195: Add a TSV option for potential consent (P) to address Ronan's
> use case
>
> --- /w3ccvs/WWW/2011/tracking-**protection/drafts/tracking-**dnt.html
> 2013/04/22 21:28:40    1.201
> +++ /w3ccvs/WWW/2011/tracking-**protection/drafts/tra
>
>