RE: ACTION-152 - Write up logged-in-means-out-of-band-consent

Jonathan,

A consent standard has broad implications that would apply to many areas outside of DNT. Such a broad topic should not be embedded in our tracking protection standard. There should be a separate standard for addressing levels of consent and how they might apply to various scenarios.

We did agree early on that there could be server-side overrides for DNT. Now you want to fight about what is acceptable server-side consent. The client-side consent was too arduous. 

There is enough for us to do just focusing on the core set of principles for the standard without creating another set of obstacles to a timely completion of our work.

Thanks,
JC

-----Original Message-----
From: Jonathan Mayer [mailto:jmayer@stanford.edu] 
Sent: Sunday, April 01, 2012 9:46 PM
To: Shane Wiley
Cc: Rigo Wenning; public-tracking@w3.org; Alan Chapell; Jeffrey Chester; David Singer; John Simpson
Subject: Re: ACTION-152 - Write up logged-in-means-out-of-band-consent

I've heard three chief arguments against defining a consent standard.  I don't think any withstands scrutiny.  (I presented arguments in favor of a consent standard in a prior email.)

First, a consent standard is out of scope.  I dealt with that in a prior email - it's just wrong.

Second, local law trumps whatever we decide.  I think that argument needs some unpacking.  A jurisdiction could of course require more or less from consent than we recommend.  Nothing in a consent standard represents an assault on sovereignty.

With that red herring aside, let's be honest about the practical effect of setting a consent standard: we'll level up jurisdictions that have a weak consent standard (e.g. the U.S.).  I don't believe any jurisdiction with a strong consent standard (e.g. the EU) would level down its requirements on our account.

Third, defining a consent standard is too hard.  I don't in the slightest see how defining a consent standard is uniquely challenging.

As I noted in an earlier email, it seems to me the exercise would be relatively straightforward.  We could begin with a set of bright-line rules that give clear guidance, then set an underlying standard (either adopting a pre-existing approach or articulating our own test).  Here is sample text.

--------------------------------------------------

A website need not use the browser exception API to attain a user's permission for otherwise prohibited practices.  An "out-of-band" choice mechanism has the same effect under this standard as the browser exception API, provided that it satisfies the following bright-line requirements:

1) Actual presentation: The choice mechanism MUST be actually presented to the user.  It MUST NOT be on a linked page, such as a terms of service or privacy policy.

2) Independent choice: The choice mechanism MUST be presented independent of other choices.  It MUST NOT be bundled with other user preferences.

3) No default permission: The choice mechanism MUST NOT have the user permission preference selected by default.

An "out-of-band" choice mechanism must additionally satisfy the following high-level standard:

An ordinary user would know that the choice overrides his or her privacy protections under this standard.

On Apr 1, 2012, at 8:54 PM, Shane Wiley wrote:

> Rigo,
> 
> I disagree with your basic premise here: '"Out-of-band" is creating the trouble, because it imports troubles from outside in our definition space and we have to decide in how far we accept that (see below).'
> 
> We've always said since the very early days of this working group that user consent would trump DNT - full stop.  I don't believe anyone has issues with that perspective and now the conversation has moved to "what would be fair and appropriate consent?".  While I don't disagree with the question, I believe it is up to local legal jurisdictions to answer this questions for companies that operate in their territories (this should allow the EU to give their "blessing" as you've stated).  This does not mean that the only option is 22 pages of legalese, as you suggest, and may instead be as simple as an in-registration flow notice or some other approach.  The issue is attempting to be overly prescriptive here and define "meaningful consent" in this forum.  It's too broad of topic to handle quickly but if we're willing to postpone the TPWG time table by 4 to 5 months then we may have a chance at addressing it here.  I'm assuming the original timeframe is a higher priority and would therefore respectively suggest we can use broad terms such as "fair and appropriate" but suggest we stay away from more prescriptive terms or descriptions than these.
> 
> - Shane
> 
> -----Original Message-----
> From: Rigo Wenning [mailto:rigo@w3.org] 
> Sent: Sunday, April 01, 2012 1:07 PM
> To: public-tracking@w3.org
> Cc: Alan Chapell; Jeffrey Chester; Shane Wiley; Jonathan Mayer; David Singer; John Simpson
> Subject: Re: ACTION-152 - Write up logged-in-means-out-of-band-consent
> 
> Alan, 
> 
> 1/ we do not set standards at W3C, we issue Recommendations. Being involved in 
> more traditional standardization, I know the difference between both and I'm 
> happy to explain, but I assume you know this at least as much as I do. 
> 
> 2/ We do technical specification here. And this means we define a certain 
> header that comes with a HTTP GET request. Now we define what the server 
> should do in case the server receives that header and wants to be compliant to 
> the Recommendation. "Out-of-band" is creating the trouble, because it imports 
> troubles from outside in our definition space and we have to decide in how far 
> we accept that (see below)
> 
> 3/ Whether our factual specifications are accepted as "consent", "meaningful 
> consent" or "informed consent" is not up to the Group as those definitions are 
> under a different sovereignty. But what we can discuss is whether we want to 
> align with requirements as defined elsewhere. We do that e.g. by trying to get 
> some EU blessing with our tool so that it is really really useful for industry 
> there and by inviting those others to our table.
> 
> So, to me, the consent discussion is a wrong discussion here, but has some 
> merit. The problem of ISSUE-115 is that a user may not be consciously logged 
> in. (see my other email).  By allowing any "out-of-band" agreement to trump 
> DNT, ALL other sovereign definitions will trump DNT, whatever they are. This 
> will open the path back to the deep legalese that allows for all those nice 
> surprises*. And this is just giving in to any outside authority to invent 
> something that may serve as an argument to ignore the DNT signal and STILL 
> claim compliance. Accordingly, we are back into reading 22 pages of legalese 
> as they can tell whether the DNT signal will be ignored. And this would even 
> be compliant. This being compliant affects the value of the W3C Specification. 
> And W3C is the venue where we talk about W3C Specifications. That's why I 
> think we have a right to discuss criteria to put limitations on arbitrary 
> "out-of-band" agreements and when we accept that those can compliantly top the 
> W3C Specification. 
> 
> This gives us a truckload of choices:
> 
> 1/ Try to really understand what Shane wants to avoid and define this to get 
> the Spec closer to reality
> 
> 2/ Re-consider JC's solution to give DNT a meaning in a logged-in scenario 
> (David, I disagree that this would be too subtle)
> 
> 3/ require "direct interaction"
> 
> 4/ explore the browser-maker outrage if we start telling them they should show 
> us when we are logged in to something
> 
> 5/ Define the meaning of "logged in" for the compliance with the W3C 
> Specification
> 
> etc ... 
> 
> If we brainstorm, there are more solutions..
> 
> Best, 
> 
> Rigo
> 
> *My favorite example was that by buying a coffee maker you subscribed to 
> receiving a pound of coffee every week for 5 years at an outrageous price. 
> (Court decision, Germany, 1957) 
> 
> On Thursday 29 March 2012 12:10:39 Alan Chapell wrote:
>> I don't think the issue is regarding 'commitment' to meaningful consent. The
>> issue is whether this is the appropriate forum to set pan-world standards
>> for consent. Hence, I await some clarification from our co-chairs on
>> process.
>

Received on Monday, 2 April 2012 14:36:48 UTC