Establish a standard means of core reading privacy declarations from plugins' headers

[allendav]

To help administrators create and maintain their site's privacy policy, we not only need the privacy declarations for WordPress core (the software) but also need a means of getting privacy declarations from plugins. This ticket is about getting those privacy declarations from plugins. (See #43473 for core's declarations.)

The proposed way right now is for plugins to add their privacy declarations to their readme.txt somehow. This ticket needs to define how exactly to add those to readme.txt (e.g. what section, format).

This ticket also needs to result in the code that allows those privacy declarations to be surfaced in the privacy-policy-editing user interface proposed in #43435 (alongside the declarations from core itself from #43473)

[casiepa]

Some first thoughts:

1) It could be readme.txt or readme.md

2) I suppose it could start as:

== Plugin Privacy Policy ==

just like

== Changelog ==

3) Below that standard paragraphs or is any further 'formatting' needed?

4) Versioning would be done by increasing the version of the plugin (?)

[TZ Media]

To repeat concerns from the discussion about this (can‘t remember by whom):

• The privacy notice in the plugin description is more aimed at site admins wanting to use the plugin. But the privacy notice aimed at the end user of the site might have to be different, as it must conform to legal requirements.
• The privacy notice aimed at the end user might have different requirements depending e.g. on the configuration of the plugin. So it would be better to have this privacy notice in code, so it can adapt to that, while the privacy statement in the readme is static.

[swissspidy]

If something like that is added to the readme it won't be translated in WordPress, only on WordPress.org. Plus we would need a way to parse the readme in WordPress.

Anything that should be added on the privacy page is something plugins should add using PHP.

Anything that should be visible on WordPress.org should be in the readme.txt.

[azaozz]

The proposed way right now is for plugins to add their privacy declarations to their readme.txt

Right, all plugins should have a Privacy section in the readme.txt that will be displayed on wordpress.org/plugins.

• The plugins that do not store any user data and do not affect a website's user privacy in any way should state that in the new Privacy section.
• The plugins that affect user privacy should include some information about what exactly they do, how, why, etc.

In addition, all plugins that affect the website users privacy in any way should include some information designed for inclusion in the website's privacy policy. This will be accomplished by using wp_add_privacy_policy_content() (see [42980]). From there the information/text will be displayed in a postbox when the site owner edits the site's privacy policy, see #43620.

I understand the desire to keep this as DRY as possible in plugins, but the Privacy section in the readme is for a different context than the privacy info/text intended for the site's policy. As @TZ-Media points out above, one is info for people looking to install a plugin, the other is a legal text shown on many websites.

In that terms thinking this ticket should be closed in favor of #43620.

[mnelson4]

In that terms thinking this ticket should be closed in favor of #43620.

So this ticket just adds some text to show alongside the plugin description on wp.org, then it doesn’t sound too high priority. Plugin developers can already provide privacy information to site owners in their plugin description; and copy they want to be shown to site users when the plugin is activated will be provided by #43620.
So it sounds like the only reason to do this is if we want plugin privacy information on wp.org to be separate from the plugin description (which might be useful for helping to standardise it and have logic use that privacy information be more machine accessible).
So I haven’t totally made my mind up on this, just providing some food for thought on the topic.

[idea15]

This is one of many chicken and egg discussions that have arisen from the GDPR compliance project: in order to pull data from plugins, we need to establish that within the plugin developer guidelines. Let's return to this after 4.9.6.

[desrosj]

Moving to the new Privacy component.

[desrosj]

Related: #43938.

[allendav]

@azaozz @iandunn - for #43938 I need to know whether or not a plugin has implemented the privacy policy guide, export and erasure interfaces. (None of the present interfaces has a means of capturing any identifier for the plugins when they call them.)

I was thinking that, instead of (or perhaps in addition to) modifying those interfaces, if we could have a new row in the plugin header that indicates if the plugin implements those interfaces, then when could 1) have what we need for #43938 AND 2) have a means (down the road) of showing privacy info/icons/something for plugins in the .org repository itself.

What do you think?

