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

If it's not in the response header, it's arguably worse.  I don't think 
many consumers are going to be visiting the well-known location to 
determine how the 50 third parties on a given site define tracking, so I 
imagine that the user agents will be intermediating on their behalf.  I 
would imagine that would be easier if the values were in the response 
header.

Either way, the fracturing of DNT is an inescapable problem.  What's the 
point of a compliance spec if anyone can define compliance as they like?

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/5/2012 11:57 AM, Shane Wiley wrote:
>
> Justin,
>
> I'm not sure this was intended for the Response Header.  Would you 
> feel more comfortable with a "Compliance" field in the well-known 
> location?  This information is more for the consumer than it is for 
> the UA.
>
> - Shane
>
> *From:*Justin Brookman [mailto:justin@cdt.org]
> *Sent:* Wednesday, September 05, 2012 8:46 AM
> *To:* public-tracking@w3.org
> *Subject:* 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  <mailto: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./
>