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

Justin and Roy,

I believe the core issue here is attempting to leverage W3C standards development language constructs on what is chiefly a "policy" document and we're running into the conflict between the two worlds.  Is there a way to solve this?  The closest comparative W3C standard is P3P (not a stellar success of a story to follow) but I believe there were less issues here as the standard doesn't generally prescribe what can or cannot occur in most cases and rather creates a structured approach to sharing business/policy practices (UAs then developed their own rules around these).  Are there any other examples of a W3C standard that has deep (policy-esque) compliance elements associated with it?  I'm trying to figure out the best way to approach this problem as I've had several run-ins with providing normative action terms (should, should not) in what was meant to be explanatory/example text (non-normative).

That said, I'm beginning to agree with Roy that leaving this to current legal realities is probably the best route (versus "you must have a check-box in this location" as a long-term workable solution as some may argue).

- Shane

From: Justin Brookman [mailto:jbrookman@cdt.org]
Sent: Monday, May 07, 2012 8:32 PM
To: public-tracking@w3.org
Subject: 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