Duane and I work very hard, this much is uncontested. We both recognize that to grow our company and to do things they way they ought to be done in this business means a high level of dedication, will, determination and fortitude to ensure success. We’ve been working non-stop on a variety of client projects, like courtneysummers.ca, visioncritical.com, ticketfly.com, and Rogers’ urmusic.ca. We’ve also been working on our GPL projects like WordTwit, BuddyPress Geo, and of course WPtouch.

So, in short: We think we deserve a break.

Punta Cana

We’ve chosen a nice spot in the beautiful coastal area of Punta Cana in the Dominican Republic. Duane and I will be there for two weeks and will be going over company year-end stuff, planning for the next phases, and re-positioning some of our ideas to grow as a company in 2010 in the directions we really want to see things move.

Business + Pleasure

Of course a place like this doesn’t often invite the idea of ‘business’, but that’s just how we operate- why not do some of the more onerous tasks in a place you’ll enjoy? Most people wouldn’t know it but we run this company, for the most part, virtually. Duane and I live on separate sides of this big country of Canada, and a getaway like this facilitates a number of personal and business needs for us both.

Unsupported

We’ve yanked the plug on our plugin Support Forums for the time being, mostly in an effort to stop the tides of on-going to-do lists so we can focus on the overhaul we think is sorely needed, and will bring more to the table for the user community of our plugins. We apologize if it leaves you high in dry in the mean time, but rest assured that we’re not walking away from our plugins or supporting them.

Surprises

Who knows, maybe we’ll push out some plugin updates while we’re down there, or a beta of one of our slow-cooking WP plugins like Transporter (backup/migration) or Integrity (security).

Itinerary

Duane’s already arrived, and I’ll be leaving tomorrow afternoon. Weather’s looking hot and bright for the week ahead, so too for our plans : )

As we approach 300,000 downloads of WPtouch and nearly half a million if you count up our other plugins, we’ve been reflecting on what we’ve accomplished and where we’d like to go from here.

Our plugins are freely available and GPL, which means that donations are the only source of income they generate at this time. So our main source of revenue is working with some terrific clients building websites, and doing various development and graphic design for 3rd party services and products.

Over the past year and half that we’ve been running we’ve poured thousands of hours into our client work, and hundreds into our plugins. More recently we’ve had very little time to improve upon our GPL offerings, though.

I’d be lying if I said it didn’t bother me that at times it seems that people think they’re entitled to the work we produce and improvements upon it. Though it is very much the minority of what we experience from our users, it’s something that can easily take the wind out of our sails— having someone acting as if a bug in your free software is a serious problem that you must resolve or they’ll axe you.

As tough as it is, we’ve realized that our experience with free software only serves to embolden the reality of the expectations we have regarding the future and the real liklihood that we’ll release some pretty cool products or services that will be revenue generating— and which will indeed be supported and will be improved upon over time.

The Ever-So Cool Pipeline

With all of that said we’re excited to soon promote and discuss the future of BraveNewCode and what we have coming down the pipes. Our focus remains with WordPress, but we’re looking at ways we can both expand upon our existing plugins, add new and powerful ones, and build an eco-system of BraveNewCode products and services which will enhance not only WordPress but the way people use the internet, period.

It’s an exciting time, and there’s nothing but hard work ahead for us.

Fade To Black

We’re taking off on a company hiatus/strategy planning vacation in late November, and at that time we’ll be phasing the next steps for what we’re trying to accomplish. For the most part there will be a code-freeze on what we’ve done to date, but rest assured that WordTwit, WPtouch and our other forthcoming plugins like Integrity are going to get the love and attention they deserve.

Look for some exciting changes to take place in the coming weeks/months ahead from us. If you want to stay on top of the pulse follow us on Twitter and subscribe to our newsletter— in both places we share secrets you won’t get here : )

There’s been a lot of hubbub lately regarding security and WordPress. You’ve probably read a few of the more popular articles about the matter, and likely heard some of the opinions from notable technology gurus. Some of the solutions to increase and maintain security for a WordPress installation are rather straightforward— others… not so much. But they all don’t do anything after an attack or compromised WordPress installation has occurred. This is what Integrity for WordPress seeks to change.

We’ve come up with a plugin that uses a variety of methods to detect if WordPress has been modified in any way. We’re calling this plugin Integrity for WordPress, and it’ll do just that: verify the integrity of a WordPress installation, including themes and plugins. If they are hacked selected e-mail addresses will be notified immediately about the change, told what file(s) were modified, and given some options to act against it.

