Do not get excited. This is not going to be a name and shame post. No plugin will be named directly, though I bet a number of people will wonder if I meant their plugin.
So here is your one and only explanation. After reviewing plugins for something between 12 and 15 years, as a pretty much daily process, I have incredibly strong opinions about development, companies, and ideologies. If you, while reading this, think I might mean you … probably not. You folks have no clue how many of the same problems I’ve seen!
This includes Jetpack. I know I said I wasn’t going to name and shame, and I’m not. Jetpack is the perfect illustration of the first problem with security plugins, and that is their WAF (web application firewall) requires editing files, and multiple times it’s broken on upgrade.
I repeat, this is not a shame! The problem isn’t Jetpack is bad or wrong, here. The problem is even within a webhost, you get a dozen different versions of server software! Trust me, your webhost would loooove if all our sites were on the same server, but that isn’t how it works. You acquire servers in batches, so you get batches of ‘like’ and then god knows.
But. Because of the myriad versions of server setups, it is impossible for Jetpack (or any WAF type plugin) to work perfectly 100% of the time. And this is especially true of upgrades, where servers prioritize different processes.
Basically, I hate them because they can’t do the one thing for everyone, and I accept that.
The real thing I hate about security … The things I hate…
They aren’t secure
They’re the wrong tool for the job
They slow your site
They think they know everything for everyone
Safety in Danger
Not being secure is as galling as you think. I have seen the vast majority of security plugins have the most basic wrong code out there. We’re talking not sanitizing, wrong sanitizing, not using prepare with SQL calls, not escaping, using sanitize functions to escape (and vice versa), and no nonces.
All that was seen in a plugin I reviewed back in late 2022, and I remember just putting my face in my hands and shouting ‘aaaaarrrrrrgggggghhh’ loud enough to wake my aged cat. And it was not the only one.
There are very few security plugins that have ever passed an initial review without having to be held back for security. I can only think of one in 2022-23, and they had a unique WordPress.org-only error (stable tags).
Because of that, I’m probably never going to use anyone’s security plugin. I just cannot trust plugins that, by their nature, are trying to protect, but are not safe. It’s like locking your front door and leaving your patio doors wide open.
Hammering with a Spoon
I also have long said that most security plugins are the wrong tool. This directly relates to making your site slow, because you are using WordPress to monitor and secure itself. That’s always gonna be slow, folks. And honestly having your app be the check for itself has the blindingly obvious flaw of … if the site gets hacked, that plugin is gonna be useless in 10 seconds.
The correct place for a firewall is a separate app on your server (or via DNS). The wall comes outside the town, people! It draws the line between dangers and safe.
PS I would rename any plugin that’s a WAF to a castle or something beside wall. You’ve built a tiny fortress castle and WordPress is the noble who lives inside. You’re the last line of defence.
The Need for Speed
How do security plugins make a site slow? This should be obvious. If a plugin has to run on every single load of your site and check it the person visiting is an evil doer… it slows things down. The more checks, the slower.
That’s it. Pretty simple.
This is another reason I think they’re the wrong tool. They’re on WordPress, and run using the same specs that WordPress can. PHP is usually more limited than other commands on a server.
I Know You Know
The whole “I know better” schtick was popularized by Steve Jobs. He claimed he knew what customers wanted before they did.
There was a plugin developer who had a security plugin that thought that. He got into a pissing match with another plugin that is hard to explain without naming names. Now, in this case I don’t feel the need to protect. They took to the forums and outed themselves. Heck, you can see some of the details of this saga on WPTavern.
Even though there is a little more to the story, it really doesn’t pertain to this. Suffice to say, some of my burnout is directly related to that event, which was years before I retired from plugin reviews. Oh and no, it’s not about a safe-space situation that people seem to think I run in when I tell them I’m not going to continue a conversation. I just don’t feel the need to waste time and energy on someone who refuses to compromise. I feel that if I’m at an impasse and won’t be able to change the other’s mind, I will agree to disagree and stop arguing.
That event is far from the only time I’ve seen someone decide “I know what is best, and I will force it” in a security plugin. Instead of giving options, or recommended settings, they go out and block what they think is wrong, regardless of the nuances. Sometimes they do it without a way to override, and that just isn’t cool.
While the goal of perfect security is laudable, the reality is it’s impossible. There will never be a perfect solution for everyone, and if your security plugin doesn’t allow for the nuance of the real world, then I got nothing for you.
Basically, Don’t
This probably reads like “don’t bother with a security plugin.”
There are some reasons you would want to use them. I use a lot of security checks on my sites, within WordPress, but for a specific purpose. See, I use them as tools to interact with services.
For example, Akismet and spam. I have written bespoke plugins to stop a serial idiot from submitting a form so I don’t have to fire up my terminal and block IPs. I hate IP blocks. They always hurt the innocent.
And yes, I am using the WAF from Jetpack right now on a large site! Warts and all, it’s been helpful.
But for me? Having seen what I have with security plugins? They will always be a hard sell.
Many people have told me that I should write a book about plugins and name and shame the shitty ones.
I’m not down with that.
For the past fifteen years or there abouts, I’ve been reviewing plugins at WordPress.org. In 2015 I took over as the rep. I stepped down entirely in July 2023 for personal reasons that have nothing to do with my passion for WordPress, but is in fact “because” of WordPress.
In fact, it’s really “because” of plugins. But to be specific, it’s because of developers.
Book Him, Danno
I really mean this. It didn’t used to be this bad at all. Sure we had some rough devs, many of whom have left the ecosystem, but overall the level of ashattery was tolerable. You could have an argument and things were kind of okay.
I distinctly remember when that changed. Like, I can tell you exactly where I was standing, talking to a coworker, when it dawned on me what was happening and that this was probably a turning point.
It was 2010 and we got the weirdest email from a company (fake name Booker Inc.) who explained their former employee (fake name Liam) had stolen a plugin.
Stealing a plugin is a weird concept to many when you think of OpenSource. You can’t steal something that is free, and anyway WordPress’ license lets you fork (copy and alter). A lot of people despise me for saying they stole, likely becuase of that. But the reality here is if you take something, created by someone else, put your name on it and proclaim it was 100% your original work … ya done stole.
An employee stealing from a company though, that was fascinating. I replied asking for some more details and what really was going on. As it transpired, Booker Inc. made a booking plugin that was behind a paywall, primarily built by an employee, Liam, who then was terminated, took the code, and put a copy up on WordPress.org.
The Investigation
Naturally the first thing I did was check the logs. Since Booker Inc’s was a paywall’d plugin, I asked for a copy to compare to as well. The logs I wanted to compare to their timeline claim. Liam was fired on X date, and a week later the plugin was submitted.
That told me that it was extremely likely Booker Inc.’s plugin came first. I downloaded both plugins and ran a diff on them using DeltaWalker. What I saw was a line by line copy, where all copyright and credit was removed.
The copyright is the reason, by the way, that I use the terms “theft” and “stealing” when I talk about this kind of thing. Copyrights and trademarks are, as I often say, “things with which one does not fuck around.” Copyright and Trademark laws are serious shit, and the GPL even says you need to include copyright! In fact…
If you have copied code from other programs covered by the same license, copy their copyright notices too. Put all the copyright notices for a file together, right near the top of the file.
That means in this case, we had copyright infringement (the second plugin had removed the copyright), and a copy of a plugin that was line-to-line identical except the name.
Oh and it was copied from a plugin … that wasn’t GPL.
Conclusion Clue(do): Close the plugin.
The End is the Beginning
After the second plugin was closed, Liam was emailed something to the gist of “Your plugin is a copy of your old employers, Booker Inc., and you broke copyright. On top of that, the code isn’t GPL, so we can’t host it.”
That’s pretty reasonable, I thought. It wasn’t until about 10 years later that we sat and formalized all those emails as you see today (mad thanks to Josepha for being my copy editor back in those days!). Back then, 2010? Nah, we were winging it. But the email in this story was serviceable.
At the same time we did that, I emailed Booker Inc. and said the plugin was closed and we wouldn’t host it because of the GPL thing. Done, dusted, situation over.
Liam replied that the code was legally his and he had the right to do this and change copyright as the owner.
And you know what? That might have been the case.
Above and Beyond
One thing about plugins that pisses off OpenSource purists is that the guidelines are above and beyond the GPL. Meaning, you have to meet all the requirements and restrictions of the GPL, but you also have follow the WordPress.org guidelines!
So what guidelines kick in when Booking Inc. reports a plugin is not GPL and Liam says since the plugin was 100% his, and he can re-assign the licence? Is that still theft? Is it violating the GPL requirement (one of the few we cannot give a ‘pass’ on)?
At the time, the guidelines had a lot more wiggle room. Today, WordPress.org is patently clear that even if the premium plugin is GPL, we will not host it because it hurts the ecosystem. I readily agree that all plugins behind paywalls hurts the ecosystem as well, but taking someone’s work and giving it away (usually claiming it’s yours), is a dick thing to do. You took money out of their pockets and could be wrecking a small business. It’s a balancing act.
I immediately asked Booking Inc. if they had a contract for the work that clearly spelled out ownership. They did, and agreed to share it with Plugins. It stated the work would be the property of Bookings Inc.
Next I asked Liam if he had a copy of his contract so we could validate ownership rights. He did, he shared it with us, and lo the contracts matched.
Now, regardless of my personal feelings on this, it was pretty clear. The contracts spelled out the code would belong to the company. It also actually said that the code wasn’t GPLv2, which I’d never seen in a contract before. The contract also stipulated that Liam would work with a team. They did the UX, he did the PHP.
So. I emailed Liam back and said I was sorry, but the contract made it clear that he did not have legal ownership, and thus couldn’t change the license. In addition, even if he was the owner, the contract indicated he was not the sole developer, and would have to get permission from everyone who wrote so much as a line of code to change the license.
Booking dot Hell
At first, Liam seemed to understand. He didn’t like it, but he understood he’d signed this contract. I told him something I have told many people before, and it’s always get a contract that protects you. If someone hires you for work, get that damn contract to protect you. There’s a story I will share later about a reverse of this situation, but basically that contract exists to clarify who owns the code, who has the rights, and it wasn’t Liam.
About a week or so later, Liam submits a new plugin. Also booking related. I eyeball it because while that contract implied an NDA existed to restrict Liam on working on booking code, I knew that wouldn’t hold up in court in their country. However, there is a fun legal concept known as “fruit from the poison tree.”
If a single line of code in that plugin was taken from Booking Inc.’s plugin, the entirety of the new plugin was not permitted. Generally we advise people to not try and submit a similar/related plugin, mostly for that concern, but also because of bad-blood. There was no way on earth that Booking Inc. would be chill.
As it happened, the code was about 75% the same. It was summarily rejected and Liam was told why. I distinctly remember telling him not to submit another booking plugin, because the wall for him was so high, he’d have to start from zero and not use anything from the original.
Liam said he was mad, but understood. He said he wouldn’t resubmit a booking plugin.
Liam Lied
For the next three weeks, Liam made a new account every other day or so, and resubmitted variations on the plugin. I rejected them all and would email his first address, explaining he needed to stop.
He didn’t. We ended up banning first his email domains, then his IP, and there was a time he couldn’t even visit .org. I hate doing that kind of ban, because it impacted others, but again, hard choices.
Then it got weird.
Someone with another booking plugin emailed plugins freaking out because they got an email, impersonating me, telling them that their plugin was closed! It was a mostly copy pasta of my email. And Liam had spoofed the plugin email address.
I had the new person check the email headers, and we confirmed it was not official. But then more people with booking plugins contacted us! Worse, those emails had “me” attacking those people! The closest I get in plugin emails to insulting people is when I tell them they made a stupid choice, or they acted like a jerk.
We fixed the spoofing issue, and that stopped, but it was that second email, the second one impersonating me, that told me this was bad. Real bad. This was changing the game bad.
Abuse is Now Common
It’s been 13 years, give or take, and people like Liam went from being a once in a decade occurrence to yearly to weekly, and finally to pretty much daily.
People hear “no” and decide the correct thing is to be a complete and utter abusive asshole. They believe they have the right to do what they want, and damn everyone else. These days people call it being a “Karen.” Oh and yes, they ask if they can speak to my manager.
By May 2023, if a day went by without someone, somewhere, deciding that the plugins team could fuck themselves, I was surprised and relieved. You’d get three in one day, move their emails to the auto-block system, and it would be tense for a couple days because most people made fake accounts to try again.
And again.
And again.
The Toll
While Liam pissed me off, personally, in retrospect what he did was tell me we needed to clean up the guidelines, organize our rules, and make it more clear that being abusive needed to stop. Impersonation should be an instant permaban.
WordPress.org didn’t get a community guideline until 2022, and yes, I was one of many people who regularly complained that we needed it a hell of a lot sooner. It became up to each team to sort out how to handle infractions, and what in fact was an infraction.
Each team has suffered rage quitting and burn out, due in part to the loosey goosey guidelines like that. It feels like you don’t have real support. If we did, that saga I refer to as “my idiot harasser” would have been a lot shorter. Or over.
I don’t blame WordPress directly for this. The community has done their level best to help and protect each other. So has leadership, as much as they could. But I really do feel the absolute lack of overall guidelines for “don’t be a dick” would have short circuited a lot of the pain people have had to deal with.
No, this was clearly not a thing WordPress did. This was a shift in the world, and honestly? It’s only gotten worse.
Why Not Name?
I have a lot of stories like this, and I absolutely will be sharing more. But I will not tell you exactly who people are.
Oh Liam probably sees himself in this, and that’s fine. What’s he going to do? Leave a comment to complain I’m not telling the whole story, and out himself as a human who felt impersonation was the right way to prove his point? He crossed a line and there probably is no way back at this point.
But naming him removes the “probably” from that. Naming him means that he is forever branded as the asshole. And I actually still firmly believe that nearly everyone can come back from crossing that line.
Otto has often called me an optimist for that. He’s right. I am optimistic that the human condition lends itself to empathy. We’re all on this rock together. We aren’t getting to Mars if we can’t figure out how to exist respectfully with people we disagree with.
And I feel that most people want to be in a group. Humans don’t want to be alone. Getting excluded from the group hurts, and people will do anything to get back in if that’s the only group. That’s reasonable, right? And when people have a bad day, getting kicked out, they lash out.
Likely Liam and most people like him never think about me again. I recently was reminded that for an adult, making a joke about a kid being chubby doesn’t stick in the adult’s memory, it’s just another day. But that kid will remember the time and place their parent called them fat.
I’m not the parent.
I remember the days, probably all of them given a prompt, I’ve had to tell someone no and close the door on them. Because it remains my secret hope that everyone like Liam feels a little bad, and sorry. Not sorry because he got kicked out, though. Sorry that he hurt someone.
And if that happens? If a Liam developed the empathy to understand how his actions harmed others and sincerely apologized? I would be the happiest woman in the world.
I want to leave that door open for the Liams in the world.
There are a lot of reasons why, but none matter for the purpose of this post.
I’ve already written up and scheduled some posts about my time there, and things I’ve seen. One about when I realized the atmosphere in developers had made a serious shift (it involves plugin theft, NDAs, GPL, and impersonation), as well as why I hate most security plugins.
But my problem is that I have a lot of plugin stories to tell.
What kind of stories do you want to hear? What things have you always wondered about?
While I will not name names except in cases where the story happened in public. In my first post (July 5) I’ll explain why in a little more detail about why I don’t name, so don’t ask for that. Besides, if I name and shame, they’ll come after me and I’m too tired for that shit.
I’m weeding through my notes (yes, I have them for self protection) of stories that can be sanitized and retold, but not all can.
Do people want to hear about common mistakes? Do they just want to see someone losing their blob (that’s most of them)? The ones I think most people would want to hear is thinks like the guy who stole a plugin from the contractor he hired.
So. Comments are open. Do the thing. But be nice.
We use cookies to personalize content and ads, to provide social media features, and to analyze our traffic. We also share information about your use of our site with our social media, advertising, and analytics partners.
