Re: Agenda for 21 December 2012 TPE call - V01

On Jan 21, 2013, at 15:08 , Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:

> 
> ISSUE-153: What are the implications on software that changes requests but does not necessarily initiate them?
>     https://www.w3.org/2011/tracking-protection/track/issues/153
>       Proposed text (by david and nick): "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."

To be fair, there is the major open issue of how exceptions would work in the such a model; can the intermediary generating or modifying the header also handle exceptions?

If it is *generating* but not modifying, then an exception request to the UA would then result in the UA sending DNT:0, and so the right effect is achieved. For modifying, I am more puzzled.

> 
> ISSUE-144: User-granted Exceptions: Constraints on user agent behavior while granting and for future requests?
> http://www.w3.org/2011/tracking-protection/track/issues/144

Most of these are resolved in the current spec., if not all.  These questions were mostly applicable when the UA had an exception UI.  The processing model is pretty clear in the current spec.  I am not sure there is much to discuss...

There is one issue that a colleague pointed out.  In the old model, the contents of the DNT header always reflected the UA's understanding of the user.  Now, the UA is responsible for the 'general setting' but the sites are responsible for exceptions.  On the wire, they all look as DNT:1 or DNT:0, however.  It may be cleaner to  indicate what the UA has determined in the first character, and the existence of an exception as an outbound qualifier or some other signal, e.g.

DNT:1e (the user's general preference is for not tracking, but you have a recorded exception)


David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 22 January 2013 11:34:31 UTC