Automattic Acquires Parka LLC, The Creators Of BruteProtect

photo credit: Peter Slutsky
photo credit: Peter Slutsky

The parent company of BruteProtect, Parka, LLC has been acquired by Automattic for an undisclosed amount. BruteProtect is a service providing brute force login protection for thousands of WordPress sites. The BruteProtect plugin will be phased out and rolled into Jetpack and will  remain free to use. The services offered by BruteProtect pro are now free for anyone to use. As part of the acquisition, all seven Parka employees will be employed by Automattic and will be part of the Jetpack development team.

Once it’s merged into Jetpack, an announcement will be made to confirm the end-of-life date for the BruteProtect plugin. You won’t have to worry about managing two different API keys since it will function with the same key used by Jetpack. Unless you opt-out, BruteProtect will run at the same time as Jetpack. However, it’s unclear if it will be an auto-activated module when the merger is complete.

The Origin Of BruteProtect

BruteProtect Plugin Header
BruteProtect Plugin Header

In 2013, Matt Mullenweg published an article with his thoughts on passwords and brute force. The article was published around the same time a large botnet was using brute force techniques to login to WordPress sites using Admin as the username. The article generated a healthy discussion on the WP-Hackers mailing list, especially around the Limit Login Attempts plugin which is commonly recommended to protect against unwanted login attempts.

The discussion prompted Hotchkiss to come up with a better solution. Instead of websites battling the problem alone, BruteProtect brought websites together to fight a common cause, similar to how Akismet works. Little did he know that he was writing his destiny.

Another option to consider would be adding a “Security” plugin to Jetpack.

This could be used to manage a centralized blacklist, as well as to patch security vulnerabilities as they pop up. If all failed login attempts get reported back to Jetpack central, it could blacklist an IP for X minutes/hours after Y number of failed logins on any Jetpack-enabled site within Z minutes/hours.

Since its launch, it’s been installed on 106,836 sites and defended against 135,986,764 brute force attacks worldwide.

BruteForce Protection For The Masses

Having the product remain free was an important part of the acquisition. “I feel strongly that we need to be free and used by as many people as possible in order to provide the best protection and to do the most good,” Hotchkiss told the Tavern.

With BruteProtect now part of Jetpack, millions of websites will be protected from BruteForce login attempts and contribute to the centralized blacklist of IP addresses making the service much more effective. I think this is a huge win, especially for those who use Jetpack. Users don’t have to figure out technical jargon or difficult configuration settings.

What do you think about the acquisition? Let us know in the comments.

