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

comments in advance of the next TCS working draft

From: David Wainberg <david@networkadvertising.org>
Date: Wed, 19 Sep 2012 23:19:40 -0400
Message-ID: <505A8B4C.2030102@networkadvertising.org>
To: "public-tracking@w3.org" <public-tracking@w3.org>, "Aleecia M. McDonald" <aleecia@aleecia.com>, Justin Brookman <jbrookman@cdt.org>, Heather West <heatherwest@google.com>
As requested by Aleecia, I am providing these comments in advance of 
publication of the TCS as a working draft.

Items stated as objections are things I can't live with in the draft. 
Where I insist on something, or say we must do something, those are 
things I cannot live without in the draft. Comments, suggestions, and 
proposals are just that. I apologize in advance if the words "object" 
and "insist" or anything else impart a brusque tone; I just couldn't 
find a way to indicate my positions as clearly while also sounding 
friendlier. Also, please do not take my omission of anything as an 
indication of agreement. There are many important substantive issues 
that still need to be addressed, and the aim here is just to get this to 
the next working draft.

Editors -- I appreciate how much work it must be to evaluate and 
integrate all of these comments. If there is a better way for me to 
provide this to you, I'll be happy to do it. Let me know.

One quick question at the outset. Shouldn't the draft include specific 
references, where relevant, to all open, pending, or postponed issues? I 
don't think it does, but I did not do a thorough check.

My notes are below. Thanks!


  * Status
      o I would propose making clear that outcomes are not limited to
        the options included in the draft, and that yet-to-be-proposed
        options may ultimately be adopted. This is to ensure external
        parties reading the draft understand the extent to which some
        issues are still in flux.
      o Proposed text: "Options included in this draft should not be
        read as limitations on the potential outcome, but rather simply
        as possible options that are currently under consideration by
        the working group."
  * Introduction
      o There is language here I'd object to. However, my understanding
        is we'll be editing it later. So, in the interest of time, I'll
        just flag it for now as something I'll want to address down the
  * Scope and Goals
      o Same comment as the intro, but there is one thing I would like
        to address for the working draft. I find this section misleading
        without an explicit statement regarding the scope. It sounds
        very broad and generally applicable to the internet, when that
        is not actually the case. It will be important for readers to
        understand that clearly. So, regardless of my views on the scope
        with respect to first and third parties, I think it's fair and
        necessary to be up front about it, so I would insist on adding
        language along the following lines.
          + "This standard has limited applicability to any practices by
            first parties, their service providers, subsidiaries, or
            affiliated companies. Under the standard, first parties may
            and will continue to collect and use data for tracking and
            other purposes. This standard is directed at third parties."
  * Definitions
      o 3.2 I would insist on acknowledging here some ongoing issues
        with the definition of UA, and possibly the need to distinguish
        types of UA to address, e.g., issues around defaults, conflicts,
        and ensuring user choice.
      o 3.7 I do not understand the non-normative explanatory text. What
        is the issue/question is it intended to address?
      o 3.8 Transactional data is defined but not used anywhere else in
        the document, as far as I can tell. I would therefore propose
        removing it. If it is to remain, I would object to the current
        text, and would propose an alternative.
  * First party compliance
      o I do not understand the Note.
  * User agent compliance
      o I believe Issues 150 and 153 (and possibly others) pertain to
        this section and therefore must be noted here.
  * Third party compliance
      o I do not understand the Note at the beginning of this section.
      o I insist we make more clear that this entire section and most
        everything in it is still hotly debated, i.e. add a Note saying
        very clearly that "This entire section, and all subsections
        within, remain open for debate."
      o Why "operator of a third-party domain?" Why not just "if a
        third-party receives...?"
      o Is "communication" the right term?
      o Item 2 must include "explicitly-granted exceptions."
      o the terms "super-campaign" and "campaign id" won't mean
        much to most readers. I'd propose a clarification, but I'm not
        sure what the aim is here. Perhaps someone else can explain further.
      o I don't understand the Note about "look to 3rd parties"
      o I have a pending Action-256 to fix up this language,
        including using a term other than "fraud." I'll try to get to it
        ASAP, so we can at least include it as an option.
      o I believe the graduated response proposal pertains to
        security in and not debugging
Received on Thursday, 20 September 2012 03:20:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:39:00 UTC