Re: ISSUE-161: proposal for transparent non-compliance

I strongly object to the Do Not Track protocol facilitating noncompliance with the Do Not Track compliance policy.  We've addressed this topic a number of times now; it appears I'm far from alone in my concerns.

I'm uncertain why Roy thought there might be "no objections."

Jonathan


On Thursday, September 13, 2012 at 12:32 PM, David Singer wrote:

> I think this is a very pragmatic and prudent approach, and eases deployment, and encourages development.
> 
> For the paranoid, one can simply treat 'P' sites the same as sites that don't say or claim anything.
> 
> Thanks
> 
> On Sep 12, 2012, at 1:25 , Roy T. Fielding <fielding@gbiv.com (mailto:fielding@gbiv.com)> wrote:
> 
> > 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.
> > 
> > 
> > Cheers,
> > 
> > Roy T. Fielding <http://roy.gbiv.com/>
> > Principal Scientist, Adobe Systems <http://adobe.com/enterprise>
> > 
> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
>