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

Aleecia,

The proposal pertains to an open issue: ISSUE-45, which seeks a means 
for companies using DNT to make public commitments for purposes of 
creating a "regulatory hook." The proposal was submitted in response to 
an action item assigned to me on a working group call two weeks ago,  
and fulfills the aim of ISSUE-45, while avoiding the problems identified 
in the current proposed language. If, after discussion, participants in 
the working group feel this is not an appropriate solution to ISSUE-45, 
that's one thing, but we should provide the same opportunity for this 
proposal to be considered as we would for any other proposal.

-David

On 9/6/12 5:01 AM, Aleecia M. McDonald wrote:
> In case this wasn't clear from my prior message, the group considered 
> and rejected the multiple standards approach in Seattle. (Regional 
> designations were not considered; that is new.) To quote our documents:
>
> The chairs may re-open issues if a participant brings information not 
> previously considered by the group, and proposes a concrete 
> alternative to the recorded decision that takes this information into 
> account. "I don't like this decision" is not a sufficient reason to 
> re-open an issue.
>
> I currently see neither new information nor an actual proposal for 
> multiple standards.
>
> Aleecia
>
> On Sep 5, 2012, at 9:00 AM, Aleecia M. McDonald <aleecia@aleecia.com 
> <mailto:aleecia@aleecia.com>> wrote:
>
>> 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./
>>>
>>>
>>
>