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

Is it perhaps useful to think of the consent issue in terms of internal consistency or coherence?

IMHO the DNT mechanism -- user making a deliberate choice to set it at 1 or 0 -- has an inherent consent element, aspect, flavor, whatever you want to call it.  And I think part of our thinking here is that servers can rely on it as the consumer's expressed preference because it's a high-quality signal.  

So the issue seems to me NOT about anyone's law, but rather that the DNT spec is internally consistent, doesn't create an "arbitrage" that undermines it.  (Part of that, I think, also has to be what we think users who indeed chose DNT:1 expect, but internal consistency may be the easier way to approach.)

Lee


On Apr 2, 2012, at 8:40 AM, Alan Chapell wrote:

> I'm having a hard time understanding some of your arguments. You say the
> group should not be creating standards for consent. And then you also say
> that we are creating a consent requirement - and one which others have
> indicated should be outlined in considerable detail. Sorry, but I'm afraid
> you've lost me.
> 
> And I don't believe we are here because regulators are unable to determine
> standards of fairness for their jurisdiction. If the goal is to set out a
> detailed level of requirements around 'consent' that will work in every
> jurisdiction, then I think we're in for a long discussion that will push
> the development of our spec out several months.
> 
> 
> 
> 
> 
> On 4/2/12 11:25 AM, "Rigo Wenning" <rigo@w3.org> wrote:
> 
>> On Monday 02 April 2012 09:54:26 Alan Chapell wrote:
>>> On 4/1/12 4:06 PM, "Rigo Wenning" <rigo@w3.org> wrote:
>>>> 1/ we do not set standards at W3C, we issue Recommendations. Being
>>> 
>>> Thanks for the clarification, Rigo. You may want to direct this to
>>> Jonathan and Jeff - as they are the ones that seem to be pushing for
>>> this
>>> group to create consent standards. (Jonathan and Jeff - if there's a
>>> nuance I'm missing, please let me know.)
>> 
>> I think they understand that the consent requirement we would create are
>> scoped solely to the compliance of the W3C Specification and not some
>> general rule as only a legislator can issue it (and there are over 192 of
>> those world wide)
> 
> 
>> 
>> [...]
>>>> 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.
>>> 
>>> I'm not sure how aligning with a single jurisdiction's definition of
>>> consent isn't tantamount to creating a pan-world consent standard based
>>> upon that single jurisdictions laws. What works in the EU may not work
>>> elsewhere. Again - I may be missing a nuance here.
>> 
>> I think you are. Please do not overlook the "e.g." I wrote. It is the
>> other 
>> way around. We do some technical specification and it is on every region
>> to 
>> accept that and give it a useful role in their system (or not). And we
>> would 
>> be ill advised not to take into account feedback whether our stuff is
>> useful 
>> in a regional system or not. But W3C is not the organization that can
>> decide 
>> on whether our Specifications are useful in a certain region. So the EU
>> will 
>> decide on EU things and the US will decide on US things. And we can use
>> the 
>> W3C platform to provide a tool. Or fall back into the trenches.
>> 
>> [...]
>>>> This
>>>> will open the path back to the deep legalese that allows for all those
>>>> nice
>>>> surprises*.
>>> 
>>> I like the coffee example - But the FTC and other regulators already
>>> have
>>> recourse if a business engages in these types of surprises. Do you
>>> agree?
>> 
>> We wouldn't be here if the regulators had a better idea on how to solve
>> those issues. They let us try as they think the industry has the
>> technical 
>> experts and maybe something useful comes out before they do some SOPA
>> on the industry.  So this is an opportunity the regulator gives us, not
>> an 
>> argument to fall back on letting the regulator do stuff. I encourage you
>> to 
>> see our effort here as an opportunity. At least I see it like this.
>> 
>>>> 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.
>>> 
>>> Again - regulators are free to take action to the extent they believe
>>> that
>>> 22 pages of legalese are unfair or deceptive based upon that
>>> jurisdictions
>>> legal framework.
>> 
>> You misunderstood IMHO. It is on W3C to decide what should be compliant
>> to 
>> W3C DNT and it will use its process to come to a fair result. W3C decides
>> on 
>> W3C Specifications. And if W3C, within the process, decides that some
>> "out 
>> of band" event hidden in 22 pages of legalese is not sufficient to claim
>> compliance with the W3C Specification, then W3C is just deciding on its
>> Specification, not on the US or EU legal system. See my email to Shane to
>> understand that you can't have the cake and eat it too. (But you can
>> always 
>> try)
>>> 
>>>> This being compliant affects the value of the W3C Specification.
>> 
>>> 
>>> I think Shane has been pretty clear here. User consent trumps DNT.
>> 
>> In terms of a US legal perspective, you may be right. I haven't assessed
>> any 
>> of that. But there is no consent in the Group that out of band agreements
>> allow you to ignore the signal and still claim compliance with the W3C
>> DNT 
>> Specifications. And unless we accept Shane's wording, which I'm against,
>> I 
>> wouldn't agree that the requirements of the DNT Specifications are
>> fulfilled 
>> by ignoring the DNT signal thus allowing someone to claim compliance.
>> 
>>> 
>>>> 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
>>>> 
>> It is unfortunate that we do not look forward in a creative way and
>> consider 
>> some of the solutions. So far, you haven't considered the solutions
>> proposed 
>> above.
>> 
>> Best, 
>> 
>> Rigo
>> 
> 
> 
> 

Received on Monday, 2 April 2012 16:29:58 UTC