- From: Fred Andrews <fredandw@live.com>
- Date: Tue, 23 Oct 2012 12:37:26 +0000
- To: Mike O'Neill <michael.oneill@baycloud.com>, 'Nicholas Doty' <npdoty@w3.org>
- CC: "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <BLU002-W18200620E6F5679560877E6AA790@phx.gbl>
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
Received on Tuesday, 23 October 2012 12:37:59 UTC