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

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./