Re: ISSUE-239: Link to compliance document

Thanks for your replies, Roy. Inline I've tried to explain a little further where it seems productive to do so.
—Nick

On December 18, 2013, at 7:11 AM, Roy T. Fielding <fielding@gbiv.com> wrote:

> 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.

I share your frustration and concern over the time we've spent debating compliance. However, the concerns I've tried to express above may be major blockers to adoption and to the value of Do Not Track generally -- if we have a defined DNT signal but no common meaning for how to comply with it, how should user agents explain it to their users? How can we provide users any greater confidence than they have with non-standardized DNT implementations today?

I further agree that with a compliance array approach, it would still be possible (albeit more complicated) to eventually get to that same outcome: a common meaning of complying with a user's expressed Do Not Track preference. We can of course do them as separate steps, but if the value relies on having a common concept of compliance that we can explain to users, then additional parameterization in the TPE doesn't provide an advantage over existing non-standard implementations.

>> 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.

I wasn't suggesting that any of these UI suggestions were good or likely, but in defining the terms that will be communicated over the protocol, we generally add them only if we think they may be used by the client. If we don't think any users will review the compliance array and we don't expect or don't want user agents to block/allow resources based on those values, then providing the extra configurability is not valuable.

>> 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.

I know that different people have had different concerns about working on Tracking Selection Lists or on blocklists more generally; I was listing what I believed to be the most commonly expressed concerns. In particular, there was concern about blocking requests altogether because it could prevent verification for billing or display of ads altogether and wouldn't facilitate communication about tracking preferences with the end user. If participants from the advertising community are more comfortable with white- and black-listing based on an array of compliance URIs, then this wouldn't be an objection.

>> 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.

We haven't separately documented every single point of agreement within the group with a formal call for consensus. My understanding was that the text in the TPE (before your changes in late November) was agreed upon, except for those sections marked with Option blocks or issue markers. In some cases, we did formally note decisions, for example, on defining optional qualifiers in the TPE for expressing claimed permitted uses, which have also been removed. (I'd have to dig around regarding the history on "1" and "3".)

> 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".

While I am a voice in favor of keeping indicators of compliance in the TPE, I had also suggested an appendix where we could define "1" and "3". We could describe those as "designed for use in a first party context" or "designed for use in a third party context" and still be somewhat informative to the end user.

> 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 had thought this was the meaning of "N", but I guess that indicates never tracking, as opposed to just not tracking when a user expresses DNT:1.

> 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.

Is there a reason qualifiers only appear in the resource, and not appended to the value (that might be sent as a Tk: header)? I believe the spec has varied on that point in the past and it seems a useful option for server implementers who may use the Tk header a lot, especially as under your new framing the qualifiers will be needed for more information than in the past.

> 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.

I appreciate your continued effort and your pragmatism. For what it's worth, I believe specifications can and regularly do advance to Last Call even with normative dependencies on unfinished, working drafts, even though they would need to reach parity for later maturity levels. Given concerns we've heard about definitions and compliance issues in the TPE document, using a normative reference to a separate document might help us make prompt progress.