W3C home > Mailing lists > Public > public-tracking@w3.org > September 2012

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

From: Brendan Riordan-Butterworth <Brendan@iab.net>
Date: Tue, 18 Sep 2012 13:50:48 +0000
To: David Singer <singer@apple.com>
CC: "public-tracking@w3.org" <public-tracking@w3.org>, "Nicholas Doty (npdoty@w3.org)" <npdoty@w3.org>
Message-ID: <n55jpp5c5b7bbkqr030dmmwb.1347975227933@email.android.com>
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.

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.

/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.
Received on Wednesday, 19 September 2012 09:12:56 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:34 UTC