Website user level consent management framework (logged in users)

[carike]

Background:

The Consent API is an initiative that is currently underway in the Privacy team.
The code is available in the plugin repository here: ​https://wordpress.org/plugins/wp-consent-api/
The Feature Plugin proposal is here: ​https://make.wordpress.org/core/2020/04/01/feature-plugin-proposal-wp-consent-api/
While there has been a strong consensus for a long time that a consent management framework is necessary in Core, the Team is still building consensus on what the implementation should look like.
One of the disagreements with the proposed feature plugin implementation, is that consent choices made by website users are not going to be reliably available if they are saved in a cookie, because the cookie may expire, or more likely, be cleared.
While this is an inherent limitation for users who are not logged in, it is not necessary to subject registered users who are logged in to notice fatigue.
More information here: ​https://make.wordpress.org/core/2020/08/22/request-for-input-consent-preferences-for-logged-in-users-consent-api/
In short, it is possible to save the registered users' consent choices in the database.

The Challenge:

Cookies are inherently transient in nature.
In order to make consent choices persistent, user consent choices need to be saved in the database.
This is only possible for users who are registered and logged in.

The Scope:
This ticket represents a milestone for Website User Level Consent Management.

List of milestones:

This ticket seeks to answer the following design questions:

<?php
1. Which consent categories should be available by default?
2. Should plugins be able to add additional consent categories?
3. If yes to the above, should these be new top-level consent categories, 
or sub consent categories, or a nested hierarchy of both?

It does this by dealing only with the user meta value that is needed to save privacy choices for registered users. Users who are not logged in, or who are not registered, need to be dealt with differently and will be addressed in other tickets.
This ticket only proposes a nested hierarchy and does not explore the necessary validation / sanitization to add consent types, or escaping the output.

[] will be created to create a hook to allow for the logging of consent by plugins.
#51110 proposes a registered website user-level privacy UI.

The Solution:

In its current form the Consent API plugin (proposed feature plugin) allows for these five consent categories:

1. Functional;
2. Preferences;
3. Anonymous Statistics;
4. Statistics;
5. Marketing.

Adding too many consent types would make it unwieldy and unnecessarily complicated for website visitors.
However, there are certainly use cases in which site owners / admins may need more granular control.
One of the WordPress Core Coding Philosophies is extendibility.
We should not limit the usefulness of this long anticipated Core feature / benefit only a handful of plugins.

It seems that the best way to do this would be to provide a function in Core that would allow plugins to register sub-consent types.

It seems desirable to let site owners / admins determine default consent values - or to install a plugin to do so, for example, based on the visitor's location and the site's host's location.

It does not seem desirable to create a consent meta value for the user as soon as the user is created - instead, a consent user meta value should only be created once the registered user has explicitly indicated their choice.
This would avoid the need for expensive database upgrades.
The Website User Level Consent Manager would fall back to site defaults if no meta value exists for the user.

It should be possible to create a hook that would allow for the logging of changes in consent (i.e. when the consent user_meta value is updated).

It does not seem desirable to save multiple user_meta values relating to consent per user, for performance reasons.
A possible model might look something like the meta value for user capabilities.

Example 1:

The website offers a newsletter, but also wants user permission for third party targeted advertising on the website. The site owner does not want to exclude everyone who opts out of the latter from receiving their newsletter.
The website offers notifications. The site owner / admin does not wish to exclude someone from setting their preferred admin colour scheme if they do not wish to consent to notifications.

<?php
$consents = array(
   'functional' => array(
      'comprehensive' => true,
      'remainder' => true
   ),
   'preferences' => array(
      'comprehensive' => false,
      'notifications' => array(
         'all' => false,
         'daily' => false,
         'weekly' => true,
         'monthly' => false,
         'none' => false,
      ),
      'remainder' => true
   ),
   'anon_stats' => array(
      'comprehensive' => true,
      'remainder' => true
   ),
   'stats' => array(
      'comprehensive' => false,
      'remainder' => false
   ),
   'marketing' => array(
      'comprehensive' => false,
      'newsletter' => true,
      'targeted_ads' => false,
      'remainder' => true
   )
);

