- From: David Singer <singer@apple.com>
- Date: Wed, 24 Apr 2013 10:08:07 +0900
- To: Ronan Heffernan <ronansan@gmail.com>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
- Message-id: <516FA36D-EB6A-4441-82F5-0DE76C577AE5@apple.com>
On Apr 24, 2013, at 6:20 , Ronan Heffernan <ronansan@gmail.com> wrote: > Here is the text that I prepared on deferred determination of OOBC. If anyone prefers 'P' over 'L', that's fine with me: > > > X.X.X.X Deferred Determination of Out-of-Band Consent > > Parties that enter into out-of-band agreements with web users that allow for the collection and use of web transaction data SHOULD determine in real-time whether an out-of-band consent exists for a user or device, and respond with ‘C’ for those users who have consented, and with the appropriate DNT responses for other users. If it is not practical to make this determination in real-time, then the server may return response code ‘L’, to indicate that the out-of-band consent determination will be made at a later time. > > In this case of deferred determination, raw (non-deidentified) data MAY be stored for up to 48-hours from time of receipt so that server-side systems will have an opportunity to determine which data correlates to an existing out-of-band consent. This raw data MUST NOT be used to alter the user experience and MUST NOT be analyzed, reported on, shared with other parties, or used in any other way, except for existing permitted uses (e.g. 6.2.2.5 “Financial Logging and Auditing”, 6.2.2.6 “Security Fraud and Prevention”, etc.). Might be best phrased as "not to be used in any way, particularly not to alter the user experience" (i.e. lead with the general restriction rather than mentioning it last) > > At the time that deferred determination of out-of-band consent is accomplished, raw data for which a consent is detected becomes out-of-scope for this specification [and can be used in any fashion that is consistent with the terms of that consent]. All raw data for which an out-of-band consent is not detected MUST be deleted or deidentified using means consistent with those required for use on the data of DNT:1 users who have not granted an exception. This provision does not change any allowed retention or use of data under other provisions of this specification. > > Response headers that indicate ‘L’ MUST include a URI for a “control link” that users can visit to learn about their out-of-band consent status. Because this determination cannot be made in real-time, the control link server MAY set a unique cookie into the User Agent that SHOULD expire within 72 hours. I think this is deeply troubling. I don't think many users will ask, but if they do, I think the system needs to be able to answer. Using a cookie assumes they return using exactly the same user-agent. I prefer Roy's language. > This cookie MUST NOT be used for any purpose other than to help inform the user of their out-of-band consent status. The control link server SHOULD inform the user of the time window when they can return to be informed as to whether an out-of-band consent was detected. In order to tie the user’s data at the control link back to the data collected during the transaction that resulted in an ‘L’ response header, the user MUST visit the control link before their IP address, cookies, or other information changes that the backend systems require to detect an out-of-band consent. The user MUST return to the control link after the time when the determination is made (up to 48 hours), and before the temporary control-link cookie expires (72 hours), and without erasing or altering the control-link cookie, or the system will not be able to inform the user as to whether an out-of-band consent was found. > > > --ronan > > > > > On Tue, Apr 23, 2013 at 1:28 AM, Roy T. Fielding <fielding@gbiv.com> wrote: > 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> > > > > > > > David Singer Multimedia and Software Standards, Apple Inc.
Received on Wednesday, 24 April 2013 01:09:14 UTC