RE: tracking-ISSUE-183 (Tk E ): Additional Tk header status value for EU [Tracking Preference Expression (DNT)]

Hi Mike,

> From: michael.oneill@baycloud.com
...
> I agree that returning a 3 status would be functionally equivalent, but both
> the value and descriptive text will not correspond to the majority usage in
> Europe. Request handlers (associated with particular URIs) could have been
> written to always operate in a 1st party context but will have to cause the
> 3 status to be returned (if DNT = 1) which seems inappropriate. Implementers
> will also be confused by the text which says "the designated resource is
> designed for use within a third-party context", when it has not.
> 
> I initially thought that we could fix this by changing the descriptive text,
> but it gets too long winded and confusing. My suggestion is to add another
> status value for this majority situation with a simpler description, to make
> the requirement clear for implementers. I do not think the added complexity
> of an extra status value, though it may be technically redundant, is too bad
> compared with the resulting gain in clarity.

The handler needs to decide if it confirms to the requirements of a 1st party

or 3rd party so surely it could just return 1 or 3.  Having to further decide
between 3 or E seems an extra step that may not even be trivial given the
rather vague distinction between 1st and 3rd party contexts.

A description such as "3: The designated resource conforms to the requirements
on a third party." seems simpler and clearer to me and is not conflated by the
1st / 3rd party context distinction.

I thought you agreed there should be no 1st / 3rd party distinction so surely
it would be better to ride the response status values of the 1st / 3rd party context
distinction rather than adding to the mess.

> The point about particular resource URIs changing from 3rd to 1st party
> context is one of the reasons for the change I suggested in issue-182. The
> user-agent has the party information at hand when it sends out a request,
> and it would be simple for it to communicate this to the server in the DNT
> header. For example the handler associated with a social widget will
> normally receive a request indicating 3rd party context usage ( DNT: 1) and
> the handler will return Tk3. If a user clicks on it a request will be sent
> out with the f qualifier ( DNT: 1f)  and the handler can return a Tk1
> response if it now conforms to 1st party rules. 

If a social widget reserves the right to act as a 1st party then surely it must
return Tk1 when loaded.  If the intention is otherwise then a new response
tracking status value is needed for this ambiguous or 'deferred decision' case.

Browsers should not be burdened with having to monitor all communication
to social widgets to detect a Tk1 response and then have to try and disable it.

A test for a workable DNT spec. should be that a browser can block resources
at load time if they do not agreed to the expressed tracking preference.

cheers
Fred