Improve checks on non-viable plugin names to prevent abuse

[Ipstenu]

Currently the plugin directory code has a very basic check for disallowed terms in plugin names, including a number of restricted terms as determined by trademark owners. This has the flaw of 'lumping together' reasons why a plugin name is not permitted, causing confusion to the community.

This check ONLY happens on initial submission.

The code is found in https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/shortcodes/class-upload-handler.php

First we check for reserved slugs (aka permalinks that if used could break the .org system in weird ways):

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/shortcodes/class-upload-handler.php#L388

Then we check for trademarked terms (and this is where our trouble begins):

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/shortcodes/class-upload-handler.php#L430

If you read down that list, you'll see we not only prohibit terms like 'wordpress' but also 'wordpess' and 'wpress' and (sadly) 'wp-'

This is due to people getting 'clever' when they receive the error messages and trying to work around the block.

However. The additional reason we flag 'wp-' is that a high percentage of people use it and don't realize that they _can't_ use "WordPress" later on in their display name. So they'll submit "WP PluginName" and, after approval, change it to "WordPress PluginName" which is clearly not okay. This results in subsequent plugin closures due to valid trademark violations.

On the other hand, we don't block "wc-" and at least once a day we're forced to pend a plugin review to make it clear that they cannot use "WC" in lieu of WooCommerce in names, and please don't replace it.

Both methods have flaws. Both methods result in people violating trademarks down the road. Neither actually seem to make a dent on people using trademarked logos in banners and icons, though that make be a lost cause.

The only real way to block the misuse once approved would be via SVN commit hooks, however there may not be an easy way to flag the allowed list (see https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/shortcodes/class-upload-handler.php#L522 for an example of how we check on submit).

A possible middle ground would be to have a list of 'probably going to be abused' terms (like wp- or wc-) and change the automated 'your submission has been received' email (and the output on the page) to make it clear:

"Your plugin begins with a term that can be commonly misused. Please remember that while the use of [term] is permitted in your plugin names, it should not be the FIRST term of your display name. If later on you change your plugin name to infringe on trademarks, your plugin will be closed without prior notice."

(Needs work - I don't know that it's clear that 'if you make your plugin start with WordPress, you're gonna have a bad time' is what we mean... maybe an array of the slug term and the actual name we're trying to prevent?)

And that doesn't really touch on how to prevent abuse after approval :( We use SVN so that would need someone with amazing SVN chops to dig into.

At this point, my brilliance fails me so I ask for help coming up with something that can stem the tide. My ultimate goal is to never have to close another plugin for trademark abuse again, because no one would violate them.

[psykro]

@Ipstenu thank you for this detailed explanation.

May I ask, would it be ok if I submitted a test plugin using the prefix wp-, to see what the automated messaging/links to documentation look like? This way I can make some suggestions to help update the feedback a new plugin developer receive, and we can iterate from there.

[tobifjellner]

Perhaps it could be meaningful to codify a few different "problem descriptions" and have one more column, i.e. {"matched term"; code for suitable description; "Additional info field, which may contain the expanded, potentially infringing, term"}

[Ipstenu]

@psykro Sure or read it in the code https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/shortcodes/class-upload-handler.php#L134

Your chosen plugin name - %1$s - contains the restricted term "%2$s" and cannot be used to begin your permalink or display name. Per the requirements of trademark owners and law, we disallow the use of certain terms in ways that are infringing and/or misleading. In order to proceed with this submission, you must change the %3$s line in your main plugin file and readme to end with "-%2$s" instead. Once you\'ve finished, you may upload the plugin again. If you feel this is in error, such as you legally own the trademarked term, please email us at %4$s and explain why.

[dd32]

And that doesn't really touch on how to prevent abuse after approval :( We use SVN so that would need someone with amazing SVN chops to dig into.

I think we can work around this by simply applying the trademark term blocks during the import from svn stage too.

I'm imagining something like:

• ACME is registered trademark, only @acme.org emails are authorised.
• XYZ is rejected for the plugin 'acme-widgets', gets approved once they rename to 'Block Widgets for ACME theme' (please disregard any existing trademark requirements for this example)
• SVN Commit 1 with 'Block Widgets for ACME Theme' (v1) is imported
• SVN Commit 2 with 'Block Widgets for ACME Theme By XYZ Team' (v2) is imported
• SVN Commit 3 with 'ACME Block Widgets By XYZ Team' (v3) is then commited, and we simply don't ever import that SVN commit. Maybe we email the author at this point along the lines of "Commit 3 has been skipped by the plugin directory due to failing to meet the automated trademark terms. Please review <link> and contact plugins@… if you believe this is in error."

At that point, the problematic plugin will remain live as 'Block Widgets for ACME Theme By XYZ Team' (v1) and the problematic new version 'ACME Block Widgets By XYZ Team' (v3) remains unreleased / unseen by the WordPress ecosystem, other than for the svn commit.

I see two ways to which trademarks would be allowed to be used in this scenartio:

1. The existing owner email allowance list for the term. I think this is the defacto obvious only case we really need to support.
2. We add a field in wp-admin, editable by plugin reviewers, which defined the list of terms that the author / trademark owner has stated the plugin may use. For example, Let's say ACME & XYZ come to an agreement to jointly name the plugin as 'ACME Widgets', they could transfer it to an @acme.org email address, or the plugins team could add 'ACME' as a authorised trademark term to the plugin metadata?.

I'm suggesting #2 as instinctively think there's going to be edge-cases and grandfathered uses that are allowed, but maybe I'm wrong, and I'm over thinking it, and the email allowance is simply enough. Especially since 'agreements' for one company to use a term to another can be rescinded at any time and is one of the reasons for the hardline trademark rules we have, to limit the amount of work the reviewers team have to spend on legal requests/threats.

[Ipstenu]

Option 2 sounds awesome, since then we can manage people who work for multiple companies. Also a number of Automattic employees, for example, still use personal emails, which is totally fine but hard to manage ;) Bonus it can be revoked so if someone uses the wrong account to submit a plugin (it happens) we can restrict it and make them use the proper company plugin-ownership account.

It would be 'better' IMO if we had a non-hardcoded way to manage which emails for which companies/slugs/names, too. Having to have it in the PHP code limits who can make changes, and I don't expect whomever the next plugin rep is to be the same sort of dev that I am :)

[tellyworth]

Replying to Ipstenu:

It would be 'better' IMO if we had a non-hardcoded way to manage which emails for which companies/slugs/names, too. Having to have it in the PHP code limits who can make changes

That could be seen as a feature. Also, having it in svn means we can make it transparent, including changes over time.

[dd32]

In 13460:

Plugin Directory: Extract the trademark logic from the upload handler, into a generic class for use in the plugin directory.

See #5868, #6108.

[dd32]

In 13462:

Plugin Directory: Expand the trademark checks to match multiple trademarks in the field checked.

Simplifies the error message and centralises the 3 uses of it.

See #5868.

[dd32]

In 13465:

Plugin Directory: Trademarks: Assume a plugins trademark exceptions are those of it's owners and committers. Better handling for portmanteaus, and trim - off when displaying in the error messages.

See #5868.