-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Notify changes to consent signal #6
Comments
I think the ID is a no-no because tracking, but the changed flag is a good idea. |
I agree with the proposal and discussion (and also that IDs are problematic for tracking). However, I'm not clear whether Since the ADPC does not transmit an identifier, the indication would be that it relies on the website to collect and handle that identity/identifier. For example, |
The server can always see what this user has agreed to, if anything, in the ADPC header, which it receives in every HTTP request. |
Yes, the server can see the preferences in the request contents, but not who has set those preferences. So if a preference is changed (assume withdraw or permission set to prohibition), how will the server/website/controller interpret it and decide which user's data processing must be stopped? So I disagree that all state needed is in the header, since the header (or request contents) do not contain an identifier. So how does the server understand which user has given that preference or changed it? The request ids may themselves also be used as identifiers for the user, but this is not a feasible solution, e.g. when using standardised request ids. See Issue #3 for this discussion regarding tracking using ids. |
All an internet protocol knows about are endpoints, The person using an endpoint has to be inferred, how else would you do it? |
On subject IDs - server-side consent managers like Signatu must map a HTTP request to a subject ID in order to store the consent event and enable retrieval of the event later, e.g., on other devices or other browser sessions. So if we're not getting an ID with the ADPC header we will need to get it from somewhere else, e.g., a cookie. If the user agent and server handles subject IDs is outside of the ADPC spec, and we'll probably get a lot of different approaches for keeping track of a subject ID, and new creative forms of tracking. For example - in the Incognito case, or where the user has explicitly said "do not track" - I assume the header will be something like If instead we add a subject and a receipt ID to the headers we can e.g., signal that we don't want any persistence like The interaction would be something like this:
This can be used for tracking #3 of course, but so could any cookie set on the site origin domain. This approach makes subject ID handling explicitly defined under ADPC. So how do we prevent the ADPC header to be misused for tracking? It will never be fool-proof, but I guess we can:
So in summary, I'm looking for a way to explicitly deal with a) the subject ID, and b) giving the user agent a receipt ID that indicates that the signal has been registered for the subject ID. The user agent could allow the user later to review their consent receipts, and revoke permissions in a user agent dashboard and so on. What the subject ID should be is up to the user agent and/or the client side code - we can imagine user agents assigning new IDs regularly based on user preference, for example. These are not fully formed thoughts and I'm sure there are many issues with the proposed approach above. |
If the consent request were stored in a well-known location #9 then the browser can check the cache and look for updates. (If the Last-Modified date is newer than the last consent withdrawn/accepted date, then it's been updated and the UA can notify the user.) |
Storing consent requests in |
For the sake of transparency consent request text strings should be viewable by all. Not only should they be restricted to a .well-known location, the browser should strip Cookie headers from the HTTP request. |
Making consent strings user-dependent opens it up for misuse, e.g. #3. |
Thanks for opening this discussion. It is good to hear the views from implementers of consent management software, as you may valid practical issues that we might have overlooked. To the original question:
Some thoughts that pop up (not fully well-formed either; apologies for this unstructured and inconclusive rain of bullet points):
|
I that explicit checks for every HTTP request are not feasible. As I've noted in #9, adding ADPC headers in the requests and responses will increase the size of requests/responses. Web pages often include many embedded resources (images and other media, scripts, stylesheets) so this can easily add a few hundred bytes to each request. For users on mobile networks, or with slow internet connections, or even busy/overloaded networks, this is a real performance concern. Likewise, processing ADPC headers can affect performance. Adding a few milliseconds of processing time for pages adds up to an extra second of processing for a few hundred pages. Speed performance affects not just SEO but (perhaps more importantly) cost for cloud services where processing time and network bandwidth are metered. If you want developers to use the protocol, then you need to consider ways to streamline the protocol so that
|
Happy to see ADPC - this is the right direction to go.
At Signatu we are developing and operating a consent platform for registering consent events from users and storing them in a immutable store (for e.g., audits, notifications to 3rd party systems, etc). This complements nicely the approach you are taking with ADPC.
However, since the signals are sent with every HTTP request, we need to store some state server side in order to determine whether we need to register changes to the user's choices. We could just set a cookie, of course, but I feel the ADPC should deal with this case explicitly. Explicit checks for each HTTP call is not going to be feasible.
A couple of approaches that come to mind:
changed
flag in theADPC
header so the server will get a hint when it needs to persist changes, e.g.,ADPC: withdraw=*, object=direct-marketing, changed=1
Any thoughts on this use case?
The text was updated successfully, but these errors were encountered: