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

Hi All,

There are lots of assumptions and accusations flying around in this 
discussion which are not helpful.  Can we please back up for a second?  
This proposal arose out of a working group call two weeks ago, during 
which I pointed out the potential legal landmine introduced by the 
notion of making the WKL in and of itself a public commitment of 
compliance with the W3C DNT standard. This led to a discussion of the 
diversity of actors that will be attempting to implement DNT, and the 
fact that there will necessarily be relevant distinctions in how they 
implement. I took an action item to propose an approach that better 
accommodates this diversity without creating a legal landmine. This is 
all this is -- an idea for dealing with the two issues that were 
identified on the call.  We are -- and continue to be - working on this 
in good faith and nothing has changed about anyone's commitment to 
anything.

Notwithstanding concerns about complexity and user confusion (which I'll 
address), it is my personal opinion, as I've already stated, that the 
current proposed language will inhibit wide adoption of the full spec. I 
think we're all agreed that the desirable outcome is to have something 
reasonable that will be widely used.

Regarding complexity and user confusion, I believe that users may not 
understand the W3C DNT spec any better than they understand privacy 
policies. Lawyers and engineers are going to have a difficult time 
determining exactly what the spec says can and cannot be done. In almost 
all cases, I believe that users' understanding will come from what's 
presented in the UA's UI and in the media.  It does concern me that we 
have almost zero control over either, and I expect that given where the 
spec is going, there will be a considerable delta between users' ideas 
about what DNT means and what DNT actually means. I fear this may be 
largely due to the fact that we're stuck with the term "track," which we 
are unable to define in a way that is consistent with the WG's policy 
aims and the common understanding of the meaning of the word.

Given that, the TPWG is making choices on users' behalf based on what 
the TPWG thinks should be reasonable, regardless of what common 
understanding is. So let's be clear that what's important is that in any 
case DNT means something in the ballpark of what a reasonable user would 
expect. This can be accomplished in many ways, and as long as it is 
reasonable, it's not going to make things substantially more confusing. 
The confusion will stem from the way the choice is represented to users.

So, this is the problem we have to solve. We need a standard that is 
reasonable for everyone, including the businesses that will be affected 
by it; that is relatively consistent with common understanding and 
expectation; that is not unnecessarily rigid and does not become 
calcified; and that will be widely adopted. My proposal was intended 
with those aims in mind.

-David

On 9/5/12 12:06 PM, Shane Wiley wrote:
>
> Aleecia,
>
> I believe this proposal and the strong support within IRC during the 
> working group call would officially declare this as NOT a dead end.  
> It would be helpful to gauge the working group as I believe you'll 
> find considerable support for a compliance flag within the well-known 
> location resource.
>
> - Shane
>
> *From:*Aleecia M. McDonald [mailto:aleecia@aleecia.com]
> *Sent:* Wednesday, September 05, 2012 9:00 AM
> *To:* public-tracking@w3.org (public-tracking@w3.org)
> *Subject:* Re: ISSUE-45 ACTION-246: draft proposal regarding making a 
> public compliance commitment
>
> Of note: in Seattle, we discussed the possibility of having multiple 
> codes to indicate different flavors of DNT. Specifically, I raised it 
> as a suggestion. The WG members soundly rejected, in favor of coming 
> to a common single understanding of DNT. We have already declared this 
> a dead end.
>
> One can imagine a world with, say, a DAA approach and a W3C approach, 
> without needing a new flag sent with every response. Just pick 
> different semantics. It will be very clear which is what, without the 
> overhead. If that is the problem you are trying to solve, I think it 
> is already solved without needing any work here.
>
> If we take this just as being about different regions, I'm not sure 
> what a USA or NLD designation entails. And I'm not sure how to convey 
> that to users. I think I do not understand what you have in mind yet. 
> I look forward to hearing more about how you think that could work.
>
> Aleecia
>
> On Sep 4, 2012, at 5:51 PM, David Wainberg 
> <david@networkadvertising.org <mailto:david@networkadvertising.org>> 
> wrote:
>
>
>
> This fulfills ACTION-246 
> (http://www.w3.org/2011/tracking-protection/track/actions/246), which 
> relates to ISSUE-45 
> (http://www.w3.org/2011/tracking-protection/track/issues/45).
>
> There are problems with the current proposed approach to issue 45. The 
> current version does not accommodate implementation distinctions based 
> on, for example, geography/jurisdiction, business model, or 
> technology. It also creates unnecessary and counter-productive legal 
> landmines that will spur companies to avoid implementing the full 
> spec. We can provide for making legal commitments without this 
> unwanted result.
>
> I think the first point should be obvious. There will be a tremendous 
> diversity of organizations, business models, and technologies to which 
> DNT may be applied, either voluntarily or compulsorily, under a 
> diversity of regulatory regimes. The spec needs to accommodate this 
> diversity.
>
> The more important point is that, if we make the mistake of tying the 
> server response (the header or WKL) to a broad, legally-binding 
> representation that goes well beyond the specific meanings of the 
> responses, end-users will lose out because companies will avoid 
> implementing the response mechanisms. The reality is that companies 
> who may otherwise be eager to implement DNT will avoid making 
> representations that could be construed in overly broad ways, that may 
> be ambiguous, or that otherwise are potentially misaligned with what 
> they do. Instead, companies will seek to make representations that 
> unambiguously describe their practices. We should facilitate this, not 
> make it difficult.
>
> Note that I am definitely not saying that companies should be able to 
> act contrary to what they represent in the response mechanism(s). 
> That, however, is not a problem we need to solve. Companies will be 
> held to account for any such misrepresentations anyway, regardless of 
> what the spec says. And if the available responses are sufficiently 
> precise and adequately defined, I think companies will implement them.
>
> This proposal solves both problems. It will provide for the 
> enforceable statement that the working group is aiming for, but it 
> will also allow needed flexibility for servers operating under various 
> regulatory regimes, and would do so especially for servers operating 
> under multiple regulatory regimes. And, most important, it would 
> create a mechanism whereby companies can clearly and accurately say 
> what they do and then do what they say.
>
> The proposal is the following:
>
>   * /The compliance spec remains silent on the matter/
>   * /Add a required "compliance" field to the tracking status resource
>     in the TPE, where the value indicates the compliance regime under
>     which the server is honoring the DNT signal./
>   * /The value of the compliance field is a 3-5 letter token
>     indicating the applicable regulatory regime. Allowed tokens could
>     include 3-letter country codes, e.g. USA, GBR, NLD, or
>     designations for voluntary regimes, e.g. W3C, DAA, NAI, IABEU. My
>     understanding is that an organization like IANA can manage a list
>     of tokens in order to prevent collisions./
>