I recently participated in a panel discussion on Fighting Online Harassment in WordPress. Coordinated by Matt Cromwell, Co-Founder and COO at GiveWP, the panel aimed to continue the conversation about online harassment, which recently became more personal for the WordPress community through Mika Epstein’s experiences shared on her personal blog.

You can watch a replay of the discussion on the GiveWP YouTube channel. This post shares thoughts that my team and I gathered on how we, as the creators and maintainers of the open source plugin Paid Memberships Pro, can approach fighting abuse and harassment through our code.

Banner image for Disrupt Harassment and Fight Abuse Through Code

Jump to: Skepticism | Limiting the Potential for Harassment | Coding Against Abuse for Site Admins | Coding Against Abuse for End Users

At first I was skeptical: what can code really do?

Open source products are unique from traditional premium software or SaaS solutions.

  1. Users are not customers. Our software is open source, so in general we can’t stop people from using it. If we find they have beliefs different from ours, or if we find out they are creating a membership site designed to abuse or harass others, we can’t stop them from using PMPro. We have no idea what people are doing with our product, and we have no idea if they are building secure WordPress environments that will keep their users safe.
  2. Like WordPress, we carry a GNU General Public License. This means, among other things, that you may install the plugin on any site for personal or commercial use, and that the plugin is distributed WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

In general, you cannot stop people from using your open source software. However, as a business, you can choose who you do business with. You can exclude customers from your support and paid services.

From a business perspective, this is the best route every plugin author can take to fight abuse and disrupt harassment. For example, include a policy related to hateful sites and action you will take against these users in your Terms of Service for any paid or free user support offered. Some TOS are more specific, but ours is pretty general and we use it to remove the occasional hate group customer: “Stranger Studios, LLC may terminate your access to all or any part of our Services at any time, with or without cause, with or without notice, effective immediately.”

Another important factor here is building in policies that support your team directly. Our team knows what to do if they get assigned a ticket they feel uncomfortable supporting. For any reason, a team member can hand off a customer or a specific ticket to their team leader, Jason, or myself.

These are all business policies, though. So what can code do?

Teach Site Owners How to Limit the Potential For Harassment

Aside from code-based solutions, I feel like it is our job as plugin owners to educate the people on all sorts of business topics related to running a membership site with PMPro. While this list is unique to the memberships/ecommerce domain, I’m including it as an important reminder. As a plugin author, you are in a unique position to share the depth of knowledge you have about your customer’s users. Use your knowledge to help them protect their sites and their communities from negativity.

  • Remind the site owners that use your plugin product to have current Terms of Use and Privacy Policy pages. Plugin authors that facilitate user account creation and ecommerce should check that the site has defined a policy under Settings > Privacy and include a link to this page in the forms that allow user registration. WordPress allows you to suggest text for your users’ privacy policies.
  • For membership sites, we have seen that charging even a notional fee for access to a site will keep some trolls from signing up. If you had a free membership level and saw a lot of account abuse, adding a small fee of $1 / month can greatly improve the quality of members joining your site.
  • We encourage site admins to remove any friction that can lead to problems. For example, we are big fans of the “no-questions-asked 100% refund policy.” This simple policy prevents the majority of enraged communications that our team would have to process. Further, we advise site admins not to engage with these non-customers. A simple “Your refund has been processed.” is the best and only response needed.

Build Better Products for End Users and Site Admins

This section details some of our team’s code-based opportunities to build better products. Products that make it much hared for site admins to abuse end users and for end users to abuse the site owner.

Coding Against Abuse: For Site Admins

  • Paid Memberships Pro, our primary product, allows users to create accounts on your WordPress site. We create all users with the site’s default user role, which for most WordPress sites is the “Subscriber” role. Plugin authors must protect the site admin and ensure that users do not have capabilities beyond the most basic access rights granted by the Subscriber role. Yes, there are cases where a higher level of access is needed. For most sites, though, the Subscriber role carries the correct level of account privileges.
  • If you do give users a higher tier role, take steps to ensure strong passwords or even enforce two-factor authentication for specific users that have higher tier access. It is the site administrator’s job to maintain security for their WordPress install, specifically in an ecommerce environment with historic customer data.
  • WordPress should consider a safeguard against the site default role. I cannot think of a single instance where the default role should be set to “administrator”. I suggest that we force an override in wp-config.php to show “administrator” as an option in the Settings > General > New User Default Role dropdown. (There is a trac ticket about this.)
  • From a plugin standpoint, here are a few of our tools that protect membership site owners from various types of account-related abuse:
    • Lock Membership Level Add On: restricts a user from joining or cancelling membership on your site indefinitely or for a fixed term. We built this tool in part for our own use case as we noticed a few users would repeatedly sign up, receive help, then ask for a refund. While not the most harmful of cases for online abuse, our team did feel the stress of seeing these “customers” float in and out of the support channels. I recommend this tool to sites that are experiencing similar account abuse.
    • WP Bouncer plugin: designed to discourage user account sharing. This plugin is free in the WordPress.org repository. Similarly, setting up 2-factor authentication will further discourages account sharing.
    • Approvals Add On in combination with required registration questions: Membership communities often want to ensure that they are attracting and including the right type of member. These communities are successful because they create a safe space for members to discuss shared topics and values. For membership communities, using an approval process for membership allows them to pre-qualify members before allowing them access to their community. Sites can use a series of custom registration questions to force members to opt-in to your values before gaining access.
  • Fields validation is another way plugin authors can ensure safe data is being collected and stored for the related field. Field validation can also protect the site admin from users injecting corrupt files or other scripts into their site.
  • Consent logs, audit trails, and local data logs are a great way for plugin authors to support admins in the event that there is an abusive event. These methods track when a user or other admin managing your site makes changes. Along with this, though, plugin authors have a responsibility to anonymize stored data if that data log is “phoning home” to a remote location for technical support or other debugging.

Coding Against Abuse: For End Users

It’s WordPress. Everything is customizable. Site owners can get as scammy as they want, but plugin authors do not have to make it easy for them. For this reason, even though OUR direct customer is the owner running a membership site, we build our software with the end user customer in mind.

  • Some misguided site owners might want to hide payment reminders or payment confirmation emails from their customers. We enable these by default because the end user customer would want it that way.
  • In this same vein, we default to allowing members to cancel and terminate their subscription without the need for admin intervention or approval. Some subscription products make you call or write a specific letter to get cancelled. We believe users should have control to terminate their account whenever they want, for any reason.
  • Not every member of your site wants their information made public by default. For example, we added an option to our Member Directory Add On that allows users to opt out of inclusion in the directory. If you are building a product that can expose user, member, or customer data on the frontend, please add a way for members to turn this off. For example, have you ever seen those FOMO “Social Proof” notices on an ecommerce site. Did that purchaser know their name and maybe even their avatar would be shown as a popup on your site? The people building these tools are overlooking an important step to protect the end user customer.
  • With GDPR came a new system in WordPress to facilitate users in accessing or erasing all of the personally identifying information collected about them. Plugin authors should take steps to include their custom data in Personal Data Exports and Personal Data Erasures.

An Open Free Internet For All

Dealing with haters, abuse, and harassment is an important part of running an online community or open source software project. Ignoring these poisonous users and customers can lead to issues that spiral out of control and cause a lot of damage.

I hope that sharing some of our current thinking about these issues may help others. We will continue to review and improve our processes and actions to ensure that we are protecting each other while continuing to advocate for an open free internet for all.