├── .github └── workflows │ └── auto-publish.yml ├── LICENSE ├── README.md ├── consent popup mockup.png └── index.html /.github/workflows/auto-publish.yml: -------------------------------------------------------------------------------- 1 | name: CI 2 | on: 3 | pull_request: {} 4 | push: 5 | branches: [main] 6 | jobs: 7 | main: 8 | name: Build, Validate and Deploy 9 | runs-on: ubuntu-20.04 10 | steps: 11 | - uses: actions/checkout@v2 12 | - uses: w3c/spec-prod@v2 13 | with: 14 | GH_PAGES_BRANCH: gh-pages 15 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Mozilla Public License Version 2.0 2 | ================================== 3 | 4 | 1. Definitions 5 | -------------- 6 | 7 | 1.1. "Contributor" 8 | means each individual or legal entity that creates, contributes to 9 | the creation of, or owns Covered Software. 10 | 11 | 1.2. "Contributor Version" 12 | means the combination of the Contributions of others (if any) used 13 | by a Contributor and that particular Contributor's Contribution. 14 | 15 | 1.3. "Contribution" 16 | means Covered Software of a particular Contributor. 17 | 18 | 1.4. "Covered Software" 19 | means Source Code Form to which the initial Contributor has attached 20 | the notice in Exhibit A, the Executable Form of such Source Code 21 | Form, and Modifications of such Source Code Form, in each case 22 | including portions thereof. 23 | 24 | 1.5. "Incompatible With Secondary Licenses" 25 | means 26 | 27 | (a) that the initial Contributor has attached the notice described 28 | in Exhibit B to the Covered Software; or 29 | 30 | (b) that the Covered Software was made available under the terms of 31 | version 1.1 or earlier of the License, but not also under the 32 | terms of a Secondary License. 33 | 34 | 1.6. "Executable Form" 35 | means any form of the work other than Source Code Form. 36 | 37 | 1.7. "Larger Work" 38 | means a work that combines Covered Software with other material, in 39 | a separate file or files, that is not Covered Software. 40 | 41 | 1.8. "License" 42 | means this document. 43 | 44 | 1.9. "Licensable" 45 | means having the right to grant, to the maximum extent possible, 46 | whether at the time of the initial grant or subsequently, any and 47 | all of the rights conveyed by this License. 48 | 49 | 1.10. "Modifications" 50 | means any of the following: 51 | 52 | (a) any file in Source Code Form that results from an addition to, 53 | deletion from, or modification of the contents of Covered 54 | Software; or 55 | 56 | (b) any new file in Source Code Form that contains any Covered 57 | Software. 58 | 59 | 1.11. "Patent Claims" of a Contributor 60 | means any patent claim(s), including without limitation, method, 61 | process, and apparatus claims, in any patent Licensable by such 62 | Contributor that would be infringed, but for the grant of the 63 | License, by the making, using, selling, offering for sale, having 64 | made, import, or transfer of either its Contributions or its 65 | Contributor Version. 66 | 67 | 1.12. "Secondary License" 68 | means either the GNU General Public License, Version 2.0, the GNU 69 | Lesser General Public License, Version 2.1, the GNU Affero General 70 | Public License, Version 3.0, or any later versions of those 71 | licenses. 72 | 73 | 1.13. "Source Code Form" 74 | means the form of the work preferred for making modifications. 75 | 76 | 1.14. "You" (or "Your") 77 | means an individual or a legal entity exercising rights under this 78 | License. For legal entities, "You" includes any entity that 79 | controls, is controlled by, or is under common control with You. For 80 | purposes of this definition, "control" means (a) the power, direct 81 | or indirect, to cause the direction or management of such entity, 82 | whether by contract or otherwise, or (b) ownership of more than 83 | fifty percent (50%) of the outstanding shares or beneficial 84 | ownership of such entity. 85 | 86 | 2. License Grants and Conditions 87 | -------------------------------- 88 | 89 | 2.1. Grants 90 | 91 | Each Contributor hereby grants You a world-wide, royalty-free, 92 | non-exclusive license: 93 | 94 | (a) under intellectual property rights (other than patent or trademark) 95 | Licensable by such Contributor to use, reproduce, make available, 96 | modify, display, perform, distribute, and otherwise exploit its 97 | Contributions, either on an unmodified basis, with Modifications, or 98 | as part of a Larger Work; and 99 | 100 | (b) under Patent Claims of such Contributor to make, use, sell, offer 101 | for sale, have made, import, and otherwise transfer either its 102 | Contributions or its Contributor Version. 103 | 104 | 2.2. Effective Date 105 | 106 | The licenses granted in Section 2.1 with respect to any Contribution 107 | become effective for each Contribution on the date the Contributor first 108 | distributes such Contribution. 109 | 110 | 2.3. Limitations on Grant Scope 111 | 112 | The licenses granted in this Section 2 are the only rights granted under 113 | this License. No additional rights or licenses will be implied from the 114 | distribution or licensing of Covered Software under this License. 115 | Notwithstanding Section 2.1(b) above, no patent license is granted by a 116 | Contributor: 117 | 118 | (a) for any code that a Contributor has removed from Covered Software; 119 | or 120 | 121 | (b) for infringements caused by: (i) Your and any other third party's 122 | modifications of Covered Software, or (ii) the combination of its 123 | Contributions with other software (except as part of its Contributor 124 | Version); or 125 | 126 | (c) under Patent Claims infringed by Covered Software in the absence of 127 | its Contributions. 128 | 129 | This License does not grant any rights in the trademarks, service marks, 130 | or logos of any Contributor (except as may be necessary to comply with 131 | the notice requirements in Section 3.4). 132 | 133 | 2.4. Subsequent Licenses 134 | 135 | No Contributor makes additional grants as a result of Your choice to 136 | distribute the Covered Software under a subsequent version of this 137 | License (see Section 10.2) or under the terms of a Secondary License (if 138 | permitted under the terms of Section 3.3). 139 | 140 | 2.5. Representation 141 | 142 | Each Contributor represents that the Contributor believes its 143 | Contributions are its original creation(s) or it has sufficient rights 144 | to grant the rights to its Contributions conveyed by this License. 145 | 146 | 2.6. Fair Use 147 | 148 | This License is not intended to limit any rights You have under 149 | applicable copyright doctrines of fair use, fair dealing, or other 150 | equivalents. 151 | 152 | 2.7. Conditions 153 | 154 | Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted 155 | in Section 2.1. 156 | 157 | 3. Responsibilities 158 | ------------------- 159 | 160 | 3.1. Distribution of Source Form 161 | 162 | All distribution of Covered Software in Source Code Form, including any 163 | Modifications that You create or to which You contribute, must be under 164 | the terms of this License. You must inform recipients that the Source 165 | Code Form of the Covered Software is governed by the terms of this 166 | License, and how they can obtain a copy of this License. You may not 167 | attempt to alter or restrict the recipients' rights in the Source Code 168 | Form. 169 | 170 | 3.2. Distribution of Executable Form 171 | 172 | If You distribute Covered Software in Executable Form then: 173 | 174 | (a) such Covered Software must also be made available in Source Code 175 | Form, as described in Section 3.1, and You must inform recipients of 176 | the Executable Form how they can obtain a copy of such Source Code 177 | Form by reasonable means in a timely manner, at a charge no more 178 | than the cost of distribution to the recipient; and 179 | 180 | (b) You may distribute such Executable Form under the terms of this 181 | License, or sublicense it under different terms, provided that the 182 | license for the Executable Form does not attempt to limit or alter 183 | the recipients' rights in the Source Code Form under this License. 184 | 185 | 3.3. Distribution of a Larger Work 186 | 187 | You may create and distribute a Larger Work under terms of Your choice, 188 | provided that You also comply with the requirements of this License for 189 | the Covered Software. If the Larger Work is a combination of Covered 190 | Software with a work governed by one or more Secondary Licenses, and the 191 | Covered Software is not Incompatible With Secondary Licenses, this 192 | License permits You to additionally distribute such Covered Software 193 | under the terms of such Secondary License(s), so that the recipient of 194 | the Larger Work may, at their option, further distribute the Covered 195 | Software under the terms of either this License or such Secondary 196 | License(s). 197 | 198 | 3.4. Notices 199 | 200 | You may not remove or alter the substance of any license notices 201 | (including copyright notices, patent notices, disclaimers of warranty, 202 | or limitations of liability) contained within the Source Code Form of 203 | the Covered Software, except that You may alter any license notices to 204 | the extent required to remedy known factual inaccuracies. 205 | 206 | 3.5. Application of Additional Terms 207 | 208 | You may choose to offer, and to charge a fee for, warranty, support, 209 | indemnity or liability obligations to one or more recipients of Covered 210 | Software. However, You may do so only on Your own behalf, and not on 211 | behalf of any Contributor. You must make it absolutely clear that any 212 | such warranty, support, indemnity, or liability obligation is offered by 213 | You alone, and You hereby agree to indemnify every Contributor for any 214 | liability incurred by such Contributor as a result of warranty, support, 215 | indemnity or liability terms You offer. You may include additional 216 | disclaimers of warranty and limitations of liability specific to any 217 | jurisdiction. 218 | 219 | 4. Inability to Comply Due to Statute or Regulation 220 | --------------------------------------------------- 221 | 222 | If it is impossible for You to comply with any of the terms of this 223 | License with respect to some or all of the Covered Software due to 224 | statute, judicial order, or regulation then You must: (a) comply with 225 | the terms of this License to the maximum extent possible; and (b) 226 | describe the limitations and the code they affect. Such description must 227 | be placed in a text file included with all distributions of the Covered 228 | Software under this License. Except to the extent prohibited by statute 229 | or regulation, such description must be sufficiently detailed for a 230 | recipient of ordinary skill to be able to understand it. 231 | 232 | 5. Termination 233 | -------------- 234 | 235 | 5.1. The rights granted under this License will terminate automatically 236 | if You fail to comply with any of its terms. However, if You become 237 | compliant, then the rights granted under this License from a particular 238 | Contributor are reinstated (a) provisionally, unless and until such 239 | Contributor explicitly and finally terminates Your grants, and (b) on an 240 | ongoing basis, if such Contributor fails to notify You of the 241 | non-compliance by some reasonable means prior to 60 days after You have 242 | come back into compliance. Moreover, Your grants from a particular 243 | Contributor are reinstated on an ongoing basis if such Contributor 244 | notifies You of the non-compliance by some reasonable means, this is the 245 | first time You have received notice of non-compliance with this License 246 | from such Contributor, and You become compliant prior to 30 days after 247 | Your receipt of the notice. 248 | 249 | 5.2. If You initiate litigation against any entity by asserting a patent 250 | infringement claim (excluding declaratory judgment actions, 251 | counter-claims, and cross-claims) alleging that a Contributor Version 252 | directly or indirectly infringes any patent, then the rights granted to 253 | You by any and all Contributors for the Covered Software under Section 254 | 2.1 of this License shall terminate. 255 | 256 | 5.3. In the event of termination under Sections 5.1 or 5.2 above, all 257 | end user license agreements (excluding distributors and resellers) which 258 | have been validly granted by You or Your distributors under this License 259 | prior to termination shall survive termination. 260 | 261 | ************************************************************************ 262 | * * 263 | * 6. Disclaimer of Warranty * 264 | * ------------------------- * 265 | * * 266 | * Covered Software is provided under this License on an "as is" * 267 | * basis, without warranty of any kind, either expressed, implied, or * 268 | * statutory, including, without limitation, warranties that the * 269 | * Covered Software is free of defects, merchantable, fit for a * 270 | * particular purpose or non-infringing. The entire risk as to the * 271 | * quality and performance of the Covered Software is with You. * 272 | * Should any Covered Software prove defective in any respect, You * 273 | * (not any Contributor) assume the cost of any necessary servicing, * 274 | * repair, or correction. This disclaimer of warranty constitutes an * 275 | * essential part of this License. No use of any Covered Software is * 276 | * authorized under this License except under this disclaimer. * 277 | * * 278 | ************************************************************************ 279 | 280 | ************************************************************************ 281 | * * 282 | * 7. Limitation of Liability * 283 | * -------------------------- * 284 | * * 285 | * Under no circumstances and under no legal theory, whether tort * 286 | * (including negligence), contract, or otherwise, shall any * 287 | * Contributor, or anyone who distributes Covered Software as * 288 | * permitted above, be liable to You for any direct, indirect, * 289 | * special, incidental, or consequential damages of any character * 290 | * including, without limitation, damages for lost profits, loss of * 291 | * goodwill, work stoppage, computer failure or malfunction, or any * 292 | * and all other commercial damages or losses, even if such party * 293 | * shall have been informed of the possibility of such damages. This * 294 | * limitation of liability shall not apply to liability for death or * 295 | * personal injury resulting from such party's negligence to the * 296 | * extent applicable law prohibits such limitation. Some * 297 | * jurisdictions do not allow the exclusion or limitation of * 298 | * incidental or consequential damages, so this exclusion and * 299 | * limitation may not apply to You. * 300 | * * 301 | ************************************************************************ 302 | 303 | 8. Litigation 304 | ------------- 305 | 306 | Any litigation relating to this License may be brought only in the 307 | courts of a jurisdiction where the defendant maintains its principal 308 | place of business and such litigation shall be governed by laws of that 309 | jurisdiction, without reference to its conflict-of-law provisions. 310 | Nothing in this Section shall prevent a party's ability to bring 311 | cross-claims or counter-claims. 312 | 313 | 9. Miscellaneous 314 | ---------------- 315 | 316 | This License represents the complete agreement concerning the subject 317 | matter hereof. If any provision of this License is held to be 318 | unenforceable, such provision shall be reformed only to the extent 319 | necessary to make it enforceable. Any law or regulation which provides 320 | that the language of a contract shall be construed against the drafter 321 | shall not be used to construe this License against a Contributor. 322 | 323 | 10. Versions of the License 324 | --------------------------- 325 | 326 | 10.1. New Versions 327 | 328 | Mozilla Foundation is the license steward. Except as provided in Section 329 | 10.3, no one other than the license steward has the right to modify or 330 | publish new versions of this License. Each version will be given a 331 | distinguishing version number. 332 | 333 | 10.2. Effect of New Versions 334 | 335 | You may distribute the Covered Software under the terms of the version 336 | of the License under which You originally received the Covered Software, 337 | or under the terms of any subsequent version published by the license 338 | steward. 339 | 340 | 10.3. Modified Versions 341 | 342 | If you create software not governed by this License, and you want to 343 | create a new license for such software, you may create and use a 344 | modified version of this License if you rename the license and remove 345 | any references to the name of the license steward (except to note that 346 | such modified license differs from this License). 347 | 348 | 10.4. Distributing Source Code Form that is Incompatible With Secondary 349 | Licenses 350 | 351 | If You choose to distribute Source Code Form that is Incompatible With 352 | Secondary Licenses under the terms of this version of the License, the 353 | notice described in Exhibit B of this License must be attached. 354 | 355 | Exhibit A - Source Code Form License Notice 356 | ------------------------------------------- 357 | 358 | This Source Code Form is subject to the terms of the Mozilla Public 359 | License, v. 2.0. If a copy of the MPL was not distributed with this 360 | file, You can obtain one at http://mozilla.org/MPL/2.0/. 361 | 362 | If it is not possible or desirable to put the notice in a particular 363 | file, then You may include the notice in a location (such as a LICENSE 364 | file in a relevant directory) where a recipient would be likely to look 365 | for such a notice. 366 | 367 | You may add additional accurate notices of copyright ownership. 368 | 369 | Exhibit B - "Incompatible With Secondary Licenses" Notice 370 | --------------------------------------------------------- 371 | 372 | This Source Code Form is "Incompatible With Secondary Licenses", as 373 | defined by the Mozilla Public License, v. 2.0. 374 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # ADPC 2 | Advanced Data Protection Control (or ADPC) is an automated mechanism for the communication of users’ privacy decisions and data controllers' responses. It aims to empower users to protect their online privacy in a human-centric and enforceable manner. It also helps online publishers and service providers to comply with the data protection and consumer protection regulations. 3 | 4 | The ADPC spec defines a method for expressing user decisions about personal data processing under the European Union’s data protection regulations, and similar regulations outside the EU. Currently, ADPC functions through the exchange of HTTP headers between the user agent and the web server, or through an equivalent JavaScript interface. 5 | 6 | The mechanism serves as an automated means for users to give or refuse consent, to withdraw any consent already given, and object to processing based on legitimate interest. ADPC is an alternative to existing non-automated consent management approaches (e.g. ‘cookie banners’) which aims to reduce the overheads of the different parties involved in the protection of users privacy equation. 7 | 8 | You can find more information about ADPC on our website: [https://www.dataprotectioncontrol.org](https://www.dataprotectioncontrol.org) 9 | -------------------------------------------------------------------------------- /consent popup mockup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Data-Protection-Control/ADPC/af94fe2ac9f624b0ca65431914ae8ae638402db4/consent popup mockup.png -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Advanced Data Protection Control (ADPC) 6 | 11 | 65 | 71 | 72 | 73 |
74 |

