12 Comments


  1. Note: *In my opinion*, they’re not “phoning home”. Information like PHP and MySQL version is indeed being sent back as part of the core update call, but the information is necessary information to get the proper core update response. Similarly, plugin and theme api checks send information like the plugin and theme headers, in order for the api code to be able to find the right plugins and themes to check updates for.

    It is perfectly reasonable for other people to see these API calls differently and say that this is “phoning home”, and I can understand their point of view. For this reason, plugins exist to disable those update checks if somebody wants to do so.


  2. Once upon a time, all of my plugins called home. I added an XML-RPC hook to my server to capture the calls that told me which plugin was installed, which version, what versions of PHP/WP/MySQL were installed, and the email address of the site administrator. They would also immediately send me any reports of crashes or errors so I could debug things proactively and release updates that targeted specific, observed user issues.

    The information was invaluable.

    But I gradually realized the problem with my system. I was, essentially, farming a huge email list on my site. I had contact information for thousands of users, the names of sites they administered, and detailed diagnostic information about their servers.

    And they had no idea.

    Then someone using a plugin I wrote in a tutorial found the code, loved it, forked it, and added it to a few of their own systems. Suddenly I had a flood of data from other plugins (they forgot to change the XML-RPC server endpoint) … again, without user input or permission.

    The thought that someone other than me could be collecting this data scared me to death. I trust me. But I also know some of the people who use my code, and I DON’T trust them.

    So, until I rewrite my API to allow anonymous, opt-in communication, I’ve pulled it from every system I write. I’ve also deleted any records I have on my end because, really, I don’t want to be responsible for holding on to an extensive list of other people’s email addresses.


  3. I’ve often thought that the best approach to handling this sort of thing, is to simply replicate what WordPress core does. If you set your plugins up to auto-update from YOUR site instead of WordPress.org, then you would have access to that data too. That would not require an opt-in, but would allow you to analyse data that you happened to access via the update API.

    Of course, this then means you lose out on “downloads” on your plugin or theme page on WordPress.org.

    FYI, I have not done this to any of my own plugins hosted at WordPress.org. It’s just an idea I had a while back.

  4. Ted Clayton

    Ubuntu’s system is the best around.

    Mozilla is walking itself out off a cliff.

    WordPress is well-loved, and has an inner circle that used to be so small as to be a singularity. So like your mother, it could get away with crap.

    Just modify the current Update menu item in Admin so that it is the users de facto “Opt in” agreement. It works mostly this way now … except for that nagging issue of it taking it upon itself to check certain ‘vital’ WP info, just because you happened to log in to Admin.

    WP gets away with it because they’re everybody’s trusted sweetheart.

    As WordPress grows, as inner responsibilities & authority is distributed and delegated, practices like these become greater liabilities.

    Facebook is sleazy. They’re successful, and powerful, and impressive. But they suck. Nobody feels sweet for Facebook; nobody trusts them to take out the garbage.

    Downside, yes, the installed WordPress base ages & decays. There will be exploits, using stuff that has been fixed in recent updates … which some people can’t be bothered to check for on their own. That’s why WP does it for them … to protect WP’s good name, to minimize those painful security traumas, of which there have been a few.

    Goose-stepping release cycles are a big part of the problem. Recently, we have watched it morph into an outright frenzy. Google goaded Mozilla into clinical hysteria, and they’re defending it to the hilt. Release-madness pushes coding, and deprecates testing. “Upgrades” replace validation.


  5. @Otto -I agree with Otto and would take it a step further. While, as a website owner, I may feel a little concerned about a plugin “phoning home” reporting how I use it, frankly if that’s the cost I have to pay for a free plugin that allows me or even my clients to extend the core’s functionality, then it’s a small price to pay and I’m willing to ante up. Frankly, I assumed that in this day and age that all free plugins or themes reported back to some extent and am (pleasantly) surprised to learn that WP holds plugin developers to such a high standard.

    Ted’s reply is typical whining from people who gladly take free software, complain when it’s not perfect, and expect not to have to contribute.

    I’m not a developer, I can’t contribute to the WP core or to a plugin project in that way, so if they need to track my usage, I’m happy to oblige.

  6. Ted Clayton

    @Daniel -

    Ted’s reply is typical whining from people who gladly take free software, complain when it’s not perfect, and expect not to have to contribute.

    Free Open Source Software is not the wilted lettuce and day-old bread that they sit out on the loading dock in the alley, for the unfortunate to pick through.

    There is still a lively debate, whether closed commercial paradigms are inherently handicapped, in comparison to open & free … but GNU/GPL projects have stayed right at the front of the pack for long enough now that nobody mistakes it for second-rate.

    No, the implication that of course one will pare off the moldy spots and pretend to prefer soft, rubbery greens, when he accepts free programs, misses the main facts about FOSS.

    Matt Mullenweg gives the product away, not just to crummy people and ingrates, but to everyone. And inspecting it for bugs, rot and suitability to purpose certainly is an important role of those who put it to use.


  7. @Daniel – Degrading privacy concerns to whining is just lame and misses the point completely. I feel sorry for you.

    Phoning home private things like my URLs and e-mail addresses is not okay in my books.


  8. We did some analysis on this a while back: http://interconnectit.com/1722/who-is-wordpress-talking-to/ – some seems not too sinister, but you do have to remember that there’s little in the way of protection of the data sent, and that somewhere there is possibly a big goldmine of install data that isn’t being shared with anybody.

    Due to the relative opacity of the organisations behind WP there’s no real easy answer – we can’t see in very easily to anything other than the code.

    Somebody will fork WP one day or another, if only to address the concerns that are required for enterprise use. That sensitive content posted to an Intranet site could find itself elsewhere (for example when using the Google API for spell checking) is a big concern.

    It’s perfectly valid to question these things and to look into the potential impacts for different groups of users. It may not matter if you’re a blogger in NYC but it may matter a lot to an activist in Cuba or an internal communications team at a government agency.

  9. Ted Clayton

    @David Coveney -

    The article on interconnect/it that you link to, What Exactly Does WordPress Tell The World? describes the concerns/motivations, and the particulars of the technical tests selected to investigate those questions, very well.

    The website itself, it’s homepage, has more in this general vein.

    Those who provide services to ‘non-IT’ businesses, who want to use IT but are not especially ‘into’ IT themselves, are both somewhat obliged and so-to-speak ‘given permission’ to leave behind a lot of the usual ‘postures & dance’ of Computerdom, which themselves can be persistent issues.

    I am not a business-person, and am not into IT business-services, but I am an experienced technical/systems person, and the way these tests were set up & described in the article is very good.

    Thanks!


  10. What has always bugged me is the the installed plugins/theme info sent to wp.org. WordPress.org can identify each site by url and the plugins/themes installed and/or activated on it uniquely, along with the full plugin headers (author, name, author site, etc). And most importantly they do that for ALL plugins/themes, whether or not they came from the repo and have a valid reason for being sent (checking for updates).

    Most worrying is the conflict of interest when it comes to WordPress.org vs Automattic. What kind of privacy policy covers that data? Does Automattic the for-profit corporation have access to this valuable information on their potential plugin, theme, and service competitors? Even if there are strict protocols in place there, the same guy runs both so there is information overlap. If I were building a competing plugin or service to one of automattic’s (akismet, VaultPress, etc), they would have valuable data I don’t for things like gauging potential demand or keeping an eye on competitors.

    So why is wordpress sending info on things it doesn’t? It should only send:
    - Installed themes/plugins FROM THE REPO
    - Their active status (useful for repo stats)
    - Only their slug + version number (all header data is extraneous)

    When I designed my own update notifications plugin (http://premium.wpmudev.org/project/update-notifications), I made sure it only sent the list of installed plugins of ours, as that’s all that’s needed and all that we have a right to.


  11. We just went through quite a bit of discussion about this issue internally. The end result was not to do anything for the moment, except we included a “submit a support ticket” system in our plugin.

    Initially, I had gathered some site meta data to include with the ticket; but I realized that I was breaking a cardinal rule with interacting with customers, so now we include a “Here is what will be included in the support ticket” box with *exactly* what we’re going to poll. On support tickets especially, we’re virtually always going to ask the same handful of things: What version of WP are you running, what’s your current theme, and what plugins are active? Now we can just gather those facts with the request.

    Of course, we’ve tried to further make it clear that if the customer doesn’t want to include that information, they can email us directly for support. Unfortunately; those are the exact things that we need for virtually any support request!

    Good post though; I think as plugins & services for WP get more sophisticated it’s important that the plugin & theme development communities stay in front of this. Watching the current crop of stuff coming up around this whole iPhone “address-book-gate” I think respecting our customer / user privacy & data is more important than ever. Even things that we might interpret as trivial or aggregate and unthreatening.


  12. Dave’s Dashter certainly does it right, prefilling a form that clearly indicates what will be sent and sending it. Kudos for that (and the very awesome Dashter too).

    I do wish someone you come up with a chunk of code that ALL plugin authors not using the wp.org repo could use the check for update and auto-install. In fact I really think this should be in core, although I suspect the powers that be would strongly object to that. Having a system built into core would at least standardize the data policy surround updates and potentially around bug-reports too.

    Aaron does raise a good point about data sharing between wp.org and Automattic… would be interested in learning the answer to that.

Comments are closed.