[wp-trac] [WordPress Trac] #43797: Consent Logging

[WordPress Trac]

#43797: Consent Logging
----------------------------------------+------------------------------
 Reporter:  xkon                        |       Owner:  xkon
     Type:  enhancement                 |      Status:  assigned
 Priority:  normal                      |   Milestone:  Awaiting Review
Component:  General                     |     Version:
 Severity:  normal                      |  Resolution:
 Keywords:  gdpr 2nd-opinion has-patch  |     Focuses:
----------------------------------------+------------------------------

Comment (by xkon):

 Replying to [comment:13 ericdaams] (also adding general things discussed
 in slack so we can have them here as well):
 > Storing consents in the posts table seems fraught with peril to me, if I
 understand the purpose behind consents correctly.
 > I understand that there is precedent for doing things as CPTs, say with
 requests for data erasure or export, but those requests are likely to be
 far fewer; consents is something that can very likely be hit again and
 again.

 This first patch was made from a plugin that I already made / using for my
 clients as mentioned above as it was using CPTs already. One of the
 websites already has over 3k consents within a matter of days logged and
 they're moving up so I can easily see the concerns on this.

 I pretty much took some time to match it with our current way of providing
 tools so you could just hit apply patch and check how things work ( at
 least for me :) ) the last weeks after I saw that @Shelob9 and @mnelson4
 mentioned pretty much the same stuff that I was already using.

 > For example, if I have a cookie notice that is displayed to all
 visitors, and this is agreed to by the visitor, would this be something
 that I could/should store a consent for?

 Depends on if you want proof for it or yes you might as well log
 everything.

 > If that's the case, then **every single visitor** to my website who
 accepts this will end up having a consent entry created for them; that's a
 whole lot of bulk added to the posts table.

 It is but you can avoid logging if you want. It's not 'automated' and
 won't be (by core) in any way for the consent part at least. We provide
 the means to do it, but it's up to any Admin to use them or not.

 > On the topic of developing this in core vs. as a plugin, would this be
 an appropriate candidate for a feature plugin? That might allow us to
 develop it in a less rushed fashion, with a custom table designed just for
 it.

 So there have been some chats in slack already and the thinking around
 this is to make it even more global to log more things and not only
 Consents. That being said the records will be even more and the logging
 will be 'endless' but that's how logs work + that's up to any admin to
 decide for how long the records will be kept for.

 This is in general something that I will continue to try and have it in
 Core as it's apparently needed from the regulation + a privacy/security
 measure that the Core itself can easily provide with an api that everybody
 can use and follow.

 Examples that have been mentioned:
 - Consents
 - User Logs (Registration/Profile Updates/Deletion)
 - Privacy Tools Logs ( to port them here for centralization )
 - Page/Post Editing ( User/Date -> pretty much like the revision table is
 viewed inside an Edit page at the moment, but again this will just be a
 mention + centralized for a quick review )

 As you can imagine the list might even get bigger/smaller etc it's still
 on early discussions.

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