The above should be appropriately serialized before being saved to the database.

Example 2:

This shows a use case for which one additional top-level consent type (not exposed to the front end, only available on /wp-admin/) would be very useful.
Plugin authors are currently allowed to advertise / provide notices, as long as they don't hijack the admin panel.
One of the most common ways to permanently dismiss a notice is to add a user_meta value for it - which isn't the best use of the database / ideal for performance.

The below may allow for theme authors to be able to provide installation / setup instructions via admin notifications as well. This ticket only shows a possible way it could be done. All discussion about the theme guidelines themselves should happen during Team meetings and on the relevant P2 posts.
In this example, the notice has not yet been permanently dismissed. Once the notice has been permanently dismissed for that user, the boolean value for that theme under "repos" should be set to "false".

<?php
$consents = array(
   'functional' => array(
      'comprehensive' => true,
      'remainder' => true
   ),
   'preferences' => array(
      'comprehensive' => false,
      'remainder' => true
   ),
   'anon_stats' => array(
      'comprehensive' => true,
      'remainder' => true
   ),
   'stats' => array(
      'comprehensive' => false,
      'remainder' => false
   ),
   'marketing' => array(
      'comprehensive' => false,
      'remainder' => true
   ),
   'repos' => array(
      'comprehensive' => false,
      'exampleTheme' => true,
      'remainder' => false
   )
);

The above should be appropriately serialized before being saved to the database.

Example 3:

This shows a use-case where the website owner needs to cater for legislative consent requirements from various jurisdictions.

In this example, the website owner would still like to be able to send first party marketing to website users who choose to opt-out of the sale of their data i.t.o. the CCPA.

<?php
$consents = array(
   'functional' => array(
      'comprehensive' => true,
      'remainder' => true
   ),
   'preferences' => array(
      'comprehensive' => true,
      'remainder' => true
   ),
   'anon_stats' => array(
      'comprehensive' => true,
      'remainder' => true
   ),
   'stats' => array(
      'comprehensive' => true,
      'remainder' => true
   ),
   'marketing' => array(
      'comprehensive' => false,
      'sell_data' => false,
      'remainder' => true
   )
);

Acknowledgements:

Thanks to Rogier for defining the initial 5 categories with input from the privacy team.
Thanks to Paapst for the heads-up that consent needs to be re-confirmed if new cookies are added.
Thanks to Retrofitter for inquiring about additional consent categories on P2.
Thanks to Jono for input on a nested structure for consent.

[paapst]

The Consent API primarily wants to enable the communication between the different consent management plugins and all the plugins, themes etc that make use of a cookie, local storage etc. Adding sub-consent types and a nested hierarchy will only add extra complexity to the API and to core . You only have to look at the complexity that is caused by IAB with their TCF framework to understand that this is not desirable.

The only use case that is being mentioned here (the offering of a newsletter) will actually not make use of the Consent API. That particular form of consent is usually not being handled by consent management systems but is being registered in the database when you use a newsletter plugin or a contact form, where consent for receiving the newsletter is being asked.
All the other use cases I can think of, all make use of the 5 initial purposes.

[carike]

The only use case that is being mentioned here (the offering of a newsletter) will actually not make use of the Consent API.

Not as per current compliance / newsletter plugins, but it is definitely a conceivable use case.
One of the core WordPress coding philosophies is extend-ability.
We should leave room for developers to innovate, while still respecting user's consent choices.

All the other use cases I can think of, all make use of the 5 initial purposes.

Let's say a site hosts third party videos and offers their registered users the option to subscribe to notifications.
But some of these third parties upload ten or fifteen videos a day and this is causing all sorts of issues like e-mails being marked as spam because of the high volume of very similar messages - so they want to give users the ability to have more granular control over their notifications, rather than simply have an AI decide their preferences for them.
This isn't quite marketing and it isn't quite functional. I'd personally regard notifications as preferences, but regardless of the classification, a nested hierarchy makes a Consent API much more useful.

