This specification defines the DNT request header field as an HTTP mechanism for expressing the user's preference regarding tracking, an HTML DOM property to make that expression readable by scripts, and APIs that allow scripts to register site-specific exceptions granted by the user. It also defines mechanisms for sites to communicate whether and how they honor a received preference through use of the Tk response header field and well-known resources that provide a machine-readable tracking status.

Readers may review changes from the previous Working Draft; in particular, recent changes have updated definitions, requirements on determining a user preference and introduced a media type. An issue tracking system is available for recording issues regarding this document and their resolutions.

This document is published as a Last Call Working Draft, which invites broad community review of technical requirements and dependencies. The Tracking Protection Working Group encourages people to comment on the extent to which technical requirements of the group's charterhave been met and how significant dependencies with groups inside and outside W3C have been satisfied. The Working Group will evaluate all comments received and determine whether or how the specification needs to be modified in light of the comments. Comments will be evaluated on whether they identify technical problems with the TPE, whether the TPE fulfills its requirements, and whether the TPE creates or does not otherwise resolve dependencies with other technical standards, practices or processes. The Chairs of the Working Group will issue written responses to all comments received.

Of note, this document does not define site behavior for complying with a user's expressed tracking preference, but does provide sites with a mechanism for indicating compliance. The Tracking Compliance and Scope [[TCS]] specification which standardizes how sites should respond to Do Not Track requests, including what information may be collected for limited permitted uses despite a Do Not Track signal, is under discussion. The Tracking Protection Working Group expects that specification to proceed to Last Call in the summer of 2014. Both specifications are currently scheduled to go to Candidate Recommendation in December 2014.

Introduction

The World Wide Web consists of billions of resources interconnected through the use of hypertext. Hypertext provides a simple, page-oriented view of the information provided by those resources, which can be traversed by selecting links, manipulating controls, and supplying data via forms and search dialogs.

A Web page is often composed of many information sources beyond the initial resource request, including embedded references to stylesheets, inline images, javascript, and other elements that might be automatically requested as part of the rendering or behavioral processing defined for that page. The user's experience is seamless, even if the page has been composed from the results of many network interactions with multiple servers. From the user's perspective, they are simply visiting and interacting with a single Web site: all of the technical details and protocol mechanisms used to compose a page to represent that site are hidden behind the scenes.

It has become common for Web site owners to collect data regarding the usage of their sites for a variety of purposes, including what led the user to visit their site (referrals), how effective the user experience is within the site (web analytics), and the nature of who is using their site (audience segmentation). In some cases, the data collected is used to dynamically adapt the content (personalization) or the advertising presented to the user (targeted advertising). Data collection often occurs through the insertion of embedded elements on each page, which connect the user's activity across multiple pages. A survey of these techniques and their privacy implications can be found in [[KnowPrivacy]].

Users need a mechanism to express their own preferences regarding tracking that is both simple to configure and efficient when implemented. However, merely expressing a preference does not imply that all recipients will be able to comply. In some cases, a server might be dependent on some forms of tracking and is unwilling or unable to turn that off. In other cases, a server might perform only limited forms of tracking that would be acceptable to most users. Servers need mechanisms for communicating their tracking behavior and for storing user-granted exceptions after the user has made an informed choice.

This specification defines Hypertext Transfer Protocol [[!HTTP]] elements for communicating the user's tracking preference (if any) and communicating the server's tracking behavior (if any). The DNT request header field is defined for communicating the user's tracking preference for the request target. A well-known URI for a tracking status resource and the Tk response header field are defined for communicating the server's tracking behavior. In addition, JavaScript APIs are defined for enabling scripts to determine DNT status and register a user-granted exception.

This specification does not define requirements on what a recipient needs to do to comply with a user's expressed tracking preference, except for the means by which such compliance is communicated. Instead, the tracking status provides the ability to identify a set of compliance regimes to which the server claims to comply, with the assumption being that each regime defines its own requirements on compliant behavior. For example, [[TCS]] is a work-in-progress that intends to define such a compliance regime.

Terminology

Tracking is the collection of data regarding a particular user's activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. A context is a set of resources that are controlled by the same party or jointly controlled by a set of parties.

A user is a natural person who is making, or has made, use of the Web.

A user agent is any of the various client programs capable of initiating HTTP requests [[!HTTP]], including (but not limited to) browsers, spiders (web-based robots), command-line tools, custom applications, and mobile apps.

A network interaction is a single HTTP request and its corresponding response(s): zero or more interim (1xx) responses and a single final (2xx-5xx) response.

A user action is a deliberate action by the user, via configuration, invocation, or selection, to initiate a network interaction. Selection of a link, submission of a form, and reloading a page are examples of user actions. User activity is any set of such user actions.

A party is a natural person, a legal entity, or a set of legal entities that share common owner(s), common controller(s), and a group identity that is easily discoverable by a user. Common branding or providing a list of affiliates that is available via a link from a resource where a party describes DNT practices are examples of ways to provide this discoverability.

With respect to a given user action, a first party is a party with which the user intends to interact, via one or more network interactions, as a result of making that action. Merely hovering over, muting, pausing, or closing a given piece of content does not constitute a user's intent to interact with another party.

In some cases, a resource on the Web will be jointly controlled by two or more distinct parties. Each of those parties is considered a first party if a user would reasonably expect to communicate with all of them when accessing that resource. For example, prominent co-branding on the resource might lead a user to expect that multiple parties are responsible for the content or functionality.

For any data collected as a result of one or more network interactions resulting from a user's action, a third party is any party other than that user, a first party for that user action, or a service provider acting on behalf of either that user or that first party.

A party collects data received in a network interaction if that data remains within the party’s control after the network interaction is complete.

A party uses data if the party processes the data for any purpose other than storage or merely forwarding it to another party.

A party shares data if it transfers or provides a copy of that data to any other party.

A user-granted exception is a specific tracking preference, overriding a user's general tracking preference, that has been obtained and recorded using the mechanisms defined in .

Notational Conventions

Requirements

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [[!RFC2119]].

Formal Syntax

This specification uses Augmented Backus-Naur Form [[!ABNF]] to define network protocol syntax and WebIDL [[!WEBIDL]] for defining scripting APIs.

Determining User Preference

