This partial draft attempts to reflect some of the points of consensus across multiple proposals presented at the Washington, DC f2f meeting, including issue-10 (what is a first party), issue-17 (data use by a first party), issue-19 (data collection and use by a third party), issue-31 (data minimization), issue-49 (third party on behalf of first party), and issue-73 (silo v. contract for outsourcing partner). It does not get into the disputed areas of issue-22 (operational use), issue-24 (fraud exemption), issue-25 (research exemption).
If you remember the eight page poster on the wall with only two points of major disagreement in DC, this draft tries to capture the parts where we basically agreed. The idea is to have a format we can now go through and tweak and fix, then hand off to the Compliance editors to integrate into a public draft. Our next step is to see where we have consensus on these issues, where we are still working out wording, and where there are differences. Please review this text carefully prior to discussions during the Seattle f2f.
Much of the text comes from two proposals, one from Jonathan / Peter / Tom, the other from Shane et. al. Extraordinarily little text is actually new. The structure is different, with definitions pulled to the beginning and a simplified hierarchy.
A functional entity is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person.
Functional entities are affiliated when they are related by both common majority ownership and common control.
A party is a set of functional entities that are affiliated and follow requirements to be easily discoverable.
A network interaction is an HTTP request and response, or any other set of logically related network traffic.
An outsourced party is any party, in a specific network interaction, that is working on behalf of a specific first or third party in compliance with the outsourced party information practices.
A first party is any party in a specific network interaction that can infer with high probability that the user knowingly and intentionally communicated with it, and complies with DNT under first party information practices.
A third party is any party in a specific network interaction that is not a first party, an outsourced party, or the user. A party without the ability to infer with high probability that the user knowingly and intentionally communicated with it MUST represent itself as a third party and comply with third party information practices. A first party MAY choose to represent itself as a third party and comply with third party information practices.
A dataset is unidentifiable when there is a high probability that it contains only information which could not be linked to a particular user, user agent, or device by a skilled analyst. N-unlinkability is the special case of K-anonymity where all values are considered part of the pseudo-identifier.
Protocol information includes:
Protocol information does not include:
A party collects data if the data comes within its control and the control of that data is not transient.
Open action on defining collection; this is not done
A party retains data if the data remains within the party's control.
A party uses data if the party processes the data for any purpose, including for storage.
A party shares data if the party enables another party to collect the data.
This section of the specification applies to all parties who comply with an incoming DNT signal. See the companion [[!TRACKING-DNT]] document for information on how to respond to an incoming signal.
This specification sets a minimum common standard for compliance. Any party MAY take additional steps to protect user privacy when responding to a Do Not Track request.
We have discussed this at length in action-152, action-157, and action-159. This section attempts to merge several texts together.
A party MAY engage in information practices otherwise prohibited by this recommendation if it has received explicit, informed consent from the user to do so, a
user-granted exception. When seeking a user-granted exception, sites SHOULD communicate those requests clearly, accurately, and in line with applicable law. Permission may be attained through either (A) receiving a DNT:0 signal, (B) the browser API defined in the companion [[!TRACKING-DNT]] document or (C) consent attained "out-of-band". An "out-of-band" consent mechanism has the same effect under this standard as the browser exception API.
Still to be addressed, DNT permission if consent from before (via Terms of Service or other) applies. ISSUE?
If a party has received prior consent for tracking a given user, user agent, or device, that consent overrides the general preference indicated by the DNT header. If a party chooses to track based on that prior consent, the party MUST indicate that status, as described in [[!TRACKING-DNT]]. For example, if you have two conflicting signals from a user with a global DNT:1 yet also have the user's consent specific to you (via browser API or out-of-band consent) then the user's consent is the correct signal to follow.
An "out-of-band" choice mechanism MUST additionally satisfy the following condition: A reasonable user would know that the choice overrides his or her general Tracking Preference.
Out-of-band consent will be further reinforced in user interactions through either the Header Response or Well-Known URI approaches to replying to user Tracking Preferences. This will provide a constant reminder of prior consent on each interaction and provide a resource (link) to allow the user to understand how this consent was achieved and ideally present options to alter that consent if the user chooses to do so.
We suggest the following properties for any out-of-band consent mechanism:
What constitutes explicit consent is not necessarily the same across all legal jurisdictions. It is the site's responsibility to ensure that it has consent.
Any party MAY collect, retain, or use unidentifiable data, subject to the requirements that the party MUST either:
Unidentifiable information will either be unidentifiable at the time of collection, or be made unidentifiable by aggregating data after it is collected; both are described below.
A party may collect non-protocol information if it is, independent of protocol information, unidentifiable data. The data may be retained and used subject to the same limitations as protocol information.
Example Advertising sets a language preference cookie that stores one of a few values, such as us, de, and so on, and thousands of users share the same language preference.
If we do not adopt the notion of a grace period for log files, then this section applies only to parties that know they are always first parties. For everyone else, the only form of permitted aggregation will be at the point of collection as things are currently written.
During the period in which a party may use protocol information prior to processing, it may aggregate protocol information and unidentifiable data into an unidentifiable dataset. Such a dataset may be retained indefinitely and used for any purpose.
Example Advertising maintains a dataset of how many times per week Italy-based users load an ad on Example News.
It would be helpful to describe what 1024-unlinkable means so we do not send implementers scrambling for other texts. Also useful, a discussion that this can be either calculated mathematically (with a pointer to a readable reference) or by estimating based on actual data, perhaps with non-DNT users or pre-DNT users.
While there is disagreement over whether discoverability is sufficient, we do seem to be converging on what discoverability is. Should we decide discoverability is not helpful, or insufficient, we can easily remove this section.
A functional entity must make its affiliated functional entities easily discoverable by a user.
In addition to the information practices for all parties as described in this section, for each network interaction an additional set of information practices applies based on which type of party you are during that network interaction: first party, outsourced party, or third party.
Determination of a party's status is limited to a single transaction because a party's status may be affected by time, context, or any other factor that influences user expectations. Other than some third parties becoming first parties when users interact (for example, social widgets or ads,) party status will usually stay stable for the entire interaction with a given user.
This section of the document applies just to first parties.
A first party MUST NOT share information with a third party that the third party is prohibited from collecting itself. A first party MUST NOT share (send or collect) identifiable information about a user to any party it does not have an outsource relationship with. [reference to "outsource" definition]
strawman: A first party MUST NOT share identifiable information about a user with any party with which it does not have an outsource relationship.
core purpose: to prevent a first party as a loophole?
While confining data just to the first party reflects discussions of the TPWG to date, newer members have concerns about these provisions.
We draw a distinction between those parties an ordinary user would or would not expect to share information with, "first parties" and "third parties" respectively. The delineation exists for three reasons.
First, when a user expects to share information with a party, she can often exercise control over the information flow. Take, for example, Example Social, a popular social network. The user may decide she does not like Example Social's privacy or security practices, so she does not visit examplesocial.com. But if Example Social provides a social sharing widget embedded in another website, the user may be unaware she is giving information to Example Social and unable to exercise control over the information flow.
Second, we recognize that market pressures are an important factor in encouraging good privacy and security practices. If users do not expect that they will share information with an organization, it is unlikely to experience market pressure from users to protect the security and privacy of their information. In practice, moreover, third parties may not experience sufficient market pressure from first parties since increasingly third parties do not have a direct business relationship with the first party websites they appear on. We therefore require a greater degree of user control over information sharing with such organizations.
Last, third parties are often in a position to collect a sizeable proportion of a user's browsing history — information that can be uniquely sensitive and easily associated with a user's identity. We wish to provide user control over such information flows.
We recognize that, unlike with a bright-line rule, there can be close calls in applying our standard for what constitutes a first party or a third party. But we believe that in practice, such close calls will be rare. The overwhelming majority of content on the web can be classified as first party or third party, with few cases of ambiguity in practice.
We require a confidence at a "high probability" before a party can consider itself a first party. Where there is reasonable ambiguity about whether a user has intentionally interacted with a party, it must consider itself a third party. Our rationale is that, in the rare close cases, a website is in the best position to understand its users' expectations. We therefore impose the burden of understanding user expectations on the website. We also wish, in close cases, to err on the side of conforming to user expectations and protecting user privacy. If the standard is insufficiently protective, ordinary users have limited recourse; if the standard imposes excessive limits, websites retain the safety valve of explicitly asking for user permission.
There will almost always be only one party that the average user would expect to communicate with: the provider of the website the user has visited. But, in rare cases, users may expect that a website is provided by more than one party. For example, suppose Example Sports, a well known sports league, collaborates with Example Streaming, a well known streaming video website, to provide content at www.examplesportsonexamplestreaming.com. The website is prominently advertised and branded as being provided by both Example Sports and Example Streaming. An ordinary user who visits the website may recognize that it is operated by both Example Sports and Example Streaming.
This section of the document applies just to third parties.
A third party may not collect, retain, use, or share any information related to communication with a user or user agent. There are exceptions to this general rule as defined in the following sections.
We recognize a limited set of data uses as important enough to continue even with data in potentially identifiable form. For all other uses, many of which are quite valuable, sites can ask users for permission. Note that first parties are not constrained to permitted uses. Outsourced parties may act as the party they work with would act: if working with a third party, they are also bound to this list of permitted uses.
While we agree on this general structure, we do not agree on uses at this point.
A party may start out as a third party but become a first party later on, after a user interacts with it. If content from a third party is embedded on a first party page, the third party may become an additional first party if it can infer with high probability that the average user knowingly and intentionally communicated with it. If a user merely moused over, closed, or muted third party content, the party would not be able to draw such an inference.
Discussion: Example Weather is a third party. The user has interacted with Example Weather's widget, but an ordinary user would not expect that scrolling through the widget involves communicating with Example News.
Example: Example Social, a popular social network, hosts a social sharing button that other websites can embed. The button is colored and styled in the same fashion as Example Social's website, contains descriptive text that is specific to Example Social, includes Example Social's logo, and very frequently appears on Example Social's website. Example News embeds the Example Social button, and a user clicks it.
Discussion: Example Social is a first party once the user clicks its embedded social sharing button. The average user would understand that by clicking the button she is communicating with Example Social.
This section applies to parties engaging in an outsourcing relationship, wherein one party "stands in the shoes" of another party to perform a specific task. Both parties have responsibilities, as detailed below.
A first party or a third party MAY outsource functionality to another party, in which case the third party may act as the original first party or third party under this standard, with the following additional restrictions:
An outsourced company acting on the behalf of another party is subject to all of the same restrictions on that party (for First or Third party, as appropriate.)
Outsourced companies that act purely as vendors for their customers (often first parties in this context) are not the intended target for the Tracking Preference Expression but it is important there are no unintended activities that are extended to another party through this allowance. In all cases, its expected an outsourced company acting on the part of a customer follows all of the same restrictions placed on that customer.
For the data separation requirement, outsourced companies have technical options to achieve appropriate separation but in each the critical element is that data is never reconstituted for users that have indicated a preference not to be tracked. One possible approach would be to leverage a per partner hash against a common cookie identifier, ensuring the resulting identifier is consistent for a specific customer, but is unable to be linked with another customer’s identifier.
Contractual requirements that enforce data rights and responsibilities for separation are a critical element of establishing an outsourcer acting on another party’s behalf. Contracts may occur directly through parties (for example, a Publisher in an Ad Network) or between intermediaries (for example, an Ad Network acting through an Ad Exchange). In either case, data separation and removal of independent rights are necessary elements that must survive intermediary contractual constructs.
Throughout all data collection, retention, and use, outsourced parties MUST use all feasible technical precautions to both mitigate the identifiability of and prevent the identification of data from different first parties.
Structural separation ("siloing") of data per first party, including both
are necessary, but not necessarily sufficient, technical precautions.
Outsourcing services should use browser access control features so that stored data specific to one party is never accessed or collected when the user visits another party.
The same-origin policy silos stored data by domain name. An outsourcing service can use a different domain name for each first party.
Example Analytics provides an outsourced analytics service to Example News and Example Sports, two unrelated websites. Example Analytics stores its cookies for Example News at examplenews.exampleanalytics.com, and it stores its cookies for Example Sports at examplesports.exampleanalytics.com.
The HTTP cookie path can be used to silo data to a first party.
Example Analytics stores its cookies for Example News with "Path=/examplenews", and it stores its cookies for Example Sports with "Path=/examplesports".
For key/value storage APIs, such as Web Storage and Indexed Database, an outsourcing service can use a different key or key prefix for each first party.
Example Analytics stores data for Example News at window.localStorage["examplenews"] and data for Example Sports at window.localStorage["examplesports"].
An outsourcing service should encrypt each first party's data with a different set of keys.
An outsourcing service should deploy access controls so that only authorized personnel are able to access siloed data, and only for authorized purposes.
An outsourcing service should deploy access monitoring mechanisms to detect improper use of siloed data.
An outsourcing service should retain information only so long as necessary to provide necessary functionality to a first party. If a service creates periodic reports, for example, it should delete the data used for a report once it is generated. An outsourcing service should be particularly sensitive to retaining protocol logs, since they may allow correlating user activity across multiple first parties.
Throughout all data collection, retention, and use, outsourced parties MUST use sufficient internal practices to prevent the identification of data from different parties.
An outsourcing service should establish a clear internal policy that gives guidance on how to collect, retain, and use outsourced data in compliance with this standard.
Personnel that interact with outsourced data should be familiarized with internal policy on compliance with this standard.
An outsourcing service should establish a supervision and reporting structure for detecting improper access.
External auditors should periodically examine an outsourcing service to assess whether it is in compliance with this standard and has adopted best practices. Auditor reports should be made available to the public.
An outsourced service:
A party's representation that it is in compliance with this standard includes a representation that its outsourcing parties comply with this standard.
A first party MUST enter into a contract with an outsourced party that requires that outsourced party to comply with these requirements.