doNotTrack of type DOMString,

Returns the same string value that would be sent in a DNT-field-value (section 4.2 DNT Header Field for HTTP Requests) to a target that is the document-origin of the window, in the 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).

5.2.1 Definition

A tracking status value (TSV) is a short notation for communicating how a designated resource conforms to the tracking protection protocol, as defined by this document and [TRACKING-COMPLIANCE]. For a site-wide tracking status resource, the designated resource to which the tracking status applies is any resource on the same origin server. For a Tk response header field, the corresponding request target is the designated resource and remains so for any subsequent request-specific tracking status resource referred to by that field.

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

TSV    = "1"              ; "1" — first-party
       / "3"              ; "3" — third-party
       / %x43             ; "C" - consent
       / %x44             ; "D" - disregarding
       / %x4E             ; "N" - none
       / %x50             ; "P" - potential consent
       / %x55             ; "U" - updated
       / %x58             ; "X" - dynamic
       / ( "!" [testv] )  ; "!" - non-compliant

testv  = id-char
          

5.2.3 First Party (1)

A tracking status value of 1 means that the origin server claims that the designated resource is designed for use only within a first-party context and conforms to the requirements on a first party. If the designated resource is operated by an outsourced service provider, the service provider claims that it conforms to the requirements on a third party acting as a first party.

For the site-wide tracking status and Tk header field, the tracking status values 1 and 3 indicate how the designated resource is designed to conform, not the nature of the request. Hence, if a user agent is making a request in what appears to be a third-party context and the tracking status value indicates that the designated resource is designed only for first-party conformance, then either the context has been misunderstood (both are actually the same party) or the resource has been referenced incorrectly.

For the request-specific tracking status resource, an indication of first or third party as the status value describes how the resource conformed to that specific request, and thus indicates the applicable set of requirements to which the origin server claims to conform.

5.2.4 Third Party (3)

A tracking status value of 3 means that the origin server claims that the designated resource conforms to the requirements on a third party.

5.2.5 Dynamic (X)

A tracking status value of X means that the origin server claims that the designated resource is designed for use in both first and third-party contexts and dynamically adjusts tracking status accordingly.

If X is present in the site-wide tracking status, more information MUST be provided via the Tk response header field when accessing a designated resource. If X 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 X as the tracking status value in the representation of a request-specific tracking status resource.

5.2.6 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.

If the consent was signaled to the origin server 'out of band', that is, by some other mechanism than the receipt of a DNT:0 header, then the 'edit' member of the well-known-resource MUST provide both documentation of how the consent was established and documentation of the means, or the means, to revoke that consent.

5.2.9 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.

