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

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 
> < <>> 
> wrote:
>     ACTION-246
>     (,
>     which relates to ISSUE-45
>     (
>     Hello all,
>     This is a clarification of my previous proposal
>     (
>     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