The goal of this protocol is to allow a user to express their personal preference regarding tracking to each server and web application that they communicate with via HTTP, thereby allowing recipients of that preference to adjust tracking behavior accordingly or to reach a separate agreement with the user that satisfies all parties.

Key to that notion of expression is that the signal sent MUST reflect the user's preference, not the choice of some vendor, institution, site, or network-imposed mechanism outside the user's control; this applies equally to both the general preference and exceptions. The basic principle is that a tracking preference expression is only transmitted when it reflects a deliberate choice by the user. In the absence of user choice, there is no tracking preference expressed.

A user agent MUST offer users a minimum of two alternative choices for a Do Not Track preference: unset or DNT:1. A user agent MAY offer a third alternative choice: DNT:0.

If the user's choice is DNT:1 or DNT:0, the tracking preference is enabled; otherwise, the tracking preference is not enabled.

A user agent MUST have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the user's decision to use that agent. For example, use of a general-purpose browser would not imply a tracking preference when invoked normally as SuperFred, but might imply a preference if invoked as SuperDoNotTrack or UltraPrivacyFred.

Implementations of HTTP that are not under control of the user MUST NOT add, delete, or modify a tracking preference. Some controlled network environments, such as public access terminals or managed corporate intranets, might impose restrictions on the use or configuration of installed user agents, such that a user might only have access to user agents with a predetermined preference enabled. However, if a user brings their own Web-enabled device to a library or cafe with wireless Internet access, the expectation will be that their chosen user agent and personal preferences regarding Web site behavior will not be altered by the network environment (aside from blanket limitations on what resources can or cannot be accessed through that network).

An HTTP intermediary MUST NOT add, delete, or modify a tracking preference expression in a request forwarded through that intermediary unless the intermediary has been specifically installed or configured to do so by the user making the request. For example, an Internet Service Provider MUST NOT inject DNT:1 on behalf of all users who have not expressed a preference.

User agents often include user-installable extensions, also known as add-ons or plug-ins, that are capable of modifying configurations and making network requests. From the user's perspective, these extensions are considered part of the user agent and ought to respect the user's configuration of a tracking preference. The user agent as a whole is responsible for ensuring conformance with this protocol, to the extent possible, which means the user agent core and each extension are jointly responsible for conformance. However, there is no single standard for extension interfaces. A user agent that permits such extensions SHOULD provide an appropriate mechanism for extensions to determine the user's tracking preference.

A user agent extension MUST NOT alter the tracking preference expression or its associated configuration unless the act of installing and enabling that extension is an explicit choice by the user for that tracking preference, or the extension itself complies with all of the requirements this protocol places on a user agent.

Likewise, software outside of the user agent might filter network traffic or cause a user agent's configuration to be changed. Software that alters a user agent configuration MUST adhere to the above requirements on a user agent extension. Software that filters network traffic MUST adhere to the above requirements on an HTTP intermediary.

Aside from the above requirements, we do not specify how the tracking preference choices are offered to the user or how the preference is enabled: each implementation is responsible for determining the user experience by which a tracking preference is enabled.

For example, a user might select a check-box in their user agent's configuration, install an extension that is specifically designed to add a tracking preference expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., Privacy settings: high). A user agent might ask the user for their preference during startup, perhaps on first use or after an update adds the tracking protection feature. Likewise, a user might install or configure a proxy to add the expression to their own outgoing requests.

Expressing a Tracking Preference

Expression Format

When a user has enabled a tracking preference, that preference needs to be expressed to all mechanisms that might perform or initiate tracking.

When enabled, a tracking preference is expressed as either:

DNT meaning
1 This user prefers not to be tracked on the target site.
0 This user prefers to allow tracking on the target site.

A user agent MUST NOT send a tracking preference expression if a tracking preference is not enabled. This means that no expression is sent for each of the following cases:

In the absence of regulatory, legal, or other requirements, servers 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, servers might make use of other preference information outside the scope of this protocol, such as site-specific user preferences or third-party registration services, to inform or adjust their behavior when no explicit preference is expressed via this protocol.

DNT Header Field for HTTP Requests

The DNT header field is a mechanism for expressing the user's tracking preference in an HTTP request [[!HTTP]].

DNT-field-name  = "DNT"
DNT-field-value = ( "0" / "1" ) *DNT-extension
        

A user agent MUST NOT generate a DNT header field if the user's tracking preference is not enabled.

A user agent MUST generate a DNT header field with a field-value that begins with the numeric character "1" (%x31) if the user's tracking preference is enabled, their preference is for DNT:1, and no exception has been granted for the request target (see ).

A user agent MUST generate a DNT header field with a field-value that begins with the numeric character "0" (%x30) if the user's tracking preference is enabled and their preference is for DNT:0, or if an exception has been granted for the request target.

A proxy MUST NOT generate a DNT header field unless it has been specifically installed or configured to do so by the user making the request and adheres to the above requirements as if it were a user agent.

GET /something/here HTTP/1.1
Host: example.com
DNT: 1

        

The remainder of the field-value, after the initial character, is reserved for future extensions. DNT extensions can only be transmitted when a tracking preference is enabled.

DNT-extension   = %x21 / %x23-2B / %x2D-5B / %x5D-7E
                ; excludes CTL, SP, DQUOTE, comma, backslash
        

For example, additional characters might indicate modifiers to the main preference expressed by the first digit, such that the main preference will be understood if the recipient does not understand the extension. Hence, a field-value of "1xyz" can be thought of as do not track, but if you understand the refinements defined by x, y, or z, then adjust my preferences according to those refinements.

User agents that do not implement DNT extensions MUST NOT send DNT-extension characters in the DNT field-value. Servers that do not implement DNT extensions SHOULD ignore anything beyond the first character.

The extension syntax is restricted to visible ASCII characters that can be parsed as a single word in HTTP and safely embedded in a JSON string without further encoding (). At most one DNT header field can be present in a valid request [[!HTTP]].

JavaScript Property to Detect Preference

The doNotTrack property enables a client-side script with read access to the Window object to determine what DNT header field value would be sent in requests to the document-origin, taking into account the user's general preference (if any) and any user-granted exceptions applicable to that origin server.

readonly attribute DOMString doNotTrack
Returns the same string value that would be sent in a DNT-field-value () to a target that is the document-origin of the window, in the browser context of the current top-level origin. The value is null if no DNT header field would be sent (e.g., because a tracking preference is not enabled).

Tracking Preference Expressed in Other Protocols

A user's tracking preference is intended to apply in general, regardless of the protocols being used for Internet communication. However, it is beyond the scope of this specification to define how a user's tracking preference might be communicated via protocols other than HTTP.

Communicating a Tracking Status

Overview

In addition to expressing the user's preference regarding tracking, this protocol enables servers to communicate machine-readable claims regarding their own tracking behavior. Since a personalized tracking status on every response would disable caching, a combination of response mechanisms are defined to allow the tracking status to be communicated prior to making a trackable request and without making every response dynamic.

Tracking Status Value

Definition

A tracking status value (TSV) is a single character response to the user's tracking preference with regard to data collected via the designated resource. For a site-wide tracking status resource, the designated resource is any resource on the same origin server. For a Tk response header field, the target resource of the corresponding request is the designated resource, and remains so for any subsequent request-specific tracking status resource referred to by the Tk field value.

The tracking status value is case sensitive, as defined formally by the following ABNF.

TSV    = %x21   ; "!" - under construction
       / %x3F   ; "?" - dynamic
       / %x4E   ; "N" — not tracking
       / %x54   ; "T" — tracking
       / %x43   ; "C" - tracking with consent
       / %x50   ; "P" - tracking only if consented
       / %x44   ; "D" - disregarding DNT
       / %x55   ; "U" - updated
          

Under Construction (!)

A tracking status value of ! means that the origin server is currently testing its communication of tracking status. The ! value has been provided to ease testing and deployment on production systems during the initial periods of testing compliance and during adjustment periods due to future protocol changes or shifting regulatory constraints. Note that this value does not indicate that the user's preference will be ignored, nor that tracking will occur as a result of accessing the designated resource.

Dynamic (?)

A tracking status value of ? means the origin server needs more information to determine tracking status, usually because the designated resource dynamically adjusts behavior based on information in a request.

If ? is present in the site-wide tracking status, the origin server MUST send a Tk header field in all responses to requests on the designated resource. If ? is present in the Tk header field, more information will be provided in a request-specific tracking status resource referred to by the status-id. An origin server MUST NOT send ? as the tracking status value in the representation of a request-specific tracking status resource.

Not Tracking (N)

A tracking status value of N means the origin server claims that data collected via the designated resource is not used for tracking and will not be combined with other data in a form that would enable tracking.

Tracking (T)

A tracking status value of T means the origin server might perform or enable tracking using data collected via the designated resource. Information provided in the tracking status representation might indicate whether such tracking is limited to a set of commonly accepted uses or adheres to one or more compliance regimes.

Consent (C)

A tracking status value of C means that the origin server believes it has received prior consent for tracking this user, user agent, or device, perhaps via some mechanism not defined by this specification, and that prior consent overrides the tracking preference expressed by this protocol. An origin server that sends the C tracking status value for a designated resource MUST provide a reference for controlling consent within the config property of its corresponding tracking status representation ().

Potential Consent (P)

A tracking status value of P means that the origin server does not know, in real-time, whether it has received prior consent for tracking this user, user agent, or device, but promises not to use or share any DNT:1 data until such consent has been determined, and further promises to delete or de-identify within forty-eight hours any DNT:1 data received for which such consent has not been received.

Since this status value does not itself indicate whether a specific request is tracked, an origin server that sends a P tracking status value MUST provide a config property in the corresponding tracking status representation that links to a resource for obtaining consent status.

The P tracking status value is specifically meant to address audience survey systems for which determining consent at the time of a request is either impractical, due to legacy systems not being able to keep up with Web traffic, or potentially "gamed" by first party sites if they can determine which of their users have consented. The data cannot be used for the sake of personalization. If consent can be determined at the time of a request, the C tracking status is preferred.

Disregarding (D)

A tracking status value of D means that the origin server is unable or unwilling to respect a tracking preference received from the requesting user agent. An origin server that sends the D tracking status value MUST detail within the server's corresponding privacy policy the conditions under which a tracking preference might be disregarded.

For example, an origin server might disregard the DNT field received from specific user agents (or via specific network intermediaries) that are deemed to be non-conforming, might be collecting additional data from specific source network locations due to prior security incidents, or might be compelled to disregard certain DNT requests to comply with a local law, regulation, or order.

This specification is written with an assumption that the D tracking status value would only be used in situations that can be adequately described to users as an exception to normal behavior. If this turns out not to be the case, either the server's decision to send the D signal needs re-examination, or this specification, or both.

Updated (U)

A tracking status value of U means that the request resulted in a potential change to the tracking status applicable to this user, user agent, or device. A user agent that relies on a cached tracking status SHOULD update the cache entry with the current status by making a new request on the applicable tracking status resource.

An origin server MUST NOT send U as a tracking status value anywhere other than a Tk header field that is in response to a state-changing request.

Tk Header Field for HTTP Responses

Definition

The Tk response header field is hereby defined as an OPTIONAL means for indicating the tracking status that applied to the corresponding request and as a REQUIRED means for indicating that a state-changing request has resulted in an interactive change to the tracking status.

Tk-field-name   =  "Tk"
Tk-field-value  =  TSV [ ";" status-id ]
          

The Tk field-value begins with a tracking status value (), optionally followed by a semicolon and a status-id that refers to a request-specific tracking status resource ().

For example, a Tk header field for a resource that claims not to be tracking would look like:

Tk: N

Referring to a Request-specific Tracking Status Resource

If an origin server has multiple, request-specific tracking policies, such that the tracking status might differ depending on some aspect of the request (e.g., method, target URI, header fields, data, etc.), the origin server MAY provide an additional subtree of well-known resources corresponding to each of those distinct tracking statuses. The OPTIONAL status-id portion of the Tk field-value indicates which specific tracking status resource applies to the current request.

status-id       =  1*id-char
id-char         =  ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"
          

For example, a response containing

Tk: T;fRx42

indicates that data collected via the target resource might be used for tracking and that an applicable tracking status representation can be obtained by performing a retrieval request on

/.well-known/dnt/fRx42

If a Tk field-value has a tracking status value of ? (dynamic), then the origin server MUST also send a status-id in the field-value. The status-id is case-sensitive.

Indicating an Interactive Status Change

Interactive mechanisms might be used, beyond the scope of this specification, that have the effect of asking for and obtaining prior consent for tracking, or for modifying prior indications of consent. For example, the tracking status resource's status-object defines a config property that can refer to such a mechanism. Although such out-of-band mechanisms are not defined by this specification, their presence might influence the tracking status object's response value.