We should be future-proofing this feature.

Adding sub-consent types and a nested hierarchy will only add extra complexity to the API and to core .

Could you perhaps give a practical example of this?
I do not see how a nested hierarchy would be incrementally significantly more complex than an array of only five consent types - as there already need to be functions to alter the boolean values for the five consent types (add / remove consent), as well as to retrieve a consent value - and the meta value for caps in the db already present a nested hierarchy, but I may be missing something?

[azaozz]

Thinking there is still some misunderstanding here, still not cleared out from the initial discussions about "user consent" two years ago:

1. Who are the users that need to give consent?
2. Who are the admins (or other users?) who have to ask for consent?

Could you please define the above two groups of people (in WordPress terms).

Also seems a bit weird to have a trac component "Privacy" and a ticket focus of "privacy"? One too many? :)

[carike]

Replying to azaozz:

Thinking there is still some misunderstanding here, still not cleared out from the initial discussions about "user consent" two years ago:

1. Who are the users that need to give consent?
2. Who are the admins (or other users?) who have to ask for consent?

Could you please define the above two groups of people (in WordPress terms).

Just for clarification:
The Disclosures Tab deals with site-level privacy (by helping site owners / admins understand their privacy risk profile).
The Consent API deals with individual website visitor consent.

Users who need to give consent can be registered users who are logged in, registered users who are not logged in, or website visitors who are not registered.
All three of these groups need to be able to manage their consent preferences - but will do so in different ways.
(The Consent API could conceivably serve the needs of the repos as well, in which case the site admins would be the ones denying consent, but that would be a secondary, complementary purpose.)

Those who need to ask for consent are effectively the plugin developers, on behalf of the site owners / admins, when their code performs a function which collects and / or stores user information / communicates with the user / shares the user's info.

Also seems a bit weird to have a trac component "Privacy" and a ticket focus of "privacy"? One too many? :)

I'm okay with removing the focus :) Just had it there so it would be easy to find when filtering.

[azaozz]

Replying to carike:> Just for clarification:

The Disclosures Tab deals with site-level privacy (by helping site owners / admins understand their privacy risk profile).
The Consent API deals with individual website visitor consent.

Yes, that sounds good. Need to be very clear who are the people/roles targeted in both of these features.

Users who need to give consent can be registered users who are logged in, registered users who are not logged in, or website visitors who are not registered.

Think this doesn't sound right. In WP (and on most websites) there are no "registered users who are not logged in". These people are treated as "visitors" to the site, have no access to any special areas, and are not exposed to anything more that "standard" visitors.

In that terms there are two groups of people that should be asked for consent:

• Logged-in (registered) users that are not site-owners/admins. This may include people that are buying something from an online store, however afaik the requirements there are different and a "consent API" will probably not work for these cases.
• Site visitors.

(The Consent API could conceivably serve the needs of the repos as well, in which case the site admins would be the ones denying consent, but that would be a secondary, complementary purpose.)

Sorry but not sure I understand what you mean. What repos? Do you mean trac and github? How these have anything to do with a production install of WP? Also what does it mean for a site admin to "deny consent"? What happens then? The visitor is "thrown out" of the website?

Those who need to ask for consent are effectively the plugin developers...

I think this is incorrect. Plugin authors should disclose what their plugins do or use, but the people that need to ask for consent are the site owners. Could you please double check this with somebody with a law/legal background (perhaps other member of the privacy team)?

Also, some "software development housekeeping": Generally trying to determine some kind of format to store some kind of data in some (undecided) place without knowing how that data is going to be used is a pretty bad idea. This ticket should not be considered by itself. A data structure can easily be chosen once it is known exactly how it is going to be used.

[carike]

Replying to azaozz:

Users who need to give consent can be registered users who are logged in, registered users who are not logged in, or website visitors who are not registered.

Think this doesn't sound right. In WP (and on most websites) there are no "registered users who are not logged in". These people are treated as "visitors" to the site, have no access to any special areas, and are not exposed to anything more that "standard" visitors.

Consent preferences for registered users should be saved in the DB, as per our P2 discussion and the preceding #core-privacy discussions.
Consent preferences for users who are not registered cannot be saved in the DB, so these need to be saved in cookies, which are inherently transient in nature.
When registered users are not logged in, there is no way to distinguish them from visitors who are not registered, so their consent preferences are determined by cookies when logged out.

However, registered users should be able to set their consent preferences for when they are logged out in the same /wp-admin/ UI that they are able to set their consent preferences for while they are logged in. I.e. they should be able to view and update their consent-related cookie values from inside their profile page.
This is why they constitute a third group - because something "extra" is needed for their UI.
The distinction is simply a matter of convenience.

In that terms there are two groups of people that should be asked for consent:

• Logged-in (registered) users that are not site-owners/admins. This may include people that are buying something from an online store, however afaik the requirements there are different and a "consent API" will probably not work for these cases.

Users who are logged in to your membership site (for example, this applies to any site, including e-commerce) still need to be asked for their consent to track them, for statistical or marketing purposes.
e-Commerce stores should, as a matter of best practice, ask their users to accept their product terms, but that does not affect the fact that the above still applies.

• Site visitors.

(The Consent API could conceivably serve the needs of the repos as well, in which case the site admins would be the ones denying consent, but that would be a secondary, complementary purpose.)

Sorry but not sure I understand what you mean. What repos? Do you mean trac and github? How these have anything to do with a production install of WP? Also what does it mean for a site admin to "deny consent"? What happens then? The visitor is "thrown out" of the website?

Here I am referring to the WP plugin repository and theme directory.
There have been a lot of issues with developers upselling in /wp-admin/ and the Consent API could conceivably be used to ensure that ads in the admin area are permanently dismiss-able without cluttering up the DB with multiple user_meta values or transients.
However, as I indicated, this would not be a primary purpose, simply a possible perk.

Those who need to ask for consent are effectively the plugin developers...

I think this is incorrect. Plugin authors should disclose what their plugins do or use, but the people that need to ask for consent are the site owners. Could you please double check this with somebody with a law/legal background (perhaps other member of the privacy team)?

Yes, the site owners are the ones who are responsible.
But they are not the ones actually writing the code.
So, the plugin authors are the ones that need to make use of wp_setcookie() [or its yet-to-be-determined JavaScript equivalent]. So effectively / in practice, their code is asking consent on behalf of the site owner.

Also, some "software development housekeeping": Generally trying to determine some kind of format to store some kind of data in some (undecided) place without knowing how that data is going to be used is a pretty bad idea. This ticket should not be considered by itself. A data structure can easily be chosen once it is known exactly how it is going to be used.

The data will mainly be used by plugins to determine whether or not a cookie should be set for a particular user or not.
Pretty much any other code can also be executed or not (on a per-user basis), depending on whether the user has given permission for that category of use (e.g. marketing).
The tickets have been split into smaller (perhaps hyper-focused) ones because this has resulted in more actionable input from the privacy team thus far.

[azaozz]

Replying to carike:

Replying to azaozz:

Users who need to give consent can be registered users who are logged in, registered users who are not logged in, or website visitors who are not registered.

Think this doesn't sound right. In WP (and on most websites) there are no "registered users who are not logged in". These people are treated as "visitors" to the site, have no access to any special areas, and are not exposed to anything more that "standard" visitors.

Consent preferences for registered users should be saved in the DB, as per our P2 discussion and the preceding #core-privacy discussions.
Consent preferences for users who are not registered cannot be saved in the DB, so these need to be saved in cookies, which are inherently transient in nature.

Right, exactly (just wanted to make this 100% clear). For non-logged-in users the preferences should probably be saved in "session storage" which is transient by default. It's deleted as soon as the "session" (current browser tab) is closed. Cookies aren't really "transient", can last up to 10 years...

