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

 

Fred,

 

My comments in-line.

 

Cheers,

 

Mike

 

 

From: Fred Andrews [mailto:fredandw@live.com] 
Sent: 23 October 2012 13:37
To: Mike O'Neill; 'Nicholas Doty'
Cc: public-tracking@w3.org
Subject: 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.

 


The handler can return either, (3 or E), it doesn't have to decide (because
they are functionally equivalent).

 

What I mean is if the handler was designed to operate in a 1st party context
but conforms to the TPC as a 3rd party (with exemptions etc., otherwise it
would just return N) it could return E, where the description is "the
designated resource may be designed for use in a first-party context but
conforms to the requirements on a third party". There is no requirement for
more logic, this is just for clarity.


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 would agree with that text but the value 3 is still confusing in the
majority case.



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.

 

I do agree but that is how the spec is now, and is the distinction is
unlikely to be removed. As it exists we should make the situation clear for
implementers who want to signal they acknowledge DNT:1 (conform as 3rd
parties as per the TPC) even in a 1st party context.



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

It should only return 1 when it has been requested in a 1st party context
i.e. it has been clicked on. A particular URI (handler) may have been
designed to always operate in a 1st party context but if the element causing
the request has been placed in error, say the same URI is the value of a src
attribute on an image tag, then it should (and regulators may want to) be
able to determine that. 

When a widget URI has been designed to be used in both a 1st party and 3rd
party context there should be a transparent way for the decision to be made,
otherwise bad actors may just always return Tk1 and claim they had
out-of-band evidence for it.

 



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.

I agree, I didn't imagine they would. 

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.

I agree, and they should be able to detect when a resource claims 1st party
compliance but is in fact loaded in a 3rd party context. Moreover external
compliance scanners, plug-ins etc. should be able to also, and entities
responsible for 3rd party resources should also be able to prove they have
received DNT:0 from a correctly formed API request.



cheers
Fred