Tag: administration

We Should Free All WordPress Plugins and Themes
No, I don’t mean give them away for free. But put a pin in that, because this idea begins and ends with FAIR.

If you haven’t yet heard about the FAIR Package Manager, the idea is to rethink how software is distributed and managed in the world of open web publishing. FAIR focuses on decentralization, transparency, and giving users more control.

And yes, I’m one of the first Technical Steering Committee’s Co-Chairs.

When I say we should free the plugins and the themes, I mean something I asked myself almost a decade ago…

The (Initial) Question

I remember being on an airplane flying to Japan when I first asked myself this question:

What would the WP world be like if we democratized the extension ecosystem?
Mika Epstein circa 2015

Believe it or not, that note moved to a document, which grew over time, collected all the risks and rewards I could think up. I had logical trains of thought that ended with a failure. But I kept at it. I kept scribbling notes and refining the ideas, until I felt like I had a solid frame.

Sometime in the spring or summer of 2024, I sat and wrote it as a proposal that I had planned to present to folks on the Meta team as a future path for WordPress.org to stop hosting all the world’s plugins and themes, and instead make it a hell of a lot easier for people outside the wordpress.org services to host their own while still remaining findable.

The World Before

20 years ago, the world was a different place with regards to the internet.

Remember, in 2003 Mike and Matt forked b/2 to make WP, and in 2004 MovableType decided to change their license, and in 2005 Git was invented.

So let’s set the table remembering that when WordPress came out with Plugins and Themes it was 2004 and back then it was pretty rare for people to host other people’s stuff. That was actually the problem .org was fixing! Don’t have your own SVN setup? Only have $8 a year hosting (those were the days)? Don’t have a way to save all your versions?

Welcome to the WordPress extension system!

The (Current) Problem

While WP solved the problem of 2004, 20 years passed and everything changed. Everyone’s computer has SVN and GIT now (more or less…), and everyone can host code on GitHub or GitLab or even roll their own pretty easily.

It’s almost like WordPress paved a road for self hosting being spread across the developer landscape. Not only can creators of content host their own websites, devs can host and manage their own updates.

And WordPress created a new issue of their own making: a gate. There are rules about what you can and cannot host, how you can behave, and frankly … I say this as one who was the Gatekeeper for too many years, that gate is a necessary evil.

By hosting code and content from other people, WordPress.org places itself in harms’ way. They became responsible for how everything was portrayed and published on the plugin/theme search pages, and that gate had to have rules to protect itself and ensure its continued existence. Like trademarks. You have to be vigilant because places like Facebook will try and shut the whole directory down if they decide it’s infringing.

That gate has become a hinderance to the democratized usage of WordPress.

To get around the rules of the gate, people host their own code now. Sure there are a couple options (EDD Updater, GitHub updater, there’s a plugin self-updater out there as well). But because of that gate, they aren’t findable. This hurts WordPress. It stifles growth, it makes it harder for people to make their living on WP, and that is a net loss for everyone.

My (Then) Proposed Solution

WordPress.org should stop hosting non-official Plugins and Themes (including Akismet) and instead host the following:
- Example Plugins (hello dolly)
- Core Plugins (Classic Editor, Classic Menus, HealthCheck)
- Core Themes (twenty-*)
- A directory of other plugin and theme directories
That last one is the crux of the whole matter. We give hosting back to the developers (just like we gave hosting to the content creators) and then we welcome in their content without liability.

The thing was, I knew damn well this is something that WordPress.org would fight me over. Stop hosting? Make that radical of a change to completely rewrite how we access code? Distribute everything and own nothing?

An uphill battle to say the least.

So, like I did every time I opened that doc, I re-read it, made some tweaks, ran it though and AI on a whim and cleaned it up even more, and I closed it.

The FAIR Future

This brings me back to FAIR.

Sounds like it was made for this proposal, huh?

I cannot take credit. It’s lightning striking the same place twice. But that makes sense, doesn’t it? No, I’m not talking about how WordPress and I share a birthday, I’m talking about how I absolutely couldn’t be the only human on the planet with this idea in their head.

Naturally I dove in. I helped writing the docs, translating High Geek explanations into Corporate Lingo, pitching and refining ideas, collecting information from the developers who were far better at these things than I am, learning about AtProto.

When I was nominated to be on the TSC, I sat with my wife to discuss the implications and risks of accepting. There was a very real possibility this could destroy my career, and I’m a developer looking at 50 while being female. Finding another job, if this went badly, could become impossible.

But I have a poster. “Flynn Lives.” For years it hung on the wall across from my desk, and I would look up at it and remember the line. “I fight for the users.”

I started helping in the WP forums to help the users. I joined plugins for the same thing. I ran plugins with the dual view of fighting to make things easier for users and developers. And I failed, trying to do that. But I’ve learned and grown and changed.

In order for WordPress to move from being that joke to “just a blog” CMS that ‘real’ developers mock, to grow the ecosystem and help everyone make money, to get even bigger while still giving back to everyone, distribution is key.

Democratize Distribution

FAIR is at step one of the plan.

Today, the plugin can disconnect you from WordPress.org for updates (which has the added benefit of more data privacy). There’s only one distribution source right now (thank you AspirePress! none of this is possible without you) but it proves you can do this. It’s got some work left to do and we welcome everyone’s eyes and hands to help. It is very much an MVP release (something I stressed over and over during the dev cycle, to keep folks out of the weeds).

Next is the part where we build out the system to hand the keys to the developers. No more AppStore and rules. Push what you think is right to push.

Will some people abuse that? Of course. Someone will push weekly updates so you’re always being notified. Someone will cover the admin panel with ads. Those things happen today, and the plugin review team cannot keep up because there are more devs than reviewers.

But there are things we can and will do to help and protect users, to empower developers, and assist the hosting companies and more. Everyone benefits from this future.

We have a plan, and we hope you come with us.

Other people collaborating with FAIR have blogged as well:
NB: Currently Flynn Lives is on loan to my barber for his art wall, and instead I have Nichelle Nichols and Carrie Fisher.
9 June, 2025
Plugins: Bad Thief
The summary of this story is: The GPL does not mean WordPress.org has to host whatever code you want it to, regardless of what you think.

I promise it gets there.

Starting off bad

The story of Donald (fake name) begins with a plugin submission he never finished. Back in August 2021, he submitted a plugin with a number of security flaws. And a review to which he never replied. The plugin was rejected in February ’22 and resubmitted in March (one month later).

Per usual, Plugins flags those and asks the dev “Hey, you gonna reply this time?” because it’s a waste of everyone’s time to review shit they don’t use here. Donald ensured he would, so he got a full, lengthy, review.

I’ll admit, his reply was pretty unique.

It was a massive rant which I cannot share (privacy) but here are the key takeaways:
1. He has been a developer for umpteen years
2. He copied a plugin to make his own
3. He thinks he bought the code via WordPress.org
4. He would not make the security changes we listed
5. The original plugin had the same flaws
6. Other plugins have flaws too
7. He thinks he bought the ‘source code’ (oh no…)
8. He wants us(?) to fix it
Oh no…

I pinched the bridge of my nose. Anytime someone jumps to the old chestnut claim of “I am a developer of a bajillion years!”, it never ends well. Seriously. If you’re a developer since day one of WordPress, you should know not to break the guidelines.

I rejected the plugin and clarified a couple things.
- In no way did Donald buy a plugin from WordPress.org
- We don’t review every release of every plugin so yes, some have flaws
- If it’s your plugin, you have to fix it
- If it’s not your plugin, you can’t host it on .org
- Removing the copyright and not making any changes isn’t a fork, it’s theft
That went over about as well as wearing a Yankees hat to a Cleveland baseball game.

What did he buy?

People will argue left right and center that it’s not stealing if the code is GPL. The part they always seem to miss is that it’s not their work, and it’s a lie to claim it is (this is why you add copyright, folks!) and when it’s a PREMIUM plugin, like this is, it’s stealing because you broke their license. And yes, he did.

But Donald was stuck on this weird part that he believed buying a plugin meant he owned it and could do whatever he wanted. Now if it was GPL, technically he could do that, but that doesn’t mean we have to do what he wants. And WordPress.org will not host code that you didn’t write, or at least reasonably fork.

I purchased the rights to the source code directly from the author.
Donald via Email

And he cc’d the original developer, Adam (fake name)!

I took a look at Adam’s account on .org and found his plugin. It was a free version of the one in question, and yes had security issues. In fact, it had been closed about a year ago.

Adam replied before I did and said “bro, no you did not.” I backed Adam, explaining what Donald bought was the code to use, and the license on Adam’s website said it could not be resold (remember it was non GPL code).

Good, we’re done!

Legal Drama

Donald replied with proof. What proof? A bunch of PDFs that (he said) proved he owned it.

It did not. The attachments showed he bought a yearly license for a number of domains.

Donald and Adam had a lot of back and forth about how that wasn’t how a license worked (Adam) and insisting he owned it (Donald).

The next attachment PDF showed he paid for a license (again) and a new one that said it’s a charge and how much (though not what for…). I assume he paid that for the ‘source code’ and I made this face:

At this point, Plugins was never CC’d on any reply from Adam (remember Adam’s plugin was closed because of securit), and Donald just kept going.

It’s Mine!

It got a little hard to figure out what was what, because Donald would reply-all and Adam wisely only replied to Donald. However since Donald quote-replied, we ended up getting almost everything.

Donald moved on to explain this was a fork, a term he learned from me, and he could prove it because he used fewer files and it was organized differently. The problem was the code was the same. About 80% or so the same. Not a small amount. And Donald insisted the GPL meant he could do this.

Again, yes he could, if the original code was bloody GPL to begin with! And it wasn’t. Oh and he didn’t meet the GPL requirement for copyright (GPL says you gotta retain copyright and add yours) nor WordPress’ for disclosure (you gotta credit the OG devs). Thus, Donald failed the sniff test.

This went on for hours and I didn’t reply.

Now, if you’re wondering “Why didn’t anyone reply?” it’s because that bevy of emails came in between 4pm and 4am Pacific Time. At this point, though, it was crystal clear that Donald had:
1. Copied code and did, in the end, make a fork
2. Copied premium code from a non GPL source
3. Did not disclose the copying/forking in his readme nor source code
4. Thinks he bought the rights to the source code (… that’s not what that means, but okay)
Oh and he was still insisting he bought it from WordPress.

So I tried again. I repeated the facts (you didn’t buy it from WordPress.org and it doesn’t meet the guidelines to be hosted on WordPress.org as a ‘fork’) and then followed up with banning him since, after 14+ emails overnight, it was obvious the cheese had fallen off Donald’s cracker.

I did take a moment to recommend he not post the code on GitHub due to the GPL issue, and if he did, Adam might have a legal case. I also told Adam I told Donald that, so Adam had a chance to protect himself.

Enter Crazypantsland

This time Donald agreed he didn’t buy it via WordPress.org, however he insisted he’d paid for the code (quoting half the price that was in the pdf I will note).

Again, you are wrong, I DID NOT take the premium plugin. What I took was the code base of [the version] I purchased provided to me by the author after he received payment. Only [then did I rebrand] and modify […] the code as my own.
Donald via email (removed identifying information)

Honestly I sat back.

His argument was he didn’t take the premium code, he took the code he purchased. I took a deep breath. I mean, maybe he just failed to make that connection? But I (and Adam) had already explained that before so who knows.

