- From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
- Date: Tue, 23 Apr 2013 15:57:57 +0200
- To: rob@blaeu.com, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
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) > >> 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> >>>>> >>>>> 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/tracking-dnt.html >>>>> 2013/04/22 23:11:49 1.202 >>>>> @@ -22,7 +22,7 @@ >>>>> wgPublicList: "public-tracking", >>>>> wgPatentURI: "http://www.w3.org/2004/01/pp-impl/49311/status", >>>>> issueBase: >>>>> "http://www.w3.org/2011/tracking-protection/track/issues/", >>>>> - noIDLSectionTitle: true, >>>>> + noIDLSectionTitle: true >>>>> }; >>>>> </script> >>>>> <link rel="stylesheet" href="additional.css" type="text/css" >>>>> media="screen" title="custom formatting for TPWG editors"> >>>>> @@ -544,8 +544,10 @@ >>>>> <dfn>TSV</dfn> = "1" ; "1" — first-party >>>>> / "3" ; "3" — third-party >>>>> / %x43 ; "C" - consent >>>>> + / %x50 ; "P" - potential consent >>>>> / %x44 ; "D" - disregarding >>>>> / %x4E ; "N" - none >>>>> + / %x50 ; "P" - potential consent >>>>> / %x55 ; "U" - updated >>>>> / %x58 ; "X" - dynamic >>>>> / ( "!" [testv] ) ; "!" - non-compliant >>>>> @@ -660,6 +662,42 @@ >>>>> </p> >>>>> </section> >>>>> >>>>> + <section id='TSV-P' class="option"> >>>>> + <h4>Potential Consent (P)</h4> >>>>> + <p> >>>>> + A tracking status value of <dfn>P</dfn> means that >>>>> the origin >>>>> + server does not know, in real-time, whether it has >>>>> received prior >>>>> + consent for tracking this user, user agent, or >>>>> device, but >>>>> + promises not to use any <code>DNT:1</code> data until >>>>> such consent >>>>> + has been determined, and further promises to >>>>> de-identify within >>>>> + forty-eight hours any <code>DNT:1</code> data >>>>> received for which >>>>> + such consent has not been received. >>>>> + </p> >>>>> + <p> >>>>> + Since this status value does not itself indicate >>>>> whether a >>>>> + specific request is tracked, an origin server that >>>>> sends a >>>>> + <code>P</code> tracking status value MUST provide an >>>>> + <code><a>edit</a></code> member in the corresponding tracking >>>>> + status representation that links to a resource for >>>>> obtaining >>>>> + consent status. >>>>> + </p> >>>>> + <p> >>>>> + The <code>P</code> tracking status value is >>>>> specifically meant to >>>>> + address audience survey systems for which determining >>>>> consent at >>>>> + the time of a request is either impractical, due to >>>>> legacy systems >>>>> + not being able to keep up with Web traffic, or >>>>> potentially "gamed" >>>>> + by first party sites if they can determine which of >>>>> their users >>>>> + have consented. It cannot be used for the sake of >>>>> personalization >>>>> + unless consent is determined at the time of a >>>>> request, in which >>>>> + case the <code><a>C</a></code> tracking status is >>>>> preferred. >>>>> + </p> >>>>> + <p class="issue" data-number="195" title="Flows and >>>>> signals for handling out of band consent"> >>>>> + <b>[OPEN]</b> The <code><a>P</a></code> tracking status >>>>> + value indicates a special case of general data >>>>> collection which >>>>> + is then trimmed to exclude those without out of band >>>>> consent. >>>>> + </p> >>>>> + </section> >>>>> + >>>>> <section id='TSV-D' class="option"> >>>>> <h4>Disregarding (D)</h4> >>>>> <p> >>>>> >>>>> >>>
Received on Tuesday, 23 April 2013 13:58:23 UTC