Tracking Compliance Alternative B

Tracking Compliance and Scope defines a set of requirements and best practices regarding tracking to which an origin server can claim adherence by reference within the tracking status representation of the Tracking Preference Expression (TPE) protocol. These requirements and best practices are intended to meet a user's expectations regarding a Do Not Track (DNT) preference by limiting tracking by third parties to specific permitted uses and retention policies when DNT:1 is received.

Terminology

This specification uses the following terms as they have been defined by [[!TRACKING-DNT]]: tracking, context, designated resource, user, user agent, network interaction, user activity, party, first party, third party, collects, uses, and shares.

Service Provider

Access to Web resources often involves multiple parties that might process the data received in a network interaction. For example, domain name services, network access points, content distribution networks, load balancing services, security filters, cloud platforms, and software-as-a-service providers might be a party to a given network interaction because they are contracted by either the user or the resource owner to provide the mechanisms for communication. Likewise, additional parties might be engaged after a network interaction, such as when services or contractors are used to perform specialized data analysis or records retention.

For the data received in a given network interaction, a service provider is considered to be the same party as its contractee if the service provider:

processes the data on behalf of the contractee;
ensures that the data is only retained, accessed, and used as directed by the contractee;
has no independent right to use the data other than in a permanently de-identified form (e.g., for monitoring service integrity, load balancing, capacity planning, or billing); and,
has a contract in place with the contractee which is consistent with the above limitations.

Permanently De-identified

Data is permanently de-identified when there exists a high level of confidence that no human subject of the data can be identified, directly or indirectly (e.g., via association with an identifier, user agent, or device), by that data alone or in combination with other retained or available information.

De-identification Considerations

The term permanently de-identified is used for data that has passed out of the scope of this specification and cannot, and will never, come back into scope. The organization that performs the de-identification needs to be confident that the data can never again identify the human subjects whose activity contributed to the data. That confidence might result from ensuring or demonstrating that it is no longer possible to:

isolate some or all records which correspond to a device or user;
link two or more records (either from the same database or different databases), concerning the same device or user;
deduce, with significant probability, information about a device or user.

Regardless of the de-identification approach, unique keys can be used to correlate records within the de-identified dataset, provided the keys do not exist and cannot be derived outside the de-identified dataset and have no meaning outside the de-identified dataset (i.e. no mapping table can exist that links the original identifiers to the keys in the de-identified dataset).

In the case of records in such data that relate to a single user or a small number of users, usage and/or distribution restrictions are advisable; experience has shown that such records can, in fact, sometimes be used to identify the user or users despite technical measures taken to prevent re-identification. It is also a good practice to disclose (e.g. in the privacy policy) the process by which de-identification of these records is done, as this can both raise the level of confidence in the process, and allow for for feedback on the process. The restrictions might include, for example:

technical safeguards that prohibit re-identification of de-identified data and/or merging of the original tracking data and de-identified data;
business processes that specifically prohibit re-identification of de-identified data and/or merging of the original tracking data and de-identified data;
business processes that prevent inadvertent release of either the original tracking data or de-identified data;
administrative controls that limit access to both the original tracking data and de-identified data.

Geolocation data (of a certain precision or over a period of time) might cause otherwise de-identified data to become re-identified.

Compliance

Indicating Compliance

To indicate compliance with this specification for a given designated resource, an origin server MUST do all of the following:

conform to the origin server requirements of [[!TRACKING-DNT]];
send a value other than ! (under construction) or D (disregarding) for a tracking status value (TSV) applicable to that designated resource; and
send, in a tracking status representation applicable to that designated resource, a compliance property that contains at least one reference to the following URI:
http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html

The editor's draft URI points to content that will change and is only suitable for testing purposes. Versions of this document that are published as Working Drafts or later maturity levels will use permanent URIs in this section, pointing to content that does not change.

Communicating Tracking Status

When a tracking status representation is used to communicate the tracking status for a designated resource, the origin server MUST send within the representation's tracking property a TSV that is consistent with the current or anticipated tracking that might occur if a similar request is sent to that designated resource.

