- From: David Wainberg <david@networkadvertising.org>
- Date: Tue, 09 Oct 2012 14:41:50 -0400
- To: Ed Felten <ed@felten.com>
- CC: "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <50746FEE.7040100@networkadvertising.org>
On 10/9/12 11:19 AM, Ed Felten wrote: > A company that collected only minimal information would presumably be > in compliance with all, or almost all, of the compliance regimes in > existence. If I were that company, I wouldn't want to miss out on the > benefits of claiming any compliance regime that a particular user or > browser might be looking for. > > In general, there would a number of regimes, and a server might be in > compliance with various subsets of them. Again, servers won't want to > miss out on the benefits of claiming any compliance regime that a > particular user or browser might be looking for. I find it hard to imagine it happening in practice that companies would try to claim multiple tokens at the same time. Perhaps they would adhere to different regimes depending on context, e.g. the geo of the user, but it would only be one per request. Also, there is contemplated in the tech spec a "N" signal for this purpose, yes? Although I've opposed including that, doesn't it address the case you're describing? > >> Second, do you envision some body that decides which compliance >> tokens are valid? If so, who might that be? If not, how do >> you prevent people from making up their own new compliance tokens? > I would expect it to be unusual to do this, and it might be a > self-correcting problem in the small number of cases. Given that > the tokens companies use will be transparent, advocates and > regulators will be able to investigate non-standard tokens. A > non-standard token will be a red flag that says, "hey, we're doing > something unusual." > > If there is no body or procedure deciding which tokens are allowed, > then there cannot be "non-standard" tokens. There can only be unusual > tokens. I still don't see what would stop a company, or small group > of companies, from just creating their own compliance rules and > sending the resulting token. Either there is somebody or something > deciding which tokens are valid; or all tokens are valid. What's to stop companies now from writing whatever they want in their privacy policies? This token idea would generate a small set of widely accepted tokens. Unlike with privacy policies, anyone doing something outside that small set would be machine-discoverable. But, even though I think it would work that way, I'm open to discussing ideas to standardize the set of tokens, if others are interested in that. I think I left that open in the proposal. >> On Tue, Oct 9, 2012 at 3:22 PM, David Wainberg >> <david@networkadvertising.org >> <mailto:david@networkadvertising.org>> wrote: >> >> 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). >> >> Hello all, >> >> This is a clarification of my previous proposal >> (http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0012.html). >> I'm launching it on a fresh thread, because the previous one >> got a bit wild and off-topic. >> >> Recall that this arose out of the problem of how or where >> parties may or must make statements regarding their DNT >> compliance. One proposal, which many of us strongly objected >> to, was to make provision of the tracking status resource in >> and of itself an assertion of compliance with the DNT spec. >> That proposal was a replacement for an initial proposal to >> require a public statement of compliance, but without >> specifying where or how that statement must be made. >> >> The problems with these proposals are that the one is overly >> strict, does not provide any flexibility, and sets up a legal >> landmine that companies will avoid by not providing the WKL, >> and the other is too loose; it allows for potentially >> unlimited variation in how companies honor DNT and where and >> how they make their commitments to do so. >> >> This proposal solves these problems by requiring a statement >> in the status resource regarding compliance with /one of a >> limited set of DNT variations/. Although I understand the >> desire for and attractiveness of a single universal >> specification for DNT compliance, the reality is that we will >> have to accommodate some variation based on, e.g., business >> model, geography, etc. Examples of this problem arose during >> the Amsterdam meeting. If we want to ensure wide adoption and >> enforceability of DNT, this is the way to do it. >> >> The proposal is the following: >> >> 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. In >> 5.5.3 of the TPE: >> >> / A status-object MUST have a member named >> /_/compliance/_/that contains a single compliance mode token//./ >> >> From here, I look to the group for discussion regarding how >> and where to define compliance mode tokens. My initial >> version of this proposal suggested looking to IANA to manage >> a limited set of tokens to prevent collisions. I think there >> was some misunderstanding and concern about how this would >> work. No -- companies should not just create their own >> arbitrary values. My view is that each token must have a >> well-defined and widely-accepted meaning. How's this: >> >> /Compliance mode tokens //must be associated with a >> legislative or regulatory regime in a relevant jurisdiction, >> or with a relevant and established self-regulatory regime./ >> >> I'm open to other ideas for this. >> >> Cheers, >> >> David >> >> > >
Received on Tuesday, 9 October 2012 18:42:07 UTC