75 | 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. 76 |

77 |

78 | 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. 79 |

80 |
81 | 82 | 83 | 84 |
85 |

Introduction

86 |

87 | 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. 88 |

89 |

90 | 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. 91 |

92 |

93 | 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: 94 |

95 | 109 |

110 | Despite various legal provisions suggesting its validity, a standardised means for communicating GDPR rights has thus far been lacking. 111 |

112 |

113 | 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. 114 |

115 |
116 | 117 | 118 | 119 |
120 |

Technical overview

121 |

122 | 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: 123 |

124 |
    125 |
  1. 126 | Between the website back-end, i.e. a web server, and the user agent; by means of an HTTP `Link` header (or an equivalent HTML `<link>`) pointing to a JSON file, and the `ADPC` header. 127 |
    2. 128 |
  2. 129 | Between the website front-end, i.e. a web page, and the user agent; by means of a JavaScript interface. 130 |
    3. 131 |
132 |

133 | 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. 134 |

135 |

136 | 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(…)`. 137 |

138 |

139 | 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. 140 |

141 |

142 | In the subsequent sections, the communication protocol is defined in detail. First come examples ([[[#examples]]]) and relevant definitions ([[[#definitions]]]). Then [[[#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 ([[[#http-interaction]]]) or JavaScript-based ([[[#javascript-interaction]]]) approach. 143 |

144 |
145 | 146 | 147 | 148 |
149 |

Example

150 | 199 |
200 | 201 | 202 | 203 |
204 |

Definitions

205 |

206 | 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: 207 |

208 |
209 |
user
210 |
211 |

212 | The person visiting or interacting with the website. 213 |

214 |

215 | 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. 216 |

217 | 222 |
223 |
user agent
224 |
225 | Any software that retrieves, renders and facilitates end-user interaction with web content. The user may communicate with the controller via the user agent. The term is used interchangeably with “browser”. 226 |
227 |
controller
228 |
229 |

230 | 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. 231 |

232 |

233 | 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. 234 |

235 |
236 |
website
237 |
238 | The information society service through which the user interacts with a controller. The controller may communicate with the user via the website. A website is delineated by its URL, where any URLs whose [=origins=] are [=schemelessly same site=] are understood as belonging to the same website. 239 | 244 | 249 |
250 |
251 |
252 | 253 | 254 | 255 |
256 |

Scope

257 |
258 |

Personal scope

259 |

260 | 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. 261 |

262 |

263 | 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. 264 |

265 | 273 |
274 |
275 |

Material scope

276 |

277 | 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). 278 |

279 | 284 |
285 |
286 |

Territorial scope

287 |

288 | 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. 289 |

290 | 295 |
296 |
297 | 298 | 299 | 300 |
301 |

Signals

302 |

303 | 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. 304 |

305 |
306 |

Requesting consent

307 |

308 | 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=]. 309 |

310 |

311 | 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: 312 |

313 |
314 |
text
315 |
316 |

317 | 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. 318 |

319 | 324 |
325 |
id
326 |
327 |

328 | 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. 329 |

330 |

331 | 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). 332 |

333 |
334 |
335 | 340 | 360 |

361 | A standardised consent request is a [=consent request=] whose [=request identifier=] is a [[URI|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. 362 |

363 | 368 | 393 |

394 | 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. 395 |

396 |

397 | 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. 398 |

399 |

400 | 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. 401 |

402 |

403 | 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. 404 |

405 | 410 |
411 |
412 |

Giving consent

413 |

414 | To give consent to zero or more specific processing purposes, the user agent presents the website with a list of the corresponding identifiers. 415 |

416 | 427 |

428 | 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. 429 |

430 |
431 |
432 |

Withdrawing consent

433 |

434 | The user may withdraw consent that was previously given; the consent is represented by the identifier that was used to request it. 435 |

436 |

437 | 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. 438 |

439 | 456 |

457 | 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. 458 |

459 |
460 |
461 |

Objecting to processing

462 |

463 | The user may object to processing of their personal data as provided for under Article 21 GDPR. Objection involves passing the appropriate [=objection identifier=]. 464 |

465 |

466 | 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. 467 |

468 | 473 | 481 |
482 |
483 |

Combining signals

484 |

485 | 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. 486 |

487 |

488 | When signals are combined, specific signals (such as [=give consent|giving consent=] for specific processing purposes) SHALL prevail over more general signals (such as [=withdraw all consent|withdrawing all consent=]). 489 |

490 | 501 |
502 |
503 | 504 | 505 | 506 |
507 |

HTTP-based interaction

508 |

509 | 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. 510 |

511 | 516 |
517 | 518 |

519 | 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: 520 |

521 |
522 |
consentRequests
523 |
524 | A [=consent requests list=]. 525 |
526 |
527 | 543 |

544 | To [=request consent=], the website points to such a [=consent requests resource=] using the HTTP `Link` header, with the relation type `consent-requests`. 545 |

546 | 556 |

557 | 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. 558 |

559 | 568 | 573 | 604 |

605 | 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. 606 |

607 |
608 |

Making zero requests

609 |

610 | 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. 611 |

612 |

613 | Instead of presenting a consent requests resource without consent requests, a website SHOULD therefore link to the special target `about:blank`. 614 |

615 | 625 |
626 |
627 |
628 | 629 |

630 | 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. 631 |

632 |

633 | 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. 634 |

635 |

636 | 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). 637 |

638 |

639 | 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. 640 |

641 | 651 | 661 |

662 | To [=withdraw all consent=], the special value `*` can be used in place of an identifier. 663 |

664 | 682 |

683 | 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. 684 |

685 | 695 |
696 |
697 |

Objecting to processing

698 |

699 | 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. 700 |

701 | 719 |
720 |
721 | 722 | 723 | 724 |
725 |

JavaScript-based interaction

726 |

727 | While the HTTP signalling approach can be sufficient, there are several reasons why a website may prefer to communicate in other ways. For example: 728 |

729 | 734 | 745 |
746 | 747 |

748 | To [=request consent=] for zero or more processing purposes, a website’s scripts can invoke the {{dataProtectionControl/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. 749 |

750 |

751 | 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 {{dataProtectionControl/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=]. 752 |

753 | 775 |
776 |
777 |

Giving and withdrawing consent, and objecting to processing

778 |

779 | To signal user decisions to the website, the user agent passes the appropriate values in the return value of the {{dataProtectionControl/request()}} function. The return value is a {{Promise}} that resolves with a [=user decisions object=]. 780 |

781 |

782 | 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=]. 783 |

784 |

785 | A user decisions object is a JavaScript object, the members of which signal the user’s decisions to the website. Each member is optional: 786 |

787 |
788 |
consent
789 |
790 | An array containing any [=request identifiers=] for which the user [=give consent|gives consent=]. 791 |
792 |
withdraw
793 |
794 | An array containing any [=request identifiers=] for which the user [=withdraw consent|withdraws consent=], and/or possibly containing the string `"*"` to [=withdraw all consent=]. 795 |
796 |
object
797 |
798 | An array containing any [=objection identifiers=] that indicate the user [=objects to processing of their personal data=]. 799 |
800 |
801 | 811 |

812 | 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 {{dataProtectionControl/request()}}, as well as listen to the `decisionchange` event, in order to ensure it becomes aware of a user’s decisions. 813 |

814 | 826 |
827 |
828 |

Interface definition

829 | 
 830 |           [Exposed=Navigator]
 831 |           interface DataProtectionControl : EventTarget {
 832 |             Promise<UserDecisionsObject> request(object consentRequestsList);
 833 |           };
 834 | 
 835 |           [Exposed=DataProtectionControl]
 836 |           interface AdpcEvent {
 837 |             readonly attribute UserDecisionsObject userDecisions;
 838 |           };
 839 | 
 840 |           [Exposed=DataProtectionControl]
 841 |           interface UserDecisionsObject {
 842 |             readonly attribute DOMStringList? consent;
 843 |             readonly attribute DOMStringList? withdraw;
 844 |             readonly attribute DOMStringList? _object;
 845 |           };
 846 | 
 847 |           partial interface Navigator {
 848 |             [SameObject] readonly attribute DataProtectionControl dataProtectionControl;
 849 |           };
 850 |
851 |

852 | The dataProtectionControl interface enables a web page to request consent from the user and learn about their data protection decisions. 853 |

854 |

855 | The request() method can be used to [=request consent=], as described in [[[#requesting-consent-js]]]. 856 |

857 | 862 | 870 |
871 |
872 | 968 |
969 |

Compatibility considerations

970 |

971 | 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. 972 |

973 |

974 | 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 [[?tracking-dnt|DNT]] or Sec-GPC HTTP header), any non-contradicting communication can be interpreted in combination 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. 975 |

976 |
977 |
978 |

Privacy considerations

979 |

980 | 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. 981 |

982 |
983 |

Privacy impact in case of compliant websites

984 |

985 | 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: 986 |

987 | 1001 |
1002 |
1003 |

Privacy impact in case of non-compliant websites

1004 |

1005 | 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. 1006 |

1007 |
1008 |

Misplaced trust

1009 |

1010 | First of all, this mechanism cannot prevent websites from giving false or incomplete information, or simply disrespecting the user’s decisions. A false pretence 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. 1011 |

1012 |
1013 |
1014 |

Tracking

1015 |

1016 | 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. 1017 |

1018 |

1019 | 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. 1020 |

1021 |

1022 | 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, forty consent requests, users are unlikely to make forty independent decisions: rejecting or accepting all requests at once is a common response. 1023 |

1024 |

1025 | 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. 1026 |

1027 |

1028 | 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 anonymity. 1029 |

1030 |
1031 |
1032 |

Third-party scripts

1033 |

1034 | 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 [[[?CSP2]]] and [[[?SRI]]], can somewhat reduce the risk of including third-party scripts. 1035 |

1036 |
1037 |
1038 |
1039 |

User agent’s role in data protection

1040 |

1041 | 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. 1042 |

1043 |

1044 | 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. 1045 |

1046 |

1047 | 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. 1048 |

1049 |
1050 |
1051 |
1052 |
1053 |

Acknowledgements

1054 |

1055 | 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. 1056 |

1057 |

1058 | This work is partially supported by the Internet Foundation Austria (IPA) within the NetIdee call (RESPECTeD Project; Grant#prj4625). 1059 |

1060 |
1061 | 1062 | 1063 | --------------------------------------------------------------------------------