Donald’s email went on to …
- Agree that I was correct to not host the code
- Disagree that he’d ever claimed he bought it from WordPress.org
- Agree that he bought the code from Adam
- Disagree he should be banned
To be fair, few people would agree to that last one.

I tried again to explain how what he did was harmful, and the fastest summary of what he did is this:

Donald put some bells on it, but that’s basically what he did.

The gist again is “I did not take his code, I bought it and used it.”

He took something, which in that moment he had the legal right to take! But it’s still taking. If you bought a copy of the Sherlock story “A Study in Scarlet” (which is public domain!) and then re-released it with your name on it and a modern update, it’s not YOUR work anymore. It’s Sherlock the TV series, who bally well credits the source properly. But they don’t call it their original work, they call it an adaptation.

They credit.

Donald did not, and would not.

My Cousin Vinny

Marissa Tomei aside, Donald explained his legal rep (a family member) had told him he didn’t buy the code the way he thought he did. Donald had bought a license to use the code

Blessed hallelujah! I thought it was done. Alas, Donald went on to say he was going to clarify that little license matter with Adam (he never did, Adam refused), and then said that since it was legal to take code and reuse it, per GPL, he was good to go, please host his code.

This is after he agreed we were right about the non-GPL thing.

I explained, again, that the bottom line is WordPress.org will not host forks of premium code, will never allow non-GPL code, and would not accept forks that don’t credit the OG. Donald hit the trifecta. I recommended he ask his lawyer-family-person about the concept of “fruits from the poisoned tree.”

Donald went on to make all sorts of entirely wrong legal claims that the GPL allowed this, so WordPress had to let him host the code, and on and on. Then he threatened to sue.

At that point, I stopped. He got the final reply with the official “you are banned and we won’t read your emails anymore because you clearly do not get it” message.

The weekend happened and on Monday I found an email saying Donald had complained legally, and they too marvelled that someone would have a lawyer explain they were wrong, only to double down on the wrong.

I still need to send a sympathy gift to that poor person who had to deal with Donald.
2 August, 2023
Protect My Plugins, Please
I have a site that literally requires a specific plugin always be active for things to work. It has a lot of very complicated code, and two things must never ever happen to this:
1. It should never be disabled
2. It should never be updated by WordPress
Well. Okay. Let’s do that.

A Caveat

If you don’t have a way in place to update and secure the plugin you’re hiding, DON’T DO THIS. Once you hide it, people won’t know to update it and, in fact, won’t be able to. Because you’re also preventing traditional updates. In my case, I have a git repository that triggers a push (plus some other magic).

Again. Unless you’ve got something set up to handle updates, don’t do this.

Now let’s do this.

Never Disable Me (by Hiding)

To do this, we need to know the folder name and filename of the plugin, such as ‘my-plugin/my-plugin.php. If you want to hide the plugin you've put the code in, you can useplugin_basename( FILE )` instead, which is what I’ve done.
```
add_action( 'pre_current_active_plugins', 'mysite_hide_my_plugins' );
function mysite_hide_my_plugins() {
	global $wp_list_table;

	$hide_plugins = array(
		plugin_basename( __FILE__ ),
	);
	$curr_plugins = $wp_list_table->items;
	foreach ( $curr_plugins as $plugin => $data ) {
		if (in_array( $plugin, $hide_plugins ) ) {
			unset( $wp_list_table->items[$plugin] );
		}
	}
}
```
If you were writing a plugin to hide a lot of things, you would change the array to list all of them. But since this is a ‘hide myself’ deal, it’s easier to put it in the plugin itself.

The added bonus to making the file path dynamic is that if someone gets clever and renamed the folder or file, it would still work. Neener.

Stop My Updates

