[wp-trac] [WordPress Trac] #51188: Create a structure for consent-related user meta value
noreply at wordpress.org
Sat Sep 5 14:29:04 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: | Focuses:
Changes (by azaozz):
* keywords: close =>
Replying to [comment:14 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
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
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
> 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.
> 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
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
> 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.
Ticket URL: <https://core.trac.wordpress.org/ticket/51188#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac