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

Tamir,

You are making this too complicated.  UAs shouldn't be required to audit
applications, plugins, etc - they should, per the spec, only ever send a
signal which is consistent with a user preference.  If they don't feel
confident that what they are sending meets that requirement they shouldn't
send anything.  Anything else completely undermines the spec.  If you send
two DNT headers, you are by definition, non-compliant (schizophrenic users
not withstanding). 

-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 3:29 PM, "Tamir Israel" <tisrael@cippic.ca> wrote:

>Well I guess I was anticipating conflict : P
>
>Put aside for a sec the scenario where a server decides a UA didn't do
>it's job properly. How far does what you're proposing go? You're saying
>UAs now have sole responsibility for auditing all applications, plugins,
>etc. to make sure the DNT signal they're sending remains an accurate
>reflection of the user's preference? Or are we saying UAs should not
>allow any application, plugin, or OS for that matter to change a DNT
>preference?
>
>Shane -- the lack of a check-in mechanism is problematic both ways,
>whether the plugin changes my preference to DNT-0 or DNT-1 without
>'asking'. So it's not primarily about making an opt-in world for servers.
>
>On 8/21/2012 2:54 PM, David Singer wrote:
>> On Aug 21, 2012, at 11:40 , Tamir Israel<tisrael@cippic.ca>  wrote:
>>
>>> I still think a lot of problems can be solved and confusion avoided if
>>>the TPE incorporates a mechanism for confirming user preferences in
>>>cases of conflict.
>> What conflict?  On the wire, only one DNT header is allowed.  UAs etc.
>>have to make sure of that (and resolve any conflicts) before anything
>>goes on the wire.
>>
>>> Best,
>>> Tamir
>>>
>>> On 8/21/2012 2:26 PM, Dobbs, Brooks wrote:
>>>> 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
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>
>>

Received on Tuesday, 21 August 2012 21:14:12 UTC