Now this one again is easier if you put it in the plugin you’re disabling updates for, because again you can use plugin_basename( __FILE__ ) to detect the plugin. If you’re not, then you’ll need to make an array of names. But that should get you started.
```
add_filter( 'http_request_args', 'mysite_disable_my_plugin_update', 10, 2 );
function mysite_disable_my_plugin_update( $return, $url ) {
	if ( 0 === strpos( $url, 'https://api.wordpress.org/plugins/update-check/' ) ) {
		$my_plugin = plugin_basename( __FILE__ );
		$plugins   = json_decode( $return['body']['plugins'], true );
		unset( $plugins['plugins'][$my_plugin] );
		unset( $plugins['active'][array_search( $my_plugin, $plugins['active'] )] );
		$return['body']['plugins'] = json_encode( $plugins );
	}
	return $return;
}
```
What Does It Look Like?

Nothing, really. You’ve hidden everything. Congratulations. Now you don’t have to worry about admins or WordPress updating your plugin. Or worse.
10 July, 2018
Data Deletion May Not Be What You Think
So you’re handling GDPR and you have a privacy doc and policy and a plan for people requesting data and, yes, deleting it.

Eventually someone is going to ask you to delete their content from your site. This is the scary part for most people. Remember, you get 30 days to reply, so don’t panic. Next, figure out what they’re asking for, and if you can say no.

This is the fun part. You can say no. Sometimes.

When You Can Say No

In general, yes, you should delete people’s information if they ask. But if your website stores complicated information this is not actually as black and white as all that. The right to erasure does not apply if retaining is necessary for one of the following reasons:
- exercising your right of freedom of expression and information
- meeting any legal obligations
- performing a task for and in the public interest or in your legal authority
- archiving information of public interest or for research where deletion would impair the work significantly
- related to and legal claims you have (or may have)
This helps you balance out the problem of being told to delete things you need to keep for tax reasons. It also keeps sites that may collect public data for the general public (like wikipedia or a website that tracks queer characters on TV) from losing everything. It won’t protect you from other lawsuits, of course.

It’s that last one I feel is really important to everyone. That’s the one that means if I block you, I may not have to delete your data, even if you ask, because I may need it for the establishment of legal claims. But that has to be a legit claim.

You can also just say no for any reason you feel is justified. Now again, do not use this flagrantly. You still have to turn around and tell someone that you’re not deleting their data, so you need to be serious about this.

Self Protection

And speaking of being serious, you can actually say no to protect yourself. You see, people can only ask for deletion if the data is no longer needed for the reason it was collected. So if they want to delete their account but keep shopping at your store, you can say no since the information is needed to keep shopping!

So remember why you track the data in the first place. When people leave a comment, for example, you track their username, email, and IP (and web address if they provide it) in order to know who they are and prevent spam, but also abuse.

Here’s an excerpt from one of my privacy policies:

Comments: When visitors leave comments on the website, the collected data shown in the comments form, as well as the visitor’s IP address and browser user agent string are saved in order to help spam detection and abuse.

Since I retain data to prevent abuse, that is serial internet harassers, you can ask me all you want for me to delete any data I save about you, but I can say no to protect myself.

When You Say No

If you decide to tell someone no to a deletion request, you must:
- provide the reason
- inform them of their rights to make a complaint
- inform them of their right to a ‘judicial remedy’
That last one means yes, they can sue you to delete the data. If they’re abusing you (harassing etc) and you’ve saved all that, you’ll probably win. Which is one reason you should actually save and document people’s actions. I hate having a whole folder on my laptop that documents a bunch of people hating on me, but I need it.

Basically if you’re going to say no, have a damn good reason, document it, and be prepared for a fight.

Say Yes If You Can

Most of the time, it’s no skin off your ear to delete a comment or edit a post. But sometimes it’s going to be a huge deal. And in fact, you can turn around and tell people “If I delete all your data, I will retain information required to identify you in order to prevent you from returning to this site. Deletion requests means you will not be welcome back.”

If that sounded harsh, well, it can be. Because for most small blogs, consider what they’re asking. When someone asks to delete the content of a personal blog, it’s most likely going to be for a pretty petty reason. Unless they’re asking you to remove information that shouldn’t be public (like their phone or email – and yes, someone’s asked me to delete that before), it’s probably going to be someone asking you to remove a comment that makes them look foolish. Or at least it has been in my experience.

Make Your Life Easier

Keep this in mind too. Make your life easier. If you don’t need comments on your site, don’t have them. Turn off that contact form too. But there’s no law that says you need to let people talk to you on your blog.

This won’t be true for all situations, but do as much as you can and save yourself that GDPR headache.
5 June, 2018
Organization
In September 2005, Lorelle wrote what I consider to be the definitive piece on tags vs categories. In 12 years, my opinions have not changed and I still feel her explanation is correct. That said, there is room for improvement at scale.

The Gist

Her advice boils down to this:
- Categories are a table of contents
- Tags are index words
By this we mean that categories are the high-level, big ticket items, and tags are the smaller, more precise terms. This is, I feel, the heart of understanding the two.

Further down, Lorelle states that at around 25 posts, a tag is ‘big enough’ to be a category, and that if a category dominates a blog, it should perhaps be a separate blog. And that’s where I disagree.

On Beyond Zebra

When she wrote her post, the concept of custom taxonomies was barely a gleam in someone’s eyes. Multisite was still WPMU, and a separate installation. Today we have the ability to add our own taxonomies (either in category or tag styles) and we can create a network of related sites on our own. All we need is a little more technical know-how.

When we add on custom taxonomies, we afford ourselves a new way to classify posts, so to the above I would add this:
- Custom Taxonomies are critical but exceptionally unique index words that must be grouped together
Okay that was long, I know, but a Custom Taxonomy is in essence a new subdivision of your site. You can either make it a new table of contents or a new index … or a combination of the two. It’s a little wild, especially when you factor in custom post types.

Overwhelming Category? Custom Post Type!

Instead of making a new blog when your category gets too large and unwieldy, I would recommend making a new custom post type. If I use my helpful example of LezWatchTV, we currently have three custom post types: Shows, Actors, and Characters.

While we could have made them into posts, and used categories to index them, having them be their own post type means instead of a table of contents, I’ve made an appendix. This gives me access to all the cool WordPress features, like archives and sorting and organization, but it does so outside the realm of posts which restricts crossovers. Unless you’re really clever with cross-related content.

A custom post type keeps it all on one blog, but separates them like your laundry.

Too Many Tags? Custom Taxonomy!

If you find yourself having too many tags, it’s time to consider a custom taxonomy. Again, pointing to LezWatchTV, actors have two custom taxonomies: gender identity and sexuality. While those are the same as we use for characters, by having them separate and only applicable to the actor post type, we are able to give a list of all trans female actors with a click. In other words, we’re using WordPress’s native features.

But if we look at the custom post type for TV shows, we have a lot more taxonomies, including two that are constantly being added on to: nations and stations. Every time a new station airs a show, we have to add it in. And there, as of April 1, we end up having 29 nations and 168 TV stations.

Which brings up the next problem, and one that Lorelle does indeed address, but not the way I would.

When Tags Go Rogue

Can tags still go too large? Yes. Oh my lordy, yes.

Recently I saw a site that used unique tags on every single post. I physically flinched when I realized that.

You see, they had around 30,000 posts and 48,000 tags, and for the life of me I couldn’t understand why until I read the site and looked. For every single post there was a commensurate tag for the post title and the date. After 365 dates they thankfully started to repeat, so you might have 10 posts for the march-25 tag. Except they weren’t consistent and someone else used 25-march and now you can see the rabbit hole fall into infinity and beyond.

Now that said, I have 168 tags for TV stations, each TV show has one, maybe two if they’re lucky or weird, and some tags only have 1 show listed. Others, like ABC, NBC, and CBS, have around 60. Do I think any of those are ‘too large’?