I was thinking that maybe plugins should have a Tags header something like what themes do ( ​https://codex.wordpress.org/File_Header )

The tags we need for privacy would be

• adds-to-privacy-guide - for plugins that provide snippets for the privacy policy guide
• collects-personal-data - for plugins that register a personal data exporter and a personal data eraser for the personal data they collect and/or copy
• collects-no-personal-data - for plugins that do not collect or copy personal data (mutually exclusive with collects-personal-data)
• no-privacy-guide-text-needed - for plugins that do not do anything with personal data, and have nothing to add to the privacy policy (mutually exclusive with privacy-guide)

Admins can be alerted during privacy guide, export and erasure when they have activated plugins that don't have these tags in their header (e.g. something like "You are responsible for gathering any personal data collected by the following plugins: plugin1, plugin2, etc,")

[iandunn]

Hmmm, I'm kinda leery of the idea of relying on a dev manually setting readme.txt headers. It feels like it'll be much more likely that results will be inaccurate. A dev could forget to update it when they add/remove export/erase callbacks, use the wrong values, etc.

It's also adding another thing that devs have to learn about and do.

I wonder if there's a way we can add support for identifiers to the export/erase callback registration process, in a way that'll maintain back-compat?

Or maybe ​use ReflectionFunction to determine the plugin that the callback is from, or see which plugins are hooking in to wp_privacy_personal_data_exporters. Those could have some false-positives there too, though, but maybe it's less likely than relying on them being manually set? Maybe automatic detection could be the primary method, then then there's also a filter to let devs override the result?

None of that feels like a very elegant solution, though; a readme.txt header would probably be simpler. I don't have a strong opinion either way.

[allendav]

Replying to iandunn:

Hmmm, I'm kinda leery of the idea of relying on a dev manually setting readme.txt headers. It feels like it'll be much more likely that results will be inaccurate. A dev could forget to update it when they add/remove export/erase callbacks, use the wrong values, etc.
It's also adding another thing that devs have to learn about and do.

Absolutely - this is a downside to this. That said, I don't think plugin developers will be in the habit of removing integration to core privacy, in fact i suspect they'll probably be adding these privacy related tags just once in their plugin's lifecycle.

I'm also comforted by the fact that themes do this tag business already.

I wonder if there's a way we can add support for identifiers to the export/erase callback registration process, in a way that'll maintain back-compat?

We could, but what would you do for plugins that don't need the exporter/erasers because they don't collect or copy personal data? The plugin header approach supports those plugins (which i suspect are the vast majority of plugins.)

Or maybe ​use ReflectionFunction to determine the plugin that the callback is from, or see which plugins are hooking in to wp_privacy_personal_data_exporters. Those could have some false-positives there too, though, but maybe it's less likely than relying on them being manually set? Maybe automatic detection could be the primary method, then then there's also a filter to let devs override the result?

We could do this, but we wouldn't know what plugins implemented the export and erasure hooks until after we call all the registered exporters and erasers? I'd love to present this information to the admin before they run any export. Seems a little complicated and therefore potentially brittle too?

It also suffers from the vast-majority problem - plugins that don't collect or copy personal data and so don't need to participate in export or erasure.

None of that feels like a very elegant solution, though; a readme.txt header would probably be simpler. I don't have a strong opinion either way.

LOL, nope, neither is foolproof, but i think the readme.txt header tags idea has an edge in simplicity.

Another neat thing about the Tags: idea is that other concepts might show up there, like requires-php-7 for example :P

[Otto42]

Just for informational purposes, core currently has no way to read or parse the readme.txt at all. That has always been an exclusive thing to the org site. So, from a purist point of view, as well as an implementation one, -1.

You'd be better off to find a way for a plugin to declare that, yes, it does a thing, using the plugin header only. That's easier, more likely to gain traction, and doesn't run into myriad problems with translations.

[allendav]

Replying to Otto42:

Just for informational purposes, core currently has no way to read or parse the readme.txt at all. That has always been an exclusive thing to the org site. So, from a purist point of view, as well as an implementation one, -1.

You'd be better off to find a way for a plugin to declare that, yes, it does a thing, using the plugin header only. That's easier, more likely to gain traction, and doesn't run into myriad problems with translations.

You're absolutely right @Otto42 - I was thinking plugin header and then didn't catch that we started talking about readme.txt

The title of this issue doesn't help either :) I'll fix that next.

So, to clarify, I'm talking about adding tags to the plugin header for privacy - not to a plugins' readme.txt.

@azaozz - I'm renaming this issue to "Establish a standard means of core reading privacy declarations from a plugins' headers" - feel free to push back if that's a bad move.

[westi]

I'm not really sure what the issue we are trying to fix here is.

Site owners have to abide by local (and relevant international laws). WordPress core and plugin can surely provide tools to help with this process but I don't think that it should try and tell them if it thinks a plugin is or isn't complying with something which seems to be where this is leading.

As a site developer and site owner you have to do site specific work - we can't and shouldn't try and imply we can do all the work for you.

I think time would be better spent on evangelising the usage of features like the new privacy policy helpers so that plugin developers adopt them.

[allendav]

Replying to westi:

I'm not really sure what the issue we are trying to fix here is.

Site owners have to abide by local (and relevant international laws). WordPress core and plugin can surely provide tools to help with this process but I don't think that it should try and tell them if it thinks a plugin is or isn't complying with something which seems to be where this is leading.

I hope not - the intention here was ONLY to what extent a plugin integrates with the core privacy tools, not whether it complies to any particular law.

As a site developer and site owner you have to do site specific work - we can't and shouldn't try and imply we can do all the work for you.

Agreed! That's why I want to use these headers to drive the UI for #43938

[desrosj]

Add support for Privacy header in plugins.

[desrosj]

There will likely be something required on the w.org side to note privacy feature support directly on plugin pages eventually. But for now, let's focus on within WordPress. The main goal is to allow a plugin to declare that it integrates with a privacy feature to help site owners be aware of potential privacy issues on their site. Like declaring WordPress or PHP version support, it's a bit of an honor system.

43750.diff​ is a start by adding support for a Privacy: header of the plugin. Eventually, the value should be transformed from comma separated list to an array.

I like @allendav's suggestions in 43750#comment:10 as a starting point, but not sure those are worded the best, or that it covers all of the scenarios.

The second part of this ticket would be the functions that interpret the values specified. wp_plugin_has_privacy_support( 'feature' ), wp_privacy_plugin_supports_personal_data_export( $plugin ), are a few examples @allendav and I were kicking around.

After #43938 receives some UX feedback, the functionality needs will be clearer, but we can start to draw up the basics.

[desrosj]

Removing the GDPR keyword. This has been replaced by the new Privacy component and privacy focuses in Trac.

[xkon]

Closing this in favor of #49272 that was split from #48486 and proposes a complete set of new headers to be used on both Core & Meta eventually.

We decided this on today's core-privacy meeting as there are plenty of new discussions if anyone wants to read in full that wouldn't fit the scope here and might've been confusing.

Also, please see https://core.trac.wordpress.org/ticket/48486#comment:26 for a list of relevant Slack discussions.