The European Union’s General Data Protection Regulation (GDPR), passed in 2018, requires websites to ask visitors for consent prior to placing cookies. As any Internet user is now aware, this means an extra step required when visiting nearly any website for the first time—or potentially every time, if you choose not to accept cookies. A new proposed HTTP standard from None of Your Business and the Sustainable Computing Lab would allow the user to set their privacy preferences once, inside the browser itself, and have the browser communicate those preferences invisibly with any website the user visits.

Advanced Data Protection Control

The proposed standard enables two methods of automated preference delivery—one which communicates directly with the web server hosting a site being visited, and another which communicates with the website itself.

When ADPC communicates directly with the web server, it does so via HTTP headers—a Link header pointing to a JSON file on the server, and the ADPC header emitted by the user’s browser. When communicating with the website itself, the mechanism is via JavaScript— configuration is passed as an object to the DOM interface, e.g., navigator.dataProtectionControl.request(...).

In either case, the user’s privacy preferences are communicated to the website or server as a list of request identifiers they consent to. This list is sent in ADPC headers for the HTTP-based approach and as the final return value of the DOM interface in the JavaScript approach.

Although both mechanisms accomplish the same goal in similar fashions, there are plenty of reasons to support both. The HTTP-based approach is probably more efficient—but it obviously would require new versions of web server applications which explicitly support it (or at least, new pluggable modules in the case of servers like Apache which support them). Meanwhile, the JavaScript-based mechanism works without any special web server configuration necessary—but it won’t work for users who refuse to enable JavaScript.

Consent requests resource

A JSON file is at the heart of the website’s end of ADPC, whether using HTTP or Javascript mechanisms to reach it. That consent file will look something like this:

{
  "consentRequests": {
    "cookies": "Store and/or access cookies on your device.",
    "ads_profiling": "Create a personalised ads profile."
  }
}

In HTTP-based ADPC, the webserver links to the consent file directly in its response to an HTTP GET:

HTTP/1.1 200 OK
Link: </consent-request-resource.json>; rel="consent-requests"

When the web browser detects this link, it can either respond with previously user-configured settings or request an answer from the user via a pop-up dialog (most likely, one spawned from the browser’s lock button). Once the user has set their preferences accordingly, the browser includes an ADPC header on future HTTP GET requests:

GET /page.htm HTTP/1.1
Host: website.tld
ADPC: withdraw=*, consent=cookies

In the above example, we see a configuration similar to what one might see on a network firewall: a default DENY in the form of withdraw=*, overridden by a specific acceptance of cookies. So for our website which wanted both to set cookies and create an advertising profile, the cookie request is granted (allowing storage of, e.g., user authentication and personal settings), but advertising profile is denied.

Another benefit of the ADPC scheme is that the user is interacting with their own browser, with consistent UI regardless of website. Another benefit is that it’s possible for the user to set persistent preferences for a site without needing to allow cookies—something which isn’t possible for a website which must ask for consent via a banner embedded in the webpage itself.

Finally, cookie banners may frequently not be displayed at all—in our testing, popular ad-blocking plugins blocked the display of many cookie banners, including but not limited to The Guardian‘s. Such blocking can be due to collateral damage caused by overly aggressive block rules or deliberate attempts to minimize “click fatigue.” In either case, they prevent the user from directly expressing consent or refusal to privacy-related issues.

Request, not command

It’s important to realize that ADPC is not a mechanism for enforcing a user’s privacy profile—it’s simply a normalized way of requesting it in compliance with the European Union’s GDPR and similar privacy laws elsewhere.

Nothing technically prevents a hypothetical ADPC-compliant website from requesting permission to create an advertising profile for a user, being denied, and then creating that profile anyway. But legitimate sites can request consent in a more machine-readable, consistent, and less user-fatiguing way.

ADPC does still assist users in dealing with shady sites that ignore their users’ preferences—in the event of a GDPR or other lawsuit, users’ preferences are more likely to be logged and readable from their own systems. If a user refuses to accept any cookies via a cookie banner, their expressed preference cannot be saved and logged—but ADPC preferences will be.

Even if a user interacting with a cookie banner accepts cookies (but disables ad profiling), that cookie is much more likely to be mistakenly “cleaned” by the user themselves. That “cleaning” could be in the quest to maintain privacy or even fix problems with frequently visited websites. Since ADPC preferences are only good for that one thing—expressing or refusing consent on privacy issues—there is much less reason for them to be destroyed.

Listing image by Rdsmith4 / Wikimedia