I don’t. Because the number of 25 posts to a tag only holds up at a smaller scale. With 100 to 200 posts, yes, that starts to make sense. At 600 to 3000 posts, suddenly having 198 posts tagged with “Bury Your Queers” doesn’t sound so out of place. It’s about the percentages, somewhat, and also the use-case.

If I know people are looking for a smaller tag (say they really want to see the 10 shows that have the ‘Fake Relationship’ tag), then for the purpose of this site, it’s important. On the other hand, if only one character was tagged cougar, I might not keep the tag as it’s too small to make the data useful.

Optimal Organization

There is no magic number of tags to categories to custom post types to taxonomies. It all comes down to understanding the goal of your site, the way users look for data, and what is maintainable to you.

In the case of the site with 48k tags, I would have them delete all the date ones, as well as the ones with the same names as posts, and stick to using topical tags. After all, if a tag is only used once, or duplicates some feature already found in WordPress, it’s perhaps not the best idea.
17 April, 2018
Chronic Infections: Blacklisted

If you use Chrome, you may be used to those warnings about how a site is dangerous (or hacked) and maybe you shouldn’t visit it. If that happened to your site, you’d get an email if you use Google Webmasters (which I recommend you do), and then after you clean it up you can ask for a rescan. Or if you don’t, Google will rescan the site after a while and if it’s clean, carry on.

That ends.

Google found out something we’ve all known for a while, and that’s people can be evil and malicious. And what they’ve done is created a ‘repeat offenders’ blacklist, for sites that clean up only to allow themselves to be reinfected. As they say, “Sites that repeatedly switch between compliant and noncompliant behavior within a short window of time will be classified as Repeat Offenders.”.

This is dangerous for users when a hack is outside their control.

The number one cause of reinfections is not plugging the hole. In the case of things like WordPress, it’s down to upgrading everything, deleting anything with a known hack or backdoor, and locking down users. Hacks like Pharma, where the database becomes vulnerable and repeatedly re-infects a site, are thankfully rare for WordPress, but the same cannot be said of other CMS applications.

And far worse than that is this. By which I mean what happens when your ad network is the cause of a hack?

Recently, a friend of mine was hacked and got upset that his webhost’s scan of his site said it was clean, while Google did not. In looking at the site, I pointed out the hack was from his ads and not the files on the webhost. His webhost’s scanner didn’t hook into Google’s Safe Browsing service so of course it didn’t come up. He was pissed off about the host missing it, but once I explained why, he realized the magnitude of the issue.

By adding an ad service to your site, you’re effectively trusting their behavior. And some ads are pretty scummy. While Google Adsense (and others) are usually pretty quick to kick-ban those idiots, the damage will be pretty hardcode. It takes but a small moment for a high-traffic site to serve up enough malware to make that attacker’s plan worthwhile. And worse, if the same kind of person get in again and again (which happens) and your site is infected multiple times, you will end of on the shit-list.

Thats enough FUD on it. Let’s talk about mitigations.

We’re all going to need to get better at figuring out where the malware is from. All of us. Security companies are going to lose money if they can’t stop repeat attacks, and since even the best firewall can’t stop shitty ads, all our scanner tools are going to need to be better about detecting what the cause is and where it’s from. This is going to be hard, since the ad may be gone by the time the site scan runs.

Google will need to tell us what they know a lot better. I don’t know if they will, but they’ll need to figure something out. At the same time, I get why they may not want to. It tips the hand to tell malicious people exactly how you caught on to them, but at the same time telling people “Your ads are serving up malware” would be impactful and hopefully not too harmful. I’m on the fence there.

Finally, we all know ads on the internet are shit. We’re all barely making money off them. So if you get infected by an ad vendor twice, it’s time to turn those ads off and look for something new. If that ad vendor is Google, open a ticket with them and provide evidence that they’re hurting your SEO and could cause you to get on that repeat offender list.

Yes, this is making a hard decision, but it’s one you must make. If you’re being betrayed by your ads, you need to quit them.

16 November, 2016