[wp-trac] [WordPress Trac] #51188: Create a structure for consent-related user meta value

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:
 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
 <?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
 <?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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51188#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform