Add compliance tab to plugin repository pages on WordPress.org

[katwhite]

Overview

"Compliance tab" is a working title that can be amended to be less intimidating and/or more generalized.

The benefit of this tab is to provide WordPress site owners who are researching plugins with privacy, accessibility, and other information to determine if this plugin will meet their site needs prior to installation and activation.

Ideally, this information can also be used in search and filter scenarios on WordPress.org to find tools compatible with the needs of site owners.

Privacy

A privacy statement could include testing done against specific regulatory standards, and a statement of where data is transferred and stored at rest. It should also include any statements that need to be added to a site owner's privacy policy as part of using this plugin.

This could potentially leverage the privacy policy post box information currently available under Settings > Privacy, added in WordPress 4.9.6.

Accessibility

An accessibility statement could include the WCAG level that the plugin targets (A, AA, etc) and where to file any issues found.

Security

A security statement should include code standards followed, measures taken, and who to contact if you find a vulnerability.

Certifications

Any certifications that this plugin has undergone for compliance.

[red_ninja]

I think this is very good idea. Nice work privacy team.

[burtrw]

As a plugin author, we would love to have a standardized way to share this information and help with what we should be sharing.

The current way of adding to Settings > Privacy is hidden and only found by the average user (that won't dig through the code) after the plugin is installed and activated.

[katwhite]

Note: This ticket was submitted by the core-privacy team as part of WordCampUS 2019 contributor day.

[Otto42]

For this to happen, you would need to define the desired goals, essentially.

What does this information consist of? What would it look like?

Would it be displayed in the plugin details screen in core (example would be /wp-admin/plugin-install.php?tab=plugin-information&plugin=akismet screen)?

How it is displayed and where would be needed to define how to implement this. Once you know where you're going with it, then you'll know how to get there. :)

[katwhite]

@Otto42 thanks so much for the feedback. Is there a standard deliverable format for defining goals like this? Are you looking for UI mockups or suggested content for additional standard sections on the​readme.txt template?

Happy to provide whatever makes sense, but as this is my first one of these tickets, I'm not quite sure what the expected approach is for the team to articulate our ideal presentation of this information for further consideration.

[Otto42]

Discussion reference: ​https://wordpress.slack.com/archives/C9695RJBW/p1572813523139500

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the ticket.

Just noting that this Trac is used for enhancements and bug reporting for the WordPress core software.

Any ideas, enhancements, or bug reports for WordPress.org sites, including Plugin Directory, should be submitted on ​https://meta.trac.wordpress.org.

[Otto42]

Replying to SergeyBiryukov:

Just noting that this Trac is used for enhancements and bug reporting for the WordPress core software.

Yes, there is some uncertainty as to the scope of the idea, so core is appropriate for now, since it would affect core depending on the changes needed. If it changes, we'll redirect it to the proper place, as needed.

[afercia]

Discussed during today's accessibility bug-scrub: the accessibility team definitely seconds this proposal, for obvious reasons :) But yes, it's related to meta and should be moved there, though we'd recommend some dedicated discussion during Slack dev chat.

[Ipstenu]

I just now got caught up on this.

Some thoughts, and it begins with this:

If we can AUTOMATE this, it's better.

Whenever you ask the developers to self-claim this stuff, then they're either going to paint themselves in the best light OR not at all. The fewer people who use this, the less useful anything is. Also remember the more you ask volunteers to monitor and manage, the more likely you are to get things missed.

So think about what you can do automagically without the developer needed to do a thing. That'll get the best and most trusted results.

Also it's unclear what specific issue you're trying to solve with each subsection.

With that in mind. Having seen @Carike's example, there are some parts that just aren't going to work.

The tab name (Privacy Related Considerations) is problematic. I would recommend just ‘Privacy’ - one word. That makes it harder for people to typo (remember we have a large number of ESL devs, let’s make things easier for them). It's broad, I know.

All those subsections should be clearly optional. And we need to be clear that if someone wants to link to their webpage where everything is leagaleezed. Speaking of that, I see no mention of 'Terms of Use' or a link to Privacy docs. Both of those are things we regularly ask for.

