RE: Issue-207

Fail - double word use in the same sentence.

s/clear/straight-forward

- Shane

-----Original Message-----
From: Shane M Wiley [mailto:wileys@yahoo-inc.com] 
Sent: Thursday, April 17, 2014 1:34 PM
To: rob@blaeu.com
Cc: Justin Brookman; W3C DNT Working Group Mailing List
Subject: RE: Issue-207

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:44:25 UTC