WordPress.org introduces a killswitch?

Joost de Valk over at yoast.com has together with Andrew Nacin (see update) used wordpress.org to try and kill of a plugin. A bad plugin, an evil plugin but the nature of the plugin is not the real problem in this story. Their actions has to me opened up a can of worms that we need to deal with.

So what exactly did they do?

They, as Joost De Valk wrote on his blog, took advantage of WordPress automatic updates and created an empty plugin on WordPress.org with a higher version number than BlogPress SEO. WordPress then displays that there is an plugin update available and when people download it BlogPress SEO gets its essence removed. This only works since BlogPress SEO didn’t disable automatic updates. In other words WordPress.org has been used to try and kill of a plugin that people did not like.

So what does the worms represent?

Well they represent as I see it 3 questions that the WordPress Community needs to deal with.

1. Should WordPress.org be used to try and disable plugins/themes?

This is really the big question. And I think a lot of people will say yes but to me this goes beyound the nature of the project and into ideology. The very essence of open source projects is to give end users power over their software, a killswitch would essentially take away power from the enduser and give more power to the project leadership.

One of the arguments for GPL is that it empowers the end user to take control over the software they use, killswitch removes power from the ordinary enduser. Would a killswitch be inline with the ”spirit of the GPL” that GPL advocates love to throwaround?

2. What criterias needs to be met for doing so?

So assuming we answered Yes on the previous question what criterias should plugins and themes have to meet inorder to be killed off by remote control?

If you’re a WordPress GPL conformist you would say one criteria is: Plugins and themes that does not conform to the GPL. But I won’t say that since I hope no one is so stupid that they would actually do something like that. Not that this criterias hasn’t crossed my mind given the attitude in certain parts of the community with regards to the GPL.

On a more serious note the criteria would be: The plugin/theme purposely creates a backdoor. That is gives access to people that is not suppose to have access to the WordPress site. Why purposely? Well security holes is to be dealt with by contacting the author of a theme/plugin regardless of the plugin/theme license.

3. And who decides which plugins/themes that should be killed?

Yes the management question. Who is in charge of what? Would it be up to the core devs? Matt? Plugin/Theme reviewers etc? I have no answer to give on this question. All choices will be wrong for some people.

So what do you think? Should WordPress.org take the step and introduce a plugin/theme killswitch?

** Update **
Andrew Nacin was not made aware of the purpose of Joosts plugin, so the removal of BlogPressSEO was not sanctioned from above.
You should keep an eye on Joosts De Valks blog for more interesting news regarding wp.org.

8 Responses to “WordPress.org introduces a killswitch?”

  1. Torsten
    November 14, 2010 at 14:12 #

    Well said Andreas!

  2. Robert O'Rourke
    November 14, 2010 at 17:04 #

    Hi, this is fair to be worried about but I have faith in the community to police the use of this. If someone gets stung theyll find out and they can prevent it within their plugin like you say. The reason I think this can be good is that there are lots of people using plugins, plugins don’t get the kind of scrutinisation that themes get and you simply can’t assume that everyone knows what they’re doing. Saurabh could have easily submitted his plugin to wp.org.

    What the community needs to be able to do is have a listing for plugins on wp.org, ideally even paid for ones, and allow community members to flag a plugin for review and removal if it’s suspected malware.

    Regardless of your politics regarding the GPL the wordpress community should be taking the idea of protecting the users of WP very seriously because we can’t assume that users know what they’re doing beyond being able to install the software.

  3. James Morrison
    November 14, 2010 at 18:15 #

    If you read Joost’s blog post and can see just how malicious this plugin is, it’s important that people stop using it right now.

    Let’s assume that anyone who installed the plugin hasn’t looked through the code prior to activation and doesn’t understand the implications of what the code does i.e. allow anyone with the admin email access to the site (p.s. the admin email is sent to the plugin author on activation).

    It’s fully justified that Joost and Andrew take advantage of automatic updates to correct this problem.

    If a plugin is free why isn’t it in the WP.org repository already unless it has malicious code?

    • Andreas Nurbo
      November 14, 2010 at 18:55 #

      Hi James
      Like I said in the intro I’m well aware of the nastiness of the plugin in question. Its not really about this plugin it is about the principle. But I’ve now learned that this was not sanctioned from above and Andrew Nacin had no direct involvement in the action except for approving the plugin. He did not know the purpose.

      If a plugin is free why isn’t it in the WP.org repository already unless it has malicious code?

      Numerous reasons. I host some plugins myself because its easier and I’m not limited by the rules for hosting at wp.org.

  4. Nick Ohrn
    November 15, 2010 at 04:36 #

    This is, without a doubt, a problem. I think that disabling and destroying a plugin is beyond the purview of the WordPress.org repository. The repository exists as a means to provide hosting for GPL licensed plugins. I don’t think that it should be used as a method to remove plugins that the repository managers don’t agree with.

    I fully understand what the plugin was doing, and it was bad, but that’s why all the code in the repository is licensed GPL. People who install those plugins can look at the code or have a trained professional look at them.

    This seems Apple-ish in its level of control, and I don’t mean that in a good way. The repository should never be used in this manner, no matter what the content of the plugin is.

  5. Chip Bennett
    November 16, 2010 at 04:56 #

    The solution seems simple to me: release a Security Plugin into which such kill-switches can be placed. That way, if users *want* WPORG to implement such tactics against nasty Plugins, the user has given some consent for them to do so.

  6. Brian
    January 26, 2011 at 20:33 #

    The software could be yet another poor copy of programs. Considering all the cloned reviews of the software I’m beggining to wonder if any of the testers have even tried the program.

Leave a Reply

Keywords are not a name. If you use keywords for a name you get marked as spam, this goes for writing them in french, german etc.

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Get Adobe Flash player