Contractual Terms as a sub-section is odd and, much like ‘installation instructions’ would be pointless for most plugins. They don't apply to the majority of plugins, and I can't think of where they'd apply outside of serviceware.

Cron Jobs and Credits don’t seem to belong there at all. They really have nothing to do with privacy. The only reason I can think to put either in is that the cron-job is used to connect to an external service (which should be disclosed in this as a subsection for 'External Services Used') and 'credits' is meant to be "The license for the font library I use is..." which should probably be in a 'Licenses' subsection.

The consent api subsection is unneeded. Either you're compliant or you're not. And if you're not, why on earth would you say it? If you really feel this is needed, then make it a new header like 'PHP Compatibility.' In fact, ANYTHING that is a Yes/No answer should be there. Less work :)

Accessibility shouldn’t be a section. In a perfect world, it’s a yes/no flag assigned to a plugin after it’s reviewed by a member of the a11y team (or a robot we can teach to do that…) and confirmed (much like we auto flag plugins for being translatable). Put it on the sidebar “Accessibility Verified {YES!}” (I am well aware we don't have a tool that can do this, nor do we have a team with the infrastructure to manage -- I still strongly feel that asking a developer to self-declare accessibility will have net negative results. They're going to be wrong, either intentionally or due to not understanding, and that would be worse for users who need this.)

Security as a tab is sadly pointless. Needed, yes, but it’s not going to be used properly and that makes it useless. This would be a place where TIDE comes into play. Tide scan on security etc linked on the sidebar would suffice and be more useful than trusting Joe Random.

Certifications/Compliance - We have a guideline that says a plugin cannot state or claim or imply that it is 100% compliant with anything because that’s just impossible. This would not be as helpful as one might think.

[Ipstenu]

I want to toss in one more note.

We've got a LOT of disparate aspects of this in one ticket. This is huge. So I suggest everyone start smaller.

What do we NEED? What do we WANT?

We need a dedicated TAB where Developers can put information regarding what their plugin does, what data it calls remotely (i.e. fonts and APIs), what data it SENDS (APIs again), and links to privacy/ToS so people can be informed before they install and use a plugin.

We need to make this easy (or else no one will use it) and not prone to fits of creativity (or it will be too confusing and useless to end users).

We need this to be simple.

Right now it's way too big a concept, spread out over the whole place, to be that.

So step back. What's the basic START we can have?

Dream big, yes, think about all the wants like something like the block scanner that scrapes everything that calls remote data. But accept that the inherent nature of plugins (that is, they are there to do ANYTHING) will make any sort of scanner impossible to be 100% accurate.

That means no matter WHAT we do, we're relying on humans. So lets make this easier for humans.

If you wanted to do it outside of WP, you'd have a form someone filled in with the information:

• Use fonts - yes/no. If yes, link to font library (i.e. google, FontAwesome)
• Use external API - yes/no. If yes, link to the API and it's ToS

Maybe this could be as easy as more headers in the readme.txt, and we teach the checker to see "IF fonts are set to TRUE, then REQUIRE the links."

Follow that up with scripting a readme validator into the plugin uploader (sorry @tellyworth and @Otto42 ) and maybe throw in an SVN scan for it on plugin update. Readme doesn't validate? No update for you!

Of course people will just leave things out, but that's a heck of a lot easier to close and tell them "Hey, you didn't document." In fact, it's the same as it is today, with a little more automation.

But start with "We need this tab, and we need a quick and easy format for people to follow."

[carike]

Hallo everyone :)

Created an example readme.txt here: ​https://github.com/carike-codes/disclosures-and-permissions-tabs/blob/master/README.txt
It is the one @Ipstenu based her comments on.

It appears that the readme.txt may not be the ideal way to deal with disclosures.

I have an idea how to automate a significant portion of the disclosures, but need feedback.

You're welcome to comment on this ticket. I will copy over comments (linking to the original here) to issues in the GitHub repository here: ​https://github.com/carike-codes/disclosures-and-permissions-tabs/
The GitHub repository was set up in response to requests in #core-privacy.
I can't reasonably ask developers who would like to help to go read through the threads in all of the related tickets to find any constraint that could apply to their Pull Request, so summarizing design considerations under (regularly updated) issues.
I'll cross-update this ticket periodically with progress too.

