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

Thanks, David.   I have two questions regarding your proposal.

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?

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?

On Tue, Oct 9, 2012 at 3:22 PM, David Wainberg <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
>
>