- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Wed, 31 Oct 2012 20:10:34 -0000
- To: <public-tracking@w3.org>
- Message-ID: <053301cdb7a3$c9492a20$5bdb7e60$@baycloud.com>
Shane, Sorry, I just noticed your message. Here is my late reply: The ability for servers to get information on how they are being accessed was not main point, though I think it would still be useful. Often cookie headers are processed by code common to both situations and having an inline indication mechanism could make implementation easier. I was mainly thinking that it would be a way for companies to prove their compliance from retained logs. Potential ambiguities flagged like your yimg.net/yahoo.com case could be explained with a note if necessary. I was also trying to address the problem Ed Felton raised with the non UI exception API, where 1st party script accidentally (or maliciously) registers an exception for a 3rd party without the user giving consent. That is the function of the t= qualifier in the DNT:0 case indicated to a third party. Mike >>Mike, >>I believe this approach is only helpful for those cases where a 1st party believes its acting as 1st party but is instead "iframed" and >>acting as a 3rd party without its knowledge. Telling a 3rd party they are a 3rd party doesn't appear to offer much value. And in some >>cases it'll be inaccurate as you're simply telling the Server it's not the top level domain but it may already know that and still be >>considered first party. For example, Yahoo! image edge serving domain is yimg.net and when I see that on yahoo.com it's still >>considered 1st party. >>This seems like a tremendous amount of weight to add to the protocol to solve for a rare problem and one that can largely be managed >>through Server deployment architectures. >>- Shane
Received on Wednesday, 31 October 2012 20:11:10 UTC