Permission levels are currently a fixed list proposed by @rogierlankhorst in #core-privacy: Functional; Anonymous Statistics; Statistics and Marketing.
The question becomes what is the best way for plugin authors to indicate which particular permission level each of their (relevant) functions need.
Discussions documented here: ​https://github.com/carike-codes/disclosures-and-permissions-tabs/issues/3

I propose that this only applies to "high risk / high impact" core functions / APIs for now.
We need to define what those would be. Thus far proposing the HTTP API and wp_mail().
Would also like to include set_cookie(), although that may be more complicated since it is a PHP function and not a WordPress one. Record of discussions here: ​https://github.com/carike-codes/disclosures-and-permissions-tabs/issues/4.
I do have an (abstract) idea of how external network calls with JavaScript / CSS can be dealt with, but need to outline it first, so not addressing it here yet.

One (design) option would be to add an additional argument for $purpose (fixed list for permission level as per the above) to "high risk / high impact" functions. I need feedback from core contributors as to how difficult this would be.
The value of the variable just needs to be available for use by plugin (Feature as a Plugin), to populate the Disclosure / Permissions Tabs.

I can also explain how existing plugins would be affected by Disclosures and Permissions Tabs.
I'll update here as soon as I have written it all down.

[Ipstenu]

@carike Keeping discussions in ONE place will make it easier for everyone to follow along and reduce the loss of comments. It's recommended we either use this, or the official github, but we strongly discourage the use of personal git repos. I've been guilty of it in the past, but it tends to cause confusion about what's official and what's not. You're welcome to copy stuff over, of course, but things should be here, with the same readme uploaded as a file for people to look at. :)

There's nothing bad about a readme, it just has flaws. To be clear, so will any automated testing/scanning we invent. We're going to need both.

But those are actually separate projects.

THIS TICKET is to add a COMPLIANCE TAB to the WP.org plugin page.

Full stop, okay?

We need to define what that means, in PLAIN LANGUAGE, so it can be readily understood by as many people as possible.

I recommend a SECOND ticket for "Automated scanning of external services to be included on the wp.org page"

In THAT ticket we can discuss what needs to be looked for, and how it should be generated.

But I want to stress, these are NOT the same thing. Conflating it all into one will make this impossible to achieve. And we absolutely need BOTH.

Now I remember one of the early concerns is that the info should be in the plugin as well as the repo page. And we don't want to duplicate effort (otherwise people just ... won't).

The only alternative I can think of is a json file that gets read by the .org repo

@tellyworth is that even possible? If not, we're stuck with the readme. If SO, let's use this ticket to work on the best and easiest way to have a json or xml file, with a standard name that goes in the MAIN folder of a plugin, and will be used to generate the privacy tab.

Yes, that will be manual effort by developers, but then in the OTHER ticket (which I think @carike should make, since they have a clearer vision of this) we can talk about auto-generating data in that tab, like we do for blocks. Combined, that will be our best bet at getting people informed.

Bonus? If you see a plugin has a lot of external calls without any explanations from that json/xml/whatever file, you can alert people :)

Third (future) step would be AFTER we have that scanner, incorporate it into the plugin uploader and/or SVN to stop abuse before it happens. But that's down the road a long ways.

Achievable steps.

[carike]

LOTS of stuff to reply to :) Won't be able to get to everything right now, but will get to it.

Tried to include the readme.txt as a file, but apparently that button is meant for a link. LOL.
So, until I figure that out, here it is as a code block:

=== Disclosures and Permissions Tabs ===
Contributors: Carike
Tags: disclosures, permissions, privacy, security
Requires at least: 4.9
Requires PHP: 5.6
License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html

CODE IS NOT FUNCTIONAL YET.  Experimental plugin.  For discussion / development.  Intended as Feature as a Plugin.

== Description ==

VISION STATEMENT:

* We believe that privacy is a strategic competitive advantage.
* This Feature as a Plugin follows a risk-based, as opposed to a compliance-based approach to privacy choices.
* We firmly believe that if your aim is informed consent and you act in good faith at all times, then you are almost certain to come down on the "right" side of legislation.

MISSION STATEMENT:

