W3C home > Mailing lists > Public > public-tracking@w3.org > September 2012

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

From: Justin Brookman <justin@cdt.org>
Date: Wed, 05 Sep 2012 13:27:45 -0400
Message-ID: <50478B91.7050008@cdt.org>
To: "public-tracking@w3.org" <public-tracking@w3.org>
This doesn't address my concerns below.  David's proposal represents a 
sea change from what the group had been discussing over the last year 
and a half.  We've been intensely negotiating a definition of 
compliance, and now you want to make that definition optional?!  If 
you're saying that's all you think industry will be willing to do, 
that's an important data point, but it has severe limitations that 
seriously compromises the usefulness of the DNT setting for users and 
industry alike.

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 12:54 PM, Shane Wiley wrote:
>
> Justin,
>
>
> Was the ackFU a Fraudian slip?  LOL
>
> The core issue is that the current Compliance and Scope approach is 
> broken across several dimensions:
>
> ·First, it is primarily aligning with US considerations and will not 
> be acceptable in the EU.  Rob and Rigo -- please feel to chime in 
> here.  We need a way to convey compliance that is meaningful to the 
> user's environment and this mechanism provides that.
>
> ·Second, the goal of the W3C TPWG was to develop the technical 
> mechanism by which to convey a user's tracking preference and allow 
> servers to reply to that preference.  Today, only the ability to 
> convey a user's preference is in place (and not wholly at that).  The 
> Compliance & Scope document is not a requirement for the TPE to 
> operate fully and as intended.
>
> ·Third, there is still about user choice.  For users to make choices, 
> they need to have information to do so.  You've already been vocal 
> that you don't feel privacy policies are a useful consumer tool.  The 
> C&S doc approach is to force all online companies across the globe to 
> a single privacy policy.  While I appreciate the simplicity of that 
> model, it doesn't provide the flexibility for a vibrant, evolving, 
> innovative ecosystem.
>
> If the goal is still to build a standard that will be highly adopted 
> and implemented around the world (I don't believe many here keep that 
> reality check in mind), allowing for a Server to communicate its DNT 
> compliance standard to a user is critical.
>
> I don't believe there will be many variants (2 to 3 per region) so in 
> my opinion that's a red herring in this debate.
>
> - Shane
>
> *From:*Justin Brookman [mailto:justin@cdt.org]
> *Sent:* Wednesday, September 05, 2012 9:30 AM
> *To:* public-tracking@w3.org
> *Subject:* Re: ISSUE-45 ACTION-246: draft proposal regarding making a 
> public compliance commitment
>
> There has obviously been an undercurrent for a while that some folks 
> would like the spec to just define the syntax of DNT in the TPE spec 
> and to be completely silent as to what it means.  I remain opposed to 
> that approach for the reasons previously stated and reiterated here.
>
> Of course this fractures DNT.  If I go to a publisher, and 10 third 
> parties respond ackNAI, 10 respond ackIAB, 10 respond ackW3C, 10 
> respond ackUS, and 10 respond ackFU, that means those parties are 
> doing potentially very different things in response to the DNT:1 
> header which completely frustrates the purpose of standardization.  
> Users cannot reasonably be expected to keep track of the varying 
> regulatory and self-regulatory models and evaluate them.  I'm not sure 
> how user agents will respond to this panoply of response headers, but 
> it is conceivable that they will be configurable to only allow content 
> that ack in certain ways, or that add-ons will be available to do that 
> for them.  I think the balkanization of DNT would push us down the 
> TPL/ad block road, which from my point of view is a bad result --- I 
> would prefer to see the ecosystem define DNT:1 in a consistent way, 
> and respond to those headers by either serving non-tracking ads and 
> content, or requesting the user to grant an exception (or turn off DNT 
> entirely if the prompts get too annoying).
>
> Again, the value add here is the standardization of what the header 
> means.  The header is out there today --- any company can publicly 
> state that they follow NAI's opt out rules in response to the header 
> if they want to.  If the end result of this process is that the 
> meaning of the header is outsourced to whoever wants to define it, 
> then we have not solved the problem this group was tasked to address.
>
>
> 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/5/2012 12:11 PM, Shane Wiley 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 <mailto: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  <mailto: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 <mailto: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./
>
Received on Wednesday, 5 September 2012 17:28:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:33 UTC