- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 23 Apr 2013 04:00:59 -0700
- To: Mike O'Neill <michael.oneill@baycloud.com>
- Cc: "<public-tracking@w3.org>" <public-tracking@w3.org>
On Apr 23, 2013, at 3:00 AM, "Mike O'Neill" <michael.oneill@baycloud.com> wrote: > I can see merit in specifying a URI to a consent page where a user can be > given information to decide, but this can be there irrespective of the TSV. > The UA would have the option to draw attention to it in the DNT set case, > and if the user agrees the consent API can be called from there. The case we are concerned with involves prior consent that has already been granted, usually in the form of a contract. It doesn't make any sense to ask for additional consent. The real question is whether a third party is allowed to collect data in general with a very short retention span if the data is not used or shared unless that prior consent exists. > The only way to make the P TSV transparent would be for the UA to check > within 48 hours if the API had been called or the TSV had changed to > something else, and it is unlikely that UAs would do that. Retaining the > requirement to use the consent API (or a C TSV if consent is otherwise > indicated by a cookie) is better. There is no consent API. We are talking about out of band consent, and the transparency is already achieved by indicating that limited tracking will occur. All HTTP requests result in limited term data collection at all recipients along the request path, so I don't see any harm in a prior consent framework that determines consent offline. ....Roy > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@gbiv.com] > Sent: 23 April 2013 06:29 > To: public-tracking@w3.org (public-tracking@w3.org) > Subject: proposed TSV for potential consensus > > 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 11:01:27 UTC