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

Re: ISSUE-45 ACTION-246 Clarified proposal on compliance statements

From: David Wainberg <david@networkadvertising.org>
Date: Tue, 09 Oct 2012 10:25:24 -0400
Message-ID: <507433D4.8050502@networkadvertising.org>
To: Ed Felten <ed@felten.com>
CC: "public-tracking@w3.org" <public-tracking@w3.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

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:58 UTC