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

[WordPress Trac]

#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 azaozz):

 Replying to [comment:12 carike]:
 > Replying to [comment:11 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 :)

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