Feature Request - Is PII? for User Meta

[bhubbard]

I would like to see a new column for the user_meta table, Boolean where user meta can be marked as Personal Identifiable Information (PII). Plugins/Themes can use this when saving/reading user data. For example, a plugin could delete all data that is PII upon request, but keep other data for other purposes.

is_pii 

[dkarfa]

We need to add one checkbox at /wp-admin/profile.php and allow the user to set the value.

[kkarpieszuk]

@dkarfa I am not sure if you understand the request. Or I don't understand, let @bhubbard resolve confusions :)

I understood @bhubbard asked to have this value set not per user as you try to do in patch, but per data. For example user could decide with checkbox that his surname is PII, but for example his siteurl isn't.

If this is what he asks, this might require a new column in wp_usermeta.

But I think this should be resolved with plugin. You can easily on every usermeta save save another row with information if this is PII.

[bhubbard]

I think the @dkarfa idea to have a field to share PII is not a bad one, but @kkarpieszuk was more right on with what I was going for.

Many plugins add/define user meta, some of which is PII and some which is not. By having this new column on user_meta, plugin/theme developers can let everyone know if the meta they are setting is PII. While I could write a plugin to add this column and set this data, it would only be useful if heavily customized for a site. I would need to look at the data created by the plugins on the site, and make decisions for each. By having it in core, plugin/theme developers can set this per field they create for a user, at which point other developers and core can then decide how to handle PII data differently over data that is not PII.

I understand this puts the burden on plugin/theme authors to decide which fields they add/modify are PII, but they should be the ones who can best make that decision (at least for the default setting).

Defaults would need to be chosen for all user meta that is created by core WordPress. Some quick examples:

first_name = true
last_name = true
rich_editing = false
syntax_highlighting = false
use_ssl = false

Function like add_user_meta, would need new support for this column, example:

add_user_meta( int $user_id, string $meta_key, mixed $meta_value, bool $unique = false, bool $is_pii = false );

[garrett-eclipse]

Thanks for the concept, I think in general it would be a very helpful idea to help plugins and site owners with understanding what information is PII.

For back-compat and to allow the update to function on existing user_meta without needing to update the table or all entries with another column I wonder if the approach could be done using a new table user_privacy which would be a mapping of the user_meta key so one entry setting say first_name to is_pii would cover all user_meta entries with that key.

This would allow core, plugins and custom code to indicate which user_meta fields and which users columns are considered PII without having to change the user_meta table or add_user_meta signatures. A new function to register the user meta or column could look like register_user_privacy( string $meta_key/$column_key, boolean $type {0 = column, 1 = meta}, boolean $is_pii ); and a function for retrieving privacy state could look like function is_pii( string $meta_key/$column_key, boolean $type {0 = column, 1 = meta} ); so when handling user meta it's key can be used to determine if it's considered PII or not.

By isolating this outside of the user_meta table we can have it not only cover user_meta but also columns from the user table as well. It also allows something like this to be built as a feature plugin for experimentation before merge proposal to core.

Thoughts?

[xkon]

Hi @bhubbard!

After a discussion with @garrett-eclipse I wanted to update this in full.

Core already has implementations for Exporters & Erasers since the first release of the component on which plugins can add their data to be exported on erased. See ​https://developer.wordpress.org/plugins/privacy/adding-the-personal-data-eraser-to-your-plugin/ and ​https://developer.wordpress.org/plugins/privacy/adding-the-personal-data-exporter-to-your-plugin/ .

As far as I can understand the use-case is similar if not 100% the same and it's simply for identifying PII from the perspective of a plugin.

On a further note, altering the database and adding a permanent marker that something is actually PII makes it wat easier for malicious code to do its dirty job. At the moment there isn't any pointing factor to what a dataset is (PII or not) up to the point that the erasers/exporters are running and plugins are just hooking in to take care of their data as well (this excludes any default Core data that is predefined obviously and well known).

Also, there's no need, in general, to alter the DB schema just for this in my opinion, there are other ways that this could be achieved if it's truly needed.

I'm closing this as I think that we're already covering all aspects but feel free to reply back if further discussion is needed!