When a Tk response header field [[!TRACKING-DNT]] is used to communicate a tracking status for the current request, the origin server MUST send a TSV that either refers to a request-specific tracking status resource or reflects the target resource's current tracking behavior for this request.

Adhering to Tracking Status

An origin server that sends a TSV of N (not tracking) MUST NOT engage tracking if a similar request is made to the designated resource while that tracking status remains fresh. A tracking status remains fresh until 24 hours after retrieval or, if later, until the HTTP response metadata indicates that it is stale (see Section 6.4.4 Caching of [[!TRACKING-DNT]]). In other words, the party MUST NOT knowingly collect, retain, use, or share data from a network interaction with the designated resource that would allow that party to associate the same user with tracking data it has previously obtained from user activity in other contexts, MUST NOT retain, use, or share data derived from this user activity outside the context in which this activity occurred, and MUST NOT tailor or personalize the response from the designated resource based on data derived from this user's activity in other contexts (aside from contextual data provided by the user in the current request).

An origin server that sends a TSV of T (tracking) MAY engage tracking if a similar request is made to the designated resource. Further limitations on that tracking depend on the received tracking preference expression, if any:

DNT:0: The user is expressing a preference for a personalized experience and this signal indicates explicit consent for data collection, retention, use, and sharing by the recipient of this signal to provide a personalized experience for the user. This specification does not limit tracking in the presence of DNT:0. Note, however, a party might be limited by its own statements to the user, if any, regarding the DNT:0 setting.
DNT:1: The party MUST limit its tracking to the permitted uses defined in . The party MAY provide additional information in the qualifiers property of a tracking status representation to indicate what permitted uses of tracking are engaged while under DNT:1, as described in . The party MUST NOT share data about this network interaction with any party other than the controller(s) of the context in which this activity occurred, service providers to said controller(s), or service providers to the party.
not enabled: In the absence of regulatory, legal, or other requirements, a party MAY interpret the lack of an expressed tracking preference as they find most appropriate for the given user, particularly when considered in light of the user's privacy expectations and cultural circumstances. Likewise, origin servers might make use of other preference information outside the scope of this specification, such as site-specific user preferences or third-party registration services, to inform or adjust their behavior when no explicit preference is expressed in a request.

An origin server that sends a TSV of C (consent) MUST have received prior consent for tracking this user, user agent, or device, perhaps via some mechanism not defined by this specification, that overrides a tracking preference expressed by this protocol.

An origin server that sends a TSV of P (potential consent) MAY engage tracking for requests made to the designated resource, but MUST NOT use or share any data to which DNT:1 applies until it can be determined that it has received prior consent to do so. If not, the origin server MUST delete or permanently de-identify the collected data within forty-eight hours.

An origin server MAY send a tracking status value of ? (dynamic), D (disregarding), or U (updated) when such a response is consistent with its associated requirements in [[!TRACKING-DNT]].

Limited Tracking Permitted under DNT:1

When an origin server sends a TSV of T (tracking) for a designated resource and a request is received targeting that resource with a tracking preference expression of DNT:1, some limited tracking is still permitted if it conforms to the requirements of this section.

General Requirements for Permitted Uses

Data Minimization, Retention, and Transparency

When DNT:1 is received, a third party MUST minimize the tracking data it collects under one or more permitted uses to what is reasonably necessary for each such permitted use. A third party MUST NOT retain such data any longer than is proportionate to, and reasonably necessary for, those permitted uses.

A third party MUST provide public transparency of the time periods for which tracking data collected for permitted uses are retained. A third party MAY enumerate different retention periods for different permitted uses. A third party MUST NOT use data collected for a permitted use once the data retention period for that permitted use has expired. When all such data retention periods have expired for the permitted uses for which a given data set has been retained, the third party MUST delete or permanently de-identify that data.

Aside from what is reasonably necessary for each permitted use, a third party to a given user action MUST NOT collect, share, or associate with related network interactions any identifiers that identify a specific user, user agent, or device. For example, a third party that does not require unique user identifiers for one of the permitted uses MUST NOT place a unique identifier in cookies or other browser-based local storage mechanisms.

