Re: ACTION-49: Propose what the operational carve-outs for 3.6.1.2.1 (e.g. debugging by 3rd party) are

Excellent points from David.

On Feb 1, 2012, at 3:21 AM, David Singer wrote:

> Shane, thanks
> 
> Some points
> 
> 1) tracking is about records that are per-user ('personally derived data').  somewhere in the document we should state that aggregated, statistical, data is not tracking and does not concern us ('we had 2361 visitors from Sweden last week').  this kind of data is not an 'exception', it's not our concern, I think.  So also the mention of aggregation in 'market research'.
> 
> 2) I would like to see some analysis of these rules taking the stance of an organization who decides to 'stretch them to the limit'.  I am concerned that they may be able to go quite far.
> 
> 3) 'Market Research' is a pretty broad term;  following on from (2), the research 'exception' to whaling has permitted a lot of whales to be caught.  This worries me.
> 
> 4) This exception needs, in my opinion, an over-riding 'you must only keep the minimum amount of data required for the actual need you have'.  Engineers hate throwing data away, and will often squirrel data just in case it could be useful in future.  Not acceptable with personally-derived data, I fear.
> 
> 5) This exception also needs a requirement that the data be anonymized and uncorrelatable to the greatest extent possible; that if the database leaks, even though it contains per-user records, it should be hard or impossible to associate any record with an identifiable person or other records.
> 
> 
> 
> [We also need, perhaps, a section in the document about 'what could go wrong'.  For example, if you exercise an exception, then think hard about what may happen if
> * there is a change of management, strategy, or policy in the organization
> * the organization is sold
> * the database's security is compromised]
> 
> 
> 
> On Jan 31, 2012, at 5:54 , Shane Wiley wrote:
> 
>> Description:
>> Propose what the operational carve-outs for 3.6.1.2.1 (e.g. debugging by 3rd party) are
>>  
>> NOTE – Initially captured in ISSUE-22
>>  
>> Draft:
>> <Non-Normative>
>> In order to not "break the Internet" and still protect consumer privacy concerns, it will be necessary to provide operational
>> purpose exceptions for critically necessary business activities even when the DNT signal is on. There are several key categories of data collection and use that must remain intact such that web site operators who are (in the vast majority) offering their services free of charge in exchange for advertising on their properties.
>>  
>> In order to motivate immediate web-wide implementation of the DNT standard upon release it will be important to focus on use based exceptions initially.  Where technical solutions exist and are readily available, parties should transition to these options over use-based restrictions.  It’s difficult to put an exact date for when these solutions will become generally available in the marketplace but it will be critical for large site operators to collaborate with industry and academics to develop these future solutions as soon as possible.
>>  
>> With this in mind, the following exceptions are to be interpreted as MUST employ use-based controls and SHOULD employ technology solutions that avoid collection in the first place.
>>  
>> <Normative>
>> Parties may continue to collect and use data in a very limited number of operational purposes outlined here:
>>  
>> - Frequency Capping:  A form of historical tracking to ensure the number of times a user sees the same ad is kept to a minimum.  Provides a benefit to users to not see the same ad over and over again, as well as, a benefit to advertisers who receive negative brand reaction if an ad is shown too many times to users.  Capping data collection and use SHOULD be limited to only campaign IDs and frequency counters where possible.
>>  
>> - Financial Logging:  Ad impressions and clicks (and sometimes conversions) events are tied to financial transactions (this is how online advertising is billed) and therefore must be collected and stored for billing and auditing purposes.  Information such as what targeting criteria existed for a particular ad campaign MAY need to be retained for audit purposes to demonstrate an ad server met its obligations to an advertiser.
>>  
>> - Aggregated & Anonymous Reporting:  Data may be retained if it is de-identified and aggregated in such a manner as to not allow re-identification of an individual or unique device.
>>  
>> - 3rd Party Auditing:  As online advertising is a billed event and there are concerns with accuracy in impression counting and quality of placement so 3rd party auditors provide an independent reporting service to advertisers and agencies so they can compare reporting for accuracy.
>>  
>> - Security:  From traditional security attacks to more elaborate fraudulent activity, Ad Servers and Publishers must have the ability to log data about suspected bad actors to discern and filter their activities from legitimate transactions. This information is sometimes shared across 3rd parties in cooperatives to help reduce the daisy-chain effect of attacks across the ad ecosystem.
>>  
>> - Market Research:  Data collected for the express purpose of market research MAY be retained at a per user/device level for a limited time to allow for reasonable aggregation.
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 

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