However, registered users should be able to set their consent preferences for when they are logged out in the same /wp-admin/ UI that they are able to set their consent preferences for while they are logged in.

This is why they constitute a third group - because something "extra" is needed for their UI.
The distinction is simply a matter of convenience.

Not sure if that's technically possible. There is no way to "recognize" the users when they are logged out (the WP logged-in cookies are deleted).

In addition, if any consent settings are stored in the DB, there must be a way to change them on every visit to the site. In WP that would probably be on the User Profile screen. When a user is logged-out their profile is not reachable, so they will not be able to withdraw their consent, etc.

Users who are logged in to your membership site (for example, this applies to any site, including e-commerce) still need to be asked for their consent to track them, for statistical or marketing purposes.
e-Commerce stores should, as a matter of best practice, ask their users to accept their product terms, but that does not affect the fact that the above still applies.

Right. So the Consent API would only apply to sites that offer some form of "memberships" and web stores.

Here I am referring to the WP plugin repository and theme directory.

Right. There is another tarc for this kind of tickets/changes: ​https://meta.trac.wordpress.org/timeline. We can open tickets there once the WP core implementation is ready (and we know exactly what is needed).

Yes, the site owners are the ones who are responsible.
But they are not the ones actually writing the code.
So, the plugin authors are the ones that need to make use of wp_setcookie() [or its yet-to-be-determined JavaScript equivalent]. So effectively / in practice, their code is asking consent on behalf of the site owner.

Right, one way would be for plugins to "trigger" consent settings for a particular case. Another would be for core to ask for "general consent" for most common cases (whether or not it is currently needed) and plugins can check if consent was given. But that's a question of the implementation design, it will be figured out.

The tickets have been split into smaller (perhaps hyper-focused) ones because this has resulted in more actionable input from the privacy team thus far.

Yeah, I understand. The point is that once we "know" exactly how this new feature will work, any data formats can easily be determined (it will most likely be a "map" or associative array of some sort). There's probably no need for a separate ticket and discussion about it, it's just an implementation detail :)

[carike]

Replying to azaozz:

Replying to carike:

Replying to azaozz:

Right, exactly (just wanted to make this 100% clear). For non-logged-in users the preferences should probably be saved in "session storage" which is transient by default. It's deleted as soon as the "session" (current browser tab) is closed.

The Consent API feature plugin proposal is here: ​https://make.wordpress.org/core/2020/04/01/feature-plugin-proposal-wp-consent-api/
It is included on the wishlist to merge in 5.6. here: ​https://make.wordpress.org/core/2020/07/31/wordpress-5-6-whats-on-your-wishlist/
There have also been a number of Slack discussions.