5.3.1 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 (section 5.2 Tracking Status Value), optionally followed by a semicolon and a status-id that refers to a request-specific tracking status resource (section 5.3.2 Referring 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

5.3.2 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: 1;fRx42

indicates that the target resource claims to conform to the first-party requirements of [TRACKING-COMPLIANCE] 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 X (dynamic), then a status-id MUST be included in the field-value. The status-id is case-sensitive.

5.3.3 Indicating an Interactive Status Change

We anticipate that 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 an edit member 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

5.4.1 Site-wide Tracking Status

An origin server MUST provide a site-wide tracking status resource at the well-known identifier [RFC5785]

/.well-known/dnt/

(relative to the URI of that origin server) for obtaining information about the potential tracking behavior of resources provided by that origin server. A tracking status resource can be used for verification of DNT support, as described in section 5.6 Using the Tracking Status.

A valid retrieval request (e.g., a GET in HTTP) on the well-known URI MUST result in 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. A user agent MAY consider failure to provide access to such a representation equivalent to the origin server not implementing this protocol. The representation can be cached, as described in section 5.4.5 Caching.

5.4.2 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 (section 5.3 Tk Header Field for HTTP Responses) can include a status-id to indicate which specific tracking status resource applies to the current request.

The 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: 1;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.

5.4.3 Representation

An origin server MUST provide a representation of each tracking status resource in the JSON format [RFC4627] that conforms to the ABNF for status-object (except that the members within each member-list MAY be provided in any order).

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

{
  "tracking": "1",
  "qualifiers": "afc",
  "controller": ["https://www.example.com/privacy"],
  "same-party": [
    "example.com",
    "example_vids.net",
    "example_stats.com"
  ],
  "third-party": [
    "api.example.net"
  ],
  "audit": [
    "http://auditor.example.org/727073"
  ],
  "policy": "/privacy.html#tracking",
  "edit": "http://example.com/your/data"
}

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

status-object = begin-object member-list end-object

member-list   = tracking         ns tracking-v
                [ vs qualifiers  ns qualifiers-v  ]
                [ vs controller  ns controller-v  ]
                [ vs same-party  ns same-party-v  ]
                [ vs third-party ns third-party-v ]
                [ vs audit       ns audit-v       ]
                [ vs policy      ns policy-v      ]
                [ vs edit        ns edit-v        ]
                *( vs extension )
          

A status-object always has a member named tracking with a string value that consists of the tracking status value applicable to the designated resource (section 5.2 Tracking Status Value).

tracking      = %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"}

An origin server MAY send a status-object member named qualifiers with a string value containing a sequence of case sensitive characters corresponding to each of the permitted uses (as defined in [TRACKING-COMPLIANCE]) that might be in use for the designated resource. The purpose of this field is to provide additional transparency where desired.

Multiple qualifiers mean that multiple permitted uses of tracking might be present and that each such use conforms to the associated requirements. All qualifiers imply some form of tracking might be used and thus MUST NOT be provided with a tracking status value of N (not tracking).

qualifiers    = %x22 "qualifiers" %x22
qualifiers-v  = %x22 0*5qualifier %x22
qualifier     = %x61  ; "a" - audit
              / %x63  ; "c" - capping
              / %x66  ; "f" - fraud
              / %x6C  ; "l" - local
              / %x72  ; "r" - referral
              / %x72  ; "t" - transferred consent
          

An origin server MAY send a member 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 member 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., no controller member is considered 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 member that contains a reference for each data controller.

Each URI reference provided in controller MUST 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-strings
          

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 OPTIONAL member named same-party MAY be provided 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-strings
          

An OPTIONAL member named third-party MAY be provided with an array value containing a list of domain names for third-party services that might be invoked while using the designated resource but do not share the same data controller as the designated resource.

third-party   = %x22 "third-party" %x22
third-party-v = array-of-strings
          

An OPTIONAL member named audit MAY be provided with an array value containing a list of URI references to external audits of the designated resource's privacy policy and tracking behavior in compliance with this protocol. 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-strings
          

An OPTIONAL member named policy MAY be provided 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 member is provided, this information might be obtained via the links provided in controller.

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

An OPTIONAL member named edit MAY be provided with a string value containing a URI-reference to a resource for giving the user control over personal data collected by the designated resource (and possibly other resources); an edit member SHOULD be provided if the tracking status value indicates prior consent (C). If no edit member is provided, this information might be obtained via the links provided in controller or policy.

An edit 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 is beyond the scope of this protocol.

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

Additional extension members MAY be provided in the status-object to support future enhancements to this protocol. A user agent SHOULD ignore extension members that it does not recognize.

extension     = object

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

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

begin-array   = <begin-array     ([), as defined in [[!RFC4627]]>
end-array     = <end-array       (]), as defined in [[!RFC4627]]>
begin-object  = <begin-object    ({), as defined in [[!RFC4627]]>
end-object    = <end-object      (}), as defined in [[!RFC4627]]>
object        = <object, as defined in [[!RFC4627]]>
string        = <string, as defined in [[!RFC4627]]>
true          = <true,   as defined in [[!RFC4627]]>
false         = <false,  as defined in [[!RFC4627]]>
null          = <null,   as defined in [[!RFC4627]]>
          

Note that the tracking status resource space applies equally to both first-party and third-party services. An example of a third-party tracking status is

{
  "tracking": "3",
  "policy": "/privacy.html",
  "edit": "/your/data",
}

5.4.4 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.

All requests on the tracking status resource space, including the site-wide tracking status resource, MUST NOT be tracked, irrespective of the presence, value, or absence of a DNT header field, cookies, or any other information in the request. In addition, all responses to those requests, including the responses to redirected tracking status requests, MUST NOT have Set-Cookie or Set-Cookie2 header fields and MUST NOT have 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.

5.4.5 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 response SHOULD be marked as cacheable and assigned 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 all users that have the same DNT-field-value, then the response MUST either be marked with a Vary header field that includes "DNT" in its field-value or marked as not reusable by a shared cache without revalidation with 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 response MUST include 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 section 5.3.3 Indicating an Interactive Status Change.

5.6.1 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.

5.6.2 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 and prior to making requests on third-party resources referenced by 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 retrieval is unsuccessful or parsing results in a syntax error, the user agent SHOULD consider the site to be non-conformant with this protocol.

The status-object is supposed to have a member named tracking containing the tracking status value. The meaning of each tracking status value is defined in section 5.2 Tracking Status Value.

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.

6.3.1 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 section 6.8 Exceptions without interactive JavaScript.)

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.

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.

6.3.2 Processing Model

This section describes the effect of the APIs in terms of a logical processing model; this model describes the behavior, but should not 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 HTTP request include:

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

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.

6.4.1 API to Request a Site-specific Exception

partial interface Navigator {
    void storeSiteSpecificTrackingException (StoreSiteSpecificExceptionPropertyBag properties);
};

dictionary StoreExceptionPropertyBag {
    DOMString? domain;
    DOMString? siteName;
    DOMString? explanationString;
    DOMString? detailURI;
};

dictionary StoreSiteSpecificExceptionPropertyBag : StoreExceptionPropertyBag {
    sequence<DOMString> arrayOfDomainStrings;
};

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.

If the document-origin would not be permitted 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.

6.4.2 API to Cancel a Site-specific Exception

partial interface Navigator {
    void removeSiteSpecificTrackingException (RemoveExceptionPropertyBag properties);
};

dictionary RemoveExceptionPropertyBag {
    DOMString? domain;
};

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.

6.4.3 API to Confirm a Site-specific Exception

partial interface Navigator {
    boolean confirmSiteSpecificTrackingException (ConfirmSiteSpecificExceptionPropertyBag properties);
};

dictionary ConfirmExceptionPropertyBag {
    DOMString? domain;
};

dictionary ConfirmSiteSpecificExceptionPropertyBag : ConfirmExceptionPropertyBag {
    sequence<DOMString> arrayOfDomainStrings;
};

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.

6.5.1 API to Request a Web-wide Exception

partial interface Navigator {
    void storeWebWideTrackingException (StoreExceptionPropertyBag properties);
};

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

6.5.2 API to Cancel a Web-wide Exception

partial interface Navigator {
    void removeWebWideTrackingException (RemoveExceptionPropertyBag properties);
};

6.5.3 API to Confirm a Web-wide Exception

partial interface Navigator {
    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.