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

To create a healthy ecosystem it is also necessary for users to be able to express a range of options and for websites to be able to adapt to the users expressed option.

Use case: A US online store wants to adapt its DNT response to meet the expectations of customer from the EU (who may not be located in the EU).  The EU customer needs to be able to express the compliance standard and the DNT option within this standard, and the website needs to be able to indicate the accepted compliance standard and the accepted DNT level.

Could I ask where this leaves the W3C DNT compliance spec?   With your proposal, are user groups free to define their own definition of DNT and to champion its adoption by creating extensions that block resources that do not comply?

Other compliance specs. may well have a range of DNT expression options and their own response tracking status values.  Perhaps the DNT header and response could be qualified by the compliance spec. and thus be specific to each.

This approach would appear to be abdicating the meaning of DNT, but given the current meaningless definition perhaps this is the best that can be done in this forum.

This group should have been the forum to define interoperable expression and response definitions, or at least a compliance spec. that is meaningful to users.

cheers
Fred


Date: Tue, 9 Oct 2012 09:22:15 -0400
From: david@networkadvertising.org
To: public-tracking@w3.org
Subject: ISSUE-45 ACTION-246 Clarified proposal on compliance statements


  

    
  
  
    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