No Secondary Uses

When DNT:1 is received, a third party MUST NOT use tracking data collected in that request for purposes other than the permitted use(s) for which that data was collected.

A third party that collects tracking data under a permitted use MUST implement reasonable technical and organizational safeguards to prevent further processing of that data for non-permitted uses. While physical separation of data retained for permitted uses is not required, a third party SHOULD implement best practices and technical controls that ensure access limitations and information security. A third party SHOULD ensure that access and use of data retained under one or more permitted uses is auditable.

Permitted Uses

First Party

A first party is expected to provide functionality requested by the user even if that functionality makes use of tracking. This includes customizing content, services, and advertising with respect to such user actions.

When DNT:1 is received in a network interaction with a designated resource that is either intended only for use in a first party context or dynamically discerned to be within a first party context, a party acting as a first party for that context MAY engage tracking and collect, retain, and use data from that network interaction. However, a party MUST NOT share DNT:1 tracking data collected as a first party with third parties who are prohibited from collecting such data under this recommendation. A first party MAY share such data with service providers acting on behalf of the first party.

A first party MAY elect to ignore this permitted use and instead follow the rules defined under this recommendation for third parties.

Frequency Capping

When DNT:1 is received, a party MAY collect, retain, and use tracking data to limit the number of times that a user sees a particular advertisement — a practice commonly referred to as frequency capping — provided that the retained data does not reveal the user’s browsing history. A party MUST NOT construct profiles of users or user behaviors, or otherwise alter a user’s experience beyond the effect of frequency capping, based on the ad frequency history retained under this permitted use.

Financial Logging

When DNT:1 is received, a party MAY collect, retain, and use tracking data to support billing and auditing related to the current network interaction and concurrent transactions. This may include counting ad impressions to unique visitors, verifying positioning and quality of ad impressions, tracking referrals and conversion to the extent necessary to account for an agreed bounty program, and auditing compliance with this and other standards.

Security

When DNT:1 is received, a party MAY collect, retain, and use tracking data to the extent reasonably necessary to detect security incidents, protect the service against malicious, deceptive, fraudulent, or illegal activity, and prosecute those responsible for such activity.

When feasible, a graduated response to a detected security incident is preferred over widespread data collection. A graduated response is a methodology where the action taken is proportional to the size of the problem or risk that is trying to be mitigated. In the context of this document, the term is used to describe an increase in the collection of data about a user or interaction in response to a specific problem that a party has become aware of, such as an increase in fraudulent activity originating from a particular network or IP address range resulting in increased logging of data relating to interactions from that specific range of IP addresses, as opposed to increased logging for all users in general.

Debugging

When DNT:1 is received, a party MAY collect, retain, and use tracking data for debugging purposes to identify and repair errors that impair existing intended functionality.

Audience Measurement

An open question for the group is whether or how audience measurement would be addressed.

Sending Qualifiers to Indicate Permitted Uses

A party MAY send the qualifiers property in a tracking status representation [[TRACKING-DNT]] to communicate what permitted uses of tracking might be in use for the designated resource. Multiple qualifier characters indicate that each of those permitted uses might be used.

While sending qualifiers is OPTIONAL, a party that does send qualifiers MUST send exactly those characters corresponding to the applicable permitted uses for that designated resource, as defined by the following table.

qualifier	permitted use
1	first party
c	frequency capping
f	financial logging
s	security
d	debugging
m	audience measurement

The qualifiers in this table correspond directly to the permitted uses described in sections above. This list, the characters, and the names may change depending on the resolution of open issues regarding the permitted uses.

Unknowing Collection

If a party learns that it possesses data in violation of this recommendation, it MUST, where reasonably feasible, delete or permanently de-identify that data at the earliest practical opportunity, even if it was previously unaware of such information practices despite reasonable efforts to understand its information practices.

Legal Compliance

Notwithstanding anything in this recommendation, a party MAY collect, use, and share data required to comply with applicable laws, regulations, and judicial processes.