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

This thread has expanded a handful of messages beyond the original pair of action items; a couple of comments inline below on the two text proposals and responses.

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.


I'm not sure this adds useful requirements beyond the text Dave Singer and I proposed below. In what sense does a User Agent "allow" other software to alter an outgoing DNT header? The operating system (and the router, and the ISP...) surely can affect outgoing HTTP requests -- short of a cryptographic protocol, I don't know how a User Agent could detect or prevent alteration. I don't think we should require user agents to do something they cannot do, but I do think it's useful to explicitly note that any software that sets a preference must follow these requirements.

On Aug 21, 2012, at 11:26 AM, "Dobbs, Brooks" <brooks.dobbs@kbmg.com> wrote:

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

The added text we propose would say explicitly that the software that adds or modifies the header is responsible for assuring that the header reflects the user's preference. Software (including plugins or extensions) that sent signals that weren't a user's preference would be non-compliant with this specification. We have long had similar language, for example, putting requirements on HTTP intermediaries not to modify or inject a header for users who have not expressed a preference.

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.

I think maybe we could address issue 150 (at least the version where multiple incompatible headers are sent) just by letting servers handle it the way they handle any syntactically invalid HTTP headers. Roy, is there anything we need to add to the ABNF in 4.2 to make it clear that only a single DNT header is valid?

Thanks,
Nick

> 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 Friday, 24 August 2012 00:46:02 UTC