Re: proposed TSV for potential consent

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