Posted on

How to stop the information leak from the WordPress API

How to stop the information leak from the WordPress API

So, over at the MainWP Facebook Group page (you are a member, right?), Luke Cavanagh brought up the issue of privacy in connection to the WordPress API.

It seems there is a trac ticket, #16778, that has been submitted for six years over at the Core Trac at WordPress.

For a couple of hours yesterday, I read through all the comments and a good time was had by all!

This was opened up because of a couple of different reasons.

Leak of Information

First, the API for WordPres sends information back to WordPress. It was slightly unclear the type of data sent when first discovered although the original submission said the number of “users and blogs.”

“we’ve noticed that WordPress will send how many users and blogs are in a given installation during the GET to api.wordpress.org together with the installation URL in the headers.”

This is, of course, concerning to those who wish to guard privacy including members of the MainWP community.

Option to disable

The second reason of the ticket was to ask the core contributors if there could be a disable option for sending this information back to WordPress.

“Is there any reason why this is done? It seems quite a leak of information. Can it be turned into an option defaulting to off and admins can opt-in if they want to report how many users/blogs are currently there?” Trac Ticket

What followed for six years was a series of comments, submissions, pending, closes, and reopens.

In addition, several developer-based technical solutions were offered, many of which seemed to be inadequate.

As such, in the six years, while there was a continuation of the ticket, there was very little activity until the past 15 months.

Several issues at play

There are several issues at play during the process of this request. The first is that it seems to have had little visibility.

This is the reason Cavanagh raised it in our Facebook group. He was hoping to send those concerned to the ticket and bring a greater awareness.

The second issue is how willing the volunteer-led core team was willing to implement a UI feature to disable the info sharing.

Finally, there is the issue of which side people are on regarding the privacy.

WordPress, it seems, doesn’t really gather much information according to the team members. Some are okay with this as long as there is some kind of disclaimer.

As such, the WordPress team doesn’t see an urgency to addressing the situation.

Some are insisting on the disclaimer and developers in other countries say it is a legal issue.

“When we’re talking about the data being passed it’s important to clarify whether it contains personal information or identifiers. Aggregated and de-identified data is not in violation of European laws or directives, although users should still have a right to opt out of it. ” Heather Burns

Some wish for a way to disable the information being shared in the admin area with a simple check

Samuel Wood, also known as Otto, explained some of the history around how this little feature became part of the WordPress core.

“Specifically, this code was imported during the merge of WordPress to WordPress-MU, when multisite was added. The reason for this particular data being sent has to do with the possible necessity of providing alternate upgrade paths for large installations.” Otto

So, it began when WordPress merged its basic install with the Multisite install.

“When in multisite mode, WordPress stores each site in the network as a separate set of tables. For anybody who has done an update on such a site, you’ll know that there is an “Update Network” process which runs through each of those tables performing any changes to them that may have happened in the update. These can be as simple as running some queries to update a few rows in the options table, or entire schema adjustments. While this process is fine for smaller installations, it won’t work on truly big installations. Too slow, basically.” Otto

He seemed to explain why the data collection existed.

“So, these checks exist in the API just in case an update ever needs to be created specially for larger instances of WordPress. They were added to the update checks solely for that reason. They’re not there specifically for data gathering purposes.” Otto

Nevertheless, many developers still want a way to disable this for their own piece of mind as well as their own customers.

Enter My Precious

One of the developers, Danny van Kooten, created a little plugin that currently sits in the GitHub repository that disables the data collection to WordPress via the API.

via GIPHY

It is called My Precious.

Can you hear the Lord of the Rings music playing now?

So, we thought we would give you instructions on how to install the plugin in your MainWP dashboard for all the websites you monitor.

Coolio?

Installing My Precious with MainWP

Danny van Kooten created the plugin My Precious which you can find here https://github.com/dannyvankooten/my-precious

How to add the My Precious plugin to “Quit leaking sensitive information to WordPress.org, where the data is beyond our control.”

Step 1: Download the My Precious Plugin (this is install ready version from https://github.com/dannyvankooten/my-precious)

Step 2: In your MainWP Dashboard navigate to MainWP Plugins –> Install

 

Install the plugin
Install the plugin

 

Step 3: Click Upload on the top left of that page

 

Upload
Upload

 

Step 4: Upload the My Precious file from Step 1 then select the sites you want to install it on leave both “Installation Options” checked

Choose sites
Choose sites

Step 5: Click Complete Installation

Confirmation
Confirmation

All your sites are now protected from leaks of information back to WordPress.org

According to MainWP, “We prefer having an option to having .org track us or not since we are strong on privacy.”

There you have it. Protect your websites from the leak of information back to WordPress.org.

Download My Precious Plugin

Over to You

What are your thoughts?

Leave a comment below or join us in the Facebook Group to discuss this subject more.

 

Get MainWP News and Notifications

Todd Jones
Along with being the resident writer for MainWP and content hacker at Copyflight, I specialize in writing about startups, entrepreneurs, social media, WordPress and inbound marketing topics.

12 thoughts on “How to stop the information leak from the WordPress API

  1. Thanks for sharing.

    1. It worries me that WP seems to have such an indifferent attitude and I’m a little suspicious at the lack of clarity regarding the data being sent.

    2. Feel free to share the article. I admire your drive on this. I followed the steps Dennis gave and added the plugin to all my sites

  2. This comment sums up the core ticket the best.

    https://core.trac.wordpress.org/ticket/16778#comment:80

    1. Appreciate your attention to this Luke!

  3. Todd, thank you for this piece of information, I will install the plugin immediately. In order to increase the page load times, I have been looking for information regarding the data is being leaked from WP installations and how I can disable them so this is useful to me.

    Would be great to read more information like this from time to time

    1. Let us know how it goes!

  4. Thanks to Luke for bringing this up!

    Hope we see some changes as a result… wanted to note also that plugin solution mentioned only does a little bit in addressing this issue – those interested might also like to look at https://gist.github.com/mattyrob/2e492e5ecb92233eb307f7efd039c121 for some more options 🙂

  5. Two questions:
    1 — Is there a concise list anywhere showing exactly what data is being leaked?
    2 — I’m curious the thoughts on page load speed, as mentioned by Lee above. I wonder if the plugin will make things faster (disabling that piece) or slower (yet another plugin to the stack)?

    1. Hi Mickey,

      1-So there is not really a concise list on what data is being sent back from wp-admin to the api, it is mostly site url and active user numbers.

      2-The API calls are just on the back-end so they would not make any difference on the front-end load time.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.