Consider putting the file in /.well-known/consent-requests.json #9
Comments
|
Yes, a |
|
Wouldn't this be better declared in the webpage metadata? E.g. as Example 13 <!doctype html>
<html>
<head>
<link href="/our-consent-requests.json" rel="consent-requests" />
… |
Not every document is a web-page, e.g. images. There might even be a separate web server that serves images, or a CDN that servers scripts and stylesheets, such as jQuery. The well-known URL could be linked to from web page HTTP response headers. But it won't need to be. |
|
Also note in Section 7.1.1 (Making zero requests), the lack of a file at this location indicates that the website is not asking for consent. |
|
Well-known URI is specified in RFC 5785. This mechanism is much better suited for this than requiring every website to advertise a Link response header.
Replying with an empty file at a well-known location, or replying with HTTP 204 No Content would fulfill the same purpose. |
Also replying with 404 (Not Found). |
No, that is a very clear signal that the server doesn’t understand or support the protocol. |
Which would signal that the website is not asking consent. |
“I’m not asking consent for anything because I don’t do anything that requires me to ask for it” is not the same as “I don’t understand – here’s a generic error.” |
A |
|
To the discussion above: we indeed thought it would be good if websites have a way to show they support the protocol, even when not requesting any consent. To the original question, whether to use Link header or well-known file, we have considered both options, but ended up with the link header for multiple reasons:
|
The website doesn't initiate interaction. The user agent does. Requiring the website to include a link has several problems:
|
|
I like the .well-known approach, as in the end it will only affect clients which really want to do consent management.
So there is only one case where the .well-known file needs to be requested before the page is requested:
Client´s without consent management won´t have the additional overhead of an extra header or a <link meta.. HTML tag |
|
First, to @robrwo’s earlier points above:
Firstly, one can also use the equivalent
Indeed. But note that most websites already use a plugin or third-party Consent Management Platform (CMP) to ask for consent and handle the responses. Presumably those would be the first to implement the ADPC protocol, and that seems an acceptable adoption path. In any case, this seems independent of the
I will comment on overhead issues separately, below. |
|
To some specific points by @Spacefish above:
I hope you meant “disabled”; otherwise we should start again from the problem description: the situation is that websites need to ask a user’s consent before they can legally ‘track’ them. (using ‘tracking’ as shorthand for any personal data processing for which they use consent as the legal basis)
Adding an extra round-trip before visiting a website sounds like something nobody is waiting for. The |
|
And overall to the above discussion: I appreciate concerns about reducing overhead; the “website obesity crisis” is still rampant, with megabytes of data being transferred from servers to clients needlessly. A link header/tag is perhaps just a hundred bytes, but I agree we still should not add a hundred bytes to every web transaction without good reason. We should especially not force such an overhead on otherwise efficient websites that weigh just a few kilobytes. However there seem to be some misconceptions and misguided comparisons here. Firstly, a website does not have to add this link if it does not want to ask for consent to anything; and if does want to ask for consent, adding one link is a lot more efficient than the currently used alternative: adding html, javascript and css for a consent banner, which easily adds tens or hundreds of kilobytes (if anyone has measurements, feel free to share). Presumably websites supporting ADPC will still want to add this in-page banner as a fall-back, but adding this one link seems insignificant in comparison. As the website can avoid loading this in-page banner for clients that support ADPC, this could in fact be a huge win in reducing overhead. Moreover, the In any case, thinking from the perspective that “users want to be asked for consent” seems unhelpful. Usually websites want to ask users for consent more than vice versa, and if it is not through ADPC they will use other ways to do so. I will keep this issue open, because using a |
Most? No, a lot of websites implement something for GDPR etc but that doesn't mean they are using a plugin for it. |
It isn't really an "extra round trip". HTTP/1.1 and later support using a single connection for multiple requests, which reduces most of the overhead. And that will more than make up for sending an extra link (either as a header or embedded in HTML) for every request. (Also note that embedding a link in HTML is useless for non-HTML documents.)
No, because websites will still need to support the banners until almost all users have upgraded to browsers that supports this. And that will take years. (I still have 1-3% of users on a site I maintain that use very old web browsers. For whatever reason, users are unable or unwilling to upgrade.)
A majority of users are for most websites are using mobile devices, and a significant portion of them are on mobile networks or from countries with poor internet connectivity. That hundred bytes is enough to force a page to take an extra packet which means a longer delay to displaying the page. |
Adding a Link header to HTTP responses can add 100-200 bytes for each response, which can affect users on slower mobile connections.
Most users will likely choose an option when they first visit a website and not need to care to see this again, so there's no reason to send the header. (Conditionally sending the header when the consent metadata has changed or the user has not responded involves tracking the user, which the user may not have consented for.)
It makes more sense for a user agent to request a well-known file if it does not have consent configuration for a site.
The text was updated successfully, but these errors were encountered: