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

Nick, Fred

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

In the DNT = 0 case the exception API will have been called. In a 3rd party
context the DNT header would now be DNT: 0t=toplevel.com indicating the
document origin of the top level page, which is also the origin host which
initiated the exception. This can be used to prove compliance (by retaining
logs in the DNT:0 case) or to debug script errors on the top level site.


Mike




-----Original Message-----
From: Nicholas Doty [mailto:npdoty@w3.org] 
Sent: 23 October 2012 01:16
To: Tracking Protection Working Group
Cc: Mike O'Neill
Subject: Re: tracking-ISSUE-183 (Tk E ): Additional Tk header status value
for EU [Tracking Preference Expression (DNT)]

This topic has also come up in reviewing the questions David Singer set out
on the needs for the server response. My understanding of the current draft
text is that the "3" value is intended to cover resources that are used in a
first- or third-party context but comply with the defined requirements for
third-parties. Whether in the EU or US, many of us expect that there will be
many resources served in a first-party context that comply with third-party
requirements.

Do we as a group think it's important for a resource to indicate separately
that it's being served in a first-party context even though it's complying
with the stricter third-party requirements? Would users/user agents do
anything different in that situation?

If not (and I don't personally know of an advantage there), then I think the
existing tracking status values will suffice.

-Nick

On Oct 21, 2012, at 4:28 PM, Tracking Protection Working Group Issue Tracker
<sysbot+tracker@w3.org> wrote:

> tracking-ISSUE-183 (Tk E ): Additional Tk header status value for EU
[Tracking Preference Expression (DNT)]
> 
> http://www.w3.org/2011/tracking-protection/track/issues/183
> 
> Raised by: Mike O'Neill
> On product: Tracking Preference Expression (DNT)
> 
> In Europe and other jurisdictions the requirement will probably be that
resource handlers accessed in a first-party context conform as a
third-party. 
> 
> In these cases resource handlers could place a Tk header in the response
with a status of 3 "The designated resource is designed for use within a
third-party context and conforms to the requirements on a third party", but
the value and the text are confusing in this situation. Even though the
overwhelming majority of these resource handlers will have been designed for
use in a first-party context the Tk  response they emit portrays them as
third-party.
> 
> This could cause confusion for implementers, leading to a loss of
interoperability.
> 
> It might be better to insert a new single character status value ( in
paragraph 5.2) for this situation for instance:
> 
> E     The designated resource may be designed for use in a first-party
context but conforms to the requirements on a third party.
> 
> This is functionally similar to the 3 response but be more appropriate for
the majority case in these jurisdictions.

Received on Tuesday, 23 October 2012 10:16:23 UTC