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

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

From: Alan Chapell <achapell@chapellassociates.com>
Date: Mon, 02 Apr 2012 11:40:28 -0400
To: Rigo Wenning <rigo@w3.org>, <public-tracking@w3.org>
CC: Jeffrey Chester <jeff@democraticmedia.org>, Shane Wiley <wileys@yahoo-inc.com>, Jonathan Mayer <jmayer@stanford.edu>, David Singer <singer@apple.com>, John Simpson <john@consumerwatchdog.org>
Message-ID: <CB9F3F34.1837F%achapell@chapellassociates.com>
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 15:41:00 UTC

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