Plugin Directory: Field on plugin info page for GDPR data collection Privacy

[brothman01]

Add a field to every plugin page (populated in the readme header for that plugin) that simply says something like "Collects Data?" and is either a yes or a no. There maybe ways of changing this field to convey the information more easily, or adding follow-up fields but since GDPR and data privacy are increasingly important these days, this would be a relatively easy to implement, light tech-lift solution that would most likely greatly improve user experience all over the community and make WordPress a better experience. Many users are trying to make sure their website is GDPR compliant and adding this functionality would make that process a lot more pleasant and manageable.

[Otto42]

It would be against the general plugin guidelines to have a "yes" there, because all data gathering is opt-in only.

[joostdevalk]

I think that's slightly too easy a close by @Otto42, so I will re-open it. I do think there's value in adding a field for a couple of reasons, outlined below.

I agree with @Otto42 that I think the only possible values should be no and opt-in for plugins hosted on the WordPress repository. Would be very helpful for premium plugins that do collect data if they set it to yes.

When it's opt-in, at least the site owner knows to look for the settings and find that.

On WordPress.org, we might want to enforce a section of the readme that explains what is tracked and where if you opt-in.

I also know that some of the things that have been allowed historically should probably be looked at again: loading RSS feeds from other sites is an example.

[alanfuller]

The original proposal to have a yes / no is too simplistic to be of any use, regardless of the fact that plugins should not be sending data without consent. Also the concept "Collects Data" goes beyond sending data and covers storing data locally, which plugins can of course do, but again too simplistic to be of any use regarding privacy laws. Most privacy laws relate to personal data,not any old data.

A section in the readme is a valid way of communicating functionality relating to privacy and many plugins already do this when they think it is important.

I don't think there is any shortcut for due diligence of the plugin user and forcing plugin authors to warrant compliance with any law would be rather against the GPL wording, namely

"THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION."

[brothman01]

At first I was going to say "yes I agree with @joostdevalk" but then I saw that @alanfuller ALSO said it, so +1 to both.

I really like the idea of a section in the readme where the author describes the type of data being collected and how it is stored. That tab will be a user-friendly part of the the "due dilligence". If we now want a section then it sounds like we would want a new tab on the plugin page showing the information rather than just a field, and for the sake of keeping compatibility with existing plugins the tab would have to be optional.

[dd32]

I'm personally a -1 on adding a boolean yes/no field.

I'm also against an entire readme section/tab on GDPR-specific things or Data-collection specific things.

BUT it should be expected that plugins that collect and use data explicitly state this in the readme description in addition to explicit user opt-in inside the plugin. This is inline with ​Guideline 7 which requires both.

A plugin may choose to state in their readme description that they do not collect user data. I'm not sure a large number actually do this.

---

Now, I understand why that might seem overly negative, but basically I feel that if we were to add something like this, then we've got the police it, we've got to audit what is inside it, we've got to explicitly check for it. Just like plugins ​can't claim to resolve legal things I don't think a plugin can 100% guarantee it's intentions purely through a yes/no or through a readme section that then an author may think means they don't need to update their plugin to have an opt-in, or have a proper privacy policy linked, etc.

[brothman01]

@dd32 I hear what you are saying and thanks for the perspective but this is not a required field. The GDPR Description would be an optional section of the readme that is satisfied as long as the header is there.

This is not something that was intended to be policed either. This is a "good faith effort" by plugin authors to tell users about their plugin and to make user experience and due diligence more user-friendly. There are enough honest/smart people in the WordPress community that this section (not field anymore) would be filled in correctly more often than not.

We can talk about what should be happening in the readme and the plugin but is that what is really happening? The purpose of this section would be obvious and so give the information quickly and efficiently.

That being said, the real, trustworthy diligence (section or no section) for larger sites would have to be up to a developer to check but at least this feature would give that developer a starting point for investigations. And as for users not thinking they need an opt-in, we can add a disclaimer that this is not legally binding.

[dd32]

Replying to brothman01:

I hear what you are saying and thanks for the perspective but this is not a required field. The GDPR Description would be an optional section of the readme that is satisfied as long as the header is there.

Optional or required doesn't make a great difference, the majority of plugin authors just copy-paste what exists in the default readme.

This is not something that was intended to be policed either.

That would make it almost useless then, as one can't rely upon the information placed within it. Those who make a good faith effort will be competing against those who don't, and just say they're compliant without thinking.

An honest developer can include these details already.

We can talk about what should be happening in the readme and the plugin but is that what is really happening?

The solution to a potential problem of developers not abiding by guidelines is to enforce guidelines, not introduce a method for those that do abide by it to make it clear.

If a plugin is not abiding by the guidelines, they should be reported and that resolved.

[brothman01]

@dd32 ok those are fairly good points and it seems to me that you have a great deal more experience with plugin authors than I do, so it sounds like you are saying that many of them they won't use the section. The issue I am trying to resolve here is that I am concerned that WordPress does not have enough in place to handle GDPR compliance. Maybe they do, and what I am suggesting is overkill. Do you think the current measures in WP are enough for GDPR compliance?

[alanfuller]

Replying to brothman01:

The issue I am trying to resolve here is that I am concerned that WordPress does not have enough in place to handle GDPR compliance. Maybe they do, and what I am suggesting is overkill. Do you think the current measures in WP are enough for GDPR compliance?

OK for clarity, compliance of GDPR is not with software or software provders but the Data Controller.

When a Data controller selects a software solution and implements it they are meant to implement it in such as way that the Data Controller is compliant.

In the case where a Data Controller selects software that they identify that transmits personal data to a third party, that third party is known as a Data Processor and the Data Controller is reposonsible to ensure that the third party Data Proceessor protects the personal data in an appropriate manner ( noramlly through a signed Data Processing Agreement with Standard Contractual Clauses ).

The Data Controller also need to identify when software stores personal data on their own systems, not just third parties and to document their own controls for such.

I'm not a lawyer, this is not legal advice just a description to make my point.

A software organisation itself is not the one that needs to be compliant.

What your original request was, was not about WP or plugins being compliant, as they never can be as they are not the entity that needs to comply, but are there tools that can make it easier for Data Processors to work out what they need to do to be compliant.

My opinion is there would be no reliable shortcut to doing proper analaysis by the Data Controller.

I don't know, but I expect that relying in court on some words written in a readme that said no personal data was transmitted and the Data Processor didnt double check and knowing that they agreed to a licence that explicily says 'THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. ' would not be a good defence.

[brothman01]

Notes From Discussion:

• The 'readme' for every plugin has a new section that the template makes into a tab on the plugin page called "Data Collection" where each author can make a "good faith" effort" to describe the data being collected.
• The "Data Collection" section has a disclaimer saying that it is not legally binding and accuracy is not guaranteed.
• I understand that plugins cannot be compliant or non-compliant, this description would be a starting point for the data controller's investigation. @alanfuller