Thus far many site owners have relied solely on their user experience / visual elements created by a plugin when choosing which of the many plugins fulfilling a particular function to install. We aim to change that.

* DPT seeks to allow website admins / owners to make more informed choices when comparing plugins by facilitating plugin developers' ability to disclose what information is collected from their site and / or their users in a format that makes it understandable for an average user.
* DPT aims to do this by rationally standardizing privacy options within the WordPress ecosystem.
* DPT was developed with the hope of leveraging unrealized synergies.
* DPT does not directly address https://core.trac.wordpress.org/ticket/48486, which only addresses an additional tab to the plugin page on the WordPress.org repository; however, it does seek to compliment it.
* DPT does not seek to replace the Consent API, however, it does seek to compliment it. You can find the Consent API at: https://github.com/rlankhorst/wp-consent-level-api/blob/master/readme.txt
* DPT hopes to assist in implementing sensible guidelines for plugins to advertise premium offerings, to hopefully enable plugin developers to monetize their content without alienating the user-base.

== Installation ==

The code in this plugin is not yet functional.
Intended for discussion / development only.
Until such time as it is submitted to the WordPress plugin repository, you will need to download a .zip folder via GitHub and upload the .zip folder under your /wp-admin/ plugins menu.

== Frequently Asked Questions ==

= Is this plugin functional? =

No.  This code is not yet functional.  It is intended for discussion and development.

= What does this plugin do? =

This plugin is intended as a Feature as a Plugin, which means it will hopefully be included in WordPress core some day soon.
The DPT plugin creates two sub-menus under the Plugins tab in the /wp-admin/ area; namely Disclosures and Permissions.
The Disclosures tab provides those with "manage options" capabilities with privacy related disclosures.
A copy of such disclosures is also available on the plugin's WordPress.org repository page.
The Permissions tab provides those with "manage options" capabilities with privacy related options.
Site administrators / owners can turn off permissions for marketing; statistics; and / or anonymous statistics on a site-wide basis; or they can do so on a plugin-by-plugin basis; or they can manage individual permissions (e.g. an external network call to example.com by plugin XYZ) on a plugin-by-plugin basis.

= Does this plugin guarantee GDPR compliance? =

No.

== Changelog == 

= 0.0.0. =
Version for discussion.  Code is not yet functional.

== Privacy Related Considerations ==

= Applicable Regulatory Standards =

The DPT plugin has not been tested against any specific regulatory standard.
It does not, nor does it claim to, comply with any specific regulatory standard.
The site administrator / owner is advised to exercise their best judgement whether this plugin is suitable for use within the regulatory frameworks in which they operate and to seek out legal advice if necessary.

= Contractual Terms =

Your use of the DPT plugin is subject to the license terms of the GNU General Public License 2.0. or later.

The DPT plugin does not seek to create any contractual relationship with you, other than those covered by the above license.
The DPT plugin does not operate as Software as a Service.

= Consent API Compatibility =

The DPT plugin aims to be compatible with the Consent API.

= Disclosure and Permissions Tabs Compatibility =

The DPT plugin aims to be compatible with the Disclosure and Permissions Tabs.

= Cookies =

The DPT plugin does not set any cookies.
The DPT plugin reserves the right to set cookies in future versions of the plugin, if this is in the best interests of its development, subject to providing the appropriate disclosures in that future version of the plugin's readme.txt file.

= External Network Calls =

The DPT plugin does not send any external network calls.
The DPT plugin reserves the right to make external network calls in future versions of the plugin, if this is in the best interests of its development, subject to providing the appropriate disclosures in that future version of the plugin's readme.txt file.

= Cron Jobs =

The DPT plugin does not create any cron jobs.
The DPT plugin reserves the right to create cron jobs in future versions of the plugin, if this is in the best interests of its development, subject to providing the appropriate disclosures in that future version of the plugin's readme.txt file.

= Mail =

The DPT plugin may attempt to send notifications to administrators, based on their e-mail notification settings.
Such e-mails are classified as functional and / or may contain security related information.
The site administrator / owner may choose to opt out from such notices on behalf of all users by visiting the Permissions Tab under the Plugins menu in /wp-admin/; however, this is NOT advisable, due to the functional nature of the notifications.

= Advertising =

