A new HTTP specification proposes to remove obnoxious “cookie banners”. | GeekComparison

The European Union’s General Data Protection Regulation (GDPR), passed in 2018, requires websites to ask visitors for consent before placing cookies. As any internet user now knows, this means an extra step required when you first visit almost any website – or possibly each 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 oncein the browser itself, and allows the browser to communicate these preferences invisibly with every website the user visits.

Advanced data protection control

The proposed standard allows for two methods of automatic preferences delivery: one that communicates directly with the web server hosting a visited site, and another that communicates with the website itself.

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

In both cases, the user’s privacy preferences are communicated to the website or server as a list of request IDs that they agree to. This list is sent in ADPC headers for the HTTP based approach and as the final return value from the DOM interface in the JavaScript approach.

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

Permission asks for source

A JSON file is at the heart of the website’s ADPC end, whether it’s HTTP or JavaScript mechanisms to reach it. That permission file looks 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 web server links directly to the consent file 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 may respond with settings previously configured by the user or prompt the user for a response via a pop-up window (most likely coming from the browser’s lock button). Once the user has set their preferences accordingly, the browser adds an ADPC header to future HTTP GET requests:

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

In the example above, we see a configuration similar to what one might see on a network firewall: a standard DENY in the form of withdraw=*canceled by a specific acceptance of cookies. So for our website that wanted to both set cookies and create an ad profile, the cookie request is granted (allowing for example to save user authentication and personalization), but the ad profile is rejected.

Another advantage of the ADPC scheme is that the user interacts with their own browser, with a consistent user interface regardless of the website. Another advantage is that it is possible for the user to set permanent preferences for a site without allowing cookies – something that is not possible for a website that has to ask for permission via a banner embedded in the web page itself included.

Finally, cookie banners are often not displayed at all. During our testing, popular ad-blocking plugins blocked the display of many cookie banners, including but not limited to The Guardian’s. Such blocking may be due to collateral damage caused by overly aggressive blocking rules or deliberate attempts to minimize “click fatigue”. In both cases, they prevent the user from expressing consent or denial directly to privacy-related issues.

Request, not command

It is important to realize that ADPC is not a mechanism to enforce a user’s privacy profile – it is simply a normalized way of requesting it in accordance 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 permission in a more machine-readable, consistent, and less tiring way for the user.

ADPC still helps users deal with shady sites that ignore their users’ preferences – in the event of a GDPR or other lawsuit, users’ preferences are more likely to be captured and readable from their own systems. If a user declines cookies via a cookie banner, their stated preference cannot be saved and recorded, but ADPC preferences can.

Even if a user interacting with a cookie banner accepts cookies (but disables ad profiling), it is much more likely that that cookie will be accidentally “cleaned” by the user themselves. That “cleaning” could be in the quest to preserve privacy or even fix problems with high traffic websites. Since ADPC preferences are only good for one thing – giving or denying consent for privacy issues – there is much less reason to destroy them.

List image by Rdsmith4/Wikimedia