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

Putting aside your . . . interesting . . . classification of my language, is there anything in that language that is unworkable or burdensome?

You say that this language is not necessary for interoperability.  I'm saying that the language (or comparable language) is necessary to accomplish the stated mission of this working group, which is to improve user privacy and user control over tracking.

If the end result of this spec is that any company can assert that they are DNT-complaint in a privacy policy and then two paragraphs later aver that all users consent to any and all tracking despite the DNT signal (by either us or our third-party marketing partners!), then whether or not the spec is *interoperable* or not, we will have all wasted a great deal of time accomplishing what is arguably less than nothing for users or for the companies who hope this endeavor is a success.  (And no, the response header and well-known URI do not solve the problem.)

Again, I thought we had reached general agreement in Washington that calling for "explicit, informed consent" was appropriate as a baseline for this spec notwithstanding any one jurisdiction's definition of what legal consent might be.  If you don't like calling it "explicit, informed consent" because you cannot dissociate the concept from legal consent, then we can change the term to "explicit, informed permission."  Which, again, we are not attempting to narrowly define --- we are merely giving explanatory (and I would hope utterly non-controversial) guidance in order to ensure that the spec actually serves to protect user privacy.
  _____  

From: Roy T. Fielding [mailto:fielding@gbiv.com]
To: Justin Brookman [mailto:justin@cdt.org]
Cc: public-tracking@w3.org
Sent: Mon, 07 May 2012 22:30:31 -0400
Subject: 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