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

On May 7, 2012, at 3:01 PM, Justin Brookman wrote:

> On 5/5/2012 8:59 PM, Nicholas Doty wrote:
>> 
>> 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.
> I think we are all in agreement that the operator of a site cannot obtain explicit, informed consent via a Terms of Service, privacy policy, or other non-obvious means.  Either the tracking is obvious by the nature of the product, or you have to go out of your way to explain clearly and conspicuously and get permission.  I am open to putting language in the normative section making that clear, but I thought that Shane and others were strongly opposed to that.  I do agree that the proposed non-normative text could make clearer that ToS by itself cannot work.  Here is revised language:
> 
> Non-Normative Text:
> 
> Even when a user has turned on a "Do Not Track" setting, the operator of a site may seek to obtain the user's permission to ignore that setting and track the user as a third party on other sites.  In seeking user consent, the tracking functionality has to be clearly communicated to the user such that the user is positioned to make a voluntary and informed decision about whether to allow the operator to collect and use cross-site data about the user in ways that would otherwise be prevented by the DNT setting.
> 
> Interactions with users to obtain consent can in many cases be contextual.  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 may not have been contemplated at the time the consent experience was designed).  For example, if a user signs up for a social reader service that clearly indicates that information about activity on other sites will be collected and published to a user's social networking page, the service would not need to get separate permission to ignore the DNT signal.  Even in these cases, however, organizations should provide Tracking Preference references in associated product or service materials such as a privacy policy, help center, and/or in separate notice to users.
> 
> Most services that a user signs up for do not have cross-site tracking functionality that would be obvious to a user.  For these services, operators who wish to comply with this spec and track despite the presence of a DNT signal should clearly and conspicuously ask users for permission to track despite the Do Not Track setting.  Simply agreeing to a long boilerplate legal agreement that includes mention of a right to track despite a DNT settings would not constitute express and informed consent.  For example, if the operator of an instant messaging client (who also owned an advertising network) asserted permission to track for behavioral advertising purposes only in a linked license agreement, a user's agreeing to the license agreement would not constitute express, informed consent to override the user's DNT preference for the purposes of this spec.
>  
> Out-of-band consent will be further reinforced in user interactions through [let's park this paragraph until the response header/well known URI are fully fleshed out.]

The above text contains 15 normative statements (highlighted in red).
None of them are necessary for interoperability.

I understand that most folks here are more familiar with the
process of lobbying for legislation or crafting regulations than
they are for writing protocol standards.  There are plenty of
forums for which the above language is appropriate.  This is
not one of them.

We can't standardize what consent means because it inherently
depends on context and interaction over time (not interaction
within a single protocol exchange).  Informed consent further
depends on social, regional, and even educational contexts.
Legislation does not define consent because there is no common
ground on which to define it, and the ground that we do have
is changing on a continual basis.  

What each of us, individually, believes is sufficient consent
is irrelevant to the protocol.  If a given site is expected to
have an audience of grandmothers, then it had better obtain
consent in a way understandable by grandmothers.  If a given
site is expected to be used by children, then a whole range
of additional requirements apply to obtaining informed consent.
Regulators impose and refine those requirements over time, based
on specific contexts and specific examples, and implementations
adjust accordingly. We don't have to. If you don't like the bar
set by regulators, then use the appropriate means to increase it.

No matter what text is added to our documents, it won't
change the nature of prior consent, nor will it change
the requirements imposed on industry by regulators regarding
consent, and thus whatever the protocol says about consent
doesn't matter: implementations must adhere to the regulations,
regardless of the standard, and protocol requirements that have
nothing to do with interoperability will be ignored.

In short, we should use the same phrase as the regulators.
That's the measuring stick that matters.  It can and will
change over time, just as discussions about social networking
evolve with each new social service introduced.  The normative
statement is that

  If a party has received prior consent for tracking a given
  user, user agent, or device, that consent overrides the
  general preference indicated by the DNT header field.
  If a party chooses to track based on that prior consent,
  the corresponding tracking status MUST indicate that tracking
  is occurring based on consent and SHOULD supply a link to
  a means for the user to remove or modify that consent.

and then define "prior consent" by reference to each of the
major regulations that define it as including "prior, specific,
explicit, and informed consent".  Include examples of what *is*
a prior consent, not examples of what isn't.

Saying that consent can't be given in a privacy policy is just
wrong.  It might be, depending on a million different variables
that go into providing the UI of a service.  Saying something
has to be "obvious" is just adding another subjective word to
the mix. We already have enough of those.

....Roy