Last call comments

Dear Co-Chairs,

In response to the last call for comments on the Tracking Preference Expression (TPE), I would like to offer the following set of concerns:

Failure to adequately bi-furcate the TPE from TCS

The separation of the TPE from the compliance document is based on the possibility of there being multiple compliance structures, but the inclusion of certain definitions within the TPE technically undermines this possibility.  If the TPE speaks to obtaining and communicating a user preference, that preference is inherently with respect to a single set of practices described to the user at the time of obtaining the preference.  The TPE’s definition of Tracking now dictates what compliance means.  Any compliance document must necessarily be congruent with that definition of Tracking.  This turns the TPE into a de facto compliance document, which it was specifically not intended to be.

Failure to be testable

Chairs have communicated that W3C rules dictate that any MUSTs used in the specification must be testable.  The primary goal of this specification is to communicate a user's preference with respect to Tracking.  Unfortunately, the specification in its current form allows for user preference signals that are not realistically testable.  While it is true that a UA may test the setting it maintains internally, it cannot test the preference received by an origin server, nor can the origin server test if the signal it received is in keeping with the actual preference of the user or even the preference recorded by the UA.  Current market implementations show this to be beyond a hypothetical problem.  The middle man alteration of signals in the market today and the failure for their to be a technical means for either party to have the ability to verify a common understanding of user preference is a fundamental flaw.

In addition to the injection of signals by the intermediaries, the TPE’s lack of more specific guidance to the UAs with respect to how to ascertain a user’s preference also makes testing that preference against the protections offered by any individual compliance regime nearly impossible.  End users are unlikely to be aware of the complicated definition of “Tracking”, its exceptions (which may vary by compliance regime) and its scope with respect to covered parties.  Where it is likely that users will have wide ranging expectations of what a choice means, testing any given signal’s meaning with respect to a given compliance regime may not be possible.

Failure to offer a choice amongst tracking alternatives

A choice, is by its very nature, the process of selecting from amongst multiple alternatives.  Though the stated goal of the TPE was to provide a choice amongst Tracking preferences, the only signal mandated by the specification is the DNT:1 option.  This shows a fundamental flaw in neutrally achieving the specification’s primary goal.  It would have been trivial to mandate that a tool meant to establish a preference MUST offer at least two choices, but the choice option of DNT: 0 was relegated to a “MAY”.  The absence of a firm requirement of meaningful choice represents a technical failure of the specification.

While I appreciate the great effort that has been expended to achieve the draft we have today, for this specification to have real meaning these issues must IMHO still be addressed.  Thank you for your consideration.

Best Regards,
Brooks Dobbs

--

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:35330FC7-2505-4379-982A-FE129FAAB715]

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.