W3C home > Mailing lists > Public > public-tracking@w3.org > December 2013

Re: ISSUE-239: Link to compliance document

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 18 Dec 2013 04:11:47 -0800
Cc: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-Id: <C21C6D6E-CDE2-4C62-9197-F0446C1D4F26@gbiv.com>
To: Nicholas Doty <npdoty@w3.org>
Hi Nick,

Thanks for providing a description of your reservations.

On Dec 17, 2013, at 11:49 PM, Nicholas Doty wrote:

> I appreciate the prompt from Matthias to discuss this on the mailing list. On last week's teleconference, I expressed my reservations about removing the compliance indicators and adding an optional list of compliance URIs; maybe it's useful for me to write those out as briefly as I can.
> 
> I think the great value that this diverse group can provide is in setting a common concept of compliance in order to ease providing users a common expectation of what compliance with their expressed preference provides. That's part of the interest in having a common document to explain (likely linked within browser UI) to users the consequences of their expressed preferences. Making assertions of that compliance available to the user was one of the reasons we settled on the server-response approach, because it can address usability concerns and give users confidence that their choice is effective.

I think that if this diverse group could provide such a thing, within
the realm of a consensus-based decision process, it would have done so
already.  Nevertheless, the compliance array doesn't prevent that consensus
from occurring in the future, nor does it prevent the group from deciding
at some future date that browsers must only recognize one such compliance
link as golden.  The only thing the compliance array does is allow the
protocol to be implemented by servers in the absence of such consensus.

> While services in different jurisdictions and in different industry segments will certainly differ in their implementations of DNT and in their privacy practices generally, I believe the group has tended against functionality that would expose every such possible implementation beyond optional links to site privacy policies. Users are unlikely to review N different compliance regimes of M different resources loaded on any single page request. Server operators have generally preferred not to create different levels of compliance (which could confuse users or be used within regulatory requirements).

Those are all assumed implementation of UI by browsers.  They have
nothing to do with the compliance array, since we could equally
speculate that browsers might configure a fixed set of URIs
(or even just one) that they consider sufficient to meet their
user's preference, or provide that configurability to the user.
Likewise, servers have control over what specs to comply with;
if they only want one, they need only list one.

> And the preference of the group to work on Do Not Track rather than a block/allow mechanism like the proposed Tracking Selection List deliverable has been motivated by not blocking/allowing content based on some machine-readable mechanism.

Umm, no, there are many reasons not to work on that, with the main ones
being that it enables extortion by list providers and interferes with
first-party site operation.

> If users aren't going to review the multiple different compliance links of every resource request, and we don't want to put the user agents in a position of white-listing or blocking certain compliance regimes, then I'm not sure the functional purpose of an array of binding compliance regimes.

If a user is not interested in verifying compliance (the far more common
case), no response is ever obtained or checked.

If a user is interested in verifying compliance, they will have to rely
on some communication of compliance by the server.  Preventing the
response message from communicating such claims directly prevents
deployment of this protocol without a completed Compliance document,
and even after such a document is produced we would have to *add* a
similar link or versioning feature if that document is ever allowed
to change.

In contrast, the compliance array solves this communication
problem directly, without reliance on some future TCS deliverable, and
does not in any way prevent TCS from becoming the one true consensus
at some time in the future.  Implementations can use the existing
TR links to indicate compliance to specific versions of the TCS.

> I would suggest we return to the existing proposal for indicating compliance with "1", "3" and the permitted use qualifiers (which I thought to be past consensus decisions of the group).

I was asked to remove dependencies on the compliance specification.
It isn't sensible to depend on a document that doesn't reflect anything
near consensus of the working group, was last published as a WD without
even approval by the group, and is not a currently active work product.
I do not believe it to be a productive use of our time to make TPE
dependent on a such a product.

Given the lack of consensus on compliance, it doesn't make sense
to suggest that "1" and "3" in a TPE would indicate compliance.
That would be a hard dependency on the particular set of rules for
first and third party behavior that nobody managed to agree to.

We never had any consensus decisions regarding those values.  What
we had was a chair's instruction to the editors to include certain
values called for by the Compliance discussion, with "1" and "3"
being part of that set.  That instruction has been overtaken by events.

What we can do in TPE is define a similar communication that can
be described using only the defined terms, such as "this resource
only collects data for use within a single context and controlled
by the same party or parties as that context". We could call that a
TSV of "1".

We could also define a response for "This resource turns off
tracking when DNT:1 is present", though I seriously doubt
we could obtain consensus on that given the perceived need for
permitted uses, which are themselves tied to compliance.

I don't see how "3" can be defined without reference to a set of rules
to which such a third party claims compliance.

In any case, qualifiers can be defined (and even required) by any
compliance spec.  Their definitions have always been subservient
to the compliance document discussion.

> Alternatively, if the group chooses to remove those compliance indications from the TPE document, then I suggest we create an appendix in the TPE or add to the Compliance document the existing set of terms ("1", "3" and permitted use qualifiers) with their definitions, which I think in Roy's new framing would all be qualifiers after a "T"/"N" tracking response value.

Qualifiers only appear in the tracking status representation.

My goal is to produce a protocol that can move forward to LC.
In my opinion, adding compliance issues to that protocol will result
in objections to LC by a majority of working group participants.
It is not a viable way forward at the present time.

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <https://www.adobe.com/>
Received on Wednesday, 18 December 2013 12:11:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 18 December 2013 12:11:53 UTC