I believe that the implemented Consent API proposal (​https://wordpress.org/plugins/wp-consent-api/) makes use of consent cookies and not of session storage. I don't think that there has been a specific discussion about this. I'll add it to points for Office Hours.
My instinct would be that a single session may be too short for the reasoning below.

While there has pretty much been a strong consensus for quite some time now that a Consent API is necessary, we are still building consensus on what the implementation should look like.
The original implementation does not distinguish between registered users and website visitors.
A Slack discussion had this outcome on P2: ​https://make.wordpress.org/core/2020/08/22/request-for-input-consent-preferences-for-logged-in-users-consent-api/

This is why I believe that tickets like this one are necessary.
We have some very specific design questions that we need to answer.

The following questions were listed on the P2:

<?php
1. Should consent preferences for registered users (applicable when logged in) be saved in cookies, 
or should they be saved in the database?
If consent preferences are saved in cookies, these could be displayed (and updated) in the user profile, 
but the choice would be transient and would effectively need to revert to site defaults 
every time the cookie is cleared.
2. If they are saved in the database, 
should the REST API be used to expose the logged in user’s consent preference on the front end?
3. If the REST API is used, should a new REST endpoint be created, 
or should register_meta() be used instead?
4. Should the consent preference be exposed on the front end using wp.data? 
The trade-off being that this provides nicer abstraction 
and makes it easier to move towards object-oriented, 
rather than event-orientated programming, but adds a few KB to the front-end?
5. If wp.data is used, should only this be used, 
or should the consent preference still be exposed to the front end by a method in point 3?

So far, the conclusion of the various discussions have been that logged in users should be treated differently logged out users, because if you are a person who regularly deletes your cookies, seeing a pop-up banner every time you visit a site even though you are logged in isn't the best user-experience and contributes to notice-fatigue.
However, registered users should be re-prompted for consent if there are changes to the consent that is being asked for (and a hook makes sense so that plugins can prompt again if they would like this to happen at any particular point).

While there have been answers to some of these questions, based on past experience, I expect that the last 3 will only receive significant input once there is a proposed implementation.

This ticket also asks design questions. In particular the following:

<?php
1. Should plugins be able to add extra consent types?
2. If plugins should be able to add additional consent types,
should these be "top-level" consent types, or should they be nested,
or should they be both?

Paapst's comment above shows that there are different opinions about this in the Privacy Team.

There are many of these types of implementation questions and the only way that they have gotten resolved thus far is by creating simple examples of what the implementation might look like.

While I hear your argument and respect your view that all of these issues should be handled under #51110, history has shown that doesn't work. Because as soon as we try to discuss too many implementation questions in a single go, the discussion devolves into something no one can follow and we scare off the multi-disciplinary contributors we need in order to get this done.

(it will most likely be a "map" or associative array of some sort)

An associative array in user_meta would be awesome :)

Cookies aren't really "transient", can last up to 10 years...

Yes, this is something I could have described better.
What we mean is that cookies are not a reliable way to store information that you would like to be available for a long(er) period of time, because people can and do clear them.
This is an inherent limitation for logged out users, but cookie banner fatigue does not have to be the fate of logged in users.

However, registered users should be able to set their consent preferences for when they are logged out in the same /wp-admin/ UI that they are able to set their consent preferences for while they are logged in.

This is why they constitute a third group - because something "extra" is needed for their UI.
The distinction is simply a matter of convenience.

Not sure if that's technically possible. There is no way to "recognize" the users when they are logged out (the WP logged-in cookies are deleted).

In addition, if any consent settings are stored in the DB, there must be a way to change them on every visit to the site. In WP that would probably be on the User Profile screen. When a user is logged-out their profile is not reachable, so they will not be able to withdraw their consent, etc.

I did not mean to suggest that registered users should be able to manage their consent preferences without logging in - only that they should be able to see on their profile screen what their consent preferences will be after they log out (based on the current value of their consent cookie - and that they should be able to update these cookie values while still logged in).

I should add here that the Consent API stores consent values separately to the WP logged-in cookie specifically because they should not be destroyed to regularly.

Users who are logged in to your membership site (for example, this applies to any site, including e-commerce) still need to be asked for their consent to track them, for statistical or marketing purposes.
e-Commerce stores should, as a matter of best practice, ask their users to accept their product terms, but that does not affect the fact that the above still applies.

Right. So the Consent API would only apply to sites that offer some form of "memberships" and web stores.

No. The Consent API would apply to someone who runs a blog and who wants to place any personalized ad as well, even if they do not allow account-creation on their site.
It would even apply to someone who does content marketing and want to do tracking to tailor their content, even if they don't allow any third party advertising on their site.
The only difference is that all their traffic would be treated as visitors and people won't be able to manage their consent choices in their profile, but would instead have to rely solely on a cookie banner.

Right, one way would be for plugins to "trigger" consent settings for a particular case. Another would be for core to ask for "general consent" for most common cases (whether or not it is currently needed) and plugins can check if consent was given. But that's a question of the implementation design, it will be figured out.

We already have one iteration for the Consent API.
Rogier has added the wp_setcookie() function (and a doing_it_wrong if the cookie info has not been added by the plugin looking to conditionally set the cookie) to it based on our feedback in the channel, but at this point we need to evaluate the iteration and iterate again.

