SiteGround’s Response to Their WordPress Plugins’ Tracking in Violation of WordPress Guidelines is to Continue Doing It

Last Friday, we noted that a major web host, SiteGround, was using their two 1+ million install WordPress plugins to collect data on websites using them in violation of the guidelines of the WordPress Plugin Directory by doing that without consent. On Monday, we noted that they also appeared to be inadvertently tracking users of the plugins, also in violation of those guidelines. We reached out to the team running the plugin directory on Friday about the first issue, but have yet to hear back from them and no change has been made. SiteGround has responded to part of the second issue, saying they will continue to do things in a way that causes unnecessary tracking and is in clear violation of the guidelines.

Making the situation a lot more problematic is, as we noted previously, that SiteGround sponsors one of the team reps for the team running the plugin directory. We reached out to that team rep about this on Twitter (X), but have gotten no response from them. At best, SiteGround is being allowed to sponsor a team member while not bothering to adhere to the guidelines of the plugin directory with their own plugins.

Before getting in to the specifics of the response from SiteGround, it seems helpful to provide some background on recent changes made to the plugins, which don’t match up with the response. In September. they rebranded the plugins to remove mention of SiteGround from them. One of the plugins had its name changed from SiteGround Security to Security Optimizer. The other went from SiteGround Optimizer to Speed Optimizer. While the security plugin appears to be built to be used alongside the server-level security provided by SiteGround hosting (though SiteGround doesn’t appear to understand the limitations of that), the plugin is marketed as if it is a general purpose plugin. The only mention of SiteGround in the plugin’s description on the WordPress plugin directory is that it says that is “Developed by the website security experts at SiteGround” (they don’t appear to be security experts). It seems clear based on that they are promoting these plugins as being separate from their hosting. The response about the apparent inadvertent tracking belies that.

Part of the explanation from the Director of Product Development at SiteGround for the apparent inadvertent tracking they are doing is this:

The first one is obviously savings. We host millions of websites and if you look at this issue from that perspective it makes waaaay more sense to load the resources from the central location instead of copying the files locally.

Among other issues, that wouldn’t apply to websites not hosted with them. SiteGround could offer the plugins directly to their customers and do whatever they want, but they are providing it through the plugin directory, which doesn’t permit what they are doing. Or at least it is clearly in violation of what is claimed to be allowed.

The other part is this:

The second reason is that this way we can easily deploy style guide changes to all users without actually releasing a new version which changes just some icons, fonts, etc. All of our plugins follow a strict design system guidelines and use elements from a style guide we use across a wide range of products.

If you are making changes to the plugin, then a new version should be released.

The plugin directory’s guidelines are clear that “Offloading assets (including images and scripts) that are unrelated to a service” is not allowed. The solution would be to start including those in the plugin. Instead, SiteGround was suggesting some time vaguely in the future they would provide an option to download and locally store the files:

On the other hand, your point of view is reasonable and I get your concerns. At this stage I cannot propose a solution which will become a reality soon. However, I am considering an option in the plugin’s settings which will allow users to overwrite the default behavior and a specific plugin to be configured to self-download the resources locally and use the locally downloaded resources instead of the ones hosted on the sub-domain.

That clearly doesn’t address the violation.