I've included below what could be a "middle way" on permitted uses, based on what I've heard from the group. ("Middle" is not to meant to imply any particular measurements or distances, of course, just somewhere between the proposals we've heard.) The text below is long, but provides full text and explanatory text as well. This is not a brand new proposal but trying to take ideas from the proposals presented and the discussions we've had in the group already. This draft includes updates from discussion on teleconferences and at the last face-to-face; in many cases the editors' draft now has largely the same content. Where this proposes changes from the editors' draft, I've noted in plum-colored boxes.
Adherence to laws, legal and judicial process, and regulations take precedence over this standard when applicable, but contractual obligations do not.
Replace "Compliance With Local Laws and Public Purposes" section with previously agreed upon text (5/23/2012).
Placing third-party cookies with unique identifiers (and other techniques for linking data to a user, user agent or device) are permitted where reasonably necessary for a permitted use. Requirements on minimization and secondary use, however, provide limitations on when any collection technique is compatible with a Do Not Track preference and what the implications of that collection are.
To give flexibility to implementers in accomplishing the requirements of this specification and the listed permitted uses, no particular data collection techniques are prescribed or prohibited.
Implementers are advised that collection of user data under a Do Not Track preference (including using unique tracking cookies or browser fingerprinting) may reduce external auditability, monitoring and user confidence and that retention of such data may imply liability in certain jurisdictions in cases of secondary use; for more information, see the Global Considerations.
A third party MUST ONLY retain information for a permitted use for as long as is reasonably necessary for that use. Third parties MUST make reasonable data minimization efforts to ensure that only the data necessary for the permitted use is retained. A third party MUST provide public transparency of their data retention period; third parties may enumerate each individually if they vary across Permitted Uses. Once the period of time for which a party has declared data retention for a given use, the data must not be used for that permitted use. After there are no remaining Permitted Uses for given data, the data must be deleted or rendered unlinkable.
Where feasible, a third party MUST NOT collect linkable data when that data is not reasonably necessary for one of the permitted uses.
Add collection limitation requirement.
It may be that this is the only time a requirement/prohibition is necessary regarding "collection". All other requirements would be prohibitions on retention (beyond what is necessary, or beyond a short-term logging period) or sharing. A definition of collection, then, is only needed for this minimization concept. "Tracking" can be defined through "retention", "use" and "share" only.
A third party MUST NOT use data retained for a particular permitted use for any other purpose.
Clarify that data retained for one purpose cannot be re-purposed (even if the second purpose might be related to another permitted use).
This does not require keeping separate copies of data for different permitted uses (agreement in Seattle that a single copy is allowable), but does require that data retained for one stated purpose cannot be repurposed, even in aggregate form. (See resolution at the end of the Bellevue meeting.)
Outside of security and frequency capping, data retained for permitted uses must not be used to alter a specific user's online experience.
Remove "based on multi-site activity" from the "No Personalization" section.
Operators MAY retain data related to a communication in a third-party context for up to six weeks. During this time, operators may render data unlinkable (as described above) or perform processing of the data for any of the other permitted uses.
Rather than a separate blacklist, clarify that the uses are just the existing uses and a time to render data unlinkable. Six weeks is suggested for the time period to faciliate monthly log analysis.
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.
This is intended to build off of the option text out of the small-group discussion in Seattle, but, as requested, at a higher-level set of requirements than any particular implementation.
Operators MAY retain data related to a communication in a third-party context to use for billing and auditing of concurrent transactions. This may include counting ad impressions to unique visitors, verifying positioning and quality of ad impressions and auditing compliance with this and other standards. Note that (as described above/below) these requirements do not prohibit retention and use of data required by law or regulation, but the existence of a contractual requirement to retain data does not take precedence over compliance with these requirements.
This permitted use is intended to provide for recording, reporting and verifying delivery of and interaction with online advertising and similar activities. It is not intended to cover retaining a user's ad impression to combine with later browsing activity, subsequent conversion, frequency capping or ad sequencing. Note that when a user meaningfully interacts with an ad or widget, such interaction is likely in a first-party context (and therefore not restricted by these third-party requirements).
This is a new attempt at a replacement for existing text on financial reporting, an update from a past proposal based on financial reporting law. The limiting factor of the "concurrent transaction" is an attempt to enable the transactional billing (and related audits) while not allowing any type of data collection required by a contract, as I believe is the common intent of the group.
Operators MAY retain data related to a communication in a third-party context to use for detecting security risks and fraudulent activity, defending from attacks and fraud, and maintaining integrity of the service. This includes data reasonably necessary for enabling authentication/verification, detecting hostile transactions and attacks, providing fraud prevention, and maintaining system integrity. In this example specifically, this information MAY be used to alter the user's experience in order to reasonably keep a service secure or prevent fraud. As described in the general requirement for minimization, operators MUST NOT retain data that is not necessary to maintain security; for example, in some cases a triggered or graduated response may be feasible.
This mostly follows the current editors' draft text; I've provided an update on graduated response as an example of the data minimization requirement, rather than a distinct normative requirement.
Operators MAY retain data related to a communication in a third-party context to use for identifying and repairing bugs in functionality. As described in the general requirements [reference to Minimization section], for this permitted use services MAY collect and retain data from DNT:1 users ONLY when reasonably necessary to identify and repair errors in functionality; in some cases, graduated responses (for example, collecting more data after report of a bug) may be feasible. This permitted use is intended for short-term diagnosis and repair of third-party Web functionality, not to cover broad quality assurance measurements.
Changes from the editors' draft: Clarify that this is for short-term investigation and bug fixing rather than an open-ended permission. Add minimization requirement/pointer.
Non-normative text, in a separate appendix, will provide suggestions for privacy-preserving techniques and data minimization approaches. Implementers are not required to use any particular technique to fulfill the requirements in this specification, but a listing of techniques might provide useful guidelines.
Implementers are advised to consider proportionality, user expectations and user consent in development and deployment. As described in the Global Considerations document, proportionality of data collection to purpose may be a legal requirement in some jurisdictions.