RE: Issue-207

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:48:45 UTC