I should also note that the code lives on GitHub, but because the team has a lot of contributors who are not coders, that is a barrier to multi-disciplinary participation.
Rogier and others have wanted to move the code over to the WordPress repository, but that has not happened yet, so the fact that it lives in a private repo is also a challenge.

[azaozz]

Replying to carike:

I believe that the implemented Consent API proposal (​https://wordpress.org/plugins/wp-consent-api/) makes use of consent cookies and not of session storage. I don't think that there has been a specific discussion about this. I'll add it to points for Office Hours.
My instinct would be that a single session may be too short for the reasoning below.

Yes, a single session is too short, but on the other hand it doesn't add yet another cookie for which the user has to give consent. It is guaranteed to be removed from the user's browser after the visit to the particular web site ends. I.e. the consent cookie by itself can be treated as a "breach of user privacy".

The results can be seen currently (on non-WP websites) where if the user doesn't consent, each time they navigate to a new page on the same website they are asked to consent, again and again. This is super annoying :)

If session storage was used instead, a "consent refusal" could be saved there and the site visitors won't be "bugged" with repeated consent requests.

Of course, this is just another implementation detail, nothing more.

While there has pretty much been a strong consensus for quite some time now that a Consent API is necessary, we are still building consensus on what the implementation should look like.

Right. For an API to be actually useful, it should be able to handle most of the needed work, and expose few functions/methods/filters to plugins that may want to use it. This generally means the API should be able to store, retrieve, and change consent settings for all groups of users. In addition it should (probably) provide UI for setting and changing these settings. This is particularly difficult as it means the "consent options dialog" for site visitors has to be on the front-end of the website, and "work well" with all themes. Not sure if the current plugin does that (yet).

The original implementation does not distinguish between registered users and website visitors.
A Slack discussion had this outcome on P2: ​https://make.wordpress.org/core/2020/08/22/request-for-input-consent-preferences-for-logged-in-users-consent-api/

This is why I believe that tickets like this one are necessary.
We have some very specific design questions that we need to answer.
...
So far, the conclusion of the various discussions have been that logged in users should be treated differently logged out users, because if you are a person who regularly deletes your cookies, seeing a pop-up banner every time you visit a site even though you are logged in isn't the best user-experience and contributes to notice-fatigue.

That's another good point. Thinking that there is a pretty big difference between logged-in users and site visitors. For starters the "consent options dialog" for visitors has to be on the front-end, and save the data in the visitor's browser. Implementation-wise it can either be fully js based or an iframe.

For logged-in users the consent options would probably be more granular or extended as a lot more "happens" in wp-admin, and the options should be saved in user_meta in the DB. That will make them accessible every time and from every device, different browsers, phones, etc. Best place for them would be the User Profile screen. That screen can easily be extended to include everything necessary and "feel" an integral part of WP.

However, registered users should be re-prompted for consent if there are changes to the consent that is being asked for (and a hook makes sense so that plugins can prompt again if they would like this to happen at any particular point).

Right. The current UI way of doing that is by showing a "bubble" on the top menu item. Can eventually also show a notice, but lets leave that for the designers.

While there have been answers to some of these questions, based on past experience, I expect that the last 3 will only receive significant input once there is a proposed implementation.

This ticket also asks design questions. In particular the following:

1. Should plugins be able to add extra consent types?
2. If plugins should be able to add additional consent types,
should these be "top-level" consent types, or should they be nested,
or should they be both?

Paapst's comment above shows that there are different opinions about this in the Privacy Team.

There are many of these types of implementation questions and the only way that they have gotten resolved thus far is by creating simple examples of what the implementation might look like.

Perhaps it may be good to gather a number of examples of how (site visitor) consent options are handled on other sites. Currently this is generally something that is being shown only to visitors from the EU, so the people collecting that data will have to be based there.

Would be really good to "investigate" how other popular website building software handles this.

While I hear your argument and respect your view that all of these issues should be handled under #51110, history has shown that doesn't work. Because as soon as we try to discuss too many implementation questions in a single go, the discussion devolves into something no one can follow and we scare off the multi-disciplinary contributors we need in order to get this done.

The idea was to "gather" all the requirements there, and then see what's technologically possible and what implementation makes sense. Then "hand off" to the designers for the actual UI.

I agree, it is quite a bit of work to try to translate the legal requirements into "actionable items", but this is (perhaps) the most important step in implementing this feature. Perhaps we can reach out for some help :)

