Public comments regarding the TPE last call document

In response to the TPWG's call for comments on the TPE, I offer the 
comments below. Thank you for your consideration of these important issues.

Regards,

David


_The TPE is not a legitimate consensus document_

The TPE cannot reasonably be called the result of a consensus process. 
Instead, it is the result of overriding the concerns and objections of 
the main parties who might be expected to implement the specification, 
i.e. small third-party ad technology companies. Meanwhile, the handful 
of very large companies who are the primary authors of the specification 
have ensured they would not be subject to it. As we know, the exclusion 
of so called "first parties" from the scope of the DNT specification is 
the result of a deal struck between certain parties present in the early 
stages of the working group. Under this agreement, the working group has 
focused the specification on "third parties," who tend to be smaller 
non-integrated companies. Moreover, to compound this issue, the working 
group has adopted an excessively broad definition of what constitutes a 
first party (or "context"). This ensures a result that skews the 
marketplace without a significant real world privacy benefit. I continue 
to be perplexed by the W3C's insistence on finalizing a specification 
just for the sake of getting it done, without regard for the legitimacy 
of the product, or the real world outcomes.

_
The signal cannot be verified_

It is non-controversial that for a signal to be valid it must reflect a 
user's informed and explicit choice. However, the TPE provides no 
mechanism for a recipient server of a DNT:1 signal to ensure that a 
signal is valid. Experience already demonstrates that there will be a 
high rate of invalid signals as a result of the signals being set by 
default or injected by intermediaries. The high rate of invalid signals, 
with no means to distinguish them, will pollute the space, undermine the 
meaning of the signal, and make it impossible for implementers to 
support the specification.

The W3C, the working group chairs, and the primary authors of the 
specification are indifferent, and seemingly willing to accept of a high 
rate of invalid signals, regardless of the source or user intent, 
regardless of the business impact, and regardless of the overall 
negative impact on the Internet. (It's worth noting that nearly all of 
the working group, including the primary authors of the specification 
and the co-chairs, would not be subject to DNT under this 
specification's definition of tracking, so would not be negatively 
impacted by a proliferation of invalid signals.)


_The definition of "tracking" is ambiguous_

The terms "set of resources" and "controlled by the same party or 
jointly controlled by a set of parties," along with the definition of 
party, are so ambiguous, both individually and together, that it is 
impossible for prospective implementers to interpret the specification 
with reasonable certainty. It is, therefore, also impossible for 
implementers to respond to a DNT signal in a reasonable manner. Here are 
just some of the questions raised by these ambiguous terms:

  * What are the elements of control?
  * What qualifies as joint control?
  * Does joint control require a contractual relationship?
  * Does minority investment count as common ownership or joint control?
  * Does "control" refer to control over the content or the underlying
    technology service or both?
  * Does a mobile app store jointly control all of the apps it offers?
  * Does a website owner control third party content that it embeds its
    website?
  * Does the definition really intend that all companies under common
    ownership could be considered the same party? Take, for example, a
    company that owns disparate media brands that serve disparate
    markets around the globe. Under this specification, as long as their
    relationship is discoverable via a link in a privacy policy, they
    could collect, share, and use user data across their properties
    irrespective of a DNT signal, and regardless of whether a reasonable
    consumer would have any idea the parties are related without digging
    into the privacy policy.
  * What about cloud services, such as blogging services or social
    media? Who is/are the controller(s) of that context? Is it the
    service provider or the content creator or both? For Joe's Blog
    hosted by BigBlogService.com, is BigBlogService a/the controller? If
    so, does that mean that it can collect and use data across all of
    the thousands or millions of blogs that it hosts?
  * What about a web hosting company? Does that company have control
    over all of the sites it hosts?

These are complex questions, not easily answered, even in the abstract, 
much less in the real world where there is an overwhelming diversity of 
use cases.


_The definition of tracking does not belong in the technical specification_

The ambiguity in the definition of tracking points to a fundamental 
issue with the TPE document: it should not contain this definition at 
all. The tracking definition is of a legal and policy nature, not 
technical. It is fraught with ambiguity of the legal and policy variety, 
not technical. Unlike true technical aspects of the specification, this 
definition, and its interpretation, creates legal risk. Lawyers, not 
engineers, will be called upon to interpret it and determine an 
implementer's TSV response.

When this definition was added to the TPE, it was argued that it was 
necessary to make the TPE a complete, standalone protocol definition. 
But the effect is just the opposite. This definition in the TPE creates 
a requirement for significant ancillary clarification.
The definition should be removed from the TPE, and defining tracking 
should be relegated to policy documents.


_User agents should be required to support user granted permissions 
mechanisms_

The protocol cannot succeed if it does not provide elements necessary 
for a dialog between users and servers. The signal is meant to express a 
user's preference. Currently the TPE requires UAs to offer only a binary 
choice, but user preferences are typically not binary, and may vary 
depending on context and the parties involved. To remedy this gap, a 
recipient server must be able to request and reliably store a user 
granted permission, but the TPE currently does not provide for this.