Re: Question to Chairs on Call-for-objection Process

Despite the bifurcation of the TPE and TCS, the group decided to define "tracking" as an expression of what the signal is intended to convey.  Otherwise, the signal becomes a tautology, effectively asking "don't do whatever it is you say you won't do to me."  The group decided to define tracking as the collection of data regarding a particular user's activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. That definition and related ISSUE are now closed for discussion absent some new information for the group to consider.  However, it is an open question whether the term "context" within that definition should be defined more precisely.  (And, either way, any definition of context will not prescribe compliance obligations.)  In the Call for Objections that we'll announce later this week, working group members will be able to argue against the proposed definitions, as well as why we shouldn't include any definition at all.

Justin you raise an interesting point here.  I may agree with your analysis that, as constructed today and absent some meaning behind the signal, you could be seen as saying "don't do whatever you say you won't do to me", BUT it seems to me that we've increasingly attempted to fix that problem by detailing what you won't do (compliance) inside the TPE.  The problem becomes that where the TPE is unaware of permitted uses in one or more separate compliance regimes you wind up with the exact same problem again but simply restated, "don't do [well defined X], except where later permitted by something I don't know about".  We're just pushing this down the road unless we a) move the compliance doc completely into the TPE (which we specifically decided against) or b) figure out a more generic way of expressing a preference that allows us to move compliance out of the TPE completely.

One loud hum for b).

-Brooks

--

Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the Wunderman Network
(Tel) 678 580 2683 | (Mob) 678 492 1662 | kbmg.com
brooks.dobbs@kbmg.com

[cid:CEE11B09-14D2-44F7-BE0D-3D1CABBBD58B]

This email – including attachments – may contain confidential information. If you are not the intended recipient,
 do not copy, distribute or act on it. Instead, notify the sender immediately and delete the message.

From: Justin Brookman <jbrookman@cdt.org<mailto:jbrookman@cdt.org>>
Date: Monday, February 10, 2014 6:26 PM
To: Chris Mejia <chris.mejia@iab.net<mailto:chris.mejia@iab.net>>
Cc: W3C DNT Working Group Mailing List <public-tracking@w3.org<mailto:public-tracking@w3.org>>, Mike Zaneis <mike@iab.net<mailto:mike@iab.net>>
Subject: Re: Question to Chairs on Call-for-objection Process
Resent-From: <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Resent-Date: Monday, February 10, 2014 6:27 PM

Hi Chris, a couple of responses below.

On Feb 5, 2014, at 4:00 PM, Chris Mejia <chris.mejia@iab.net<mailto:chris.mejia@iab.net>> wrote:

Dear TPWG Chairs,

With respect to Issue-240 on defining the word "context" as it pertains to the definition of "tracking" in the TPE (but also related more broadly to the entire TPE drafting process, procedurally speaking), I'd like to formally request a procedural ordering of issues:

  1.  We should FIRST vote/poll on the fundamental issue of whether the definition of the word "context" should be included (at all) in the TPE…. THEN;
  2.  Following the issuance of a "decision" by the chairs on the 1st poll proposed above (of whether to include a definition of context in the TPE, or not), IF it is determined through that poll that we should have this definition in the TPE document, we THEN move to a call-for-objections poll on the actual definition of the word "context".

My rationale for this request being, folks may give a different response to #2 depending on the outcome of #1. My request here, logically asks that the horse come before the cart, metaphorically speaking.  I hope this makes sense, procedurally?  I also believe this is how we should approach any potential porting of definitions (aka policy) into the TPE.

Under the current Call for Objections procedure, you are permitted to argue that while you prefer that a term remain undefined, certain of the proposed definitions are less objectionable than others.  As long as you substantiate each argument with reasoning, the Chairs can fairly evaluate the relative strength of the arguments against including any particular definition as well as against having any definition at all.

Requiring separate Call for Objection processes over (1) whether to define a term and/or change existing language and then (2) what that change should be would add needless bureaucratic red tape to this process and delay each decision at least a month, without any corresponding benefit.  In general, I'd prefer to resolve issues without using the Call for Objection process AT ALL, let alone twice per issue.


Finally, I'd like to point out that we have two conflicting "final"/closed decisions:  a) the decision to bifurcate the compliance document from the technology document and put their development on separate paths, and b) the defining of do-not-track (which is a ultimately compliance/policy element) now in the TPE working draft.  I believe this conflict needs to be discussed at an architectural level with the working group (not discussed issue by issue, as we are doing today in what feels like a 'Frankensteining' process) and reconciled accordingly.

We do not have conflicting closed decisions.  The TPE defines the meaning of the DNT signal as well as how to technically express that meaning.  On the other hand, the Compliance spec (or alternately, some other compliance policy) defines how a server must behave in order to honor that DNT request.  Defining terms within the TPE does not impose compliance requirements on anyone; you are free to honor, ignore, or otherwise disregard that signal in your own judgment or pursuant to the terms of whatever compliance rules you adopt (however, TPE does standardize a format for you to communicate back to the user whether and how you honor the signal).

Despite the bifurcation of the TPE and TCS, the group decided to define "tracking" as an expression of what the signal is intended to convey.  Otherwise, the signal becomes a tautology, effectively asking "don't do whatever it is you say you won't do to me."  The group decided to define tracking as the collection of data regarding a particular user's activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. That definition and related ISSUE are now closed for discussion absent some new information for the group to consider.  However, it is an open question whether the term "context" within that definition should be defined more precisely.  (And, either way, any definition of context will not prescribe compliance obligations.)  In the Call for Objections that we'll announce later this week, working group members will be able to argue against the proposed definitions, as well as why we shouldn't include any definition at all.


Respectfully Submitted for Your Consideration,

Chris

Chris Mejia | Digital Supply Chain Solutions | Ad Technology Group | Interactive Advertising Bureau - IAB