Abstract
This specification defines the technical mechanisms for expressing a
cross-site tracking preference via the
DNT request header field in
HTTP, via an HTML DOM property readable by embedded scripts, and via
properties accessible to various user agent plug-in or extension APIs.
It also defines mechanisms for sites to signal whether and how they
honor this preference, both in the form of a machine-readable policy
at a well-known location for first-party sites and a
Tracking
response header field for third-party resources that engage in
cross-site tracking, and a mechanism for allowing the user to approve
site-specific exceptions to DNT as desired.
Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This draft does not represent a final working group consensus, though an attempt has been made to highlight areas where issues have been identified and present multiple alternatives if they have been discussed.
This document was published by the Tracking Protection Working Group as a First Public Workingan Editor's Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-tracking@w3.org (subscribe, archives). All feedback is welcome.
Publication as a Workingan Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1. Introduction
The World Wide Web (WWW, or Web) consists of millions of sites
interconnected through the use of hypertext. Hypertext provides a
simple, page-oriented view of a wide variety of information that
can be traversed by selecting links, manipulating controls, and
supplying data via forms and search dialogs. A Web page is usually
composed of many different 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.
Each of the hypertext actions and each of the embedded resource
references might refer to any site on the Web, leading to a seamless
interaction with the user even though the pages might be composed of
information requested from many different and possibly independent
Web sites. From the user's perspective, they are simply visiting and
interacting with a single brand — the first-party Web
property — and all of the technical details and protocol mechanisms
that are used to compose a page representing that brand 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 can occur both at the first-party site and via
third-party analytics providers through the insertion of tracking
elements on each page.
Advertising revenue is the single largest source of funding on the
Web. Since advertisers desire an audience that is receptive to
whatever they happen to be advertising, a significant premium is
assigned to sites that can demonstrate a favorable target audience,
and even more so for sites that are able to identify their audience
dynamically and adjust the advertising displayed to be specific to
the interests of that user. In an attempt to better understand or
predict those interests, some advertising mechanisms follow a user's
actions over time, collect data on the observed behavior, and use
that data for targeting future advertisements: a practice commonly
referred to as online behavioral advertising (OBA).
Like analytics data collection, Web sites often contract with
third-party advertising networks for the tasks of selecting,
delivering, and measuring the advertising shown on their sites, while
advertisers often contract with third-party verification companies
to provide independent accounting of ad impressions and fraud
detection.
There are numerous techniques for integrating advertising
networks into a website, though most involve some form of embedded
resource request to a site controlled by the advertising network.
Since the advertising networks are supplying ads for multiple sites,
they are capable of monitoring how often a given ad is displayed
to that same user agent across their entire network (frequency capping).
Naturally, advertisers consider frequency capping to be a desirable
feature, and thus it is common for advertisers to contractually limit
advertising campaigns to a maximum impression count per user. As a
result, advertising networks track users from site to site
even when OBA is not in use.
In many cases, Web users welcome the use of data collection for
personalization and targeted advertising, since it can allow a site
to tailor the user experience to their specific desires, reduce ads
that are irrelevant or repetitive, and avoid the imposition of more
direct revenue in the form of subscription-only services.
In other cases, personalization and targeting can be perceived as
creepy
, intrusive, and sometimes simply incorrect.
In particular, targeting and personalization can evoke strong
negative feelings when data collected at a trusted site is used,
without the user's consent, for targeting ads on some other site
with which they have no personal trust relationship. When cross-site
tracking or cross-site sharing of data collection does not match the
user's expectations regarding privacy, the result can be a very
angry customer.
None of the participants in this Web of customization and targeted
advertising want to offend the user. For advertisers, it is
counterproductive. For Web site owners, it drives away their
audience and income. For advertising networks, it leads to blocking
and lost advertisers. Therefore, we need a mechanism for the user
to express their own preference regarding cross-site tracking that is
both simple to configure and efficient when implemented.
Likewise, since some Web sites may be dependent on the revenue
obtained from targeted advertising and unwilling (or unable) to
permit use of their content without cross-site data collection,
we need a mechanism for sites to alert the user to those requirements
and allow the user to configure an exception to DNTexceptions for specific sites.
This specification defines the HTTP request header field DNT for
expressing a cross-site tracking preference on the Web, a well-known location
(URI) for providing a machine-readable site-wide policy regarding DNT
compliance, and the HTTP response header field Tracking for
third-party resources engaged in dynamic tracking behavior to
communicate their compliance or non-compliance with the user's
expressed preference.
A companion document, Tracking
Compliance and Scope
, more precisely defines the terminology
of tracking preferences, the scope of its applicability, and the
requirements on compliant first-party and third-party participants
when an indication of tracking preference is received.
ISSUE-108: Should/could the tracking preference expression be extended to other protocols beyond HTTP?
2. Notational Conventions
2.1 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].
2.2 Formal Syntax
This specification uses Augmented Backus-Naur Form [ABNF]
to define network protocol syntax and WebIDL [WEBIDL] for
defining scripting APIs.
2.3 Terminology
This specification uses the term user agent to refer to
any of the various client programs capable of initiating HTTP
requests, includingincluding, but not limited to, browsers, spiders (web-based robots),
command-line tools, native applications, and mobile apps [HTTP11].
ISSUE-13 : What are the requirements for DNT on apps/native software in addition to browsers?
[PENDING REVIEW]
The above paragraph aims at resolving this issue.
3. Determining User Preference
The goal of this protocol is to allow a user to express their
personal preference regarding cross-site tracking to each server and
web application that they communicate with via HTTP, thereby allowing
each serverservice to either adjust their behavior to meet the user's
expectations or reach a separate agreement with the user to satisfy
bothall parties. Key to that notion of expression is that it must
reflect the user's preference, not the preference of some
institutional or
network-imposed mechanism outside the user's control.
Key to that notion of expression is that it must reflect the user's
preference, not the preference of some institutional or
network-imposed mechanism outside the user's control.
Although 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, the user is at least able to choose whether to
make use of those user agents. In contrast, 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 sites can or cannot be accessed through that network.
The remainder of this specification defines the protocol in terms
of whether DNTa cross-site tracking preference is enabled or
not enabled.
We do not specify how that preference is configuredenabled:
the user agent
each implementation is responsible for determining the user experience
by which this preference is set enabled.
For example, a user might configure their own user agent to
tell servers do not track me cross-site
, install a plug-in
or extension that is specifically designed to add that expression,
or make a choice for privacy that then implicitly includes a
tracking preference (e.g., Privacy settings: high
). Likewise,
a user might install or configure a proxy to add the expression
to their own outgoing requests.
For each
of these cases, we say that DNT a cross-site tracking preference
is enabled.
ISSUE-4: What is the default for DNT in client configuration (opt-in or opt-out)?
[PENDING REVIEW] Proposed text above.
ISSUE-95: May an institution or network provider set a tracking preference for a user?
[PENDING REVIEW]
See the second paragraph of this section, above.
4. Expressing a Tracking Preference
When a user has configured aenabled a cross-site tracking preference, that
preference
needs to be expressed to all mechanisms that might perform
or
initiate tracking by third parties, including sites that the user
agent
communicates with via HTTP, scripts that can extend behavior on
pages, and plug-ins or extensions that might be installed and
activated for various media types.
The preference is expressed as either:
| DNT |
meaning |
|---|
| 1 |
Do not track me across differently-branded sites and
do not use previously tracked/obtained behavioral data from
other sites to personalize a response. |
|---|
| 0 |
Use of cross-site tracking and personalization has been
specifically permitted for this site, as described in
section 6. User-agent-managed site-specific exceptions. |
|
|---|
If a cross-site tracking preference is not enabled, then no
preference is expressed by this protocol. This means that no
expression is sent for each of the following cases:
- the user agent does not implement this protocol;
- the user agent does implement the protocol but the user has
not yet enabled a preference; or,
- the user's preference is that DNT be not enabled for
all sites.
In the absence of regulatory, legal, or other requirements, servers
may interpret the lack of an expressed cross-site 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.
ISSUE-78: What is the difference between absence of DNT header and DNT = 0?
[PENDING REVIEW]
Proposed text above and in 4.1 below defines that a "0" is only
sent when a cross-site tracking preference is enabled and some
mechanism known to the user agent has specifically made an exception
for this origin server. Note that we have not yet defined such a
mechanism. If a cross-site tracking preference is not enabled or
not implemented, no DNT header field is sent.
4.2 HTML DOM Interfaces
The NavigatorDoNotTrack interface provides a means for
the user's cross-site tracking preference to be expressed to
web applications running within a page rendered by the user agent.
[NoInterfaceObject]
interface NavigatorDoNotTrack {
readonly attribute DOMString doNotTrack;
};
4.2.2 Implements
Navigator implements NavigatorDoNotTrack;
Objects implementing the
Navigator interface
[
NAVIGATOR] (e.g., the
window.navigator object)
must also implement the
NavigatorDoNotTrack
interface.
An instance of
NavigatorDoNotTrack is obtained
by using binding-specific casting methods on an instance of
Navigator.
ISSUE-84: Do we need a JavaScript API / DOM property for client-side js access to Do Not Track status?
[PENDING REVIEW]
We believe that we need such an API. This section proposes one.
ISSUE-96: The doNotTrack attribute should mirror the value of the header (potentially empty, extensions, etc.)
[PENDING REVIEW]
Proposed text above.
4.3 Plug-In APIs
User agents often include user-installable component parts,
commonly known as plug-ins or
browser extensions, that are capable of making their own
network requests. From the user's perspective, these components
are considered part of the user agent and thus ought to respect the
user's configuration of a cross-site tracking preference. However, plug-ins
do not normally have read access to the browser configuration.
Therefore, we will define here various mechanisms for communicating
the DNTtracking preference via common plug-in APIs.
5. Communicating a Tracking Status
The companion document, Tracking
Compliance and Scope
, defines how service providers are
expected to comply when they receive an expression of the user's
tracking preference via any of the mechanisms described in
section 4. Expressing a Tracking Preference.
If no DNT preference is received, it may indicate either that
the user has chosen to allow cross-site tracking or that their
user agent does not support this protocol for expressing DNT
(e.g., user agents deployed prior to this protocol's existence).
In the absence of regulatory, legal, or other requirements, servers
are free to interpret the lack of a DNT header as they find most
appropriate for the given user, particularly when considered in
light of the user's privacy expectations and cultural circumstances.
This section defines how a server communicates its compliance with
tracking preferences, including whether it will honor the user's
preference, require some form of site-specific exception, or indicate
that it already has the user's permission via some other agreement
(e.g., a subscription or account agreement). Optionally, links can be
provided to human-readable information regarding the site's tracking
policies or where to go to opt-in, opt-out, or edit their personal
information.
5.1 Goals
The following goals have been identified as reasons for having a
response from the server:
- Auditing compliance by servers
- Measuring deployment of DNT
- Transparency
- allow user awareness of DNT status per-site/element
- indicate what elements on page have ack'd/honored DNT
- Allow the server to indicate that it requires a site-specific exception
- GuidanceIf server claims exemption, under what clause (1st party, contracted, etc.)
- Express fine-grained track/no-track for site-specificpieces of a site
- Usability
- provide sufficient communication to enable use cases
5.2 Criteria
The following criteria have been identified as constraints on the
response design:
- Minimize impact on cacheable responses
- Simplicity
- Scalability
- Express fine-grained track/no-track for pieces of a site
- Scalability
- Minimize impact on cacheable responses
- Communication efficiency
- Simplicity
- simple for servers to implement and deploy
- simple for communication over HTTP
- simple for user agents to configure and deal with exceptions
- Consideration of appropriate legal and regulatory policies
ISSUE-98: Consider applicable laws and regulations, such as Article 5(3) of the EU ePrivacy Directive
5.3 Options
There have been many suggestions, but not much consensus, on how
servers ought to respond when DNTa cross-site tracking preference is enabled. The various
suggestions can be roughly categorized as follows:
- No response.
- A well-known location for machine-readable site-wide policy.
- A static link header field for machine-readable policy.
- A static header field indicating that DNT is honored.
- A dynamic header field indicating that tracking is enabled or
disabled for this user agent (and why).
and also some combinations of the above. For example, we might
define that compliant servers provide a machine-readable site-wide
policy that indicates how they honor DNT, what sites are considered
the same brand, and links to resources for providing site-specific
exceptions to DNT or editing collected tracking data. We could
then limit use of a tracking response header field to only those
dynamic responses for third-party resources that engage in tracking.
ISSUE-77: How does a website determine if it is a first or third party and should this be included in the protocol?
ISSUE-62: The browser or embedding site could send an architectural signal to an embedded iframe so it knows it's in a 3rd-party context
ISSUE-79: Should a server respond if a user sent DNT:0?
ISSUE-81: Do we need a response at all from server?
[PENDING REVIEW]
Yes: The users expect to be able to see whether a DNT header is
accepted, rejected, or sent into the void.
ISSUE-51: Should 1st party have any response to DNT signal
5.4 Machine-readable Tracking Policy
This can be defined as either a well-known location, as
defined by RFC5785, or as a Link header field sent in response
to any request (regardless of DNT).
- e.g., "http://example.com/.well-known/tracking"
- machine-readable (JSON or similar)
- include booleans for compliance
- response content can be either dynamic (per user) or static
(applies to everyone)
- optionally include list of domains for same-brand scope
- optionally include link to user-readable policy document
- optionally include link to opt-in/out form
- optionally include link to edit data collected
- accessible before making use of site's services
- allows third-party sites to indicate their own policies
ISSUE-47: Should the response from the server point to a URI of a policy (or an existing protocol) rather than a single bit in the protocol?
ISSUE-80: Instead of responding with a Link: header URI, does it make sense to use a well-known location for this policy?
ISSUE-87: Should there be an option for the server to respond with "I don't know what my policy is"
ISSUE-61: A site could publish a list of the other domains that are associated with them
5.6 Status code for Tracking Required
An HTTP error response status code might be useful for indicating
that the site refuses service unless the user either logs into a
subscription account or agrees to an exception to DNT for this
site and its contracted third-party sites.
6. User-agent-managed site-specific exceptions
5.7 Site-specific Exceptions
ISSUE-43: Sites should be able to let the user know their options when they arrive with Do Not Track
ISSUE-27: How should the "opt back in" mechanism be designed?
ISSUE-46: Enable users to do more granular blocking based on whether the site responds honoring Do Not Track
ISSUE-115: Should sites be able to manage site-specific tracking exceptions outside of the user-agent-managed system?
6.3 JavaScript API to
prompt for exceptions
A JavaScript API allows sites to request a site-specific tracking
exception from the user and to check whether exceptions are already
granted for particular tracking domains.
[NoInterfaceObject]
interface NavigatorDoNotTrack {
boolean requestSiteSpecificTrackingException (sequence<DOMString> arrayOfDomainStrings);
readonly attribute sequence<DOMString> siteSpecificTrackingExceptions;
};
5.7.16.3.1 Attributes
siteSpecificTrackingExceptions of type sequence<DOMString>, readonly- A list of domains granted tracking exceptions for this site.
No exceptions.
6.3.2 Methods
requestSiteSpecificTrackingException- Returns true if the user granted all of the exceptions,
false if any exceptions were not granted.
| Parameter | Type | Nullable | Optional | Description |
|---|
| arrayOfDomainStrings | sequence<DOMString> | ✘ | ✘ | |
No exceptions.
The requestSiteSpecificTrackingException method takes
one argument, arrayOfDomainStrings a JavaScript array
of strings. Each string specifies a document origin of a tracking
element used by the site invoking this function. The special string
* signifies all document origins.
User agents must provide a user interface prompting the user to
choose whether to provide site-specific exceptions to Do Not Track
for the requested origins, or, if pre-configured to accept or reject
these permissions, respond with the user’s previously
configured preference. The user interface should include the domains
included in arrayOfDomainStrings and may include
additional metadata about those domains (included EV certificate
information, historical data, human-readable descriptions of the
tracker and its purpose, links to privacy policies, etc.). The user
agent should express to the user that the exception will cover
tracking done by each tracker while the user is browsing the current
first party (as defined by the Compliance document).
The siteSpecificTrackingExceptions property is a
read-only list of strings, each specifying a domain granted a
site-specific tracking exception (by previous calls to
requestSiteSpecificTrackingException or through browser
configuration). A first party may query this property to determine
whether to request additional exceptions; a third party may query
this property to determine whether Do Not Track applies to its
domain.
ISSUE-109: siteSpecificTrackingExceptions property has fingerprinting risks: is it necessary?
This list property enables even easier fingerprinting by any first
or third party JavaScript. Could first parties instead rely on
calling requestSiteSpecificTrackingException and
receiving a true response if exceptions have already
been granted?
6.4 Exception management user interface
A user agent might provide an interface like the following in
order to present a tracking exception request to the user.
The New York Times (http://nytimes.com) requests that you allow
tracking by the following parties:
- analytics.nytimes.com
- adserver.example.com
If you agree, you opt-in to tracking by these parties while
browsing nytimes.com.
[Allow] [Deny]
The user agent may provide users with granular choice over which
tracking origins are granted site-specific exceptions and which are
not (using checkboxes, for example). The user agent must store
granted site-specific exceptions in the form of a pair (document
origin of the top-level document, site-specific-exception
document-origin). If the user has agreed to grant all of the
requested site-specific exceptions, then the user agent must return
true to the
requestSiteSpecificTrackingException call, otherwise it
must return false.
User agents may automatically clear site-specific exceptions after a
period of time or in response to user activity. User agents must
provide the user with an interface to explicitly revoke
site-specific exceptions.
6.5 Behavior for future requests with site-specific exceptions
ISSUE-111: Different DNT values to signify existence of associated exceptions
Should the user agent send a different DNT value to a first party
site if there exist site-specific exceptions for that first party?
(e.g. DNT:2 implies “I have Do Not Track enabled but grant
permissions to some third parties while browsing this domain”)
When Do Not Track is enabled and an HTTP request is about to be
made, the user agent must first check the list of valid
site-specific exceptions if one exists. Let top-level-origin be the
document origin of the top-level document (e.g. the domain of the
Web page explicitly requested by the user in the URL bar) and
other-origin be the document origin of other resources on the page
that are fetched in the course of loading and displaying the
requested page. Let top-level-parents be all domains that include
top-level-origin as a subdomain. If the pair (top-level-origin,
“”) or any of (top-level-parents,
“”) is present in the site-specific exceptions
list, the user agent must send DNT:0. For each other-origin and each
top-level-parent, if the pair (top-level-origin, other-origin) or
(top-level-parent, other-origin) is present in the site-specific
exceptions list, the user agent must send DNT:0, otherwise, it must
send DNT:1.
ISSUE-110: Is top-level-origin for outgoing requests workable for site-specific tracking exceptions?
Will all implementers, including browser extensions, be able to
determine the corresponding top-level-origin for all outgoing
requests?
ISSUE-112: How are sub-domains handled for site-specific exceptions?
Should a request for a tracking exception apply to all subdomains of
the first party making the request? Or should a first party
explicitly list the subdomains that it’s asking for?
Similarly, should third party subdomains be allowed (e.g.
*.tracker.com)?
6.6 Web-wide exceptions
Users may also wish to configure exceptions for a certain trusted
tracker across several or all sites. User agent configuration of
these preferences is outside the scope of this specification.
ISSUE-113: Should there be a JavaScript API to prompt for a Web-wide exception?
User agents should take care in communicating the breadth of a
Web-wide exception to the user’s Do Not Track preference.
6.8 Fingerprinting concerns
By storing a client-side configurable state and providing
functionality to query it later, this functionality may enable user
fingerprinting and user tracking.
ISSUE-114: Guidance or mitigation of fingerprinting risk for user-agent-managed site-specific tracking exceptions
6.10 Use case: Site-specific exceptions should persist
It would annoy users of DNT if they are presented with an
exception dialog each time they visit a site.
- User turns on DNT and visits Example.com
- Example.com does not receive a signal it's on the
exception list
- Example.com requests exception to DNT from user to access
content for free
- User grants exception to Example.com (and perhaps
listed parties)
- User views content
- User returns to Example.com a week later
- DNT signal is still turned on but Example.com is sent an
exception flag (or else doesn't send a DNT signal at all)
- In either case, it'll be important that Example.com know
to not trigger the exception request for this
user/web browser/device
A. Acknowledgements
This specification consists of input from many discussions within
and around the W3C Tracking Protection Working Group, along with
written contributions from
Nick Doty (W3C/MIT),
Roy T. Fielding (Adobe),
Tom Lowenthal (Mozilla),
Aleecia M. McDonald (Mozilla),
Matthias Schunter (IBM),
and Shane Wiley (Yahoo!).
The DNT header field is based on the original Do Not Track
submission by Jonathan Mayer (Stanford), Arvind Narayanan
(Stanford), and Sid Stamm (Mozilla).
The DOM API for NavigatorDoNotTrack is based on the
Web Tracking Protection submission by Andy Zeigler,
Adrian Bateman, and Eliot Graff (Microsoft).
Many thanks to Robin Berjon for ReSpec.js.
B. Closed Issues
ISSUE-2: What is the meaning of DNT (Do Not Track) header?
[CLOSED]
When rephrased as "Does the presence of a DNT header field on requests
always indicate
an explicit choice". The?" the answer we agreed upon is "yes".
ISSUE-4: What is the default for DNT in client configuration (opt-in or opt-out)?
See section 3. Determining User Preference regarding the
multiple ways that a preference might be enabled and
section 4. Expressing a Tracking Preference regarding how servers
might interpret the lack of a preference expression.
ISSUE-13 : What are the requirements for DNT on apps/native software in addition to browsers?
Resolved by text in section 2.3 Terminology.
ISSUE-40: Enable Do Not Track just for a session, rather than being stored
[CLOSED]
Resolved in DNT Call 2011-10-26: The user agents are free to send
different DNT values for different sessions. We agreed that this is
a user-interface issue and out of scope on its own.
ISSUE-42: Feedback to the user from the browser when Do Not Track is turned on
Resolved as out of scope.
ISSUE-50: Are DNT headers sent to first parties? Yes
ISSUE-68: Should there be functionality for syncing preferences about tracking across different browsers?
[CLOSED]
Resolved in DNT Call 2011-10-26: The user agents may or may not sync.
However, this is out of scope for this spec.
ISSUE-70: Does a past HTTP request with DNT set affect future HTTP requests? No
ISSUE-81: Do we need a response at all from server?
Yes, some form of response is necessary for verification.
ISSUE-82: Should the DNT header be extensible with additional parameters?
Yes, the field-value definition in
section 4.1 DNT request header field allows for an
extension string. At this point, no extensions have been defined.
C. Postponed Issues
ISSUE-44: Ability to measure/detect who is honoring Do Not Track at a technical level
[POSTPONED]
The info at the well-known URI declares whether a server promises to
follow DNT. Whether it actually does (or just pretends to do so) is
hard to determine and should be addressed later.
ISSUE-64: How does site preference management work with DNT
[POSTPONED]
To what extent cookies can be used for preference management (such as
storing a language preference) will be resolved later.