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

On May 7, 2012, at 8:32 PM, Justin Brookman wrote:

> 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.

We can completely remove it from the spec and it would not lower
the user's privacy nor remove control over tracking. If a site has
the user's consent to do something, then by definition the site
does not violate the user's control by doing that something.
It is the site's responsibility to ensure that it has consent
to override DNT before it does so.

It is not our responsibility to tell the entire world how it must
define consent mechanisms. If the chosen mechanism is not sufficient
to obtain informed, specific, and explicit consent from a given user,
in that user's specific context with that specific service, then the
site does not have consent.  If the site does not provide a means for
modifying consent over time, then the site does not have consent
over time. No further elaboration is necessary.

> 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.)

That is hyperbole.  The word "explicit" in the definition already
requires an active response by the user that is not pre-selected,
and hence your scenario is prevented already.

I didn't say that the company can define consent however it wants.
The consent is either sufficient for the user or it doesn't exist.
When companies fail to obtain consent, either deliberately or in
ignorance, then users can complain and regulators, legislators,
and judges are expected to narrow the boundaries on a case-by-case
basis, as they do already.

There is nothing worthwhile that this group could add -- we'd
only waste our time and remove flexibility from sites that already
do have legitimate consent from the user, but don't happen to match
your preconceived notions of what to include in that paragraph.

> 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.

I said to use "prior consent" in verbiage because it is short and simple,
and to place the other adjectives in the definition of prior consent.
They need to be in the spec, but only one place; there is no need to
repeat them everywhere.  I don't know why folks in the *other* breakout
session wanted to remove "specific"; IIRC, the EU policy requires
consent to be specific in order to exclude permission that is buried
in some other text (like a general policy document).

....Roy