W3C home > Mailing lists > Public > public-tracking@w3.org > April 2012

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

From: Jonathan Robert Mayer <jmayer@stanford.edu>
Date: Mon, 2 Apr 2012 09:47:01 -0700 (PDT)
Message-Id: <AB3B14BD-CA7A-43BC-85B8-DC7F7CEB299E@stanford.edu>
To: Shane Wiley <wileys@yahoo-inc.com>
Cc: Lee Tien <tien@eff.org>, Alan Chapell <achapell@chapellassociates.com>, Rigo Wenning <rigo@w3.org>, "public-tracking@w3.org" <public-tracking@w3.org>, Jeffrey Chester <jeff@democraticmedia.org>, David Singer <singer@apple.com>, John Simpson <john@consumerwatchdog.org>
Shane,

Could you please explain how a term buried in a privacy policy is "real-time, in experience information" that constitutes "consent in context"?

Thanks,
Jonathan

On Apr 2, 2012, at 9:35 AM, Shane Wiley <wileys@yahoo-inc.com> wrote:

> Lee,
> 
> As DNT signals come with very little consumer education (single check box - not defined - no detail - no context), I believe out-of-band consent structures are the "higher-quality signal" as they provide real-time, in experience information and capture consumer consent in context.
> 
> - Shane
> 
> -----Original Message-----
> From: Lee Tien [mailto:tien@eff.org] 
> Sent: Monday, April 02, 2012 9:29 AM
> To: Alan Chapell
> Cc: Rigo Wenning; public-tracking@w3.org; Jeffrey Chester; Shane Wiley; Jonathan Mayer; David Singer; John Simpson
> Subject: 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:47:33 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:27 UTC