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

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.

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

Received on Tuesday, 21 August 2012 18:40:58 UTC