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

Re: ISSUE-45 ACTION-246: draft proposal regarding making a public compliance commitment

From: Justin Brookman <jbrookman@cdt.org>
Date: Wed, 05 Sep 2012 22:00:37 -0400
To: public-tracking@w3.org
Message-ID: <20120906020037.f25e47e8@mail.maclaboratory.net>
David, I do not mean to ascribe any devious motivations to your proposal.  I'm just pointing out that substantively it cannot work.


Your argument on complexity and confusion does not make sense.  You say that the current spec may not match all users' expectations.  That may well be the case, but I fail to see how varying standards of uncertain rigor are less complex and confusing than one good faith, transparent, multistakeholder effort at determining a reasonable and workable definition of tracking.  I'm sorry, but your "in the ballpark" standard does not pass the laugh test and anyway is not reflected anywhere in your proposal (though I would enjoy drafting an FTC complaint with the subject heading "B. Ain't No #%$@$! Ballpark, Neither").  I agree on the need for flexibility, but the cost to the integrity of the Do Not Track standard is far too high.


As no one has tried to address the points I made earlier today, I see no need to reiterate them now.  This proposal saps the value of DNT to the companies engaging in this process, and offers consumers no assurance that their DNT settings will be meaningfully honored.
  _____  

From: David Wainberg [mailto:david@networkadvertising.org]
To: Shane Wiley [mailto:wileys@yahoo-inc.com]
Cc: Aleecia M. McDonald [mailto:aleecia@aleecia.com], public-tracking@w3.org (public-tracking@w3.org) [mailto:public-tracking@w3.org]
Sent: Wed, 05 Sep 2012 19:22:49 -0500
Subject: Re: ISSUE-45 ACTION-246: draft proposal regarding making a public  compliance  commitment

                        Hi All,
      
      There are lots of assumptions and accusations flying around in this      discussion which are not helpful.  Can we please back up for a      second?  This proposal arose out of a working group call two weeks      ago, during which I pointed out the potential legal landmine      introduced by the notion of making the WKL in and of itself a public      commitment of compliance with the W3C DNT standard. This led to a      discussion of the diversity of actors that will be attempting to      implement DNT, and the fact that there will necessarily be relevant      distinctions in how they implement. I took an action item to propose      an approach that better accommodates this diversity without creating      a legal landmine. This is all this is -- an idea for dealing with      the two issues that were identified on the call.  We are -- and      continue to be - working on this in good faith and nothing has      changed about anyone's commitment to anything.  
      
      Notwithstanding concerns about complexity and user confusion (which      I'll address), it is my personal opinion, as I've already stated,      that the current proposed language will inhibit wide adoption of the      full spec. I think we're all agreed that the desirable outcome is to      have something reasonable that will be widely used. 
      
      Regarding complexity and user confusion, I believe that users may      not understand the W3C DNT spec any better than they understand      privacy policies. Lawyers and engineers are going to have a      difficult time determining exactly what the spec says can and cannot      be done. In almost all cases, I believe that users' understanding      will come from what's presented in the UA's UI and in the media.  It      does concern me that we have almost zero control over either, and I      expect that given where the spec is going, there will be a      considerable delta between users' ideas about what DNT means and      what DNT actually means. I fear this may be largely due to the fact      that we're stuck with the term "track," which we are unable to      define in a way that is consistent with the WG's policy aims and the      common understanding of the meaning of the word.
      
      Given that, the TPWG is making choices on users' behalf based on      what the TPWG thinks should be reasonable, regardless of what common      understanding is. So let's be clear that what's important is that in      any case DNT means something in the ballpark of what a reasonable      user would expect. This can be accomplished in many ways, and as      long as it is reasonable, it's not going to make things      substantially more confusing. The confusion will stem from the way      the choice is represented to users.
      
      So, this is the problem we have to solve. We need a standard that is      reasonable for everyone, including the businesses that will be      affected by it; that is relatively consistent with common      understanding and expectation; that is not unnecessarily rigid and      does not become calcified; and that will be widely adopted. My      proposal was intended with those aims in mind.
      
      -David
      
      
On 9/5/12 12:06 PM, Shane Wiley wrote:
                                            
          

Aleecia,          

           

I              believe this proposal and the strong support within IRC              during the working group call would officially declare this              as NOT a dead end.  It would be helpful to gauge the working              group as I believe you’ll find considerable support for a              compliance flag within the well-known location resource.          

           

-              Shane          

           
            
              

From:                  Aleecia M. McDonald [mailto:aleecia@aleecia.com] 
                  Sent: Wednesday, September 05, 2012 9:00 AM
                  To: public-tracking@w3.org                  (public-tracking@w3.org)
                  Subject: Re: ISSUE-45 ACTION-246: draft proposal                  regarding making a public compliance commitment                                

           

Of note: in Seattle, we discussed the            possibility of having multiple codes to indicate different            flavors of DNT. Specifically, I raised it as a suggestion. The            WG members soundly rejected, in favor of coming to a common            single understanding of DNT. We have already declared this a            dead end.          
            

                     
            

One can imagine a world with, say, a DAA              approach and a W3C approach, without needing a new flag sent              with every response. Just pick different semantics. It will              be very clear which is what, without the overhead. If that              is the problem you are trying to solve, I think it is              already solved without needing any work here.                    
            

                     
            

If we take this just as being about              different regions, I'm not sure what a USA or NLD              designation entails. And I'm not sure how to convey that to              users. I think I do not understand what you have in mind              yet. I look forward to hearing more about how you think that              could work.            
              

                         
              
                

                             Aleecia                            
                

                 
                  
                    

On Sep 4, 2012, at 5:51 PM, David                      Wainberg <david@networkadvertising.org>                      wrote:                                    


                    
                                      
                    

This fulfills 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).                      
                      
                      There are problems with the current proposed                      approach to issue 45. The current version does not                      accommodate implementation distinctions based on,                      for example, geography/jurisdiction, business model,                      or technology. It also creates unnecessary and                      counter-productive legal landmines that will spur                      companies to avoid implementing the full spec. We                      can provide for making legal commitments without                      this unwanted result.
                      
                      I think the first point should be obvious. There                      will be a tremendous diversity of organizations,                      business models, and technologies to which DNT may                      be applied, either voluntarily or compulsorily,                      under a diversity of regulatory regimes. The spec                      needs to accommodate this diversity.
                      
                      The more important point is that, if we make the                      mistake of tying the server response (the header or                      WKL) to a broad, legally-binding representation that                      goes well beyond the specific meanings of the                      responses, end-users will lose out because companies                      will avoid implementing the response mechanisms. The                      reality is that companies who may otherwise be eager                      to implement DNT will avoid making representations                      that could be construed in overly broad ways, that                      may be ambiguous, or that otherwise are potentially                      misaligned with what they do. Instead, companies                      will seek to make representations that unambiguously                      describe their practices. We should facilitate this,                      not make it difficult.
                      
                      Note that I am definitely not saying that companies                      should be able to act contrary to what they                      represent in the response mechanism(s). That,                      however, is not a problem we need to solve.                      Companies will be held to account for any such                      misrepresentations anyway, regardless of what the                      spec says. And if the available responses are                      sufficiently precise and adequately defined, I think                      companies will implement them.
                      
                      This proposal solves both problems. It will provide                      for the enforceable statement that the working group                      is aiming for, but it will also allow needed                      flexibility for servers operating under various                      regulatory regimes, and would do so especially for                      servers operating under multiple regulatory regimes.                      And, most important, it would create a mechanism                      whereby companies can clearly and accurately say                      what they do and then do what they say.                    

The proposal is the following:                    
                      
* The compliance spec remains silent                          on the matter                      
* 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.                      
* The value of the compliance field                          is a 3-5 letter token indicating the applicable                          regulatory regime. Allowed tokens could include                          3-letter country codes, e.g. USA, GBR, NLD, or                          designations for voluntary regimes, e.g. W3C,                          DAA, NAI, IABEU. My understanding is that an                          organization like IANA can manage a list of                          tokens in order to prevent collisions.                    
                    

                                                   

                                                         
          
Received on Thursday, 6 September 2012 02:01:06 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:33 UTC