Re: Issue-207

Thanks Justin,

Relying only on the TPE is would leave room for ambiguity in the privacy 
policy, e.g. by listing all the reasons why the D-response may have been 
triggered, and/or the D-paragraph may be burried or not clear to a user. 
Therefore I call for additional requirements in the TCM to address my 
concern of transparency.

Rob

Justin Brookman schreef op 2014-04-17 22:01:
> If this is already addressed in TPE, do we need to address it in TCS?
> I suppose I don't object to it both places, but not sure it's
> necessary.
> 
> TPE currently says:
> 
> A tracking status value of D means that the origin server is unable or
> unwilling to respect a tracking preference received from the
> requesting user agent. AN ORIGIN SERVER THAT SENDS THE D TRACKING
> STATUS VALUE _MUST_ DETAIL WITHIN THE SERVER'S CORRESPONDING PRIVACY
> POLICY THE CONDITIONS UNDER WHICH A TRACKING PREFERENCE MIGHT BE
> DISREGARDED.
> 
> . . .
> 
> Note
> 
>  This specification is written with an assumption that the D tracking
> status value would only be used in situations that can be adequately
> described to users as an exception to normal behavior. If this turns
> out not to be the case, either the server's decision to send the D
> signal needs re-examination, or this specification, or both.
> 
> On Apr 17, 2014, at 3:24 PM, Shane M Wiley <wileys@yahoo-inc.com>
> wrote:
> 
>> 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 [1]]
>> 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.
> 
> 
> 
> Links:
> ------
> [1] http://blaeu.com

Received on Thursday, 17 April 2014 20:12:41 UTC