- From: David Wainberg <david@networkadvertising.org>
- Date: Tue, 09 Oct 2012 10:25:24 -0400
- To: Ed Felten <ed@felten.com>
- CC: "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <507433D4.8050502@networkadvertising.org>
Hi Ed, Thanks for the questions. On 10/9/12 10:01 AM, Ed Felten wrote: > > First, why include only one compliance token? If there are multiple > compliance regimes, a company might be following any subset of them. > Why not allow a server to provide multiple compliance tokens? > I suppose it could be allowed, though I'm not sure of the utility. Is there a use case you had in mind? > 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." > > 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 14:25:39 UTC