Re: TPE Editorial Proposal to Remove Another Hard Dependency on the Compliance Specification

On Mar 6, 2014, at 6:15 PM, Shane M Wiley wrote:

> Based on your comments below it appears you would feel comfortable if a Server sent back the “T” and a resource link explaining what “Tracking” means to them and how they manage DNT requests?

Nobody cares what the server thinks tracking means.  This is not a
server preference protocol.  What the links provide is an explanation
of how the server limits itself based on the received DNT value.

I prefer to think of it as follows:

A future user has a presumed understanding of what "tracking" means
based on the definition in TPE and how it is colloquially described by
conformant browsers.  When the user expresses DNT:1 via the protocol,
they are expressing a wish for such tracking to be disabled for this request.

When a server receives DNT:1, the server interprets the user's preference
according to the defined protocol in TPE.  That is, the server understands
the semantics of the expressed protocol as we have defined it, assuming
that the user agent conforms to the protocol.

Once it understands the semantics of the received signal, the server
then has a number of options regarding how to respond to that signal
(the response protocol) and how to constrain its own behavior in light
of the preference received (compliance, or lack thereof).
Understanding the user's preference is not the same as obeying it.

The server can choose not to conform to TPE, which is outside our scope
[i.e., they might not provide TPE's required response, or provide an
invalid syntax instead].

The server can send the "N" TSV to the client to indicate that it
does not perform tracking (as defined by TPE) of data collected on
a request to the designated resource.  This relies entirely on TPE's
definition of tracking.

The server can send the "T" TSV to the client to indicate that it
might perform tracking (as defined by TPE) via data collected on
a request to the designated resource.  This indicates that the server
understands the user's preference and is complying to whatever
constraints are specified in the identified compliance regime(s)
[which might be the empty set], as qualified by the set of qualifiers.
Those constraints are entirely defined by the compliance regime.

The server can also send one of the other potential TSV values, as
explained in the spec.

> I believe the core concern is that the TPE hard coded a definition for Tracking where a compliance standard may have a slightly different definition.  I’m looking for a way to bridge the two worlds.

I don't find that a useful phrasing of the situation.  Using the same
term in two different ways within the same document, or different from a
normative dependency like TPE, is guaranteed to confuse the average
reader and will have no effect whatsoever on the user's preference.
A user might even consider it deliberately misleading if such definitions
were mixed in a privacy policy.

A compliance regime doesn't need to address "what is tracking", since
only the "N" response depends on that definition.  All the regime needs
to do is define its own constraints on recipient behavior, based on the
received TPE signals, and define any corresponding qualifiers that might
help the user agent understand which constraints are being applied.

Ultimately, the compliance regimes are going to be judged by users,
regulators, browser developers, and the peanut gallery according to
how well their constraints preserve the user's privacy, not by how well
the terms have been (re)defined.

....Roy