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

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 19:29:42 UTC