example for OOBC with cookies (was Re: change proposal)

Hi Mike,

Thanks for the note. As the substance of this change is intended for the TPE rather than for our set of open issues on Compliance, I haven't documented a change proposal on the wiki. I believe the suggested clause noting an example in the TPE can be an editorial change to the Compliance document if we include such examples in the TPE.

Providing non-normative text suggesting a convention for cookies used for out-of-band consent sounds similar to Roy's proposal that we drop the JS APIs altogether in favor of such conventions. Roy, CCed, do you think providing such conventions (in a non-normative way) would be a useful way forward?

Thanks,
Nick

On Jun 25, 2013, at 9:49 AM, "Mike O'Neill" <michael.oneill@baycloud.com> wrote:

> Ignore the last one which had grammatical errors
>  
> 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 [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 [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 isabout 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.