39 Comments


  1. Please don’t! I really enjoy BruteProtect and have it installed in all sites that I develop… Now it’s time to find another option…

    Jetpack is great for non tech WordPress users, but for developers is just a lot of unnecessary options to slow down our website…

    Crap…

    Report


    1. I agree!

      In fact, I’d go further. Jetpack is everything that a WordPress plugin should not be. After all, WordPress is supposed to be modular.

      This is not a huge win, Jeff. It’s a huge loss!

      Report


    2. Many of the features in Jetpack, like Photon, actually speed your site up. Others like the sharing buttons and related posts are way faster (and protect your privacy better) than many of the standalone alternatives. And finally the promotional aspects of hooking in your Twitter, Facebook, etc and some connections we have to search engines and SEO stuff built into Jetpack will get you more traffic. Jetpack is absolutely for developers, just not everyone has caught up to that fact yet.

      Report


      1. Hi Matt,
        Jetpack might be for the develper if this plugin system provides an API. :)
        I like many of the tools from Jetpack (Jetpack comments, subscribe to posts), but how they function is very general. For examplet the CSS/JS libs are included on every page, even if the tools aren’t use on these pages. I guess this is something what a user means if they say that Jetpack will slow doen your website. Most Jetpack tools doesn’t provide options for the experienced user and require to use other Jetpack tools too: To add the Jetpack subscription option to your contact form you need to use the Jetpack contact form wich is very limited in functionality. I really would like to use Jetpack on every website, but need to consider this choice most of the time.

        Report


      2. For me, and many others I’ve spoken to, while JetPack offers various benefits, it means connecting more data to WP.com. That’s the beauty of WP.org and self-hosted: we’re not forced into connecting data points that we don’t have to. Instead, we can use the most optimized plug-ins and settings that are right for our needs, versus being restricted to what JetPack decides are optimal.

        Report


  2. Hmm.. I tried out Brute Protect the same day I read about it here, a little over a year ago.. As of today I can claim just over 84,900 of the 140,135,150 Attacks Thwarted number Brute Protect has posted today. The Plugin has never given me any problems.

    But I don’t use Jet Pack, and probably won’t start just so I can use one of the of the Jet Pack plugins…

    Report


  3. Sounds like good news Jeff but that’s not reflected in the comments!!

    As with most things time will tell.

    Report


  4. I am not a fan of this news. Pleased for the BP devs, but hate the fact I now have to use JetPack if I want to continue with BP. JetPack is fine for hosted WP sites, but there are far better solutions all round for self-hosted bloggers. This is a disappointing move, and will mean I’ll have to look elsewhere, as I refuse to use a poor man’s option for the features JetPack “offers”, just to get BP.

    Report


  5. black listing IPs is a bad idea however it is implemented. If it didn’t work for spam why should it work for logins? I can also claim zillion successful protection events by simply using a good password. The real test for such a service is the ratio between true positive – how many malicious logins, ones that used the proper user and password were prevented, and false positive – resulting in people being locked out of their sites. without the false/true positives ration the bruteprotect stats are meaningless.

    And it is not like wordpress.com needs the service as they have enough attacks on their sites to build a good IP DB by themself, therefor I assume that if any technology was actually acquired it is related to remote managements and not protection.

    And jeckpack…. it becomes a incredible piece of bloat, soon it will probably be bigger then wordpress itself.

    Report


    1. I agree that a pure blacklist approach is not a good idea. Fortunately we’ve learned a lot over the years building Akismet (now blocking 7.5M spams a hour) and will put some of that learning toward this problem as well.

      Report


      1. Matt, IMHO the biggest challenge with BP is how false positives are being handled. With all due respect to comments, losing one because of a false positive is usually not a big deal, but getting yourself lock out of your site because of a false positive can raise a nasty “OMG someone hacked my site” moment.

        Report


  6. Hey guys– I totally understand where you’re coming from re: Jetpack. There are a lot of people who feel like it’s too bloated, etc.

    A few things:
    1) The data that we’re going to gain by being a part of Jetpack will have immeasurable significance. We’re talking about millions of sites that will be contributing data to our algorithms, making everything better.
    2) The Jetpack team (which now includes us), is aware of the concerns, and they/we are going to be working on ongoing performance enhancements. There is a *lot* of exciting stuff coming down the Jetpack pipe.
    3) This deal will allow us to keep sites safe for a long time to come. At the end of the day, running BP is a very expensive venture, and having the backing of Automattic makes the future both solid and bright.
    4) You don’t need to install Jetpack today, tomorrow, next week or next month. Once our BP integration into Jetpack is ready, we will give you at least 3 months before BP will cease to function. Give it a little time and see what you think of Jetpack at that point.
    5) Remember that Jetpack is totally hookable and customizable. You can turn off EVERYTHING in it except for BP if you’d like.

    We wouldn’t have made this deal if didn’t have 100% confidence that this would be the best move for both our current users and the community as a whole. We have always had, and will always have a complete commitment to making the WordPress community better, faster, and safer, and we know that we can take leaps and bounds towards that goal with this partnership.

    Best,
    Sam

    Report


    1. Hey Sam, great that you come here to comment.

      The Jetpack team (which now includes you) have a lot of work to show WP developers that Jetpack have true value for our works…

      The most frustrating part of Jetpack is that after every update we need to change our code to disable crap that are automatically activated by Jetpack… which means that after every Jetpack’s update I need to login in ALL websites I manage to update things. Why can’t Jetpack keep it simple??

      I hope you guys maintain BP as a standalone plugin not only for three months…

      Report


      1. Hey Darlan– one quick comment:

        add_filter( ‘jetpack_get_default_modules’, ‘__return_empty_array’ );

        That filter will ensure that NO modules get auto-activated, ever.

        Report


      2. Sorry, but that’s the wrong answer, Sam.

        The right answer would have been that, now you’re part of the Jetpack team, NO modules will get auto-activated, ever.

        Report


      3. I don’t entirely agree. Keep in mind that many Jetpack users are novices looking for “plug-and-play” functionality. The developer crowd – proficient, smart people – should be capable of going in and turning off unnecessary modules *or* using the snippet that Sam mentioned. What’s a few extra seconds in a project that takes days, weeks, or months to complete?

        Personally, I like Jetpack. It covers a lot of the base functionality that used to be handled by a bunch of other plugins. I trust the development team, and I appreciate the diligence that’s put into the product.

        Is it perfect for everyone? No. But it serves a purpose.

        Report


      4. Why does that filter have to be invoked? Shouldn’t that be the default out of the box?

        Report


      5. I don’t think so — some things really make sense to be on for as many people as possible. That’s the promise of Jetpack, why it’s become one of the most popular plugins in the world in just a few short years: complete, integrated, hassle-free functionality, always the latest and greatest.

        Some advanced users may not like that, and they can have plugins or filters to alter how JP works, but it’s the right answer for the vast, vast majority of WordPresses in the world, the same way that new features in core are “on by default.”

        Report


  7. I agree with the majority of voices here – this should be and would be great news and a reason to truly celebrate on one condition:

    That Jetpack is rebuilt to remove bloat.

    In its current distended state there is no way that I would be running it on any of my sites. I’ve worked way too hard to optimize them to drop in a 200 tonne plugin to weigh down my server.

    I’d wager that the average wordpress user has no idea that jetpack is actually larger than the core wordpress install!

    Report


  8. I’ve known Sam for a few years, and other members of the Parka team for a while as well, and they’re all amazing, and I’m so happy for all of them. They deserve this success and I know it will lead to amazing things.

    That said, I wanted to throw my two cents into the fray here, because this is the Internet, and that’s what it’s here for :)

    I’m a bit disappointed that BP is being rolled into Jetpack, but not because I’m anti-Jetpack (I don’t use it regularly, but that’s just because I don’t need its features).

    Really, I’m disappointed because I think it would be much better to see BruteProtect merged into Akismet.

    The comment spam that Akismet is designed to stop is basically (warning: gross oversimplification) brute force attacks pointed at the comment form. BruteProtect is designed to stop brute force attacks pointed at the login form. Both use distributed knowledge as their main method of protection, making them a perfect pairing.

    Adding to the benefits? Akismet is included with WordPress by default, while Jetpack isn’t (and I hope it never is; again, I don’t hate Jetpack but I don’t think including it by default is the right decision), making it more likely to reach a broad number of installs.

    And, as Akismet tries to get more people coughing up a few bucks a month, the value proposition would be essentially doubled—and much more compelling—if that subscription fee also included the benefits of BruteProtect.

    I’m sure the decisions have already been made and there’s little point in making my case, but as brute-force attacks become more common for self-hosted WordPress sites, along with surges in comment spam, I think there’s a really compelling argument to be made that such essential protection shouldn’t be tied up with Jetpack, which people have such strong, divided feelings about.

    Akismet is widely loved, already focused on solving a “brute force”-style problem with distributed knowledge, and is installed on a massive scale. To me, it just seems like a much more logical home for the features BruteProtect offers!

    Report


    1. Also, I imagine there could be improvements to both BruteProtect and Akismet’s data if they shared resources. Maybe blacklisted IPs in BruteProtected are automatically throttled from commenting, or IPs blacklisted in Akismet aren’t allowed to log in without some kind of verification check.

      I know this type of data-sharing is possible without rolling the two into a single plugin, but it would make much more sense to end users if they were just additional features in a single product rather than two separate products that happen to communicate (if you have both installed and configured separately).

      Report


    2. I thought a lot about putting it into Akismet, or VaultPress, but ultimately decided against it. These days Jetpack actually gets better distribution, and is a better place to put free functionality that we want available to as many people as possible. I’d like as many of the WordPresses in the world as possible to be protected. BruteProtect also can auto-update plugins and themes — something like that just doesn’t make sense for Akismet, which is best with its narrow focus on the commenting experience.

      Report


      1. Hi Matt –

        First, thanks for responding. I truly appreciate your hands-on approach to the WordPress community.

        Second, I totally understand mixing BruteProtect into Jetpack. I can see the logic, even if I think there’s a better alternative. Admittedly, I don’t have the experience you’ve had running a company at the scale of Automattic, and may be missing aspects of your long-term vision.

        Perhaps a good compromise (not that you need to—it’s your money!) would be to commit to offering a BruteProtect API, similar to the Akismet API. That way, third parties could offer a BruteProtect-powered experience outside of Jetpack, much like Akismet can offer. (In fact, I’ve been able to use Akismet in projects completely unconnected to WordPress because of this API capabilities.)

        Anywho, thanks for taking the time to read the comments here. Independent of other issues and disagreements, a leader like yourself is the reason the WordPress community (and, as a result, my business and livelihood) can flourish.

        Cheers!

        Report


  9. The acquisition and plan to keep the BP service free looks like a win for WordPress users.

    My understanding is that deactivated plugins do not slow down a site, except perhaps viewing the plugins page or in this case the Jetpack settings page.

    Report


  10. My gosh, Jetpack ain’t that bad. They’ve actually made it easier than ever to turn off the stuff you don’t want. Giving the average user some bundled security (for free) is a nice move.

    Report


  11. Personally, I’m a fan of single purpose themes and single purpose plugins.

    But I guess I’m in the minority. Users seem to want to buy multi-purpose themes and to download multi-purpose plugins. I can see it from the average user’s point of view even though I don’t particularly like it.

    In that context, I guess it’s a good move.

    Report


    1. Check out previous surveys from State of the Word talks — people’s top complaints are around plugins: security problems, compatibility with core updates, compatibility with each other, and not knowing which are good.

      Jetpack solves all those, and it’s telling that all the folks that run millions of WordPresses (Automattic, all the web hosts) support Jetpack.

      And lots of other goodies — I’m keeping up with comments here because Tavern is a Jetpack-enabled site, so I get a notification in my toolbar and mobile apps when there’s a reply to me here.

      Report


      1. Hi Matt,

        I know that it solves real problems and provides great value. That’s definitely not in question.

        I’m just saying that, personally, I’d rather have a series of separate single-purpose plugins than one multipurpose plugin.

        I get that most users aren’t like that. I get I can fork it or use something else if I don’t like it. I was just stating my personal preference. :)

        Report


  12. Blacklists only produce false positive results. Filters only product false positive results. Those two methods are used by Akismet and BruteProtect. Simple Comments uses anonymous authentication, which results in zero false positives to block spambots and hackbots 100% of the time. I guess we should start posting our customer’s spambots and hackbots blocked numbers, since that seems to be the trend.

    Here’s just one of our customers using Simple Comments to block 890,388 hackbots on the WP login form in just a few months, without any impact on the server’s performance.

    http://cl.ly/image/06462x2F0o2U

    https://www.toddlahman.com/shop/simple-comments/

    Report


    1. What do you mean by “Blacklists only produce false positive results”? Yes occasionally a legitimate IP will be blacklisted, but that is usually due to activity initiated due to a compromised account. After it is cleaned up the IP is removed from the blacklist. Blacklists are very effective and have been used for many years before BruteProtect or Akismet became a thing.

      Report


  13. I think it’s good that it has been acquired by Automattic, as they have the resources and marketing ability to make it popular. But I find it sad that it’s being shoved inside JetPack. Hopefully someone will maintain a good plugin which sits outside of JetPack, yet hooks into the same API.

    Report


  14. I agree that adding BruteProtect to JetPack is the right answer for “the vast, vast majority of WordPresses in the world”, and I understand this decision within that context.

    However saying “some advanced users may not like that” will I expect prove to more than a little understated. There is clearly at this stage significant resistance from many WordPress Developers to being effectively forced to use Jetpack to gain access to BruteProtect.

    Some of that resistance might be overcome by the JetPack team fleshing out Matt’s comment that advanced users “can have plugins or filters to alter how JP works”. It makes sense to listen to the concerns expressed here and develop hopefully relatively simple ways to overcome them.

    Nevertheless I expect that many advanced users will remain resistent to using JetPack and look for alternatives to BruteProtect.

    Report


    1. @buzztone what are you looking for as far as “fleshing out Matt’s comment”? There are currently 133 actions and 333 filters in Jetpack that allow you to customize nearly everything.

      Report


      1. @Ben Lobaugh – In this instance I mean giving people that are resistant to using JetPack, due to the reasons given above, a few easy ways to mitigate those specific issues.

        For example I would suggest the JetPack team write articles which show advanced users which hooks they should use and how to use them to meet their concerns in this instance.

        You can also point them at current suitable plugins, or write a new one which deals specifically with their concerns.

        It makes sense to try keep as many advanced WP users onboard with BruteProtect. That way they can continue to evangelise for BruteProtect within the WP Community.

        The JetPack team can help that happen by listening to their concerns and offering suitable solutions that meet their needs but at the same time don’t damage the main objectives for BruteProtect with the “the vast, vast majority of WordPresses in the world”.

        If they don’t do that, it is highly likely IMHO that many advanced WP users will continue to evangelise against the inclusion of BruteProtect only within JetPack.

        Report


  15. Never heard about this plugin until today ! i will test it, add some security to wordpress is not a bad idea :-)

    Report

Comments are closed.