- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Tue, 23 Oct 2012 11:15:24 +0100
- To: "'Nicholas Doty'" <npdoty@w3.org>
- Cc: <public-tracking@w3.org>
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