The DPT plugin does not currently contain advertisements.
The DPT plugin reserves the right to display advertisements on the plugin's settings page; the plugin list page, as well as the dashboard in the /wp-admin/ area.
We endeavour to comply with any Guidelines pertaining to advertisements set by repositories that we submit to.
Any advertisements set by the DPT plugin should be dismiss-able by a user with the "manage options" capability visiting the Permissions settings page under the Plugins tab in the /wp-admin/ area.

= Credits =

The WordPress.org repository's Guidelines requires opt-in consent if credits are to be displayed to users on the site's front end.
The DPT plugin does not currently seek to set credits on the front end.

== Accessibility ==

As the DPT plugin does not have a focus on presentation elements, it does not seek to target any specific WCAG 2.0. level.
The accessibility of this plugin should be roughly equivalent to that of the /wp-admin/ area in general.

== Security ==

The DPT plugin does not aim to conform to any specific security framework.

The DPT plugin does seek to conform to WordPress.org repository best practices, including as they relate to security.
If you would like to help keep the WordPress.org ecosystem safe for the community and you have spotted a possible vulnerability in this plugin, please use the "Report This Plugin" button provided.
If you suspect that this plugin itself constitutes an exploit, please choose the option to notify only the Plugin Team.  An e-mail will be sent to them.  Members of the Plugins Team are volunteers, so please allow some time for them to respond.
If you would like to inform the developer of the suspected exploit, please select the appropriate option.  You may choose to include your contact details to the developer or not.
Please note that your contact details may be used to assist you with the resolution of your query and may be processed and stored in accordance with the WordPress.org and the developer's privacy policies (if applicable).
Please include Proof of Concept if you can, as well as as many other details as possible.
Please note that the "Report This Plugin" is not a support channel.  Any e-mails not related to security vulnerabilities will not be responded to.

== Certifications ==

The DPT has not undergone any certifications with regards to compliance.

The plugin is provided in accordance with the GNU 2.0. General Public License (or later) and as such, is offered "as is" and expressly offers no warranties or guarantees of any kind, including, but not limited to, fitness for any purpose.

I'll jump through whatever documentation hoops I need to (which I guess includes figuring out how to use the official repo).
Just relying on the ticketing system contributed to a lot of friction for other projects, so I'll copy over and see if that helps.

There's nothing bad about a readme, it just has flaws. To be clear, so will any automated testing/scanning we invent. We're going to need both.

I agree 100%.
The issues people have mentioned in Slack is that the readme.txt is not translation-ready.
It would also be good to have the Disclosures on a tab in the user's installation, in addition to having it in the WordPress.org repository plugin page.

Just to make it very clear to everyone, I don't expect that one single measure will address all the issues that come up. I follow a risk-based approach, not a compliance-based approach.

I also don't expect that all of this will be part of a version 1.
Trying to articulate a vision for a v3 or even a v4.

I actually think that deciding on yes / no headers is a great place to start for v1.

Deciding what needs to be disclosed is key.

I would simply like to see a solution that would enable some level of "checking" / audit of what plugin authors disclose.

I realize parts of that may be considered as advanced tools and may not be considered suitable for inclusion in core.

And I am okay with that :)
Changes aren't an insult :)

[carike]

Version 2 of the Example Readme.txt :)

=== Disclosures and Permissions Tabs ===
Contributors: Carike
Tags: disclosures, permissions, privacy, security
Requires at least: 4.9
Requires PHP: 5.6
License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Consent API: TRUE
Disclosures Tab: TRUE
External Network Calls PHP: FALSE
External Network Calls JavaScript: FALSE
External Network Calls CSS: FALSE
SaaS: FALSE
Calls to External APIs: FALSE
Remote Assets: FALSE
Sets Cookies: FALSE
Writes to DB: FALSE
Creates Custom Post Type: FALSE
Creates Custom Table: FALSE
Stores PPI: FALSE
Sends e-mails: TRUE
Advertising on Dashboard: FALSE
Advertising on Plugins List: FALSE
Advertising on Plugin Setting Page: FALSE
Asks for Backlinks: FALSE
Code Audited by Third Party: FALSE

CODE IS NOT FUNCTIONAL YET.  Experimental plugin.  For discussion / development.  Intended as Feature as a Plugin.

