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

On Sep 18, 2012, at 6:50 , Brendan Riordan-Butterworth <Brendan@iab.net> wrote:

> Greetings David.
> 
>  My read of your point (a) suggests you expect a UA that allows modification of the HTTP headers to monitor them for modified DNT state - or to take other action to monitor the behavior of plugins and toolbars with regards to the DNT state.
> 
> This is a reasonable position (if technically difficult to implement on the UA side), and is the one that the issues seem to suggest - but the current draft wording doesn't have language to this effect.

I think we may be trying to over-engineer the situation.  My position is that the specification should set requirements on what the protocol is, and (to the least extent possible) set requirements on the user-facing aspects, and then we should leave people to build conformant products.

So, in this case, the item that sets the DNT header is responsible for 
a) complying with the HTTP spec. (e.g. that there is only one)
b) complying with the protocol spec. (e.g. that the header is correctly formed to the DNT spec.)
c) ensuring it reflects the user's expressed intent
d) ensuring that any statement made to the user about the state is true

> If language to the effect of (a) does end up getting created, I'd argue that (b) is redundant - if the UA is responsible for ensuring that the plugins are not out of sync with the UA UI, the case of DNT:1 and DNT:0 on the same header is a UA bug and not a plugin bug.


I think I argue roughly the same, but from the perspective above.

I know there is a lot of anxiety about both ends -- there are lots of people concerned about sites that won't message properly to the user, that won't communicate properly, and so on, but as long as the spec. is clear about the external behavior (protocol and messaging), I think we should keep those anxieties in check until we see how things deploy in practice (when I confidently expect we will learn more).

> /brendan.
> 
> 
> 
> David Singer <singer@apple.com> wrote:
> 
> 
> On Sep 17, 2012, at 15:25 , Brendan Riordan-Butterworth <Brendan@iab.net> wrote:
> 
>> Clearing this thread to try to get back to the essence of the issue.  Here's the background information I'm using to frame the issue in my head.
>> 
>> - Section 4.2 explicitly calls out that: "An HTTP intermediary must not add, delete, or modify the DNT header field in requests forwarded through that intermediary unless that intermediary has been specifically installed or configured to do so by the user making the requests."
>> - RFC 2616 (HTTP 1.1) defines "User Agent" specifically as "The client which initiates a request", and subdefines "client" as "A program that establishes connections for the purpose of sending requests."  It doesn't explicitly define "intermediary", but uses the term in the definitions of "proxy", "gateway", and "tunnel" .
>> - We have to go to RFC 6202 (Bidirection HTTP) for an attempt at defining the term "intermediary" - but note that this is 12 years after 2616 - and even this is a weak rehashing of the 2616 text.
>> 
>> Given that the User Agent is the client which initiates the request, there are two main classes of software that may affect the outbound HTTP header:
>> 1 - Software that falls into the traditional classification of "intermediary", as in proxies, gateways, and tunnels.  This type of software has access to the HTTP request after it has left the User Agent.
>> 2 - Software that can modify the outbound HTTP headers in the User Agent, as in plugins and toolbars.  This type of software has access to the HTTP request before it has left the User Agent.
>> 
>> My read of the specific concern (as raised in issue-150) is that, given that some plugins and toolbars (class 2) *do* have access to the outbound HTTP headers, but *do not* have (or have not sought) access to modify the DNT state in the User Agent settings, a user can currently end up with a User Agent UI that indicates one DNT state, while they are sending another.
>> 
>> Given that neither issue-150 nor issue-153 is currently resolved, am I correct to understand that it is currently permissible for a plugin or toolbar to modify the DNT state on the HTTP request without altering the DNT state selected in the User Agent UI?
> 
> as long as (a) the user-agent was written with this possibility in mind and (b) the plug-in takes responsibility for making sure that there is only one DNT header sent, and it conforms to the spec. requirements (reflects the user's intent, correctly formed, and so on), I don't see a problem, myself.
> 
> I think it's odd, but not something we need to legislate.
> 
> If (a) is not true, the UA has a bug (e.g. it says "I am sending DNT:1" when a plug-in has over-ridden that to DNT:0).  If (b) is not true, the plug-in has a bug.  Neither are spec. bugs per se.
> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 18 September 2012 16:23:53 UTC