W3C home > Mailing lists > Public > public-tracking@w3.org > October 2012

Re: ACTION-254: Draft text on freq. capping that would avoid new definitions and/or remove redundant normative requirement

From: Nicholas Doty <npdoty@w3.org>
Date: Wed, 31 Oct 2012 12:14:28 +0100
Cc: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>, "Amy Colando (LCA)" <acolando@microsoft.com>
Message-Id: <17EFDA73-B935-4162-A652-F96C1CCECABE@w3.org>
To: Shane Wiley <wileys@yahoo-inc.com>
Thanks for the notes, Shane. Comments inline.

On Oct 31, 2012, at 11:05 AM, Shane Wiley <wileys@yahoo-inc.com> wrote:

> Nick,
> 
> This is close.  I've made a few edits as I believe there are two use cases we're attempting to cover:
> 	- Non-Site Specific Frequency Capping:  No need of specific URL structure in these cases
> 	- Site-Specific Frequency Capping:  Mask the URL structure in some way to avoid retaining URL History in the clear for the purpose of frequency capping.
> 
> NOTE:  As all Permitted Uses are to be used expressly and only for the purpose outlined, I don't believe the last sentence is needed (already covered in the "master" Permitted Use rules).  I also believe that Permitted Uses being applied specifically to third parties is already covered in the "master" Permitted Use rules but I've left it in for argument sake.

Sure, I was mostly just providing that as a reminder as some people might be concerned that this was opening a loophole when in fact we have a general requirement there. I'm happy for the editors to remove that or include references depending on what they think is easiest for the reader.

> "<Normative> 
> Operators may retain data related to a communication in a third-party context to use for limiting how often advertisements are shown to a particular user if the data retained do not include the user's browsing history in the clear.

We haven't used "in the clear" in the past, right? Is that a different requirement or do we all agree that what's important is that for this permitted use the URL history is not retained? If you've transformed the data so that you can't get the original back, then I think that satisfies the requirement not to retain this data for the purpose. (Conversely, I don't think encrypting the URL history while retaining the key makes a difference. Limits on not retaining data are distinct from the general requirement to use reasonable security.)

> <Non-Normative>  
> Non-site specific frequency capping can occur by retaining a unique cookie identifier, a campaign ID, and a counter (may be a master counter or broken down by day-part) - there is no need to retain a user's URL in this scenario.  For site-specific frequency capping, Operators can mask the URL structure of the site through approaches like hashing the user ID against the URL that is the target of frequency capping.  This will result in a consistent identifier to use for frequency capping but not reveal the actual URL that is being visited."

I'm happy to provide some examples of privacy-preserving frequency capping techniques; I suggest we move those in general to an appendix. I think Jonathan and others can provide some examples that don't require a unique identifier cookie, and that all these technique details will be left up to implementers.

I'm not sure I understand the full details of the second technique, but I certainly imagine there are hashing techniques that would provide site-specific frequency capping without the server being able to re-create a log of URL visits from that history. 

Thanks,
Nick

> -----Original Message-----
> From: Nicholas Doty [mailto:npdoty@w3.org] 
> Sent: Wednesday, October 17, 2012 3:39 AM
> To: public-tracking@w3.org (public-tracking@w3.org)
> Cc: Shane Wiley; Amy Colando (LCA)
> Subject: ACTION-254: Draft text on freq. capping that would avoid new definitions and/or remove redundant normative requirement
> 
> I think Shane and Amy were taking the lead on new possible text for frequency capping, but here is one attempt:
> 
>> Operators may retain data related to a communication in a third-party context to use for limiting how often advertisements are shown to a particular user if the data retained do not include the user's browsing history (for example, page URIs on which ads were past delivered). For this permitted use, operators must not construct profiles of users or user behavior based on their ad frequency history  or otherwise alter the user's experience based on this data.
> 
> The motivation here was to reflect the idea from the Bellevue meeting of frequency capping that doesn't retain URI histories, but to make that a high-level requirement rather than a specific implementation (hashing of campaign IDs). It may be that those implementations would still be useful examples for an appendix. Shane, Amy or others, please let me know whether this captures what you had in mind.
> 
> Thanks,
> Nick
> 
Received on Wednesday, 31 October 2012 11:14:39 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:37 UTC