W3C home > Mailing lists > Public > public-tracking@w3.org > May 2012

RE: Action-157: Update logged-in consent proposal

From: JC Cannon <jccannon@microsoft.com>
Date: Sun, 6 May 2012 15:42:19 +0000
To: Nicholas Doty <npdoty@w3.org>, Shane Wiley <wileys@yahoo-inc.com>
CC: David Singer <singer@apple.com>, "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <BB17D596C94A854E9EE4171D33BBCC810D7D28@TK5EX14MBXC136.redmond.corp.microsoft.com>
Nick,

I would vote for using "SHOULD NOT" because of cases where it is obvious that the product or service relies on tracking.

JC

From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: Saturday, May 05, 2012 6:00 PM
To: Shane Wiley
Cc: David Singer; public-tracking@w3.org
Subject: Re: Action-157: Update logged-in consent proposal

Thanks Shane (and Justin too?) for drafting this proposal text, and apologies for my delay in replying.

We may have some confusion on the normative/non-normative distinction here as there are a few uses of "should" in the non-normative section that could be interpreted as normative requirements.

Also, Shane and Justin, does this sentence
"Companies ... should not seek to obtain explicit, informed consent from users in non-obvious ways such as placing these details in their Terms of Service or deeply placed within their Privacy Center"
imply that a service *can* obtain explicit, informed consent to override a user's DNT preference via a Terms of Service document and be in compliance with this standard?

If not, then we could make this clearer by updating the normative text:
Sites MAY override a user's DNT preference if they have received explicit, informed consent to do so. Sites MUST NOT obtain explicit, informed consent via Terms of Service or other non-obvious means.

Or if the group believes there are some cases where non-obvious means would be acceptable, that would be a SHOULD NOT rather than MUST NOT. Or this could be phrased definitionally instead: "Consent via a Terms of Service or other non-obvious means is not explicit and informed."

Also, per the question on "ideally", is that a SHOULD requirement? e.g. "Sites SHOULD provide options to alter this consent via the tracking status resource."

Thanks,
Nick

On Apr 25, 2012, at 12:23 PM, Shane Wiley wrote:


I'm fine with "ideally":

<Normative>

Sites MAY override a user's DNT preference if they have received explicit, informed consent to do so.

<Non-Normative>

In the absence of a Tracking Preference standard, many organizations have developed direct consent mechanisms for web-wide tracking.  Interactions with users to obtain consent are often contextual.  For example, If a service has an obvious cross-site tracking function that the user deliberately signs up for then this could be deemed to have achieved "explicit and informed" consent from a user without directly addressing its reaction to an external Tracking Preference (which wasn't contemplated at the time the consent experience was designed).  Even in these cases, organizations should consider providing Tracking Preference references in associated product or service materials such as a privacy policy, help center, or separate notice to users.

Companies claiming public compliance with the W3C Tracking Protection standard, should not seek to obtain explicit, informed consent from users in non-obvious ways such as placing these details in their Terms of Service or deeply placed within their Privacy Center if it will not be obvious to users that the nature of the service will lead them to ignore a user's Tracking Preference based on the nature of the consent the user is granting.

Out-of-band consent will be further reinforced in user interactions through either the Header Response or Well-Known URI approaches to replying to user Tracking Preferences.  This will provide a constant reminder of prior consent on each interaction and provide a resource (link) to allow the user to understand how this consent was achieved and ideally options to alter that consent if the user chooses to do so.
Received on Sunday, 6 May 2012 15:42:55 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:28 UTC