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

This adds an incredible amount of complexity to the DNT standard.  Under 
this proposal, the response header is now expected to include a value 
that corresponds to any number of policy statements on what the header 
should mean.  The point of the W3C standardization is to come up with 
one consistent approach; not a platform for any number of other 
authorities to message their own.  This puts a lot of burden on user 
agents (and users) to intermediate these potentially ever-multiplying 
definitions of what all the third parties on a site interpret DNT:1 to mean.

I think the existing text is substantially more reasonable for everyone 
involved.  I think even silence would be preferable to this approach as 
well.  Let's come up with a reasonable standard on what DNT:1 means, and 
servers can message whether they're not tracking as described in that 
standard.  This is not intended to be a compliance tool for every 
regulatory and self-regulatory regime around the world.

Justin Brookman
Director, Consumer Privacy
Center for Democracy&  Technology
1634 I Street NW, Suite 1100
Washington, DC 20006
tel 202.407.8812
fax 202.637.0969
justin@cdt.org
http://www.cdt.org
@CenDemTech
@JustinBrookman


On 9/4/2012 8:51 PM, David Wainberg 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./
>
>