== Description ==

VISION STATEMENT:

* We believe that privacy is a strategic competitive advantage.
* This Feature as a Plugin follows a risk-based, as opposed to a compliance-based approach to privacy choices.
* We firmly believe that if your aim is informed consent and you act in good faith at all times, then you are almost certain to come down on the "right" side of legislation.

MISSION STATEMENT:

Thus far many site owners have relied solely on their user experience / visual elements created by a plugin when choosing which of the many plugins fulfilling a particular function to install. We aim to change that.

* DPT seeks to allow website admins / owners to make more informed choices when comparing plugins by facilitating plugin developers' ability to disclose what information is collected from their site and / or their users in a format that makes it understandable for an average user.
* DPT aims to do this by rationally standardizing privacy options within the WordPress ecosystem.
* DPT was developed with the hope of leveraging unrealized synergies.
* DPT does not directly address https://core.trac.wordpress.org/ticket/48486, which only addresses an additional tab to the plugin page on the WordPress.org repository; however, it does seek to compliment it.
* DPT does not seek to replace the Consent API, however, it does seek to compliment it. You can find the Consent API at: https://github.com/rlankhorst/wp-consent-level-api/blob/master/readme.txt
* DPT hopes to assist in implementing sensible guidelines for plugins to advertise premium offerings, to hopefully enable plugin developers to monetize their content without alienating the user-base.

== Installation ==

The code in this plugin is not yet functional.
Intended for discussion / development only.
Until such time as it is submitted to the WordPress plugin repository, you will need to download a .zip folder via GitHub and upload the .zip folder under your /wp-admin/ plugins menu.

== Frequently Asked Questions ==

= Is this plugin functional? =

No.  This code is not yet functional.  It is intended for discussion and development.

= What does this plugin do? =

This plugin is intended as a Feature as a Plugin, which means it will hopefully be included in WordPress core some day soon.
The DPT plugin creates two sub-menus under the Plugins tab in the /wp-admin/ area; namely Disclosures and Permissions.
The Disclosures tab provides those with "manage options" capabilities with privacy related disclosures.
A copy of such disclosures is also available on the plugin's WordPress.org repository page.
The Permissions tab provides those with "manage options" capabilities with privacy related options.
Site administrators / owners can turn off permissions for marketing; statistics; and / or anonymous statistics on a site-wide basis; or they can do so on a plugin-by-plugin basis; or they can manage individual permissions (e.g. an external network call to example.com by plugin XYZ) on a plugin-by-plugin basis.

= Does this plugin guarantee GDPR compliance? =

No.

== Changelog == 

= 0.0.1. =

For discussion purposes only.  Code is not yet functional.

Updated readme.txt:

"Privacy", "Security", "Accessibility" and "Certifications" sections were removed in favour of headers.
Headers should default to FALSE (when parsed), unless explicitly declared as TRUE.

"Privacy" section:

1. Declaring compatibility with privacy tools:
1.1. Removed "Consent API Compatibility" section;
1.1.1. Added header for "Consent API";
1.2. Removed "Disclosures and Permissions Tabs compatibility" section;
1.2.1. Added header for "Disclosures Tab";

2. Helping the site administrator / owner understand how the plugin communicates with other sites:
2.1. Removed "External Network Calls" sub-section;
2.1.1. Added header for "External Network Calls PHP";
2.1.2. Added header for "External Network Calls JavaScript";
2.1.3. Added header for "External Network Calls CSS";
These were split as they may generally be associated with varying levels of risk.

3. Contractual Terms other than the GNU GPL License that may apply to use of the plugin:
3.1. Removed "Contractual Terms" section;
3.1.1. Added header for "SaaS";
Intended for cases where the plugin requires an account with a third party.
E.g. Accounting software
3.1.2. Added header for "Calls to External APIs";
Intended for cases where an account with the third party is not necessarily required.
E.g. Add To Any Social Sharing Buttons
3.1.3. Added header for "Remote Assets";
Intended for cases where information is fetched from a third party domain.
E.g. external loading of fonts / images / etc.

If the plugin author sets any of these headers as TRUE, they need to provide a comma-separated list to the Terms of Service / license terms for each instance.

