Add support for new privacy headers in core

[carike]

Update: This ticket has been closed in favour of #51092, to account for the recommendations in this ticket.
Thank you to everyone who contributed.

This ticket was split from #48486 to explore ways of adding extra Headers in order to provide a standard way to eventually create a Disclosures and Permissions Tab in both Core and Meta.

Having a standardized set of headers will allow plugin authors to easily state their plugins' intentions, external resources, PII usage, and other privacy-related information.

Reference with links to slack discussions can be found here: https://core.trac.wordpress.org/ticket/48486#comment:26

As well as from today's core-privacy meeting: ​https://wordpress.slack.com/archives/C9695RJBW/p1579721408083300

Also, an earlier idea similar to this was at #43750 (along with various slack chats that are hard to track at the moment), but we decided to start fresh and avoid further confusion from long chats and missing context.

---

The scope of this ticket is to finalize the headers needed and to discuss the best way to support & read them for further usage.

---

A plugin author should be able to declare these headers in the plugin's main PHP file.

The following headers are being proposed:

Consent API
Declares compatibility with the Consent API.
If not declared as TRUE / FALSE, it should default to NULL.

Disclosures Tab
Declares compatibility with the Disclosures and Permissions Tabs.
If not declared as TRUE / FALSE, it should default to NULL.

External Network Calls PHP
Should accept a comma separated lists of URLs.
The plugin author should link to the Privacy Policy of any site that external network calls are being made to using PHP.
Should default to NULL if the header is not declared.

External Network Calls JavaScript
Should accept a comma separated list of URLs.
The plugin author should link to the Privacy Policy of any site that external network calls are being made to using JavaScript.
Should default to NULL if the header is not declared.

External Network Calls CSS
Should accept a comma separated list of URLs.
The plugin author should link to the Privacy Policy of any site that external network calls are being made to using CSS.
Should default to NULL if the header is not declared.

SaaS
Should accept a comma-separated list of URLs.
The plugin author should link to the Terms of Service of any site that provides Software as a Service for the plugin.
Should default to NULL if the header is not declared.

Calls to External APIs
Should accept a comma-separated list of URLs.
The plugin author should link to the Terms of Service that applies to each external API.
Should default to NULL if the header is not declared.

Remote Assets
Should accept a comma-separated list of URLs.
The plugin author should link to the Licence that applies to the use of each remote asset.
Should default to NULL if the header is not declared.

Sets Cookies PHP
If not declared as TRUE, it should default to NULL.

Sets Cookies JavaScript
If not declared as TRUE, it should default to NULL.

Writes to DB
If not declared as TRUE, it should default to NULL.

Creates Custom Post Type
If not declared as TRUE, it should default to NULL.

Creates Custom Table
If not declared as TRUE, it should default to NULL.

Stores PPI
If not declared as TRUE, it should default to NULL.

Supports PPI export
If not declared as TRUE, it should default to NULL.

Supports PPI erasure
If not declared as TRUE, it should default to NULL.

Sends e-mails
If not declared as TRUE, it should default to NULL.

Advertises in wp-admin
If not declared as TRUE, it should default to NULL.

Asks for Backlinks
If not declared as TRUE, it should default to NULL.

Code Audited by Third Party
Should accept a comma-separated list of URLs.
The plugin author should link to the third party's site that performed each independent review of the code.
If not declared as TRUE, it should default to NULL.

[johnbillion]

Can you provide a bit more background on the proposal of these headers? Links to the privacy team chats etc so interested people can read the discussions. Thanks!

[TimothyBlynJacobs]

Have you considered instead a ".well-known" like JSON file? For instance, plugins could create a privacy.json file in the root directory of their plugin. It would still be machine readable by .org ( or anyone else ), but wouldn't make it difficult to read ( and parse! ) the plugin headers.

{
  "saas": [
    "https://example.org",
    "https://example.com"
  ],
  "sends-email": true
}

[xkon]

#43750 was marked as a duplicate.

[xkon]

I agree with @TimothyBlynJacobs here on using a completely new file to support this (it might as well be a JSON for the ease of use). This would give us the freedom to create free functionality and built it as needed to fulfill the purposes of the DPT and also "tag" it along with all other existing wp_privacy_ functionality.

