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

James,

The codified approach is intended to point to established and enforced self-regulatory codes of conduct and there isn't a "90 day" self-regulatory code in place today so this example wouldn't work.  Instead, the current C&S draft already requires organizations to publically publish their individual data retention periods for Permitted Uses, so through that compliance approach this information would already be available to a user.

- Shane

-----Original Message-----
From: Grimmelmann, James [mailto:James.Grimmelmann@nyls.edu] 
Sent: Friday, September 07, 2012 6:29 AM
To: Shane Wiley
Cc: Rigo Wenning; public-tracking@w3.org; David Wainberg; Grimmelmann, James
Subject: Re: ISSUE-45 ACTION-246: draft proposal regarding making a public compliance commitment

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 14:35:34 UTC