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

On Aug 21, 2012, at 12:29 , 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?

Hi

I think that there are two rules here, and they can be satisfied in different places.  No, it's not necessarily the job of the UA to verify the plug-ins:

* whoever establishes a DNT header to be sent has the responsibility to ensure it reflects the user's intent;
* whoever forms the HTTP request that is sent has the responsibility to ensure it contains at most one DNT header;

I think this is all quite clear from the current specification; are we trying to over-engineer this?

In the hypothetical case where two DNT headers get sent from two different pieces of software, in the same HTTP request, there are two violations:  one of the headers is presumably not reflecting the user's intent, and there should not be two headers.


> 
> 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.
>> 
>> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 21 August 2012 20:22:09 UTC