- From: Justin Brookman <justin@cdt.org>
- Date: Wed, 05 Sep 2012 12:03:03 -0400
- To: "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <504777B7.1000303@cdt.org>
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./ >
Received on Wednesday, 5 September 2012 16:03:41 UTC