When an origin server provides a mechanism via HTTP for establishing or modifying out-of-band tracking preferences, the origin server MUST indicate within the mechanism's response when a state-changing request has resulted in a change to the tracking status for that server. This indication of an interactive status change is accomplished by sending a Tk header field in the response with a tracking status value of U (updated).

Tk: U

Tracking Status Resource

Site-wide Tracking Status

A site-wide tracking status resource provides information about the potential tracking behavior of resources located at that origin server. A site-wide tracking status resource has the well-known identifier

/.well-known/dnt/

relative to the origin server's URI [[RFC5785]].

An origin server that receives a valid GET request targeting its site-wide tracking status resource MUST send either a successful response containing a machine-readable representation of the site-wide tracking status, as defined below, or a sequence of redirects that leads to such a representation. Failure to provide access to such a representation implies that the target origin server does not implement this protocol. The representation can be cached, as described in .

See for examples of how tracking status resources can be used to discover support for this protocol.

Request-specific Tracking Status

If an origin server has multiple, request-specific tracking policies, such that the tracking status might differ depending on some aspect of the request (e.g., method, target URI, header fields, data, etc.), the origin server MAY provide an additional subtree of well-known resources corresponding to each of those distinct tracking statuses. The Tk response header field () can include a status-id to indicate which specific tracking status resource applies to the current request.

A tracking status resource space is defined by the following URI Template [[URI-TEMPLATE]]:

/.well-known/dnt/{+status-id}

where the value of status-id is a string of URI-safe characters provided by a Tk field-value in response to a prior request. For example, a prior response containing

Tk: ?;ahoy

refers to the specific tracking status resource

/.well-known/dnt/ahoy

Resources within the request-specific tracking status resource space are represented using the same format as a site-wide tracking status resource.

Status Checks are Not Tracked

When sending a request for the tracking status, a user agent SHOULD include any cookie data [[COOKIES]] (set prior to the request) that would be sent in a normal request to that origin server, since that data might be needed by the server to determine the current tracking status. For example, the cookie data might indicate a prior out-of-band decision by the user to opt-out or consent to tracking by that origin server.

An origin server MUST NOT retain tracking data regarding requests on the site-wide tracking status resource or within the tracking status resource space, regardless of the presence, absence, or value of a DNT header field, cookies, or any other information in the request. In addition, an origin server MUST NOT send Set-Cookie or Set-Cookie2 header fields in responses to those requests, including the responses to redirected tracking status requests, and MUST NOT send a response having content that initiates tracking beyond what was already present in the request. A user agent SHOULD ignore, or treat as an error, any Set-Cookie or Set-Cookie2 header field received in such a response.

Caching

If the tracking status is applicable to all users, regardless of the received DNT-field-value or other data received via the request, then the origin server SHOULD mark the response as cacheable [[!HTTP-cache]] and assign a time-to-live (expiration or max-use) that is sufficient to enable shared caching but not greater than the earliest point at which the service's tracking behavior might increase.

For example, if the tracking status response is set to expire in seven days, then the earliest point in time that the service's tracking behavior can be increased is seven days after the tracking status representation has been updated to reflect the new behavior, since old copies might persist in caches until the expiration is triggered. A service's tracking behavior can be reduced at any time, with or without a corresponding change to the tracking status resource.

If the tracking status is only applicable to users that have the same DNT-field-value, the origin server MUST send a Vary header field that includes "DNT" in its field-value or a Cache-Control header field containing one of the following directives: "private", "no-cache", "no-store", or "max-age=0".

If the tracking status is only applicable to the specific user that requested it, then the origin server MUST send a Cache-Control header field containing one of the following directives: "private", "no-cache", or "no-store".

Regardless of the cache-control settings, it is expected that user agents will check the tracking status of a service only once per session (at most). A public Internet site that intends to change its tracking status to increase tracking behavior MUST update the tracking status resource in accordance with that planned behavior at least twenty-four hours prior to activating that new behavior on the service.

A user agent that adjusts behavior based on active verification of tracking status, relying on cached tracking status responses to do so, SHOULD check responses to its state-changing requests (e.g., POST, PUT, DELETE, etc.) for a Tk header field with the U tracking status value, as described in .

Tracking Status Representation

For each tracking status resource, an origin server MUST provide a valid representation using the application/tracking-status+json media type. This media type is defined as a JSON format [[!RFC7159]] that conforms to the ABNF for status-object (below) except that the properties within a property-list can be provided in any order. More information about the application/tracking-status+json media type can be found in .

Status Object

A tracking status representation consists of a single status-object containing properties that describe the tracking status applicable to the designated resource.

status-object = begin-object property-list end-object

property-list = tracking-p       ns tracking-v
                [ vs compliance  ns compliance-v ]
                [ vs qualifiers  ns qualifiers-v ]
                [ vs controller  ns controller-v ]
                [ vs same-party  ns same-party-v ]
                [ vs audit       ns audit-v      ]
                [ vs policy      ns policy-v     ]
                [ vs config      ns config-v     ]
                *( vs extension )
          

The following example tracking status representation illustrates a status object with all of the properties defined by this specification, most of which are optional.

{
  "tracking": "T",
  "compliance": ["https://acme.example.org/tracking101"],
  "qualifiers": "afc",
  "controller": ["https://www.example.com/privacy"],
  "same-party": [
    "example.com",
    "example_vids.net",
    "example_stats.com"
  ],
  "audit": [
    "http://auditor.example.org/727073"
  ],
  "policy": "/privacy.html#tracking",
  "config": "http://example.com/your/data"
}

Tracking Property

A status-object always has a property named tracking with a string value containing the tracking status value () applicable to the designated resource.

tracking-p    = %x22 "tracking" %x22
tracking-v    = %x22 TSV %x22
          

For example, the following demonstrates a minimal tracking status representation that is applicable to any resource that does not perform tracking.

{"tracking": "N"}

Compliance Property

An origin server MAY send a property named compliance with an array value containing a list of URI references that identify specific regimes to which the origin server claims to comply for the designated resource. Communicating such a claim of compliance is presumed to improve transparency, which might influence a user's decisions or configurations regarding allowed tracking, but does not have any direct impact on this protocol.

