changes to TPE before last call.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
 /
 Email: michael.oneill@baycloud.com
/Professional Profile
 
 
 See who we know in common
 Want a signature like this?
 
 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.2.34.4474 - http://www.gpg4o.de/
Charset: utf-8

iQEcBAEBAgAGBQJS8lvPAAoJEHMxUy4uXm2JGN0H+gJAzKT5FiVFJSoMZ2jrjA3J
1Q8rKWVlJHq2j6u+HLZGg20DHYzgMSnVBOSgAL+2nB3sZFoaKwIZ+7zQLjPRVPdW
FKsYW93jYs7R1FViSO0D4uVkQXWOQ3XYNgccEatxkPBval/kNK+dtMSI+HHOZonU
Y40T9PCV2+EYUhbgW/7BKuMT7b8bDjIRAaGFzIieJbBUj1++Pvmlnwl+UA0HEx4Q
gXj1r8TOGNnwb3TrFE21c2nx25Hu6Gzb5Gjl5DxapCjM/6VxKqhCPoU629cNgvMk
wYvsCV3W3TjkJWBmHcAlFxftWfRbDk8v79RKBKfwYm5WqEml1PMW6a8ruu4UZVM=
=Qlzr
-----END PGP SIGNATURE-----