For example, if the consent options have to comply only with GDPR, the requirements can be taken from ​https://gdpr.eu/gdpr-consent-requirements/. (Note that this site is build with WP. If we implement the consent options dialog on the front-end, it will (probably) be shown there too.) :)

No. The Consent API would apply to someone who runs a blog and who wants to place any personalized ad as well, even if they do not allow account-creation on their site.

Right. What I meant was that handling of consent options for site visitors would (likely) be quite different from logged-in users. One would likely be js, the other php, etc.

We already have one iteration for the Consent API.
...
Rogier and others have wanted to move the code over to the WordPress repository, but that has not happened yet, so the fact that it lives in a private repo is also a challenge.

I can help there, but thinking the current implementation is not quite ready yet. The API should be able to do most of the work, have UI, etc. Of course, this will be added after the above questions are cleared/decided.

Removing the "close" keyword as there is quite a bit of discussion here, but still thinking this ticket is a "follow-up" and can be decided only after the implementation requirements are set.

[paapst]

I don't agree with the fact that this ticket is being presented as a milestone for the Consent API. The proposal for the WP Consent API is not, and I repeat is not , a proposal for implementing a consent management system in core. It is only a small and simple plugin (​https://wordpress.org/plugins/wp-consent-api/) to facilitate the communication between the existing consent management systems such as Cookiebot, Complianz or GDPR Cookie Consent, and plugins or themes that place cookies or that make use of local storage or other resources. As can be seen in the proposal the API does not store the consent choice. This is why the consent API does not need a UI, and does not need to be able to do all the things the consent management systems already are offering.
In the proposal we have already mentioned that some of the functionalities that are offered by consent management systems would be too intrusive to do in core, because certain functionalities are not applicable to all users due to different cookielaws around the world.

Now, if it is really necessary to do something special for logged-in users, I think that the proposal for that new functionality and the current ticket should be treated separate from the original proposal for the Consent API.

[carike]

Replying to paapst:

to facilitate the communication between the existing consent management systems such as Cookiebot, Complianz or GDPR Cookie Consent, and plugins or themes that place cookies or that make use of local storage or other resources.

I cannot support the idea of creating a functionality in Core to benefit a handful of plugins.
In such a case, it is more suitable for the plugins who wish to use a common framework, to either recommend / require the Consent API plugin in its current form, or to bundle it into their .zip

[carike]

Changed from a milestone for the Consent API to a milestone for Website User Level Consent Management as per the request from @paapst in https://core.trac.wordpress.org/ticket/51188#comment:16

[paapst]

I must admit that my initial assumption regarding the extra (sub) consent types was wrong. The new examples that have been given by @carike in the description indeed show the need for plugins to add additional consent categories.

[garrett-eclipse]

5.6 beta is coming up quickly, will revisit in a future release.

[hellofromTonya]

Discussing with @carike about the next steps for this ticket and consensus on it.

A version of the Consent API is needed for part of COPPA for the KidsCamp content on Learn.
More details here ​https://make.wordpress.org/meta/2021/01/03/protecting-childrens-privacy-on-wordpress-through-the-lens-of-coppa/

The proposal was discussed briefly during the #meta meeting last night.
I believe it will need to be an inter-team effort.

[xkon]

5.7 Beta 1 is around the corner, moving to Future Release for now :).

[paaljoachim]

Perhaps someone could write a summary of where this ticket is at?
It seems to have become stuck and it would be helpful to find a way to move it onward!
Thank you!