change proposal

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