- From: Chris Pedigo <CPedigo@online-publishers.org>
- Date: Thu, 17 Apr 2014 20:57:53 +0000
- To: Shane M Wiley <wileys@yahoo-inc.com>
- CC: "rob@blaeu.com" <rob@blaeu.com>, Justin Brookman <jbrookman@cdt.org>, "W3C DNT Working Group Mailing List" <public-tracking@w3.org>
+1 to Shane. Transparency is the key. > On Apr 17, 2014, at 4:49 PM, "Shane M Wiley" <wileys@yahoo-inc.com> wrote: > > Rob, > > I agree Transparency is important that's why I'm supporting a required resource link when the "D" response is sent. I can't foresee all of the unexpected things that browsers or 3rd parties may do so I'm hesitate to develop a list for you that could be represented as exhaustive or complete. > > - Shane > > -----Original Message----- > From: Rob van Eijk [mailto:rob@blaeu.com] > Sent: Thursday, April 17, 2014 1:44 PM > To: Shane M Wiley > Cc: Justin Brookman; W3C DNT Working Group Mailing List > Subject: RE: Issue-207 > > > Shane, > > Transparency is important for user trust. Would you be willing to draft a limitative list with reasons for dropping the signal? > > > Rob > > Shane M Wiley schreef op 2014-04-17 22:34: >> Rob, >> >> I believe a specific resource for each possible issue would be costly >> for Servers to support. Having a single resource would help drive >> adoption and I believe would be clear for users to clearly understand >> (at least in the universe of reasons I'm contemplating). >> >> - Shane >> >> -----Original Message----- >> From: Rob van Eijk [mailto:rob@blaeu.com] >> Sent: Thursday, April 17, 2014 1:02 PM >> To: Shane M Wiley >> Cc: Justin Brookman; W3C DNT Working Group Mailing List >> Subject: RE: Issue-207 >> >> Shane, thanks. >> >> Since the current editor's draft does not address issue-207, I >> respectfully ask the Chairs to leave the issue open until we have >> found a solution to accommodate any concerns. >> >> The resource link should be specific. Listing all the options why the >> signal could have been disregarded would not be enough in my view. >> Equally, burying the explenation in a large text would not suffice >> either. In that sense, I would accept the use of a specific D-clause, >> separated from the general terms and conditions. However, if there is >> more than just one reason why a valid expression was disregarded, I am >> not convinced yet, that a generic resource link to explain why the >> user may be receiving the disregard response is meeting our goal. >> >> Rob >> >> >> Shane M Wiley schreef op 2014-04-17 21:24: >>> Rob, >>> >>> The Working Group had originally agreed on two principles pre-W3C >>> Staff/Co-Chair "June Draft" Compliance document that I believe are in >>> alignment with your thinking here: >>> >>> 1) If a Server is representing compliance then they must send the "D" >>> response when disregarding the user's signal, not simply disregard it. >>> 2) A Server must accompany a "D" response with a resource link to >>> explain why the user may be receiving the disregard response. >>> >>> - Shane >>> >>> -----Original Message----- >>> From: Rob van Eijk [mailto:rob@blaeu.com] >>> Sent: Thursday, April 17, 2014 12:02 PM >>> To: Justin Brookman >>> Cc: W3C DNT Working Group Mailing List >>> Subject: Re: Issue-207 >>> >>> >>> Hi Justin, >>> Dear group members, >>> >>> Having given this issue a bit more thought, I have come to the >>> conclusion that something needs to be added the discussion. I >>> therefore request the issue to remain open. >>> >>> The TCS should IMHO include text that a party MUST provide information >>> regarding the specific reason for not honoring the user expression. A >>> key element, addressed in the TPE is that Tracking providers should >>> not ever have to second-guess a user's expressed Do Not Track >>> preference. It is fair to say, that users should not have to >>> second-guess with regard to the D-signal (quid pro quo principle). >>> Just responding with 'D' would not be enough IMHO to fulfill the quid >>> pro quo. The user / user agent needs to know about the reason why the >>> signal got disregarded. The party's representation MUST be be easy >>> discoverable, clear and unambiguous. It MAY be machine readable. The >>> guiding principle IMHO, is that transparency is key in the granular >>> discussion between the user agent and the server to prevent e.g., >>> discrimination based on the use of (a certain brand of) technology, or >>> just plain arbitrariness. >>> >>> I am trying to strike the right balance hear, and welcome your views. >>> >>> Regards, >>> Rob >>> >>> --- >>> Recital 66 >>> >>> "Third parties may wish to store information on the equipment of a >>> user, or gain access to information already stored, for a number of >>> purposes, ranging from the legitimate (such as certain types of >>> cookies) to those involving unwarranted intrusion into the private >>> sphere (such as spyware or viruses). It is therefore of paramount >>> importance that users be provided with clear and comprehensive >>> information when engaging in any activity which could result in such >>> storage or gaining of access. >>> The methods of providing information and offering the right to refuse >>> should be as user-friendly as possible. Exceptions to the obligation >>> to provide information and offer the right to refuse should be limited >>> to those situations where the technical storage or access is strictly >>> necessary for the legitimate purpose of enabling the use of a specific >>> service explicitly requested by the subscriber or user. Where it is >>> technically possible and effective, in accordance with the relevant >>> provisions of Directive 95/46/EC, the user’s consent to processing may >>> be expressed by using the appropriate settings of a browser or other >>> application. The enforcement of these requirements should be made more >>> effective by way of enhanced powers granted to the relevant national >>> authorities. " >>> >>> Justin Brookman schreef op 2014-04-17 20:22: >>>> On yesterday's call, we discussed ISSUE-207 (Conditions for >>>> Disregarding (or Not) DNT Signals) against the Compliance >>>> specification. Previously, some working group participants had >>>> argued that servers should never disregard or second guess DNT >>>> signals that are correctly formed (syntactically valid). However, as >>>> we crafted the TPE, we explicitly provided for a mechanism that >>>> allows servers to signal to a user that they are disregarding the >>>> signal. As adherence to TCS (or any other compliance regime) is >>>> voluntary anyway, there may no longer be an argument that TCS should >>>> prohibit disregarding certain DNT headers. In any event, no one on >>>> the call yesterday expressed support for the previous change proposal >>>> to require servers to honor all DNT requests. >>>> >>>> If anyone wishes to argue for amending the TCS to require compliance >>>> with all DNT signals --- or alternatively thinks that TCS needs to be >>>> revised to make it more clear that servers have the option to send a >>>> D >>>> (disregard) signal --- please reply on the mailing list. Otherwise, >>>> we will close the issue with no further edits as decided by consensus >>>> in two weeks.
Received on Thursday, 17 April 2014 20:58:26 UTC