Re: action-231, issue-153 requirements on other software that sets DNT headers

David,

I would suggest that this is already implicit and much more basic.  We all
agree that UAs MUST only send a signal that reflects a user's preference
(unless someone wants to flip this and say that it is okay to send a
signal which does not reflect a user's preference).  What this means then
is that if you want the advantages coming from the ability to send any
signal, you have the responsibility to ensure that the signal you send
accurately reflects a user's preference.  I am assuming we are on safe
ground to say that if a UA sends a signal which does not reflect user
preference it is out of compliance?


I have no doubt that doing this might, in reality, mean that that the UA
must be the only one to seek preference, but I am not sure there is an
easy way around this.  If my duty (form which I gain benefit) is to
represent someone else's preference accurately, I need to: 1) ensure they
are adequately informed about the issue on which they are rendering a
preference and 2) only where 1) is satisfied represent that determined
preference.  If you don't have this, you have a hole you can drive a truck
through.  A user could elect 1 or 0 as their true preference; 3rd party
software can reverse the decision and UA sends new "false" signal.  If it
isn't the UA's responsibility to maintain preference, who would be "out of
compliance"?  The answer "no one" undermines the spec.

-Brooks 
-- 

Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the
Wunderman Network
(Tel) 678 580 2683 | (Mob) 678 492 1662 | kbmg.com
brooks.dobbs@kbmg.com



This email ­ including attachments ­ may contain confidential information.
If you are not the intended recipient,
 do not copy, distribute or act on it. Instead, notify the sender
immediately and delete the message.



On 8/21/12 1:01 PM, "David Wainberg" <david@networkadvertising.org> wrote:

>To fulfill my action item on this, I propose also adding the following:
>
>"A UA that allows or enables other software to alter the DNT setting
>MUST ensure that such alteration reflects the user's intent."
>
>Maybe it needs some tweaking, but the idea is that, although there may
>be many pieces of software that can and do alter the DNT setting under
>various conditions, in most cases there will be one or two enclosing
>pieces of software that can ultimately control what DNT signal gets
>sent. That software can ensure the signal matches the user's intent.
>
>
>On 8/1/12 12:06 PM, David Wainberg wrote:
>> This looks ok to me. However, I am contemplating additional language
>> regarding a UA's responsibility to reconcile conflicts (issue 150?) or
>> ensure the user's choice, but I've not written it yet.
>>
>> On 8/1/12 1:46 AM, Nicholas Doty wrote:
>>> Hi all,
>>>
>>> Dave Singer and I volunteered to draft a very short proposal to
>>> capture the idea that if software outside the user agent (like
>>> anti-virus software, or a http proxy or what-have-you) sets a DNT
>>> value, it should still capture the user's intent.
>>>
>>> Proposal:
>>>
>>> After this existing sentence in the TPE spec:
>>>> Likewise, a user agent extension or add-on must not alter the
>>>> tracking preference unless the act of installing and enabling that
>>>> extension or add-on is an explicit choice by the user for that
>>>> tracking preference.
>>> Add:
>>>> Software outside of the user agent that causes a DNT header to be
>>>> sent (or modifies existing headers) MUST NOT do so without following
>>>> the requirements of this section; such software is responsible for
>>>> assuring the expressed preference reflects the user's intent.
>>> I believe this fulfills a common concept we've heard in the WG. It
>>> may also go towards issue-150 (conflicts between user agents), in
>>> explaining that any software must follow the same requirements for
>>> non-default user choice.
>>>
>>> David Wainberg is also working on a proposal around this issue but we
>>> haven't had a chance to compare/combine texts yet.
>>>
>>> Thanks,
>>> Nick
>>
>

Received on Tuesday, 21 August 2012 18:26:44 UTC