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

ISSUE-161: proposal for transparent non-compliance

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 12 Sep 2012 01:25:27 -0700
Message-Id: <6FC18020-A426-4EE3-AE95-D52B1CF406AB@gbiv.com>
To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
This is a rough (pre-spec-text) proposal to solve ISSUE-161.

Currently, the TPE draft does not provide a means to supply
information to the user without also claiming compliance.
That is a problem for several reasons:

1) sites that are in the process of deploying DNT but have
   not yet completed deployment (or are simply too scared to
   claim compliance until a third-party audit is complete)
   have no means to test while working through issues;

2) regulations tend to shift over time, as do standards, and it
   might be necessary to stop claiming compliance on short order
   until something is fixed.  For example, there are many companies
   that have a guesswise implementation of DNT:1 already, usually as
   a uniform means of opting out, and they would like to support
   as many of the draft's transparency features as possible,
   right now, even though they don't know what full compliance
   means yet; and,

3) sites that have not yet implemented DNT but would still like
   to be more transparent to the user by providing links to a
   control resource (for opting out or managing data) and a
   tracking policy (to explain what tracking does occur, and
   possibly what their plans are for future DNT implementation).

In all cases, these would still be considered non-compliant, and
the expectation would be that a verifying user agent would treat
them as such.  The value proposition is that a verifying user agent
could still make use of the policy and control links to provide
uniform access to information and controls to the user.

I will refer to this as partially compliant simply because the
server would have to comply with many of the TPE requirements
just to support the expression protocol and syntax, though
I am open to better ideas for a category name.

The following requirements would be imposed on partially compliant
origin servers:

  a) The server MUST provide the same response WKL and header
     fields as required for compliant servers, except that the
     TSV is "P".  All syntax requirements are REQUIRED.

  b) The tracking status representation fields for policy and
     control are REQUIRED, since the lack of a claim of compliance
     means that the user can't rely on a DNT:1 being effective.

Note that a partially compliant server might actually be fully
compliant with the standard in every respect except the TSV,
which allows sites to switch from testing to full deployment
by changing a single character value.

If there are no objections, I will work on actual spec changes
consistent with the above.


Roy T. Fielding                     <http://roy.gbiv.com/>
Principal Scientist, Adobe Systems  <http://adobe.com/enterprise>
Received on Wednesday, 12 September 2012 08:25:45 UTC

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