- From: Karl Dubost <karld@opera.com>
- Date: Fri, 18 Nov 2011 00:30:10 -0500
- To: Shane Wiley <wileys@yahoo-inc.com>
- Cc: "<public-tracking@w3.org> (public-tracking@w3.org)" <public-tracking@w3.org>
Le 17 nov. 2011 à 21:56, Shane Wiley a écrit : > On the "how" - in the use case we were exploring, example.org dynamically assembles its pages and at that time includes the beacon for stats.com - and typically passes some information about users to stats.com for independent use (I don't believe this happens very often in the real world but our goal here is to close on a suspected loop hole). So anonymousJoe creates an HTTP request on SWEET.example.org with DNT:1 for the first time. The page is dynamically created with either a variable in the page saying DO NOT TRACK this page and/or a cookie saying DNT. If I continue to follow your reasoning for each potential services that have been put in the initial page there will be a different beacon (let say cookies). STATS and SUPERTRACKING, because the first one is just STATS and the second one is tracking. The user then is going on BADABOUM.example.net with DNT:1 which has also deals with STATS and SUPERTRACKING, but BADABOUM.example.net is a simple web site with no complex infrastructure. They can't implement the specific cookie dance. * What is happening for the user anonymousJoe? * What is SUPERTRACKING doing with the received data in the two cases? > If example.org sees the DNT signal from user 1234, for all subsequent pages built for user 1234 they would no longer include this add'l information in the beacon call. This happens server-side during page assembly to be sent to the user's web browser (which is what I meant by outside of browser controls). Here you assume you have a user 1234 with an account? Correct? -- Karl Dubost - http://dev.opera.com/ Developer Relations & Tools, Opera Software
Received on Friday, 18 November 2011 05:30:45 UTC