4. Helping the site administrator / owner understand how the plugin collects user data:
4.1. Removed "Cookies" sub-section / Added header for "Sets Cookies";

5. Helping the site administrator / owner understand the ways in which the plugin processes / stores user data:
5.1. Removed "Cron Jobs" sub-section;
5.1.1. This remains relevant to the Disclosures and Permissions Tabs, but is excluded from the recommended readme.txt.
5.2. Added header for "Writes to DB";
5.2.1. This is intended for any instance in which the plugin writes to the MySQL / MariaDB database;
5.3. Added header for "Creates Custom Post Type";
5.4. Added header for "Creates Custom Table";
5.5. Added header for "Stores PPI";
Intended for plugins that store Personally Identifiable Information (e.g. creates entries in the user_meta table).

6. Helping the site administrator / owner understand other ways in which the plugin can send user data:
6.2. Removed "Mail" sub-section;
6.2.1. Added header for "Sends e-mails";

7. The site administrator / owner as a customer:
7.1. Removed "Advertising" sub-section;
7.1.1. Added header for "Advertising on Dashboard";
7.1.2. Added header for "Advertising on Plugins List";
7.1.3. Added header for "Advertising on Plugin Settings Page";
7.2. Removed "Credits" sub-section;
7.2.1. Added header for "Asks for Backlinks";

8.1. Removed "Applicable Regulartory Standards" section
8.1.1. Alternatives to be considered and discussed.

"Security" section 

9.1. Removed "Security" section;
9.1.1. "Report this Plugin" button in sidebar recommended (with appropriate measures to help prevent abuse);

"Accessibility" section

10.1. Removed "Accessibility section;
10.1.1. Automated tools are not currently available.
10.1.2. Alternatives to be considered and discussed.

"Certifications" section

11.1. Removed section regarding Certifications;
11.1.1. Added header for "Code Audited by Third Party".

= 0.0.0. =
Version for discussion.  Code is not yet functional.

Cross-posted here: ​https://github.com/carike-codes/disclosures-and-permissions-tabs/blob/0.0.1/readme.txt for now.

[carike]

Just because it can be difficult to find conversations in Slack later:

Initial objections to using headers:
​https://wordpress.slack.com/archives/C9695RJBW/p1576608710098600?thread_ts=1576580192.092000

It is quite a comprehensive conversation.

Some reasons for using headers:
​https://wordpress.slack.com/archives/C9695RJBW/p1576612494158500 Friendlier towards those whose first language is not English @Ipstenu;
​https://wordpress.slack.com/archives/C9695RJBW/p1574339135277400 Free text in the Readme.txt is not translation-ready @tobifjellner;
​https://wordpress.slack.com/archives/C9695RJBW/p1576675896233700 Available in the get_plugins(); function when using a foreach loop @carike;
​https://wordpress.slack.com/archives/C9695RJBW/p1576613987168400 Manual disclosure serves as a reference point for checking credibility @carike.

[carike]

More discussions about Disclosure Tab in the #core-privacy meeting.
​https://wordpress.slack.com/archives/C9695RJBW/p1576697592324100

[xkon]

Discussion on finalizing headers and a way of supporting & reading them has been split to #49272.

[ryokuhi]

This ticket has been reviewed by the accessibility team a few times during the last months.
As a general idea, the team finds this proposal valuable, as it might be a good way to make to encourage plugins to have a more active approach towards accessibility.

Unfortunately, it would be very hard to make the accessibility claims included in the compliance tab verifiable: only some aspects of accessibility can be tested using automated checks and the accessibility team does not have enough resources to really test plugins for accessibility. As such, information included in the compliance tab can only be self-reported and, as such, probably not really helpful.

Also, it isn't clear where the compliance tab would appear: if it appears in the plugin repository, then it will be better to move the discussion about this feature to the Meta Trac and then work from there.

Because of all the above, and given that there hasn't been movement on this ticket for quite some time, it isn't clear what contribution the accessibility team can give to push this ticket forward, at least at the moment. As such, we agreed to remove the accessiblity focus from this ticket. If, at any time in the future, the involvement of the accessibility team in this ticket will be of any help, feel free to add it back.