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

As I understand the current draft, nothing requires a UA to treat servers
differently depending on the server's compliance status.  But nothing
prohibits that kind of differential treatment either.

The existence of the machine-readable response (header and TSR) implies
that we think the UA might want to behave differently depending on the
content of those responses.


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

> Ed,****
>
>
> The UA is sending a user’s preference to a Server – that’s it.  The Server
> responds to that preference request.  Where in the standard does a UA make
> individual transactional choices based on the compliance of the Server?***
> *
>
> ** **
>
> - Shane****
>
> ** **
>
> *From:* Ed Felten [mailto:ed@felten.com]
> *Sent:* Wednesday, September 05, 2012 9:23 AM
>
> *To:* <public-tracking@w3.org>
> *Subject:* 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.*****
>
>  ****
>
> ** **
>