Need clear definition of Explicit Consent for Plugin Guidelines

[drubonil]

Currently plugin guideline states that:

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.

It says, plugins need explicit and authorized consent. I think paragraph need to be more explicit with example. The rule should clear few things:

• Can a Plugin author Pre-Checked the consent with some smart wording?
• Can a plugin author auto-install other unrelated plugins with same pre-checked dark UI method?

As I have reported this issue many times (via slack and email) and did not get any straight-forward answer, I think these things are allowed. So I am proposing the following changes to [the plugin guidelines]​https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#7-plugins-may-not-track-users-without-their-consent

• You can pre-checked checkboxes for the consent to access any data of the website and transfer to your own server for usage tracking
• You can pre-checked checkboxes to install unrelated or related plugins for auto-install
• You may use dark-patterns for these checkboxes for example, you can use the title "Join the [Plugin ShortName] Community" for getting access the usage data and transfer to your server.

If these practices are not allowed in the definition of "Explicit Consent" please add these as an example of that YOU CAN'T DO THESE and Plugin review team should check on the offenders.

I am attaching a screenshot of a plugin that do these. Please note that, tons of plugins use these type of dark patterns. This screenshot is only for a reference. The checkboxes pre pre-checked by default.

For example: Use just click "Save & Continue" which 99% people will do then all the sales data along with plugin, site, theme information will be transferred weekly basis. So I think it's a dark UI (or not!).

[Otto42]

I think the English definition of the words will work just fine. I don't think we need any additional examples.

The given "dark UI", as shown, is within the limits. However, note that a review can mention such UI.

[Otto42]

However, note that no plugin in the directory is allowed to install other plugins in such a manner. See Guideline 8.

[drubonil]

@Otto42 It's sad that the ticket got closed without any proper explanation. In my opinion it's an issue. Even you are saying the plugin is not allowed to install other plugins in such manner so why so many plugins are doing this?
You may say, I should email the plugin team but that does not work as the rule does not say explicitly. Maybe you may tag someone from plugin team.

Thanks again for reconsider this ticket. We all want WordPress as a safe and gentle place. Big companies playing dirty and we can only watch.

[drubonil]

By the in the Rule - 8 in the guideline, It permits to install plugins from wp.org so I don't think EDD violates Rule - 8.

I assume, it violates the number 7 if you define the "explicit consent" properly. I am really sorry that English is not my native language so it will be great if if the guideline states what Explicit Consent Means.

At Europe, "Explicit consent means that a user needs to actively give permission for such options. So the checkboxes should be unchecked by default for everything that's not necessary for the use of the plugin"

[Otto42]

Replying to drubonil:

@Otto42 It's sad that the ticket got closed without any proper explanation.

OK, what explanation do you want?

I do not believe it is a good idea to add such examples to the guidelines because people play "rules lawyers" with them. When the guidelines start getting overly specific, then people will say to us "Well, they didn't say anything about doing X in the guidelines" for every case. The guidelines are fairly general for that reason alone. If we start overly defining everything then people, instead of doing the right thing, work out ways to work around the rules.

Replying to drubonil:

By the in the Rule - 8 in the guideline, It permits to install plugins from wp.org so I don't think EDD violates Rule - 8.

That may be valid, I have not checked. The point is, the plugin review team makes a decision, and you need to report the plugin to the proper people, which is plugins@…. Not post about it on slack, not create a ticket here, but report it as a potential violation, in an email, to the team.

I assume, it violates the number 7 if you define the "explicit consent" properly.

Guideline 7 is all about data tracking. It has nothing to do with installing plugins.

I am really sorry that English is not my native language so it will be great if if the guideline states what Explicit Consent Means.

It means you say yes to something, explicitly. I agree with your understanding that the check box being pre-checked is a "dark pattern", but honestly, I don't really care about that. My suggestion would be to read the the form before you say yes to it.

The plugin team may take a different tack and make a different decision, which is why reporting it to them is a better idea.

Nevertheless, this ticket is about whether we should add examples of the guidelines. I say no to that.

At Europe

I am not in Europe. Presumably neither are the plugin authors.

