Product Customer List for WooCommerce plugin misuses the wp_options table

Dave Hilditch
Talk to me

I actually discovered this performance issue right here on our own website. Normally I discover performance issues on client or customer websites. From now on, as I discover badly behaving plugins, either on my site, or through optimisation work I do for clients and customers I will be taking the time to write about them and expose this bad behaviour.

My first hope is that these plugin authors will be shamed into acting – if you own this plugin, you could contact the plugin authors through their support channels and link them to this article. My second hope is that WordPress developers learn and improve over time. It’s a sad truth that many plugins are written with truly awful code where the developers spend more time on marketing than they do on quality of code.

Plugins list with all plugins blurred out except Product Customoer List for WooCommerce.

In this case, I had Query Monitor active and was looking for something else – something related to MailPoet which I really dislike as a plugin but that’s a story for another article. While I was looking at what MailPoet was doing wrong, I discovered the following terrible behaviour on pages totally unrelated to products – i.e. the Product Customer List code should not be running:

The Product Customer List for WooCommerce plugin updates options on unrelated pages, indicating potential tracking behavior.
The Product Customer List for WooCommerce plugin updates options on unrelated pages – and it looks like it’s tracking you

You can see in the screenshot that this plugin is updating a few options, notably which plugins you have installed and then also many details about your installed plugins including license keys. That’s not cool.

If you look at the call stack, it looks like it gets initiated by the Surbma GDPR plugin and then by Freemius which is located inside this Product Customer List plugin.

Freemius, in case you don’t know, is a rather large company who provide a licensing system for small plugin developers to help them manage licensing and sales. In return they take 7% of your revenue. They seem decent, but I’m going to investigate further to figure out what is happening here with the storage of license keys in this option.

Call stack showing Surbma GDPR plugin and Freemius responsible for storing information in wp_options table for Product Customer List plugin.
Surbma and Freemius seem to be responsible in the call stack for storing this information for the Product Customer List plugin

Upon further investigation, on my own website I have 3 plugins which use Freemius – Surbma GDPR which I’m going to replace, EU VAT assistant which I no longer use and this Product Customer List for Woo plugin which I’m going to remove.

Freemius folder inside Product Customer List plugin calling home with installation info.
Freemius asks plugin developers to include this freemius folder which then seems to be calling home with info about my installation
Digging further, we find that wp_remote_post is wrapped inside a static function called safe_remote_post

The sensitive info (which plugins you have installed) is stored against fs_accounts, but in the code this is enumerated as: WP_FS__ACCOUNTS_OPTION_NAME

Suspicious filenames referencing WP_FS__ACCOUNTS_OPTION_NAME for storing sensitive information.
WP_FS__ACCOUNTS_OPTION_NAME is referenced in a few suspicious sounding filenames
Recommendation to find an alternative plugin and avoid Product Customer List for WooCommerce performance issue
On my server, 92KB is being saved to the wp_options table, this happens 4 times for some reason and on every admin page load

According to Freemius and @Vova, they gather all of this data in order to help their plugin authors improve the usage of their plugins.

I myself am planning to add something like this in a future version of Scalability Pro, but you can be 100% sure that I will ask users – they will have to opt-in – and it will be 100% clear what they are opting into and what type of information will be sent to us.

Probably better than that, I probably won’t make the data submission automatic – I’ll probably raise it at a relevant point in time and ask the admins if they would like to send this data to us rather than doing it hidden underneath.

Here’s what Freemius had to say:

Freemius deny any wrongdoing, claiming to be GDPR compliant, but I definitely never approved for them to collect this information on my website
Freemius has tried to obfuscate this data collection behind ‘never miss an update for the plugin’ type messaging

There is quite a bit more back and forth with other customers getting involved, but the upshot is it looks like Freemius do not care and are going to remain non-compliant with GDPR.

https://wordpress.org/support/topic/freemius-and-privacy-concerns/

As for me, I care about performance and that’s how I got here in the first place – what is this plugin updating massive options on every page load?

The answer is that it’s any plugin that has Freemius embedded that is saving massive amounts of info to your wp_options table and then at some later point uploading this info to the Freemius servers so the plugin authors can review their analytics and so Freemius can improve and track sales.

For me, I’ve now removed all 3 of these Freemius embedded plugins and Freemius is now on my blacklist. If any plugin comes embedded with Freemius, it is not recommended for both performance and GDPR-compliance reasons – controversial given that one of the Freemius plugins is focused on helping you stay compliant with GDPR!

2 Comments
Show all Most Helpful Highest Rating Lowest Rating Add your review
  1. Really interesting.

    What bothers me, too, is the wp_options = autoload yes for frermius options. Do you think these could just be set to autoload = off?

    • How big are they and how many of them are there? Then the other question, are they actually used and looked up on every page? If they are not used on every page then turning autoload to off will help.

      You can test turning off items to check before & after performance by setting autoload to anything other than ‘on’ – the PHP code does not check for alternative values, it only grabs items that have ‘on’. When get_option is called and the option requested is not an autoload item, in that case a SQL query is created to grab that item and they ignore the autoload option in that case.

      i.e. you could set autoload to ‘test_freemius’ and this would switch autoload for those options off, and then if you need to switch them back on then you can target all the options with autoload=’test_freemius’ in order to reset autoload to ‘yes’

Leave a reply

Super Speedy Plugins
Logo