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

David,

#1 - Agreed - Aggregate & Anonymous appears to be outside the scope of DNT and we're simply making that very clear through this exception.  A bigger question this leads to is how long can data live in raw form prior to aggregation/anonymization to fit within this exception.

#2 - It's not my intention to make a huge, gapping loop-hole so I look forward to us tightening down on the exceptions language to not allow activities that modify a user's online experience if they have DNT enabled.

#3 - Agreed - more discussion needed.  Please see my comments to Jeff C. and John S. in this regard.

#4 - I would say Researchers like keeping data for as long as possible and Engineers on the other hand are fine with getting rid of it sooner rather than later (especially if it gives them greater storage budget for new features :) ).  That said, I agree with the principles of minimization and suggest we continue to support those in the standard.

#5 - The data most security teams works with is digital fingerprint oriented and not personally identifiable.  Bad guys learned long ago to not use real accounts when attempting to do bad things.

I would rename the "what could go wrong" section to "known limits to any voluntary technical standard" as I believe it covers what you've outlined and more.

- Shane

From: David Singer [mailto:singer@apple.com]
Sent: Wednesday, February 01, 2012 6:22 AM
To: Shane Wiley
Cc: Tracking Protection Working Group WG
Subject: Re: ACTION-49: Propose what the operational carve-outs for 3.6.1.2.1 (e.g. debugging by 3rd party) are

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.