[wp-trac] [WordPress Trac] #51188: Create a structure for consent-related user meta value
noreply at wordpress.org
Sat Sep 5 09:20:24 UTC 2020
#51188: Create a structure for consent-related user meta value
Reporter: carike | Owner: (none)
Type: feature request | Status: new
Priority: normal | Milestone: 5.6
Component: Privacy | Version:
Severity: normal | Resolution:
Keywords: close | Focuses:
Comment (by carike):
Replying to [comment:13 azaozz]:
> Replying to [comment:12 carike]:
> > Replying to [comment:11 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:
It is included on the wishlist to merge in 5.6. here:
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
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:
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:
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
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
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-
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
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.
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
> (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
> > 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
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
> > 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-
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.
Ticket URL: <https://core.trac.wordpress.org/ticket/51188#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac