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

I share Shane's question about how we see the non-normative text relating to what's in  an appendix....
Thanks,
John


----------
John M. Simpson
Consumer Advocate
Consumer Watchdog
2701 Ocean Park Blvd., Suite 112
Santa Monica, CA,90405
Tel: 310-392-7041
Cell: 310-292-1902
www.ConsumerWatchdog.org
john@consumerwatchdog.org

On Oct 31, 2012, at 5:11 AM, Shane Wiley wrote:

> Nick,
> 
> Good points.
> 
> 1)  We should generally agree if we're going to repeat elements of the "master" Permitted Uses rules in the individual Permitted Uses.  I believe Rigo recently asked for a non-normative reminder for the "Finance/Audit" Permitted Use.  I personally think this is wasteful and bloats the document unnecessarily.  Others may think that implementers will only look at very specific sections of the document and not read the entire document so these types of re-statements will be necessary.
> 
> 2)  Fine with using different terms - or making a simple statement of "not retaining URL history" as any method that achieves that outcome meets the rule.
> 
> 3)  I like the idea of adding the client-side storage example here.  Why would we move this non-normative text (examples) to an appendix though?  Are we going to do that for all non-normative text?
> 
> Thank you,
> Shane
> 
> -----Original Message-----
> From: Nicholas Doty [mailto:npdoty@w3.org] 
> Sent: Wednesday, October 31, 2012 7:14 AM
> To: Shane Wiley
> Cc: public-tracking@w3.org (public-tracking@w3.org); Amy Colando (LCA)
> Subject: Re: ACTION-254: Draft text on freq. capping that would avoid new definitions and/or remove redundant normative requirement
> 
> 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
>> 
> 
>