Re: Issue-207

Thanks Nick,

>> A party to a given user action that disregards a DNT signal MUST
>> indicate so to the user agent, using the response mechanism defined
>> in the [TRACKING-DNT] recommendation. The party MUST provide
>> information in its privacy policy listing the specific reasons for
>> not honoring the user's expressed preference. The party's
>> representation MUST be clear and easily discoverable.


It may be a language issue, but for me the word unambigous does add 
value. I propose to ammend your change to:

(..) representation MUST be clear, unambiguous and easily discoverable.

Rob


Nicholas Doty schreef op 2014-05-14 08:49:
> I meant to follow up after last week's call with some edits that I
> think could clarify; apologies for the delay.
> 
> On May 6, 2014, at 11:14 AM, Mike O'Neill
> <michael.oneill@baycloud.com> wrote:
> 
>> A party MUST provide information in its privacy policy listing the
>> specific reasons for not honouring the user expression. The party's
>> representation MUST be easy discoverable, clear and unambiguous.
> 
> I think this is intended to be "easily discoverable" (a phrase already
> being used) rather than "easy discoverable". Does "unambiguous" add
> anything that "clear" doesn't already cover?
> 
> To match with the rest of the document I would also make what I think
> would be purely editorial changes (matching with a version of the
> existing text so that it makes sense.
> 
> [Nick's proposed update:]
> 
>> A party to a given user action that disregards a DNT signal MUST
>> indicate so to the user agent, using the response mechanism defined
>> in the [TRACKING-DNT] recommendation. The party MUST provide
>> information in its privacy policy listing the specific reasons for
>> not honoring the user's expressed preference. The party's
>> representation MUST be clear and easily discoverable.
> 
> And for the non-normative paragraph:
> 
>> Non normative: In the interests of transparency, and especially if
>> there are more than a single such reason listed, it is recommended
>> that servers implement the [TRACKING-DNT] “status-id” mechanism
>> so that the particular reason for not honouring the user expression
>> is provided. The _TK_ response header can contain a _status-id_
>> field identifying the relevant Tracking Status Resource whose
>> _qualifiers_ property contains a short token representing the
>> particular reason. The User Agent can parse this and communicate the
>> reason to the user.
> 
> As discussed, "recommended" is actually a normative term we typically
> use. As Roy has pointed out, the qualifiers might be used even if the
> tracking status is site-wide. So one way to rephrase this would be:
> 
> [Nick's proposed update:]
> 
>> In the interest of transparency, especially where multiple reasons
>> are listed, a server might use the [TRACKING-DNT] *qualifiers* or
>> *config* properties to indicate a particular reason for disregarding
>> or steps to address the issue. A user agent can parse this response
>> to communicate the reason to the user or direct the user to the
>> relevant section of a privacy policy. This document does not define
>> specific qualifiers for different reasons servers might have for
>> disregarding signals.
> 
> Hope this helps,
> Nick

Received on Wednesday, 14 May 2014 07:27:40 UTC