[wp-trac] [WordPress Trac] #51188: Create a structure for consent-related user meta value
noreply at wordpress.org
Fri Sep 4 14:29:53 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: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
> 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
> - 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
> > Those who need to ask for consent are effectively the plugin
> 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
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
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
Ticket URL: <https://core.trac.wordpress.org/ticket/51188#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac