- From: Nicholas Doty <npdoty@w3.org>
- Date: Tue, 17 Dec 2013 23:49:38 -0800
- To: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>
- Cc: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
- Message-Id: <4945E634-3561-4E54-ADC3-C06DEB219819@w3.org>
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. 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). 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. 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. 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). 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. Thanks, Nick On December 16, 2013, at 6:23 AM, mts-std@schunter.org wrote: > Hi Team, > > during our last call, we agreed that we will discuss ISSUE-239 on the > mailing list. > > It seems as if there is no interest in such a link. > > If nobody makes a case for / against including this link, I suggest to > continue with the Status quo and reject Roy's proposed edit and not > include a link. > > Suggestions/feedback is welcome... > > Regards, > matthias
Received on Wednesday, 18 December 2013 07:49:48 UTC