But we’ll get more in-depth with what Integrity does a little later in the article. For now let’s look at existing solutions so we see what Integrity isn’t.

A, B, U: Always Be Upgrading

Matt Mullenweg, co-creator of WordPress himself recently recommended and advocated that users are best protected by trusting WordPress’ security, with a caveat that it’ll require WordPress users to be running the latest release always.

This approach is indeed a valid one, and certainly for many users it’s easy enough to follow. It doesn’t ensure certain types of WordPress attacks or compromises don’t happen but it does protect against some of the more serious and dangerous ones. However, there are real-world use scenarios where ABU is next to immpossible, if not just impracticable.

We have several larger clients who on an hourly basis are monitoring their websites, making redundant backups, adding/changing content and so-on. If they’re going to do an upgrade they’re going to backup the entire ftp environment along with grabbing a database backup, and that costs time and money.

We also have clients who have an intimate theme/plugin scenario where an upgrade may possibly disrupt this. We work as hard as possible to future-proof our work but other plugin developers and the whole of WordPress itself can’t be quantifiably determined with regards to what will happen next and how it will happen.

So let’s assume there’s a pool of people for whom ABU isn’t viable.

Permissions and Server Side Security

We don’t profess to be gurus in these areas ourselves, but their are some rudimentary precautions and steps you can take to add security to your self-hosted WordPress installation. They’re a very good idea but often require more than a freshman’s knowledge when it comes to applying them properly to your WordPress install. Setting the correct permissions requires knowledge of FTP programs and unix; modifying php.ini or similar requires at least some working knowledge of Apache and server environments. Every web host is also a little different in how they apply settings, what type of allowances/blocks they allow customers to control, and so on.

User Accounts / Coding Practices

Another way for WordPress to be compromised is through the admin account or by using certain types of PHP code in a WordPress theme. Once a hacker has access to an admin account they can do pretty much anything. If your theme contains easily compromised code it’s impossible for WordPress to protect, save for WordPress deciding not allow that code to be used at all which isn’t a very nice approach— potentially thousands of websites unknowingly running themes with these types of holes would be broken instantly upon a WordPress upgrade that disallowed such code.

Existing Plugins

Looking at the WordPress repository for security-related plugins you’ll find a number which on the surface look to be helping the WordPress security scenario but ultimately fail to cover some of the most basic routines (such as checking WordPress and user files for changes) or scanning and repairing permissions on a WordPress install.

So there are indeed plugins out there, but most aim to cover one specific area of WordPress security and none actually prevent themselves from being compromised.

Introducing Integrity for WordPress

Integrity for WordPress does a couple things which are unique. First, it looks at your ‘WordPress Fingerprint’ to determine what is a healthy environment for your WordPress install. It’ll make some recommendations for you and provide some one-click options to beef-up your WordPress security if you choose, but you don’t have to if you don’t want to, and Integrity will still help you if you have a security issue.

There are occasions and circumstances where file and folder permissions may be loosened intentionally, and we think it’s unrealistic to expect all users to remain vigilant on security fronts such as permissions— it’s simply not going to happen because it never has happened, even when their were/are very good reasons for this to be so. Maybe you get an error trying to do something because a particular plugin requests permissions to be changed so you do so. Maybe you have some custom code which needs a more lazy chair environment to run. Regardless whether it’s as a result of sloppy or incorrect code Integrity seeks to add protection and detect issues on your WordPress install.

One of the more common forms of attack on WordPress (and many other kinds of) websites is a Cross-site scripting (XSS) attack. The exploit is pretty simple and in many cases it’s not about compromising your WordPress installation but instead adding chunks of code which represent malware, advertisements or other malicious activity.

The attack isn’t geared to destroy or disable your WordPress environment, but rather to add the code without being detected. In the case of an XSS attack, Integrity would detect this issue and assist you in resolving it.

Last but not least we’re building a method for the integrity of Integrity itself to be verified. Any security plugin faces this pink elephant in the room issue: No matter how strong a security plugin tries to be in preventing security issues with WordPress if it itself is compromised it’s all over. That’s why we’re working hard to develop a method for Integrity to check against itself to see whether it’s genuine and unmodified.

We’ll be posting more in the coming days/weeks ahead as we push for a public beta launch of Integrity for WordPress, so stay tuned!