compliance    = %x22 "compliance" %x22
compliance-v  = array-of-refs
          

Qualifiers Property

An origin server MAY send a property named qualifiers with a string value containing a sequence of case sensitive characters corresponding to explanations or limitations on the extent of tracking. Multiple qualifiers indicate that multiple explanations or forms of tracking might apply for the designated resource. The meaning of each qualifier is presumed to be defined by one or more of the regimes listed in compliance.

qualifiers    = %x22 "qualifiers" %x22
qualifiers-v  = %x22 *qualifier %x22
qualifier     = id-char
          

Controller Property

An origin server MAY send a property named controller with an array value containing a list of URI references indirectly identifying the party or set of parties that claims to be the responsible data controller for personal data collected via the designated resource. An origin server MUST send a controller property if the responsible data controller does not own the designated resource's domain name.

An origin server that does not send controller is implying that its domain owner is the sole data controller; information about the data controller ought to be found on the designated resource's site root page, or by way of a clearly indicated link from that page (i.e., an absent controller property is equivalent to: "controller":["/"]).

If the designated resource has joint data controllers (i.e., multiple parties have independent control over the collected data), the origin server MUST send a controller property that contains a reference for each data controller.

Each URI reference provided in controller ought to refer to a resource that, if a retrieval action is performed on that URI, would provide the user with information regarding (at a minimum) the identity of the corresponding party and its data collection practices.

controller    = %x22 "controller" %x22
controller-v  = array-of-refs
          

Same-party Property

Since a user's experience on a given site might be composed of resources that are assembled from multiple domains, it might be useful for a site to distinguish those domains that are subject to their own control (i.e., share the same data controller as the referring site). An origin server MAY send a property named same-party with an array value containing a list of domain names that the origin server claims are the same party, to the extent they are referenced by the designated resource, if all data collected via those references share the same data controller as the designated resource.

A user agent might use the same-party array, when provided, to inform or enable different behavior for references that are claimed to be same-party versus those for which no claim is made. For example, a user agent might choose to exclude, or perform additional pre-flight verification of, requests to other domains that have not been claimed as same-party by the referring site.

same-party    = %x22 "same-party" %x22
same-party-v  = array-of-refs
          

Audit Property

An origin server MAY send a property named audit with an array value containing a list of URI references to external audits of the designated resource's privacy policy and tracking behavior. Preferably, the audit references are to resources that describe the auditor and the results of that audit; however, if such a resource is not available, a reference to the auditor is sufficient.

audit         = %x22 "audit" %x22
audit-v       = array-of-refs
          

Policy Property

An origin server MAY send a property named policy with a string value containing a URI reference to a human-readable document that describes the relevant privacy policy for the designated resource. The content of such a policy document is beyond the scope of this protocol and only supplemental to what is described in the machine-readable tracking status representation. If no policy property is provided, this information might be obtained via the links provided in controller.

policy        = %x22 "policy" %x22
policy-v      = string       ; URI-reference
          

Config Property

An origin server MAY send a property named config with a string value containing a URI reference to a resource for giving the user control over personal data collected via the designated resource (and possibly other resources). If the tracking status value indicates prior consent (C), the origin server MUST send a config property referencing a resource that describes how such consent is established and how to revoke that consent.

A config resource might include the ability to review past data collected, delete some or all of the data, provide additional data (if desired), or opt-in, opt-out, or otherwise modify an out-of-band consent status regarding data collection. The design of such a resource, the extent to which it can provide access to that data, and how one might implement an out-of-band consent mechanism are beyond the scope of this protocol.

If no config property is provided, this information might be obtained via the links provided in controller or policy.

config        = %x22 "config" %x22
config-v      = string       ; URI-reference
          

Extensions

An origin server MAY send additional extension properties in the status-object to support future enhancements to this protocol. A recipient MUST ignore extension properties that it does not recognize.

extension     = object

array-of-refs = begin-array [ string *( vs string ) ] end-array

ns            = <name-separator  (:), as defined in [RFC7159]>
vs            = <value-separator (,), as defined in [RFC7159]>

begin-array   = <begin-array     ([), as defined in [RFC7159]>
end-array     = <end-array       (]), as defined in [RFC7159]>
begin-object  = <begin-object    ({), as defined in [RFC7159]>
end-object    = <end-object      (}), as defined in [RFC7159]>

object        = <object, as defined in [RFC7159]>
string        = <string, as defined in [RFC7159]>
true          = <true,   as defined in [RFC7159]>
false         = <false,  as defined in [RFC7159]>
null          = <null,   as defined in [RFC7159]>
          

Status Code for Tracking Required

If an origin server receives a request with DNT:1, does not have out-of-band consent for tracking this user, and wishes to deny access to the requested resource until the user provides some form of user-granted exception or consent for tracking, then the origin server SHOULD send a 409 (Conflict) response with a message payload that describes why the request has been refused and how one might supply the required consent or exception to avoid this conflict [[!HTTP-semantics]].

The 409 response ought to include a user authentication mechanism in the header fields and/or message body if user login is one of the ways through which access is granted.

Using the Tracking Status

This section is for collecting use cases that describe questions a user agent might have about tracking status and how the protocol can be used to answer such questions. More cases are needed.

Discovering Deployment

Deployment of this protocol for a given service can be discovered by making a retrieval request on the site-wide tracking resource /.well-known/dnt/ relative to the service URI.

If the response is an error, then the service does not implement this standard. If the response is a redirect, then follow the redirect to obtain the tracking status (up to some reasonable maximum of redirects to avoid misconfigured infinite request loops). If the response is successful, obtain the tracking status representation from the message payload, if possible, or consider it an error.

Preflight Checks

A key advantage of providing the tracking status at a resource separate from the site's normal services is that the status can be accessed and reviewed prior to making use of those services.

A user agent MAY check the tracking status for a designated resource by first making a retrieval request for the site-wide tracking status representation, as described above, and then parsing the representation as JSON to extract the status-object. If the retrieval is unsuccessful or parsing results in a syntax error, the user agent ought to consider the site to be non-conformant with this protocol.

The status-object is supposed to have a property named tracking containing the tracking status value. The meaning of each tracking status value is defined in .

If the tracking status value is N, then the origin server claims that no tracking is performed for the designated resource for at least the next 24 hours or until the Cache-Control information indicates that this response expires.

