- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Thu, 27 Jun 2013 16:41:07 +0100
- To: <public-tracking@w3.org>
- Cc: "'Roy T. Fielding'" <fielding@gbiv.com>
- Message-ID: <0fae01ce734c$c0fdcb90$42f962b0$@baycloud.com>
That last message was a clone of an old one I sent on Tuesday. Why it has appeared again is a mystery, but here is the one that superseded it (also sent on Tuesday), adding some new thinking. I still think we should have some reference to a named cookie consent mechanism in the TPE because it is the obvious way to do it and the way it is currently done on most large UK sites. Recommending a common name will only have the benefit of making a common technique transparent. This could also be the basis of a simpler and more powerful UGE mechanism which could be discussed after LC. User agents could detect the W3CTP name and insert a clone of it in distributary third-party requests. This would leverage all the existing attributes of HTTP cookies for sunset revocation , subdomains etc. and allow for more bits to communicate user preferences to embedded third-parties. Here is text about OOBC using cookies. This is for the TPE but referenced from the TPC. Existing text in TPC Sec 6. User-Granted Exceptions The operator of a website may engage in practices otherwise proscribed by this standard if the user has given explicit and informed consent. This consent may be obtained through the API defined in the companion [ <http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html# bib-TRACKING-DNT> TRACKING-DNT] document, or an operator of a website may also obtain out of band consent to disregard a Do Not Track preference using a different technology. If an operator is relying on out of band consent to disregard a Do Not Track preference, the operator must indicate this consent to the user agent as described in the companion [ <http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html# bib-TRACKING-DNT> TRACKING-DNT] document. Before the final period insert: which also contains an example of how such out-of-band consent may be implemented. The following is non-normative text to be added to the TPE New text in Sec 6. User-Granted Exceptions 6.12 Out-of Band Consent This section is non-normative. An origin server may provide other mechanisms for establishing, modifying or revoking out-of-band consent for tracking. It would be helpful for transparency, and therefore trust in the web, if these mechanisms used similar definitions and elements. One such method could be based on the use an HTTP cookie (as described in RFC 6265) to register and signal user agreement. The origin server would cause an HTTP Cookie to be stored in the user agent when the user had given consent for tracking. It is recommended that this cookie should have the name W3CTP and have a value that starts with the characters "C=1" to make the fact of user consent transparent to regulators, user agents and users. The rest of the cookie value could be anything the implementer decides. The "Expires"" attribute can be used so that the user agent removes the cookie after a reasonable period causing the user's registered consent signal to lapse. A copy of this attribute could also be encoded in the cookie's value so the server can determine when the consent signal is about to be removed. The server would use the presence of such a cookie in the cookies header of subsequent HTTP requests to indicate that the user had given consent. If the cookie is absent or its value does not start with "C=1" this indicates to the server that the user has not given consent.
Received on Thursday, 27 June 2013 15:41:55 UTC