Re: issue-25

Mike,
   There is no HTTP/HTTPS problem for cookies, as long as those cookies are
not marked "secure".  You are right that anyone using HTML5 LocalStorage
would have a problem with HTTP/HTTPS.  The clear tag URI cannot contain the
address of the page, since the frequency capping and reach counting has to
be performed on an ad-centric, not location- or user-centric basis.  The
creative_id is not sufficient; counting also has to be done at the
campaign_id level.  I don't see anything that addresses cache limitations
in mobile and embedded user agents, including the fact that some of the
popular mobile user agents support neither LastModified nor ETags, and some
others clear all cache on power-cycle or browser-exit.

--ronan



On Mon, Jul 22, 2013 at 9:46 AM, Mike O'Neill
<michael.oneill@baycloud.com>wrote:

> Ronan,****
>
> ** **
>
> Multiple counts could be easily encoded into the ETag value (or indeed a
> low-entropy cookie). The point is that there is no need to communicate a
> persistent user-specific value, and a little effort spent up-front can
> avoid it. ****
>
> ** **
>
> I cannot see anything here that needs UIDs, which are a transparent and
> verifiable signal for DNT compliance,  and we should not introduce a gaping
> hole in the standard for the sake of a small degree of technical effort.**
> **
>
> ** **
>
> On your other points:****
>
> ** **
>
> **·        **Cache-Control: private is enough to stop intermediates
> getting in the way.****
>
> **·        **People purge their cookies as well as caches. There probably
> is not much difference in stickiness.****
>
> **·        **https/http is as the same-origin issue This would be a
> problem for anything including localStorage and cookies. Use https for your
> tags and embed the top level origin as a parm. (don’t rely on Referer: )**
> **
>
> **·        **Caching is always based on the whole URI. The clear tag URI
> will contain the address of the page ( and the creative_id etc. if you want)
> ****
>
> ** **
>
> Mike****
>
> ** **
>
> ** **
>
> *From:* Ronan Heffernan [mailto:ronansan@gmail.com]
> *Sent:* 22 July 2013 13:56
> *To:* rob@blaeu.com
> *Cc:* Mike O'Neill; Tracking Protection Working Group WG
> *Subject:* Re: issue-25****
>
> ** **
>
> That is a frequency capping requirement, not an audience measurement
> requirement, but audience measurement reports (counts of how many browsers
> saw a creative 6 times, how many browsers saw the creative 7 times, etc.)
> are used by the advertisers to verify that the frequency capping contract
> is being properly fulfilled by the publishers or ad networks.****
>
> ** **
>
> --ronan****
>
>
>
> On Monday, July 22, 2013, Rob van Eijk wrote:****
>
>
> ? The ad contract is pretty specific:  7-times frequency cap on each
> creative and a 14-times frequency cap on the whole (6 creative) campaign,
> on a 6-month campaign
>
> That example sounds like a set of performance indicator for individual ads
> delivered to unique browsers, across sites and time.
>
> Rob****
>

Received on Monday, 22 July 2013 13:55:28 UTC