If the tracking status value is not N, then the origin server claims that it might track the user agent for requests on the URI being checked for at least the next 24 hours or until the Cache-Control information indicates that this response expires.

User-Granted Exceptions

Overview

User-granted exceptions to Do Not Track, including site-specific exceptions, are agreed between the site and the user, and stored by the user agent. A resource ought to rely on the DNT header it receives to determine the user's preference for tracking with respect to that particular request. An API is provided so that sites may request and check the status of exceptions for tracking.

We envisage that the exceptions may also be usable as a consent mechanism.

Motivating Principles and Use Cases

The following principles guide the design of user-agent-managed exceptions.

When asking for a site-specific exception, the top-level origin making the request may be making some implicit or explicit claims as to the actions and behavior of its third parties; for this reason, it might want to establish exceptions for only those for which it is sure that those claims are true. (Consider a site that has some trusted advertisers and analytics providers, and some mashed-up content from less-trusted sites). For this reason, there is support both for explicitly named sites, as well as support for granting an exception to all third-parties on a given site (site-wide exception, using the conceptual wild-card "*").

There are some cases in which a user may desire a site to be allowed to track them on any top-level origin. An API is provided so that the site and the user may establish such a web-wide exception.

Exception model

User Interaction

The call to store an exception MUST reflect the user's intention to grant an exception, at the time of the call. This intention MUST be determined by the site prior to each call to store an exception, at the time of the call. (This allows the user to change their mind, and delete a stored exception, which might then trigger the site to explain, and ask for, the exception again). It is the responsibility solely of the site making the call to determine that a call to record an exception reflects the user's informed consent at the time of the call.

Sites MAY ask for an exception, and have it stored, even when the user's general preference is not enabled. (This permits recording a permission to allow tracking in jurisdictions where such permission cannot be assumed – see .)

The user agent MAY provide interfaces to the user:

  • To indicate that a call to store an exception has just been made;
  • To allow the user to confirm a user-granted exception prior to storage;
  • To indicate that one or more exceptions exist for the current top-level origin;
  • To indicate that one or more exceptions exist for sites incorporated into the current page;
  • To allow the user to see and possibly revoke stored exceptions;
  • Other aspects of the exception mechanism, as desired.
There is no required user interface for the user agent; user agents MAY choose to provide no user interface regarding user-granted exceptions.

If the user revokes the consent by deleting the exception, the site MUST respect that revocation (though it may ask again for the exception). The exception mechanism MUST NOT be used when the site will deem consent to exist even after the exception has been revoked.

Processing Model

This section describes the effect of the APIs in terms of a logical processing model; this model describes the behavior, but is not to be read as mandating any specific implementation.

This API considers exceptions which are double-keyed to two domains: the site, and the target. A user might — for instance — want AnalytiCo to be allowed to track them on Example News, but not on Example Medical. To simplify language used in this API specification, we define three terms:

  • top-level origin is the domain name of the top-level document origin of this DOM: essentially the fully qualified domain name in the address bar.
  • A target site is a domain name which is the target of an HTTP request, and which may be an origin for embedded resources on the indicated top-level origin.
  • The document origin of a script is the domain of origin of the document that caused that script to be loaded (not necessarily the same as the origin of the script itself).

For instance, if the document at http://web.exnews.com/news/story/2098373.html references the resources http://exnews.analytico.net/1x1.gif and http://widgets.exsocial.org/good-job-button.js, the top-level origin is web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both targets.

The domains that enter into the behavior of the APIs include:

  • As described above, the document origin active at the time of the call, and;
  • Domain names passed to the API.

Domains that enter into the decision over what DNT header to be sent in a given request include:

  • The top-level origin of the current browser context;
  • The target of the request.

Note that these strict, machine-discoverable, concepts may not match the definitions of first and third party; in particular, sites themselves need to determine (and signal) when they get 'promoted' to first party by virtue of user interaction; the UA will not change the DNT header it sends them.

The calls cause the following steps to occur (subject to user confirmation of the exception, if the user agent asks for it):

  • The UA adds to its local database one or more site-pair duplets [document-origin, target]; one or other of these may be a wild-card ("*");
  • While the user is browsing a given site (top-level origin), and a DNT header is to be sent to a target domain, if the duplet [top-level origin, target domain] matches any duplet in the database, then a DNT:0 header is sent, otherwise DNT:1 is sent.

A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y. A pair of values A and X match if and only if one of the following is true:

  • either A or X is "*";
  • A and X are the same string;
  • A has the form '*.domain' and X is 'domain' or is of the form 'string.domain', where 'string' is any sequence of characters.

In addition, responses to the JavaScript API indicated should be consistent with this user preference (see below).

User-agents MUST handle each API request as a 'unit', granting and maintaining it in its entirety, or not at all. That means that a user agent MUST NOT indicate to a site that a request for targets {a, b, c} exists in the database, and later remove only one or two of {a, b, c} from its logical database of remembered grants. This assures sites that the set of sites they need for operational integrity is treated as a unit. Each separate call to an API is a separate unit.

It is left up to individual user agent implementations how to determine and how and whether to store users' tracking preferences.

When an explicit list of domains is provided through the API, their names might mean little to the user. The user might, for example, be told that there is a stored exception for a specific set of sites on such-and-such top-level origin, rather than listing them by name; or the user agent may decide to store, and show to the user, a site-wide exception, effectively ignoring the list of domain names, if supplied.

Conversely, if a wild-card is used, the user may be told that there is a stored exception for all third-parties that are, or will be, embedded on the indicated the top-level origin.

JavaScript API for Site-specific Exceptions

API to Request a Site-specific Exception

void storeSiteSpecificTrackingException ( StoreSiteSpecificExceptionPropertyBag properties)
Called by a page to store a site-specific tracking exception.
DOMString? domain
Cookie-like domain string to which the exception applies.
DOMString? siteName
A user-readable string for the name of the top-level origin.
DOMString? explanationString
A short explanation of the request.
DOMString? detailURI
A location at which further information about this request can be found.
sequence<DOMString> arrayOfDomainStrings
A JavaScript array of strings.

The storeSiteSpecificTrackingException method takes a dictionary argument of type StoreSiteSpecificExceptionPropertyBag that allows optional information to be provided.

If the request does not include the arrayOfDomainStrings, then this request is for a site-wide exception. Otherwise each string in arrayOfDomainStrings specifies a target. When called, storeSiteSpecificTrackingException MUST return immediately.