I see in the text that the mentions are specifically for "plugins". By introducing a new file allow me to take this a step further and say that Themes may as well use some of these "headers" and as on any privacy-related functionality at the moment, we don't exclude anyone, the functions/filters are there and anyone can tap into them.

Unfortunately, it's a common misunderstanding that we're only dealing with plugins because the Privacy functionality is documented under Plugins (not sure where else we can move them but we might as well talk about this again with the Docs team 🙂).

To give an example, a Theme comes bundled with plugins (not by externally requiring them but actually includes the .zips and asks for immediate installation if not automatically set them up as well else the theme won't be working).

In this instance, it's up to the theme author to actually inform of all their "built-in" functionality and what they are doing along with those extra plugins. Complicated yes, but that's why it has to be general and including every author, not only plugin authors.

About the "headers":

External Network Calls PHP/JS/CSS could be combined into just External Network Calls.

IMO there will be absolutely no difference in the eyes of an everyday user if the website is making JS or PHP external calls. They are just external calls.

Also, I don't think that we can expect from any author to literally write down every single external call that a plugin/theme might be doing. For plugins, it might be easier but for themes as an example it wont.

Imagine building a theme that comes bundled with a "Preview/Showcase" template and that template goes and sets up external images in content instead of downloading them all locally or pre-bundling them. I don't think that it's optimal or expected for anyone to just note down all of these calls. Please do correct me if I'm misunderstanding something here, an external image via CSS in my eyes is an "External Call".

By the example above, I believe that I'm already covering that Remote Assets & Calls to External APIs look kind of similar to this as well.

Sets Cookies PHP/JS could be combined into Sets Cookies.

Similar to network calls, what would be the difference in the eyes of a user from what language the cookies are set? None in my opinion and there's no need to create unnecessary confusion.

Code Audited by Third Party, what would be the purpose of this exactly? I don't believe that the majority of plugins/themes have their code audited by a 3rd party and if it was, how do I know as a user that the 3rd party selected is OK and why should I feel comfortable with it? If by 3rd party this means even automated tools like RIPS, SonarCloud, etc out of which some of them include security scans, that's not something for a DPT I think again but something for their general description if they want to showcase it at their own free will.

All of the other headers look fine to me as they are related to WordPress functionality.

One last note, I'm not entirely sure what null means in this instance. Everything is basically True/False as far as I can see and if omitted False by default.

--

Don't get me wrong, I'm all in for including this functionality and I'll be more than happy to help start patching ASAP but I would still like it to be understood by the majority of our users not just by experts on the matter.

Simplifying things can go a long way as everything is already complicated for an everyday user that has a website and unfortunately they are going to become even more complicated in regards to regulations. Let's try to keep it as simple as possible.

[carike]

This project is driven via core-privacy because it has the largest overlap.

However, we should remain mindful of the fact that, first and foremost, the purpose of the project is to help site owners / non-technical admins make more informed choices when choosing between plugins and / or themes.

I find that the use of a term like privacy.json causes confusion, as some of the items do not appear strictly related to privacy.
I propose that we should use disclosures.json instead.

One of the objections I hear the most often is that "plugin / theme authors won't understand" or will lie.

I'd like to note here that most of these items are already covered by the Detailed Plugin Guidelines and the Required section of the Theme Review Team Handbook.

Licensing:

Plugin Requirement:

1. Plugins must be compatible with the GNU General Public License #
All code, data, and images — anything stored in the plugin directory hosted on WordPress.org — must comply with the GPL or a GPL-Compatible license. Included third-party libraries, code, images, or otherwise, must be compatible.

2. Developers are responsible for the contents and actions of their plugins.
Developers are expected to confirm, before uploading to SVN, the licensing of all included files, from original source code to images and libraries. In addition, they must comply to the terms of use for all third party services and APIs utilized by their plugins. If there is no way to validate the licensing of a library or the terms of an API, then they cannot be used.

Theme Requirement:

- Be 100% GPL and/or 100% GPL-compatible licensed
- Declare copyright and license explicitly. Use the license and license URI header slugs to style.css
- Declare licenses of any resources included such as fonts or images.

Requiring a list of the URLs with the license terms that apply to the various assets isn't onerous on the authors.

SaaS:

Plugin Requirement:

6. Software as a Service is permitted.
The service itself must be [...] clearly documented in the readme file submitted with the plugin, preferably with a link to the service’s Terms of Use.

Requiring a list of the URLs with the Terms of Service that apply to any SaaS element isn't onerous on the authors.

Contacting third party sites:

Plugin Requirement:

7.  Plugins may not track users without their consent.
In the interest of protecting user privacy, plugins may not contact external servers without explicit and authorized consent. This is commonly done via an ‘opt in’ method, requiring registration with a service or a checkbox within the plugin settings. Documentation on how any user data is collected, and used, should be included in the plugin’s readme, preferably with a clearly stated privacy policy.

Theme Requirement:

Don’t ‘phone home’ without informed user consent. Make any collection of user data “opt-in” only and have a theme option that is set to disabled by default.

Requiring links to the privacy policies applicable to all calls to external servers is clearly reasonable, as plugin and theme authors should already be providing these anyway.

Plugins may also not send executable code via third party systems.
The suggested headers for the disclosures.json file would make it easier to evaluate whether external calls comply with this requirement or not.

Credits:

Plugin requirement:

10. Plugins may not embed external links or credits on the public site without explicitly asking the user’s permission.
All “Powered By” or credit displays and links included in the plugin code must be optional and default to not show on users’ front-facing websites. Users must opt-in to displaying any and all credits and links via clearly stated and understandable choices, not buried in the terms of use or documentation. Plugins may not require credit or links be displayed in order to function.

Theme Requirement:

Themes may have a single footer credit link, which is restricted to the Theme URI or Author URI defined in style.css
Themes may also have an additional footer credit link pointing to WordPress.org

Requiring that authors declare if they ask for backlinks is reasonable.

Advertising:

Plugin Requirement:

11. Plugins should not hijack the admin dashboard
Upgrade prompts, notices, alerts, and the like must be limited in scope and used sparingly, be that contextually or only on the plugin’s setting page. Site wide notices or embedded dashboard widgets must be dismissible or self-dismiss when resolved.

Theme Requirement:

Themes should not display “obtrusive” upselling.

Requiring that authors declare upfront if they advertise in wp-admin is clearly reasonable and it allows the potential user to decide upfront if they are okay with some advertising in exchange for free code.

If these items are confusing or authors are not aware of them, then we have bigger problems...
These items are also checked during plugin and theme reviews, respectively.
This change would effectively only be that the information needs to be provided in a standardized place, in a standardized format.

This will also make it a lot easier for reviewers.
(which is also incidentally why I proposed splitting the advertising into three, based on the location of the advertising - as doing so will make it easier for reviewers / potential users to decide whether or not it is obtrusive).

External calls are split into three (based on the language), as this will affect additional checks that are planned for high risk / high impact functions later on.

[burtrw]

Wanted to second @xkon in combining headers where possible, especially 'external calls' and 'sets cookies'. For end-users, not sure most would care about the types?

Also, is it possible to support either PPI Export or PPI Erasure but not both? Even if possible to only support one and not both, could we sort of better encourage best practices of supporting both by combining that into one? So you'd have to say 'false' if you only supported export but not erasure, for example.

As for 3rd party audit, as a plugin author wanting to give some sort of exposure to practices we follow, I like it. For example, it is automated, but reviews by ​https://www.ripstech.com/ could be included? But of all the headers proposed, I wouldn't fight for keeping 3rd party audit too hard, as maybe that does introduce its own complications.

I also don't think I fully understand the SaaS header :)

[garrett-eclipse]

Concerning plugin privacy audits there was a draft workflow here;
​https://docs.google.com/document/d/1R60_9SzeoAVDV7LZ6O5TT5Ppef9i3HL9nmT9oqI6SBs/edit

This was recently re-raised in #core-privacy to look into revisiting and finalizing it.

[SergeyBiryukov]

Just making it clear that this was closed in favor of #51092, as the fixed resolution generally implies that something was committed to core.

[garrett-eclipse]

Dropping privacy focus as it's already in the Privacy component.