Re: ISSUE-45 ACTION-246: draft proposal regarding making a public compliance commitment

Aleecia,

Thanks so much for this. You've pointed out an important 
misunderstanding that may have fanned the flames of concern over this 
proposal. As often happens, I was not as clear as I could have been. The 
intent was definitely not a proliferation of tokens to indicate a 
variety of practices, but rather a limited set to identify a small 
number of flavors of DNT. Also, it was not intended to allow a single 
organization to claim multiple versions of DNT (except in the case where 
they might be operating in multiple jurisdictions and would need to 
distinguish for various users and/or sites). So, yes, your conjecture 
about a more limited set is absolutely right on. And it would not be a 
general purpose tool, as it would be solely related to expressing and 
honoring a user's DNT choice.

(Note that the IANA suggestion was only because I thought that even with 
a relatively small number of tokens, a definitive list would need to be 
held somewhere, and my understanding is that's what IANA does.)

-David

On 9/7/12 11:19 AM, Aleecia M. McDonald wrote:
> I'll need to let the author(s) respond, but I did not read the proposal to have a <variable> <value> sort of approach directly. Rather it was more the idea of having a bundle of things under a common token, like "US" and that means twenty different things, or "DE" and that means a slightly different set of twenty-two things, or possibly the same twenty things with differing values. That part of the proposal was not fully explained. And perhaps a bundle of things is what Professor Grimmelmann also means with his 90DAY example: that behind that token there would be a bunch of settings that all resolve to "yes, we collect and retain this data" in each case down the line, but that there would also be a retention of 90 days for all of them. It is not clear if the original proposal was to create one syntax and let others decide upon different values, or if it is to allow multiple syntaxes as well. But even without details of what is envisioned, there are a few things that are worth remembering.
>
> We are barred by charter from two things. One is specifying UI. The other is building a general purpose tool. Rigo refers to this as a bucket maker rather than a bucket, which is a useful analogy. If you'd care to review, see http://www.w3.org/2011/tracking-protection/charter in section 1.2 -- it's a quick read.
>
> In both cases of what is out of scope by charter, there is the question of "just how far can we go?" We might give some guidance around a UI without saying, "you must have a green button with a 12 point font." There may be some things we can say about UI even though we cannot specify it, and stay inside what the charter allows, though getting close to the edge. Similarly, we might imagine a very few buckets (a few sets of defined tokens with different defined policy meanings) and still saying what we're doing is not general purpose, though getting close to the edge.
>
> I expect that any proposal that includes asking IANA to keep track of a proliferation of tokens is not going to be in accordance with the prohibition of building a general purpose tool. I would need to see a fully-specified proposal, but the direction as described for multiple national rulesets does not seem like something we could take up.
>
> Similarly, the idea of having multiple versions of what DNT means to a specific organization -- a set of flags for W3C style, DAA style, TRUSTe style, Stanford style, Microsoft style, Mozilla style, Tiger style -- also sounds like it will run into the prohibition on building general purpose tools.
>
> And now into conjecture land -- What if there were only two or three flags, perhaps W3C, DAA, and an ePriv or EU. Would that be barred by charter, to have three? Is that general purpose? Maybe. Maybe not. I expect the W3C staff and co-chairs would talk that through, and the details of a proposal would be an important part of that discussion.
>
> I hope this is helpful as a reminder on the process side, so we do not waste too much collective time on things that will not be able to move forward.
>
> 	Aleecia
>
> On Sep 7, 2012, at 6:29 AM, "Grimmelmann, James" <James.Grimmelmann@nyls.edu> wrote:
>
>> Just to be clear on the implications:
>>
>> Under this proposal, a server could communicate a Tk:3 tracking status value, and have a tracking status resource with a compliance field including the token 90DAY, which indicates that the server deletes all tracking information after 90 days but otherwise does not limit the tracking it performs.  Under this proposal, this hypothetical server would be in compliance with TPE, and the requirements of TCS would not be relevant to it because it is operating under the 90DAY compliance standard instead, and it represents this fact to the user and to the public.
>>
>> Do I have this right?
>>
>> Thanks,
>> James
>>
>> --------------------------------------------------
>> James Grimmelmann   	          Professor of Law
>> New York Law School                 (212) 431-2864
>> 185 West Broadway       james.grimmelmann@nyls.edu
>> New York, NY 10013    http://james.grimmelmann.net
>>
>> On Sep 7, 2012, at 2:33 AM, Shane Wiley <wileys@yahoo-inc.com> wrote:
>>
>>> Rigo,
>>>
>>> More than happy to speak live on this topic.
>>>
>>> I agree that "EU data protection law is too complex to express compliance in a simple tools like DNT" if you look only at the signal in isolation but strongly disagree when you pair this with appropriate consent language backed by clear user communication on the compliance approach taken to uphold the user's preference.  It's the latter part of this equation we're discussing making make easier for users and supporting entities.
>>>
>>> While this group may not deem a Server to be compliant (at this time) if they set their compliance standard as something other than the W3C C&S document, it will be possible for a Server to fully support TPE communication elements and specify in their privacy policy the details of their DNT support approach.  The goal here is to make that linkage easier to find and understand (in an automated fashion).  We already have resource options for Servers to communicate their compliance approach to users in plain text but these are not codified.  By moving to a codified approach we enable users, advocates, regulators, 3rd party auditors, UAs, etc. to quickly assess the compliance approach taken by that Server.
>>>
>>> Whether this group considers that Server to be W3C DNT "policy" compliant is not critical to the technical operation of website.  That's like saying a website is not HTML5 compliant if they don't follow a non-technical business rule of the HTML5 specification.  What's important is that their implementation doesn't break the UA's HTML5 implementation.  Technical breakage generally equates to non-compliance in the W3C universe of standards (and the Server and UA finger pointing begins :-) ).
>>>
>>> - Shane
>>>
>>> -----Original Message-----
>>> From: Rigo Wenning [mailto:rigo@w3.org]
>>> Sent: Thursday, September 06, 2012 12:51 PM
>>> To: Shane Wiley
>>> Cc: public-tracking@w3.org; David Wainberg; Grimmelmann, James
>>> Subject: Re: ISSUE-45 ACTION-246: draft proposal regarding making a public compliance commitment
>>>
>>> Shane,
>>>
>>> I'm reluctant to explain, because people feel like I sound like a broken record before the understanding comes. I had that experience in the past research projects. Keep that in mind. I doubt, we should phone.
>>>
>>> On Thursday 06 September 2012 11:13:16 Shane Wiley wrote:
>>>> Could you explain why a Server couldn't respond to a DNT:1 signal with
>>>> the compliance regime they are upholding in the context of honoring
>>>> that user's DNT:1 signal?
>>> You get the answer by translating the signals exchanged back into a human readable context. The DNT protocol starts with a user preference expression. The compliance document fills the content of that preference expression. "DNT:1" as a string is rather meaningless without the assumption that it expresses the user's expectation that a service complies with the things given in the compliance Specification. The Service can only respond ack or nack to that. Every other response is actually a new offer for a different agreement. In other words, you enter into a new negotiation. Now the Service has not accepted the terms offered by the User and offers new terms (DNT:1 OBA). In this case, the user would respond that his preference is DNT:1 GER. This will give you so many semantic mismatches that it will end in a meaningless exchange of messages. The french call it dialog of the deaf.
>>>> If a user in the UK sends a DNT:1 signal to a Server in Ireland,
>>>> couldn't the Server reply to the DNT:1 that it is both honoring the
>>>> DNT:1 signal and following the EDAA code of conduct to do so?
>>>> How does this break EU law?
>>> What we do here is very independent of EU Law. We take EU Law into account to provide a useful tool that EU Law can take up to accomplish things in certain areas (consent expression). But DNT itself is not a means to express compliance to EU Law. Because it starts with the user preference. And because EU data protection law is too complex to express compliance in a simple tools like DNT. And because the user preference is the center of all our considerations.
>>>
>>> If compliance and followed practice is in the center of our attention, we would start the protocol by having the service stating their followed practices to the user. That's P3P. The fundamental difference is the starting point. In DNT, the service has a choice whether or not to continue the interaction under the user's preference. In a compliance regime (we follow OBA) the user has to get information to be able to chose whether to continue or not. The latter is the third step in DNT we call exception mechanism.
>>>
>>> So if you want to express compliance other than "I honor the user's well defined preference", we have to change the protocol to have the service start the exchange. We may marry both in the future. We have done P3P 10 years ago (and times have changed). Now lets do DNT and only then marry the two. David's attempt to marry them now is technologically unwise and complexes a situation that is already so complex that often even experts have trouble to fully understand what this is all about. So one thing at a time please...
>>>
>>> Rigo
>>>
>>
>>
>

Received on Friday, 7 September 2012 16:07:54 UTC