- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Mon, 22 Jul 2013 09:20:11 +0100
- To: "'Ronan Heffernan'" <ronansan@gmail.com>, "'Tracking Protection Working Group WG'" <public-tracking@w3.org>
- Message-ID: <007501ce86b4$49235290$db69f7b0$@baycloud.com>
Ronan, You keep your own counts for ad impressions, they would not need to be held in the browser, and it is up to the server how caching is implemented. The ETag counts would be useful for frequency capping, though you may not need to do that. Here is a demo of unique visitor detection (and low-entropy user-agent specific counting) using cache headers I have knocked together. There is no sharing/use of persistent unique identifiers, and no cookies. A new visit is communicated to the server by letting it know the time of the previous visit so the server can update its aggregated counts. There is no need to communicate a unique identifier so the individual cannot be tracked. http://cloudclinic.com/HiImDory The duration between unique visits is set to 10 seconds to keep it simple, but of course it could be any length of time. Mike From: Ronan Heffernan [mailto:ronansan@gmail.com] Sent: 19 July 2013 22:02 To: Mike O'Neill; Tracking Protection Working Group WG Subject: Re: issue-25 Mike, Having the top-level page in the URL parameters means that the incrementing ETag won't be incremented if the same ad is seen across sites, since the browsers will cache a separate copy for each site (since nearly all caching is URL-based)? BTW, we also issue a no-cache header, and add a cache-busting parameter, to keep the browsers and intermediate proxies from supplying the pixels out of cache. These are standard practices. That means that the browsers should not be caching the pixels or the current ETag value, so there will be no value for the webservers to increment. If you are right that these techniques offer a superior way to function in an environment that involves 3rd-party cookie blocking, then industry will adopt them even with the audience measurement permitted use exception. However, they do not seem to provide the functionality that we need. --ronan On Fri, Jul 19, 2013 at 3:45 PM, Mike O'Neill <michael.oneill@baycloud.com> wrote: Hi Ronan, If you read my first example I had a third-party element addressed via a URI containing the first-party page in a query parameter, so making the exchange top level page specific. It is not very complicated and it works. In addition to being DNT compliant it also avoids the default third-party cookie blocks which are becoming very common. Mike From: Ronan Heffernan [mailto:ronansan@gmail.com] Sent: 19 July 2013 20:02 To: Mike O'Neill Cc: Tracking Protection Working Group WG Subject: Re: issue-25 Mike, I call this improper because ETags already have a purpose and semantics. If I understand you correctly, we would have to use the exact same URL, so that the browser would use the ETag value that it cached. This means that we could no longer use "cache-busting" parameters, which means that intermediary proxies could serve the content, which destroys audience measurement. I understand the desire for really complicated, unproven, solutions, but none of the ones that I have heard so far seem likely to work. We have a solution that works, and is well proven. --ronan On Fri, Jul 19, 2013 at 12:30 PM, Mike O'Neill <michael.oneill@baycloud.com> wrote: Hi Ronan, No, not a unique identifier, which I agree would diminish privacy and should be ruled out along with any other tracking identifier collection when DNT is 1. What I meant was a count value (number of ad impressions) which I assume would have limited entropy i.e. the max value would be << the number of online individuals in scope. How many ad impressions would you need to count? I agree relying on the cache for 6 months would be a stretch, but do you need to do that? At some point there may be some loss of functionality when DNT is 1 but the setting is an important indication of user intent so needs to be honoured. How an ETag is generated in not specified in the HTTP spec, so in what way would this be "improper"? Mike .
Received on Monday, 22 July 2013 08:20:43 UTC