This document is licensed under a Creative Commons Attribution 4.0 International Public License (CC-BY).
This specification defines a mechanism for expressing user decisions about personal data processing under the European Union’s data protection regulations, and similar regulations outside the EU. The mechanism functions through the exchange of HTTP headers between the user agent and the web server, or through an equivalent JavaScript interface.
The mechanism serves as an automated means for users to give or refuse consent, to withdraw any consent already given, as well as to object to processing. The mechanism provides an alternative to existing non-automated consent management approaches (e.g. ‘cookie banners’) and aims to reduce the efforts of the different parties involved regarding the protection of users’ privacy.
This section is non-normative.
Legal frameworks such as the European Union’s General Data Protection Regulation (GDPR) and ePrivacy Directive define rights and obligations around the processing of personal data. The starting position of the GDPR is that processing of personal data is only lawful if it has an appropriate legal basis; one basis being that “the data subject has given consent to the processing of his or her personal data for one or more specific purposes” (point (a) of Article 6(1) GDPR). Similarly, the ePrivacy Directive (in Article 5(3)) requires the user’s consent when any data is stored on or retrieved from terminal equipment beyond what is strictly necessary. Moreover, when a data controller relies on legitimate interest as the legal basis for direct marketing, the user has an absolute right to object under Article 21(2) GDPR.
As website publishers often desire to process their visitors’ personal data for purposes beyond what is necessary to serve the website, and beyond what can be based on legitimate interest, a website operator often wants to ask whether the visitor consents to such processing. Such communication currently tends to be done via highly disruptive and repetitive interfaces that are contained in the web page itself (e.g. ‘cookie banners’), rather than through the web browser or other automated channels.
It is the user’s choice how to communicate the exercise of GDPR rights to a data controller — the user could send an email, letter, or click a button on a website. In addition, technical means can be used:
Despite various legal provisions suggesting its validity, a standardised means for communicating GDPR rights has thus far been lacking.
This specification defines automated means for website visitors to give or refuse consent for the specific purposes that the data controller describes, to withdraw any consent already given, as well as to object to processing for direct marketing purposes based on the data controller’s legitimate interest. This enables the user to easily manage data protection decisions through the web browser, and possibly to customise how requests are presented and responded to (e.g. using a browser extension to import lists of trusted websites). The result could be comparable to the way websites ask for permission to access a webcam or microphone: the browser keeps track of the user’s decisions on a site-by-site basis, ensures that the user gets a genuinely free choice, and puts the user in control over their decisions.
This section is non-normative.
The protocol described in this document interacts between the website and the user agent (i.e. the browser). The website provides the user agent with a machine-readable “consent requests list” that specifies the data processing purposes for which it requests the user’s consent. The user agent responds the user’s decisions to the website. The current specification defines two technical paths for these interactions:
Link
header (or an equivalent HTML <link>
) pointing to a JSON file, and the ADPC
header.
The two methods are equivalent in meaning. There may be technical reasons to use one over the other, or even combine them. For example, the JavaScript approach obviously only works if the user agent supports JavaScript, but it can be used without requiring changes to the back-end infrastructure. Moreover, it permits requesting consent in response to the user’s interactions with a page.
The options to present to the user are organised as a list of request strings, each associated with an identifier. In the HTTP-based approach this list is encoded as a JSON file that the website links to. In the JavaScript-based approach, it is passed directly as a JavaScript object to the DOM interface navigator.dataProtectionControl.request(…)
.
The user’s response is presented to the website by listing the identifiers of the requests they consent to. In the HTTP-based approach, this list is sent in the ADPC
HTTP header in a subsequent HTTP request, while in the JavaScript-based approach, the list is the final return value of the DOM interface.
In the subsequent sections, the communication protocol is defined in detail. First come examples (§ 3. Example) and relevant definitions (§ 4. Definitions). Then § 6. Signals specifies the messages that the two sides exchange, defining the meaning of each. The two sections following it detail how these messages are technically conveyed via either the HTTP-based (§ 7. HTTP-based interaction) or JavaScript-based (§ 8. JavaScript-based interaction) approach.
This section is non-normative.
This document touches on data protection regulations as well as technical specifications, which tend to use very different concepts and terminology. In this document, the following terms are used to map data protection concepts into a technical specification:
The person visiting or interacting with the website.
This specification uses the word “user” as a term that includes both “data subjects” as defined under Article 4(1) GDPR and “users” as defined in Article 2(a) ePrivacy Directive.
The body that provides a website and determines the purposes and means of the processing of personal data or other information stored in the terminal equipment of the user.
This specification uses the word “controller” as a term that includes both the “controller” as defined under Article 4(7) GDPR and the “provider of an information society service” as used in Article 5(3) ePrivacy Directive.
The same person may or may not be recognisable to the website on a subsequent visit (for example when the user deletes stored IDs or uses another device or account), and may thus be considered a new user from the website’s perspective.
The scope of the user’s exercise of rights is therefore limited to any personal data and information that relates to the user present in any transaction.
The signal expressing the user’s exercise of rights includes any processing of personal data or information based on consent (Article 6(1)(a) GDPR and article 5(3) ePrivacy Directive) or for direct marketing purposes (Article 6(1)(f) and 21(2) GDPR and Article 13(1) ePrivacy Directive).
The website may determine the territorial scope where it provides support for this specification. Limited support may be expressed by not including the Link
header (or the equivalent <link>
element) in a transaction.
Regardless whether the protocol is used via the HTTP-based or JavaScript-based approach, conceptually the same messages are exchanged between website and user agent. This section describes the messages and their meaning.
The typical communication flow starts with the website requesting its visitor for consent to specific data processing purposes. The website can request consent from the user for zero or more processing purposes by presenting the user agent a consent requests list.
A consent requests list is an array containing zero or more consent requests, each representing a processing purpose. A consent request is an associative array containing the following attributes:
The request text: an arbitrary Unicode string that is to be presented to the user. The text should be formulated such that it allows an unambiguous affirmative or negative reaction by the user, such as clicking an “accept” button or ticking a checkbox.
A request identifier: a shorthand that is used to refer to this consent request. Within the website that makes the consent request, the request identifier MUST uniquely correspond to this specific consent request, in order to ensure no ambiguity arises as to which wording of a request the user has consented to. Hence a website must choose a new identifier when e.g. it modifies its request text, perhaps by including a version number as part of the identifier.
Except in standardised consent requests, the identifier consists of an arbitrary string containing uppercase and lowercase latin characters, digits, hyphen (-
), period (.
), underscore (_
), and tilde (~
) (i.e. any unreserved characters in the URI syntax).
[
{
"id": "q1analytics",
"text": "We track and analyse your visit(s) on this website, for improving our product; this places a cookie on your device to recognise you on subsequent page visits."
},
{
"id": "q2recommendation",
"text": "We observe your interaction with our content to personalise your experience by recommending content you may find of interest."
},
{
"id": "q3advertising",
"text": "We observe your interaction with our content to personalise advertising to your interests."
},
{
"id": "q4thirdPartyAdvertising",
"text": "We let third party TripleView™ observe your interaction with our content to personalise advertising to your interests on its partners’ websites."
}
]
A standardised consent request is a consent request whose request identifier is a URI rather than an arbitrary string. The attributes of a standardised consent request MUST uniquely correspond to the request identifier globally, rather than only within a website.
A website MUST NOT request consent if it will not respect the user’s decisions. The act of requesting consent thus doubles as an indication of compliance. A website that does not need to request consent, but wishes to (or is obliged to) signal that it supports the protocol, can simply request consent with zero requests.
A website SHOULD repeat its consent requests with every page it serves as long as they are applicable. The repetitions help inform the user agent that the consent requests are still relevant. The user agent can recognise which requests the user has already responded to before, and automatically repeat their responses to the website, and can determine which requests to present to the user.
Presenting the requests involves presenting the human-readable request text, along with the option to freely and unambiguously indicate an affirmative or negative wish of the user in line with Article 4(11) GDPR, such as by choosing between an “accept” and “reject” button or by ticking or not ticking an adjacent checkbox.
The exact user agent behaviour may depend on its implementation choices, its interaction modality and user preferences. User agents MUST use objective, non-discriminatory rules to determine which consent requests are presented to the user, and in what manner.
To give consent to zero or more specific processing purposes, the user agent presents the website with a list of the corresponding identifiers.
For legal validity, the user agent MUST NOT give consent without properly presenting the requests to the user and without freely given, specific, informed and unambiguous affirmative indication by the user. The user agent can remember the user’s previously given consent and repeat it on subsequent repetitions of the same request.
The user may withdraw consent that was previously given; the consent is represented by the identifier that was used to request it.
The user can also withdraw all consent for purposes not explicitly consented to in the current exchange. This also withdraws consent that was given ‘out of band’ (i.e. not through this protocol), and can therefore be useful to ensure that the user has a complete overview and control over the processing purposes they consented to.
The user agent MUST make it as easy to withdraw as to give consent in order to comply with Article 7(3) GDPR. This requires that the option to withdraw consent via the user agent must be as easy to access and exercise as the option to consent to the processing operation.
The user may object to processing of their personal data as provided for under Article 21 GDPR. Objection involves passing the appropriate objection identifier.
An objection identifier is a string corresponding to a type of objection. This specification defines only one objection identifier: direct-marketing
. The user may provide this identifier to object to processing of their personal data for direct marketing purposes, as provided for under Article 21(2) GDPR.
To ensure that the records of user preferences stored by the user agent and by the website stay synchronised and to ensure that the signalled preferences prevail over other interactions, it may be useful to combine multiple signals.
When signals are combined, specific signals (such as giving consent for specific processing purposes) SHALL prevail over more general signals (such as withdrawing all consent).
This section defines the first of the two ways to use the ADPC mechanism, which primarily communicates using the HTTP headers exchanged between the web server and user agent, while using a JSON resource to convey the consent requests.
A website lists the processing purposes it requests consent for in a consent requests resource, which is a JSON file containing an object with the following attributes:
To request consent, the website points to such a consent requests resource using the HTTP Link
header, with the relation type consent-requests
.
When returning an HTML or XML document, instead of adding the Link
header, an equivalent <link>
element can be added to the document, with the same semantics as the header.
When the user agent detects a consent-requests
link in a document in the top-level browsing context, it would typically fetch and parse the linked JSON resource and, if this succeeds, present the requests to the user. It MAY reduce traffic by only fetching the resource once the user decides to interact with the consent requests.
A website may want to explicitly express that it does not request any consent. The obvious approach would be to present a consent requests resource with an empty object as the value of consentRequests
. In the HTTP-based approach, this could however cause an unnecessary round trip for obtaining this consent requests resource. Moreover, in a user agent that notifies or hints the user about consent requests before it retrieves the consent requests resource, it could cause a confusing experience.
Instead of presenting a consent requests resource without consent requests, a website SHOULD therefore link to the special target about:blank
.
To give consent or withdraw consent to zero or more specific processing purposes listed in the received consent requests resource, the user agent adds the ADPC
HTTP header in its subsequent HTTP requests to the website.
The value of the ADPC
header is set to the characters consent=
, or withdraw=
, respectively, followed by a double-quoted string containing the corresponding request identifiers, separated by spaces. If the list has only one identifier, the double quotes can be omitted. If it has zero identifiers, the value can equivalently be empty, or the header can be omitted altogether.
To convey multiple decisions, the ADPC
header can be used any number of times in a single HTTP request, in arbitrary order. As is standard with HTTP headers, multiple header values can either be listed as separate headers, or be concatenated with a comma (optionally surrounded by whitespace).
The user agent SHOULD repeat the ADPC header with every HTTP request it makes to the website, as long as it is applicable. The repetitions enable a website to know the user’s decision without keeping records itself. The user agent MAY send a stand-alone HTTP request to ensure a user’s decision is conveyed as soon as possible, instead of waiting for the next natural occasion to transmit the signal.
To withdraw all consent, the special value *
can be used in place of an identifier.
A stand-alone HTTP request is an HTTP HEAD
request to an arbitrary path on the website’s origin. It can be used to deliver HTTP headers without requesting any resource.
To object to processing of their personal data, the user agent adds the ADPC
HTTP header to any HTTP request to the website, with the value object=
followed by a double-quoted string containing zero or more objection identifiers. If the list has only one identifier, the double quotes can be omitted. If it has zero identifiers, the value can equivalently be empty, or the header can be omitted altogether.
While the HTTP signalling approach can be sufficient, there are several reasons why a website may prefer to communicate in other ways. For example:
To request consent for zero or more processing purposes, a website’s scripts can invoke the request
()
function, passing it a consent requests list. The user agent will then present the requests to the user, or/and directly return a response based on the user’s previous responses or preferences.
Requesting consent can only be done by the web page the user consciously visits, and not by e.g. resources embedded within it. Therefore, if the request
()
function was invoked by a script that is not running in the top-level browsing context, the user agent MUST NOT act upon the consent request, and simply resolve with an empty user decisions object.
To signal user decisions to the website, the user agent passes the appropriate values in the return value of the request
()
function. The return value is a Promise
that resolves with a user decisions object.
Whenever the user changes their decisions relating to the website while visiting it, the user agent notifies the page by triggering the decisionchange
event on dataProtectionControl
, which includes the updated user decisions object.
A user decisions object is a JavaScript object, the members of which signal the user’s decisions to the website. Each member is optional:
"*"
to withdraw all consent.
Unlike with the HTTP approach, where the user agent can send request headers, in JavaScript there is not an obvious way for the user agent to take the initiative to send a signal to the website. In cases where a website does not or cannot read the ADPC HTTP header, it MUST on every page visit invoke and await the return value of request
()
, as well as listen to the decisionchange
event, in order to ensure it becomes aware of a user’s decisions.
WebIDL[Exposed=Navigator]
interface DataProtectionControl
: EventTarget {
Promise<UserDecisionsObject
> request
(object consentRequestsList);
};
[Exposed=DataProtectionControl]
interface AdpcEvent
{
readonly attribute UserDecisionsObject
userDecisions
;
};
[Exposed=DataProtectionControl]
interface UserDecisionsObject
{
readonly attribute DOMStringList? consent
;
readonly attribute DOMStringList? withdraw
;
readonly attribute DOMStringList? _object
;
};
The dataProtectionControl interface enables a web page to request consent from the user and learn about their data protection decisions.
The request() method can be used to request consent, as described in § 8.1 Requesting consent.
This section is non-normative.
Users regularly feel overwhelmed by consent requests (‘consent fatigue’). Enabeling trusted parties to suggest including or excluding certain consent requests could allow users and user agents to determine which consent requests to prioritise or automatically consent to, and which consent requests to ignore or automatically reject. Websites, groups of controllers or consumer groups may promote inclusion lists, for example of websites providing quality journalism or for the purpose of informing users about regular discounts.
The user agent may allow to import such third party bulk consent requests lists, which may be made available as a file or as a continuously updated online resource. The discovery and exchange mechanisms used are beyond the scope of this specification.
The exact user agent behaviour after importing such a list may depend on its implementation choices, its interaction modality and user preferences. For example, excluded consent requests might only be shown when a user has visited a website more often, while included consent requests are shown instantly. Other implementations might automatically consent to all included consent requests and automatically reject all excluded consent requests.
If a user agent allows to automatically consent to included consent requests, it MUST ensure a freely given, specific, informed and unambiguous indication of the user’s wishes for each consent request.
A bulk consent requests list is a JSON file containing an object with the following attributes:
A consent request descriptor is an object with the following members:
*
) if it applies to any website.
This section is non-normative.
Users may use various forms of communicating consent, withdrawal of consent, or objections — the user could send an email, letter, or click a button on a website. Independent of the communication channel, the most recent communication would usually override the previous exercise of rights. As the ADPC signal would typically be communicated in every interaction with a website, it would quickly override previous expressions through any other communication, like consent banners, emails or letters.
If the ADPC signal is sent in the same transaction as another signal with related meaning (e.g. when clicking an “agree” button on a website, or sending another signal such as a DNT or Sec-GPC HTTP header), any non-contradicting communication can be interpreted combinedly without problem. Any expressions of consent that are in conflict with each other will not be “unambiguous” as required by Article 4(7) GDPR, and should thus be interpreted as a lack of valid consent.
This section is non-normative.
While the primary purpose of the specified mechanism is to help improve personal data protection, it is important to recognise that the approach is in essence legal, rather than technical. The mechanism conveys users’ decisions in a machine-readable manner, which the website might be legally obliged to respect, but the effective protection relies on the website’s compliance with the law. Privacy impact considerations can therefore be divided into the potential benefits from its use, and potential harms from its abuse.
To assess the impact, we compare the adoption of the specified mechanism with the commonly observed alternative: requests for consent via interfaces contained within the website’s pages, and stored using cookies or other browser storage. Adoption of this specification could yield the following benefits for user privacy:
Even if the mechanism benefits privacy in websites that abide by it, it would be undesirable if it can harm their privacy in cases where websites do not comply. This section discusses limitations of the specified mechanism and some mitigations.
First of all, this mechanism cannot prevent websites from giving false or incomplete information, or simply disrespecting the user’s decisions. A false pretense of control may erode trust in the system. While this might equally be the case without use of this mechanism, the presentation through the web browser interface, which is generally more trusted than the website being visited, may give a false sense that decisions are enforced by the user agent, as is the case with permission requests for e.g. microphone access.
A common concern with a new web standard is whether it enables websites to track users. Because the specified mechanism is only used with web pages in the top-level browsing context, and the user decisions are only presented to the individual website they apply to, it does not introduce new vectors for cross-website tracking. The specified HTTP headers are not passed along with, nor read from transactions with, a web page’s subresources, and the JavaScript interface is unusable inside framed pages.
However, a limited ability to do first-party tracking is unavoidable given that users express their decisions, which will necessarily convey some information. The user’s data protection decisions, simply by being different from those of other persons, could be used to help re-identify them on subsequent visits.
The situation here is similar to that of first-party cookies, although it is made less impactful because the requests are visible to the user, and the responses are made by the user rather than set arbitrarily by the website. Moreover, the entropy of user decisions is likely very low: if a website asks four consent questions, these provide at most four bits of information, but in practice much less because users do not choose their responses perfectly at random. Especially if a website makes, say, fourty consent requests, users are unlikely to make fourty independent decisions: rejecting or accepting all requests at once is a common response.
Besides the individual users’ responses, without further precautions the request identifiers also risk to be usable as persistent tracking vectors. A malicious website could, rather than having a static list of consent requests, customise the request identifiers for each user to recognise the user again (if they consented) during a subsequent visit. Various approaches could help prevent this form of tracking. For example, user agents could refrain from transmitting the consent header value along with the first HTTP request to a website in a new session, in order to first verify whether the website still makes the same requests as before.
Even though the mechanism does not enable cross-website tracking, and is less impactful than first-party cookies, the possibility to track users would need to be much less than with cookies, so that users can trust they keep their data protection decisions when removing their cookies. To this end, mitigations should be developed, and implementers should evaluate their abilities to limit entropy and may make trade-offs between efficiency and anonimity.
Another potential privacy/security risk arises from the ability of a third-party script loaded into the web page to use the JavaScript interface as if it was part of the page itself. It could make the web page request consent and observe the user’s decisions for the website, and possibly transmit information back to its creators or other parties. However, this specification may not significantly exacerbate this already existing issue: any included third-party script needs to be fully trusted, and can do worse things than requesting consent. Common security features, such as Content Security Policy Level 2 and Subresource Integrity, can somewhat reduce the risk of including third-party scripts.
The specified mechanism gives the user agent an important role in the exercise of people’s data protection rights, and thereby also responsibilities. Following the principle of ‘privacy by default’, the mechanism is designed to err on the side of less processing when needed. For example, if a step in the protocol is hampered due to the consent requests resource being invalid or temporarily unavailable, the result is that no consent is requested, nor given.
Apart from some basic requirements to e.g. avoid invalid consent, user agents have significant freedom in the implementation of their side of the mechanism. This freedom can be used to further improve people’s data protection control, for example by supporting the import of bulk consent requests lists.
While the above analysis covers the case of non-compliant websites, it assumes that user agents are indeed acting, as the term implies, on behalf and in the best interest of the user. While the user in theory has freedom to choose and even customise their user agent, this assumption may often be hampered in practice. User agents could for example be prone to apply ‘dark patterns’ or unfairly discriminate between websites, due to misaligned interest of its developer. Legal compliance may therefore be relevant for the user agent as well as the website, and wide customisability of user agents through plug-ins/extensions can be an important factor for putting the user in control.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, SHALL, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
The authors are grateful for the contributions and feedback by Alan Dahi, Rob van Eijk, Stefanie Alice Hofer, Horst Kapfenberger, Mandan Kazzazi, Gustaf Neumann, Mike O’Neill, Harshvardhan J. Pandit, Monika Riegler, Stefano Rossetti, and our other colleagues from different institutions around the globe.
This work is partially supported by the Internet Foundation Austria (IPA) within the NetIdee call (RESPECTeD Project; Grant#prj4625).
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: