Re: RESENT: Batch Closing of Issues against TPE [Deadline for validating can-live-with consensus: August 20]


I see your concern.   We do use "consent" in some places and "preference" in others.  I would offer that "preference" seems to make more sense semantically.  Is the signal not saying "I prefer the consequences of this choice over the alternatives" or is your opinion that it should be consent with regard that treatment?  It seems easier to convey with preference, but either way, I agree we need consistency.  Whichever wording we pick will need to make clear the onus of indicating such choice on behalf of the subject.

Also there are other places where our terminology is inconsistent  site, website, server, origin server.  We should look at these as well.


Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the Wunderman Network
(Tel) 678 580 2683 | (Mob) 678 492 1662 |


This email  including attachments  may contain confidential information. If you are not the intended recipient,
 do not copy, distribute or act on it. Instead, notify the sender immediately and delete the message.

From: Tamir Israel <<>>
Date: Saturday, August 25, 2012 12:16 PM
To: "<> (<>)" <<>>
Subject: Re: RESENT: Batch Closing of Issues against TPE [Deadline for validating can-live-with consensus: August 20]
Resent-From: <<>>
Resent-Date: Saturday, August 25, 2012 12:17 PM

Thanks Matthias (and Justin and Roy) for the clarification.

This may be really nitpicky, but it might be a good idea to add a direct reference in the TPE to the out-of-band consent requirement set out in the TCS, just so there's no confusion when people turn to implementation. Specifically, it should be clear that Tk: c means 'I believe I have consent that conforms to the requirements on out of band consent'. I think this will help many of those implementing (say, smaller implementers who may not have legal departments, etc.) be more aware that compliance requires out or band consent to be an 'explicit reflection of user choice and preference'.

Along the same thread: the TPE seems to generally avoid using 'consent' terminology and instead refers to 'expression of user preference'. While I personally prefer sticking to 'consent' as a touchstone, more important for clarity purposes is to stay consistent. So where the compliance/scope document means to say 'out of band consent MUST reflect an explicit expression of user preference', it instead says 'third parties may gain explicit and informed consent by other means'.


On 8/25/2012 2:57 AM, Matthias Schunter wrote:

Hi Tamir,

ISSUE-75: How do companies claim exemptions and is that technical or not?

is indirectly affected in the following way:  The agreements below say
that there should be a technical mechanism (via Javascript) to ask for
exceptions. As a consequence, we specified such an API into the spec.

I.e., indirectly wrt ISSUE-75 we decided that there should be at least
this technical approach. This does not preclude any other approaches. In
particular we also have agreement to allow out of band consent.

Does this answer your question and mitigate your concern?


On 20/08/2012 20:52, Tamir Israel wrote:

Can someone please confirm that these issues (and particularly section
5.3.3 of the TPE) do not foreclose or pre-decide ISSUE-152 and
ISSUE-75 (out of band consent)?


On 8/15/2012 12:16 PM, Matthias Schunter (Intel Corporation) wrote:
ISSUE-47: Should the response from the server indicate a policy that
describes the DNT practices of the server?
- A policy attribute at the well-known URI may point to a site-wide
policy (Section 5.4.1)
- The response header may identify a more specific policy at a
different URL (Section 5.3.2)
ISSUE-107: Exact format of the response header?
- Revised response header values in Section 5.2 and syntax in 5.3

Received on Monday, 27 August 2012 14:50:18 UTC