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

On Tue, Oct 9, 2012 at 4:25 PM, David Wainberg <david@networkadvertising.org
> wrote:

>  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?
>
>  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.

>  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.

> 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
>>
>>
>
>