Hi Matthias,
I would like to propose a couple of changes to the TPE before LC, one to the UGE description and the other to the tracking resource. Both reflect my experience in implementing consent mechanisms and the DNT UGE on many sites.
The first is to the text about when a UGE can be made. The existing text talks about a “sites understanding” and that the intention must be determined immediately prior to each call. In addition to it being an anthropomorphism, this would cause difficulties for the controllers of sites consisting of multiple domains, or managing several sites under the same privacy policy. This would also lead to users being bombarded with pointless repetitive requests for consent caused by requests to resources in the different domains.
I propose amending the text so it refers to the data controller(s) of the sites and allows for an intention for a UGE to be applied to multiple sites if this reflects what the user has agreed to. There is no need to describe how the user’s intention is communicated as long as it is understood to reflect the controllers current understanding. A revocation of a previously stored grant should be taken as overriding any understanding of the user’s intention by the data controller, and could trigger a new exception explanation.
Existing text:
6.3.1 User Interaction
The call to store an exception MUST reflect the user's intention to grant an exception, at the time of the call. This intention MUST be determined by the site prior to each call to store an exception, at the time of the call. (This allows the user to change their mind, and delete a stored exception, which might then trigger the site to explain, and ask for, the exception again). It is the responsibility solely of the site making the call to determine that a call to record an exception reflects the user's informed consent at the time of the call.
changes to:
6.3.1 User Interaction
The call to store an exception MUST reflect the user's intention to grant an exception. This intention MUST be determined by the data controllers of the site prior to the call to store an exception, and MUST reflect the data controller’s most recent understanding of the user’s intention. (This allows the user to change their mind, and delete a stored exception, which might then trigger the site to explain, and ask for, the exception again). It is the responsibility solely of the data controller of the site to determine that a call to record an exception reflects the user's informed consent at the time of the call.
The second proposal is for an optional standard mechanism by which a controller can give users the ability to delete their tracking history. This would let them build user’s trust by offering a domain specific way to remove tracking history, e.g. to delete cookies or other identifiers in that particular domain. A simple anchor link in a privacy policy would be sufficient for a user to have their tracking data deleted, even if the policy document was addressed by a resource in a different domain (which is often the case for bigger sites).
Forget Property
An origin server MAY send a property named “forget” with a string value containing a URI reference to a resource which, when referenced in a request, will cause personal data collected from the user-agent, other than that for a permitted use, to be deleted. It is assumed that values in the cookie header (or in the request entity if a POST) are sufficient to identify the user-agent.
forget = %x22 "forget" %x22
forget-v = string ; URI-reference
Mike
Mike O'Neill Technical Director Baycloud Systems Oxford Centre for Innovation New Road Oxford OX1 1BY Tel. 01865 735619 Fax: 01865 261401 |
| ||
