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 to specific permitted uses and retention policies when DNT:1 is received.
This temporary editor's draft is provided as a proposal to address ISSUE-203. It does not constitute consensus and will change frequently, with the goal of eventually replacing or merging with TCS.
Reviewers are advised to consult the list of issues tracked in the Compliance Current product and the wiki list of change proposals developed by participants in the Working Group. The Working Group has published a Last Call Working Draft of the companion Tracking Preference Expression document.
This specification defines a set of compliance requirements and best practices for tracking protection. It applies to any tracking data that has been collected via a resource for which the origin server provided a corresponding tracking status representation, as defined in [[!TRACKING-DNT]], with a compliance property that contained at least one reference to this specification (see ).
In other words, this specification applies whenever a party that controls a given resource claims to be adhering to this specification. Such a claim implies that the origin server, resource owner, and all recipients of the data collected as a result of accessing that resource (during the period in which the tracking status representation is fresh) intend to conform to this specification with regard to that data for as long as that data has not been de-identified.
The remainder of this specification assumes that the origin server has indicated compliance on behalf of the party (or joint parties) that control any data collected via the designated resource. Requirements that are placed on either a party or an origin server are meant to constrain both the behavior of the origin server software and the behavior of any party that receives data collected via the designated resource.
Data collection, retention, use, or sharing that does not amount to tracking is outside the scope of this specification. For example, collecting data about a particular user's activity within a single context is not considered tracking, but retaining, using, or sharing data derived from that activity (such as a user profile) outside the context in which that activity occurred is considered tracking. Likewise, data that has been de-identified is outside the scope of this specification.
Short-term, transient collection and use of data is also outside the scope of this specification so long as the data is not used to build a profile about the user. For example, customization of ads based only on the current context in which the ad is placed, such as the content of the surrounding page or nature of the site being visited, is not restricted by a tracking preference.
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, collects, uses, and shares.
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:
Data is de-identified when a party:
OPEN This definition is being actively discussed and may soon be replaced by a term with less baggage.
Note that geolocation data (of a certain precision or over a period of time) may itself identify otherwise de-identified data.
To indicate compliance with this specification for a given designated resource, an origin server MUST do all of the following:
!
(under construction) or
D
(disregarding) for a
tracking status value (TSV)
applicable to that designated resource; andcompliance
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.
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.
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
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
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.
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 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]].
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.
When DNT:1
is received, a 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 party MUST NOT retain such data any longer than is proportionate
to, and reasonably necessary for, those permitted uses.
A party MUST provide public transparency of the time periods for which tracking data collected for permitted uses are retained. A party MAY enumerate different retention periods for different permitted uses. A 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 party MUST delete or de-identify that data.
When DNT:1
is received, a 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 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 party SHOULD implement best practices and technical controls that ensure access limitations and information security. A party SHOULD ensure that access and use of data retained under one or more permitted uses is auditable.
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.
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.
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.
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.
An open question for the group is whether or how audience measurement would be addressed.
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 |
---|---|
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.
If a party learns that it possesses data in violation of this recommendation, it MUST, where reasonably feasible, delete or 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.
Notwithstanding anything in this recommendation, a party MAY collect, use, and share data required to comply with applicable laws, regulations, and judicial processes.
This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written contributions from Haakon Flage Bratsberg (Opera Software), Amy Colando (Microsoft Corporation), Nick Doty (W3C), Roy T. Fielding (Adobe), Yianni Lagos (Future of Privacy Forum), Tom Lowenthal (Mozilla), Ted Leung (The Walt Disney Company), Jonathan Mayer (Stanford University), Ninja Marnau (Invited Expert), Thomas Roessler (W3C), Matthias Schunter (IBM), Wendy Seltzer (W3C), John M. Simpson (Invited Expert), Kevin G. Smith (Adobe), Peter Swire (Invited Expert), Rob van Eijk (Invited Expert), David Wainberg (Network Advertising Initiative), Rigo Wenning (W3C), and Shane Wiley (Yahoo!).
The DNT header field is based on the original Do Not Track submission by Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js.