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

It wouldn't make sense to allow servers to create their own definitions of
compliance, and at the same time to require UAs to treat all of those
definitions as equivalent.

A reasonable user experience would seem to require that some possible
definitions are treated as "strong enough to be considered real DNT" and
other possible definitions are not.  If this working group does not decide
what is "strong enough to be considered real DNT" then it seems very likely
that UAs will end up making that distinction.

On Wed, Sep 5, 2012 at 12:11 PM, Shane Wiley <wileys@yahoo-inc.com> wrote:

> Justin,****
>
> ** **
>
> I believe it could be helpful in both places but I’m struggling to
> understand how a UA would do ANYTHING other than communicate the compliance
> element to the user.  Are you suggesting UAs would make personal choices
> for users and provide different functionality based on the compliance
> approach of the Server?****
>
> ** **
>
> Allowing companies to articulate their compliance approach as a coded
> element is in no way “fracturing” DNT.  The TPE will work completely as
> intended with this field in place.  ****
>
> ** **
>
> - Shane****
>
> ** **
>
> *From:* Justin Brookman [mailto:justin@cdt.org]
> *Sent:* Wednesday, September 05, 2012 9:03 AM
>
> *To:* public-tracking@w3.org
> *Subject:* 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 <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****
>
> 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.*****
>
>  ****
>