issue-201

In the EU tracking using identifier storage is restricted irrespective of
whether the server is accessed as a first-party or a third-party, unless
consent has been given. It follows that if the DNT is not present servers
should interpret that as if DNT had been set, i.e. only an explicit DNT:0
can be taken as a signal that the user has given consent.

 

This is problematic when an EU site incorporates third-party content whose
servers are operated outside the EU. The absence if DNT could have different
interpretations by  the cooperating servers operating in different
jurisdictions. 

 

There should be a way for EU based servers to signal that consent is needed,
even though the DNT signal is not enabled, to their embedded third-parties.

 

This could be achieved by using the reciprocal of an OOB consent mechanism,
such that the fact of consent not (yet) having been obtained, but is
required by local law, is signaled to third-parties. The OOB signal would
again override DNT (unset, 0 or 1).

 

I have amended the text on a non-normative example of a cookie based OOBC
mechanism to allow for this.

 

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 a particular named cookie to be stored in the user agent indicating
the user had given consent for tracking. It could also signal that they had
not given consent in situations where absence of DNT must be assumed to
signify DNT:1 (as in the EU). 

 

It is recommended that this cookie should have the name W3CTP and have a
value that starts with the characters "C=0" or "C=1" to make the fact of a
user consent state transparent to regulators, user agents and users. The
rest of the cookie value could be anything the implementer decides. The
standard "Expires"" attribute can be used so that the user agent removes the
cookie after a 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. If the value starts with
"C=0" this indicates that consent has not been given but is required before
tracking in order to comply with local law.