[Cybr]

you need to report the plugin to the proper people, which is plugins@….

But the post is about updating the rules. Hence, I'm reopening.

I agree with your understanding that the check box being pre-checked is a "dark pattern",

Great, so that covers guidelines 9.

My suggestion would be to read the the form before you say yes to it.

But most people don't read because: they think they already read it (but the text changed), can't comprehend due to a language barrier, can't comprehend due to a learning issue, can't comprehend because they had a brain tumor, or cannot read at all due to other accessibility issues. This list can go on indefinitely, and most of that wouldn't be about ignorance.

There are also well-studied phenomena like 'consent fatigue' and 'banner blindness', which many people suffer from in the face of a large volume of consent requests which they might accept despite not having the time or resources to assess them properly. This is also why different-colored buttons for consent and many other ​dark patterns are being banned in Europe (​summary). Yet, Awesome Motive (EDD, AIOSEO, Thrive, WP Mail SMPT, etc.) is exploiting all of this human behavior; it's about an anti-consumer law, and they armed it to cause harm to many WordPress plugin developers and their users.

The Plugins Team should protect all these people. Expecting everyone to be on your level would be psychopathic.

I am not in Europe. Presumably neither are the plugin authors.

No, but I am. A great deal of other plugin authors are. A vast portion of the WordPress Community is. And ​many more Europeans use WordPress than Americans do.

Non-decisive actions like these ruin the plugin ecosystem. I've already been screwed over by half a dozen violations of Rank Math not getting dealt with; don't let other developers suffer as well.

[Otto42]

Fair enough, I will leave this open for other people to contribute, however, no, I will never agree that we need to make the guidelines more explicit.

The guidelines are "guidelines", not rules. They're what we make of them. When I originally wrote them, I wrote them vague for a reason.

However, the plugin team can make of them what they want.

[josklever]

I agree that overly detailed guidelines increase the risk that people will keep finding holes in the rules. So the rules should be as general as possible.

The big issue here is that plugins don't get the same treatment. Often small(er) plugins get temporarily closed for violating the rules, many times they are small and unintentionally. On the other hand very big plugins and companies owning many plugins (or themes) get away without any action, because nobody dares to speak up to them or they are afraid to get overruled.

So the guidelines should be followed more. Not only for what's written in detail, but how the rules were intended. See it like this: if the rules say "be nice" you don't have to ban all swear words one by one.

In this case plugin authors/owners are taking advantage of users by choosing default options, that are beneficial for these plugin authors/owners instead of their users. That's not how it should be and it will cost them their reputation. And sooner or later they might get law suites. Big companies like Google, Facebook/Meta and Amazon have already been fined for billions.

So I hope the plugins team will do what's best for the users and at the same time help the plugin authors/owners escape big fines. It would be a win-win.

[Otto42]

Replying to josklever:

On the other hand very big plugins and companies owning many plugins (or themes) get away without any action, because nobody dares to speak up to them or they are afraid to get overruled.

I do realize that it can seem that way, but the truth is that we work with plugins authors to solve the problems directly.

We have all the emails of the plugin authors, and the ability to talk to them, with the authority to talk to them about it. We can work with them to solve problems, but only if they're reported. If you don't report a problem, then we don't know about a problem. That is what it comes down to, is people not reporting problems.

Report all problems to the plugins team. It's that simple. They may tell you that your problem is invalid, but that will be the end of it.

The plugins team is made of people. And those people decide on how they want to work thru issues.

[josklever]

Please search for my reports as they are already there. I've even been told they are valid, but nothing has changed in a month (the most recent report about a 7M+ users plugin) and I was told that they can't give me details about how it's handled, which I understand, but some progress would be nice to feel heard and know we're not reporting for nothing.

[Ipstenu]

As a reminder - ​https://github.com/WordPress/wporg-plugin-guidelines exists to track the guidelines

The meta trac should be for the code part of things. The guidelines are a page, and currently copy/pasta'd from that repo.

I would start by suggesting an update to 7 for prohibited examples to add: "Default checking opt-in boxes for non-required features"