If the list arrayOfDomainStrings is supplied, the user agent MAY choose to store a site-wide exception. If it does so it MUST indicate this in the return value.

If domain is not specified or is null or empty then the execution of this API and the use of the resulting permission (if granted) use the 'implicit' parameter, when the API is called, the document origin. This forms the first part of the duplet in the logical model, and hence in operation will be compared with the top-level origin.

If permission is stored for an explicit list, then the set of duplets (one per target):

[document-origin, target]

is added to the database of remembered grants.

If permission is stored for a site-wide exception, then the duplet:

[document-origin, * ]

is added to the database of remembered grants.

If domain is supplied and not empty then it is treated in the same way as the domain parameter to cookies and allows setting for subdomains. The domain argument can be set to fully-qualified right-hand segment of the document host name, up to one level below TLD.

For example, www.foo.bar.example.com may set the domain parameter as as "bar.example.com" or "example.com", but not to "something.else.example.com" or "com".

If the document-origin would not be able to set a cookie on the domain following the cookie domain rules [[!COOKIES]] (e.g. domain is not a right-hand match or is a TLD) then the duplet MUST NOT be entered into the database and a SYNTAX_ERR exception SHOULD be thrown.

If permission is stored for an explicit list, then the set of duplets (one per target):

[*.domain, target]

is added to the database of remembered grants.

If permission is stored for a site-wide exception, then the duplet:

[*.domain, * ]

is added to the database of remembered grants.

A particular response to the API — like a DNT response header — is only valid immediately, and users may choose to edit the list of stored exceptions and revoke some or all of them.

API to Cancel a Site-specific Exception

void removeSiteSpecificTrackingException( RemoveExceptionPropertyBag properties )

If domain is not supplied or is null or empty then this ensures that the database of remembered grants no longer contains any duplets for which the first part is the current document origin; i.e., no duplets [document-origin, target] for any target.

If domain is supplied and is not empty then this ensures that the database of remembered grants no longer contains any duplets for which the first part is the domain wildcard; i.e., no duplets [*.domain, target] for any target.

There is no callback. After the call has been made, it is assured that there are no site-specific or site-wide exceptions for the given top-level origin.

DOMString? domain
Cookie-like domain string to which the exception applies.

When this method returns the database of grants no longer contains the indicated grant(s); if some kind of processing error occurred then an appropriate exception will be thrown.

If there are no matching duplets in the database of remembered grants when the method is called then this operation does nothing (and does not throw an exception).

API to Confirm a Site-specific Exception

boolean confirmSiteSpecificTrackingException ( ConfirmSiteSpecificExceptionPropertyBag properties)
Called by a page to confirm a site-specific tracking exception.
DOMString? domain
Cookie-like domain string to which the exception applies.
sequence<DOMString> arrayOfDomainStrings
A JavaScript array of strings.

If the call does not include the arrayOfDomainStrings, then this call is to confirm a site-wide exception. Otherwise each string in arrayOfDomainStrings specifies a target.

If the list arrayOfDomainStrings is supplied, and the user agent stores only site-wide exceptions, then the user agent MUST match by confirming a site-wide exception.

If the domain argument is not supplied or is null or empty then the execution of this API uses the 'implicit' parameter, when the API is called, the document origin. This forms the first part of the duplet in the logical model.

If the user agent stores explicit lists, and the call includes one, the database is checked for the existence of all the duplets (one per target):

[document-origin, target]

If the user agent stores only site-wide exceptions or the call did not include an explicit list, the database is checked for the single duplet:

[document-origin, * ]

If the user agent stores explicit lists, and the call includes one, and the domain argument is provided and is not empty then the database is checked for the existence of all the duplets (one per target):

[*.domain, target]

If the user agent stores only site-wide exceptions or the call did not include an explicit list, and the domain argument is provided and is not empty then the database is checked for the single duplet:

[*.domain, * ]

The returned boolean has the following possible values:

  • true all the duplets exist in the database;
  • false one or more of the duplets does not exist in the database.

JavaScript API for Web-wide Exceptions

API to Request a Web-wide Exception

void storeWebWideTrackingException ( StoreExceptionPropertyBag properties)
The single duplet [ * , document-origin] or [ * , *.domain] (based on if domain is provided and is not null and not empty) is added to the database of remembered grants. The properties of the StoreExceptionPropertyBag dictionary are as described above in the request for site-specific exceptions.

This API requests the addition of a web-wide grant for a specific site, to the database.

API to Cancel a Web-wide Exception

void removeWebWideTrackingException( RemoveExceptionPropertyBag properties )
Ensures that the database of remembered grants no longer contains the duplet [ * , document-origin] or [ * , *.domain] (based on if domain is provided and is not null and not empty). There is no callback. After the call has been made, the indicated pair is assured not to be in the database. The same matching as is used for determining which header to send is used to detect which entry (if any) to remove from the database.

API to Confirm a Web-wide Exception

boolean confirmWebWideTrackingException (ConfirmExceptionPropertyBag properties)

This API confirms the existence of a web-wide grant for a specific site, in the database.

The returned boolean indicates whether the duplet [ * , document-origin] or [ * , *.domain] (based on if domain is provided and is not null and not empty) exists in the database.

  • true indicates that the web-wide exception exists;
  • false indicates that the web-wide exception does not exist.

Transfer of an exception to another third party

A site may request an exception for one or more third party services used in conjunction with its own offer. Those third party services may wish to use other third parties to complete the request in a chain of interactions. The first party will not necessarily know in advance whether a known third party will use some other third parties.

If a user agent sends a tracking exception to a given combination of origin server and a named third party, the user agent will send DNT:0 to that named third party. By receiving the DNT:0 header, the named third party acquires the permission to track the user agent and collect the data and process it in any way allowed by the legal system it is operating in.

Furthermore, the named third party receiving the DNT:0 header acquires at least the right to collect data and process it for the given interaction and any other use unless it receives a DNT:1 header from that particular identified user agent.

The named third party is also allowed to transmit the collected data for uses related to this interaction to its own sub-services and sub-sub-services (transitive permission). The tracking permission request triggered by the origin server is thus granted to the named third party and its sub-services. This is even true for sub-services that would normally receive a DNT:1 web-wide preference from the user agent if the user agent interacted with this service directly.

For advertisement networks this typically would mean that the collection and auction system chain can use the data for that interaction and combine it with existing profiles and data. The sub-services to the named third party do not acquire an independent right to process the data for independent secondary uses unless they, themselves, receive a DNT:0 header from the user agent (as a result of their own request or the request of a first-party). In our example of advertisement networks that means the sub-services can use existing profiles in combination with the data received, but they can not store the received information into a profile until they have received a DNT:0 of their own.

A named third party acquiring an exception with this mechanism MUST make sure that sub-services it uses acknowledge this constraint by requiring the use of the appropriate tracking status value of 'C' (consent), and the qualifier "t", from its sub-sub-services.

The permission acquired by the DNT mechanism does not override retention limitations found in the legal system the content provider or the named third party are operating in.

User interface guidelines

As described above, it is the responsibility solely of the site making the call to determine that an exception grant reflects the user's informed consent at the time of the call.

It is expected that the site will explain, in its online content, the need for an exception, and the consequences of granting or denying an exception, to the user.

User agents are free to implement exception management user interfaces as they see fit. Some agents might provide a notification to the user at the time of the request, or even not complete the storing of the exception until the user approves. Some agents might provide a user-interface to see and edit the database of recorded exception grants. The API parameters siteName, explanationString, and detailURI are provided so that the user agent may use them in their user interface.

A user agent that chooses to highlight when tracking exceptions have been stored might provide an interface like the following.

In some user agent implementations, decisions to grant exceptions may have been made in the past (and since forgotten) or may have been made by other users of the device. Thus, exceptions may not always represent the current preferences of the user. Some user agents might choose to provide ambient notice that user-opted tracking is ongoing, or easy access to view and control these preferences. Users may desire options to edit exceptions either at the time of tracking or in a separate user interface. This might allow the user to edit their preferences for a site they do not trust without visiting that site.

Exceptions without interactive JavaScript

Some third party servers may wish to receive user-granted exceptions but when they are invoked as third parties (using, for example, images, or "tracking pixels") do not have an interactive JavaScript presence on the page. They cannot request an exception under these circumstances, both because a script is needed, and because they are required to explain to the user the need for and consequences of granting an exception, and get the user's consent. In general this process of informing, getting consent, and calling the API is not expected to be in the page where such trackers are invoked.

To obtain an exception, a document (page, frame, etc.) that loads the Javascript is needed. The user may visit the site that desires an exception directly, the first party site could load a frame of the site desiring the exception, or that frame might be part of some other page containing a number of frames, which allows aggregation of requests for exceptions.

In all these ways, the site is contributing to informing the user and getting their consent, and is also able to call the Javascript API when it is granted.

Exceptions without a DNT header

Sites might wish to request exceptions even when a user arrives without a DNT header. Users might wish to grant affirmative permission to tracking on or by certain sites even without expressing general tracking preferences.

User agents MAY instantiate navigator.storeSiteSpecificTrackingException even when window.doNotTrack is null. Scripts SHOULD test for the existence of storeSiteSpecificTrackingException before calling the method. If an exception is granted and the user agent stores that preference, a user agent may send a DNT:0 header field even if a tracking preference isn't expressed for other requests. Persisted preferences MAY also affect which header is transmitted if a user later chooses to express a tracking preference.

Users might not configure their agents to have simple values for DNT, but use different browsing modes or other contextual information to decide on a DNT value. What algorithm a user agent employs to determine DNT values (or the lack thereof) is out of the scope of this specification.

Exception use by sites

This section is to inform the authors of sites on some considerations in using the exceptions APIs to best effect; sites of particular interest here are those that need an exception in order to allow the user to perform some operation or to have some access.

The 'Store' calls do not have a return value, and return immediately. If there is a problem with the calling parameters, then a Javascript exception will be raised. In addition, it may be that the user agent does not immediately store the exception, possibly because it is allowing the user to confirm. Even though the site has acquired the user's informed consent before calling the 'Store' API, it is possible that the user will change their mind, and allow the store to proceed but then later ask it be removed, or even by denying the storage in the first place.

Sites can call the 'Confirm' APIs to enquire whether a specific exception has been granted and stands in the user agent. This is the call to make to determine whether the exception exists, and hence to control access to the function or operation; if it fails (the exception has been deleted, or not yet granted), then the user is ideally again offered the information needed to give their informed consent, and again offered the opportunity to indicate that they grant it. As stated in the normative text, the site needs to explain and acquire consent immediately prior to calling the Store API, and not remember some past consent; this allows the user to change their mind.

If they do grant it (using some positive interaction such as a button), the site can return to checking the 'Confirm' API.

In this way the site:

Fingerprinting

By storing a client-side configurable state and providing functionality to learn about it later, this API might facilitate user fingerprinting and tracking. User agent developers ought to consider the possibility of fingerprinting during implementation and might consider rate-limiting requests or using other heuristics to mitigate fingerprinting risk.

Acknowledgements

This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written contributions from Adrian Bateman (Microsoft), Justin Brookman (CDT), Nick Doty (W3C/MIT), Marcos Caceres (Mozilla), Rob van Eijk (Invited Expert), Roy T. Fielding (Adobe), Vinay Goel (Adobe), Tom Lowenthal (Mozilla), Jonathan Mayer (Stanford), Aleecia M. McDonald (Stanford), Mike O'Neill (Baycloud Systems), Matthias Schunter (Intel), John Simpson (Consumer Watchdog), David Singer (Apple), Rigo Wenning (W3C/ERCIM), Shane Wiley (Yahoo!), and Andy Zeigler (Microsoft).

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 JavaScript DOM property for doNotTrack 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.

Registrations

The Internet media type application/tracking-status+json is used for tracking status representations ().

Type name:
application
Subtype name:
tracking-status+json
Required parameters:
N/A
Optional parameters:
N/A
Encoding considerations:
binary
Security considerations:
See JSON [RFC7159], Section 12.
Interoperability considerations:
N/A
Published specification:
Tracking Preference Expression (DNT), .
http://www.w3.org/TR/tracking-dnt/
Applications that use this media type:
N/A
Fragment identifier considerations:
N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information:
W3C Tracking Protection Working Group <public-tracking@w3.org>
Intended usage:
COMMON
Restrictions on usage:
N/A
Author(s):
Roy T. Fielding and David Singer
Change controller:
W3C