Category: How It Is

Making philosophy about the why behind technical things.

TimThumb, Heroism and FUD

FUD is “Fear, Uncertainty and Doubt” and it’s a tactic used by people to scare you and make you jump into a decision that benefits them. This decision may not be a bad decision, but it’s not strictly to your own benefit, but theirs. Keep that it mind, it matters.

Recently it was discovered that there was a massive vulnerability in TimThumb (TimThumb is an image editing tool for your webapps). It had an honest-to-god Zero Day Vulnerability. I don’t use the code, and I don’t put it on any site I run, so I knew I was pretty safe. Still, I ran searches for timthumb.php on my entire server, made sure it was clean, and moved on.(Not relevant, I recently changed all my passwords on all my sites, and my servers, because I realized I’d used the same ones for about 6 years.)

The exploit primarily affected WordPress installs, because it was developed for WordPress in the beginning, but since then has grown to be used by many other apps, like Drupal and Joomla and even home-grown ones. It’s insanely cool, but it’s always had weird little problems (which is probably why it’ll never be included in the core code of those apps). Getting it to work at all on MultiSite was a pain, and when someone wrote a how-two, we gave her Tim Thumbs up!(Bad joke. BAD bad bad joke. Sorry.)

Certain people leaped into action. VaultPress, which runs a backup service for WordPress users, sent out emails to everyone who had TimThumb. Then they went the extra mile and fixed 712 possible exploits for you. (I know some people got shirty about it, since they didn’t want VaultPress editing their data. That isn’t the point here.) They jumped up and said ‘We must fix things for people’ and did it. This was, indeed, Matt’s vision for VaultPress.

But then this other thing happened, and I’ll quote Matt:

It could have gone a lot of ways, but the incident brought out the best in the community. The core team sprang into action searching through the theme directory to inoculate any themes that contained the dangerous code. Community blogs quickly got the word out about the problem so people were aware of it. Mark Maunder, who originally discovered and broke down the problem, created a fork of the code called WordThumb that rewrote TimThumb from the ground up. Forking is not usually ideal because it fragments the market for users but Mark soon connected with Ben Gillbanks, long-time WordPress community member, and they’ve teamed forces to release TimThumb 2.0, a collaboration that exemplifies Open Source at its finest. An updated plugin should be in the directory shortly.

Let me explain. There was a problem with a popular tool that is used both in themes and on its own plugin (and probably others). Mark found the problem, fixed it, and then re-wrote the tool. Then, after Matt commented on his site that Forking is a last-resort, even though this was a ground-top rewrite, Mark agreed and talked to the TimThumb guy and together they fixed everything. And now they’re a team. No one made any money off that process. People just did the right thing to make the web safer for all of us! (Okay, that’s not the point either, but it needed to be made.)

All of this was done in a way that the public knew about the problem without getting into an “OMGWTFBBQ!!!11!?” panic. Was there some fear? Yes, because you knew there was a problem and there was a possibility it could affect you. Was there uncertainty? Of course! Again, could it affect you? Was there doubt? And this here is where we have a win for the Open Source community. There wasn’t. It was a straight up ‘This is what’s wrong, this is how to fix it.’

In so many ways, that’s how every business should work. It could have been better, certainly, but when I compare this to how I get security alerts for our servers at work, I see nothing but room for improvement. Right now, one person has the job to look for vulnerabilities that are published about anything we use. If she sees one, she opens a ticket and says ‘Fix this ASAP!’ The problem is, to use a recent example, ownership of the fix. We had a vulnerability with .NET, but as I read the whole doc, I sorted out that it only happened if your server was configured in a certain way so as to make a security hole. Another quick check and I saw the server team had their own ticket ‘Fix this hole.’ So I closed my ticket and said ‘Will be resolved with Server Ticket 1234567.’ My ticket was reopened and I was told I did it wrong. This was a problem with my application (I don’t ‘own’ .NET, I happen to be on the team who brought it into the company, however). I pointed out it wasn’t that .NET was vulnerable, that it was the server. They didn’t care. My ticket has to be open until the problem is resolved, no matter what. In the end, I turned off the feature that might, possibly, be vulnerable and got chaff for not doing it right.

When you compare that to the beautiful simplicity of Open Source communities, it makes you wonder how anything actually gets done? We’re so afraid (fear) of being wrong or doing the right thing without the right approvals, we let the process hamstring us from fixing the problem. We don’t know (uncertainty) what the right thing is anymore, so we do nothing. And in the end, we’re not sure (doubt) if we’re of any use at all. (I think my premature grey came from this job, and if I leave, the first thing I’m doing is dying my hair neon blue.) Plus, to make matters worse, they told the entire company about the security hole, so everyone knows, and they can see we didn’t close the tickets. It’s a mess.

But really that’s not what FUD is about. Nor is it what this post is about. Neither way is perfect, and both are flawed in different ways.

You see, what Open Source nailed in one was that we should be aware of the dangers, and work together to make it better, not feed the fires and run around terrified about what’s going on. A little fear is a good thing. It clears the arteries and is good for your heart. If you’ve never had a moment where the blood drained out of your face because you made a mistake, you’re not trying hard enough. We all live with uncertainty and doubt, too, and inherently these are not bad things. What is wrong is allowing them to have complete control over your actions to the point of inaction or consistently making the wrong choice that you know is wrong.

Make the right choices. If a bread stick is on fire in the toaster, take it out and make that extra step to sort out who put it in there. Treat everyone as a team member, a fellow hero. You see, if we give in to FUD, we cripple ourselves, much like corporate america does every day with miles of red tape. But if we don’t, if we accept our fear and move forward, we can get past it and make better products for everyone. And that’s a great goal.

If you think you, or a friend, may have been hacked, please go to Sucuri and run the free scan for your website.

19 August, 2011
Share My Content (But Leave My Style Alone)

This came up at WordCamp Chicago. We were in the unConference, talking about BuddyPress, when John James Jacoby asked how many of us use Blackberry Pie. This is a WordPress plugin that lets you include Tweets into the content of your post, bringing the style (avatar, CSS etc) from Twitter. Then he asked if that would be cool to see in WordPress, where we could bring any other WP content to our sites.

A lot of people liked that idea. I visibly cringed. Sam “Otto” Woods made a joke about how that would bring splogs to a new level. But I was stuck on thinking about copyright and bandwidth.

The basic idea is sound and, I agree, really cool. If I can link to my site on Google+ or Facebook, and it pulls in a picture, couldn’t it pull in my formatting too? That would mean when you quote from my site, it looks like my site! The problem I see, is that the reason Facebook and Google can get away with embedding the picture is that they are copying your picture to their server and displaying it from their sites.

How do I know that? Because I have hotlink protection and I know it works. So the only way for these sites to cache my images is to come and scrape what they see IN the post. (I’m pretty sure this is why the ‘featured image’ in WordPress doesn’t always show up on a Facebook link. If you have the image inside the post, it always shows up. If you don’t, it doesn’t. Simplest answer: they’re content scraping.) It’s nice to see that technology being used for good. Of course, if you extend the thought, you’ll realize how many servers these sites must allocate just to storing snippets of other people’s data.

If your server cannot do that, then you should not be trying to emulate them.

People forget just how much work went into making Google and Facebook able to do that! They aren’t aware of how many servers, and how many people maintaining the servers, it takes to support that level of infrastructural deployment.(Mind you, WordPress has about 4 or 5 people to Facebook’s couple hundred, so it’s not about the amount, but the people.) This makes the problem two-fold. Either you must have your server set up to handle the caching, or you steal the CSS (and thus bandwidth) from someone else.

Okay, okay, so CSS bandwidth is a drop in the bucket compared to images, I know. And maybe I’m making a mountain out of a molehill, but we already know exactly how dangerous it is to have your site heavily linked. I’ve suffered the Digg/Slashdot/ma.tt effect before, and been nailed with 300% traffic. Thankfully I built this server with that end-goal in mind, and the last time it happened, no one noticed. Which is as it should be. But if I was still on my old shared host, I’d probably have died.

This cuts back to why certain things are made plugins/add-ons and others are default a part of a product. When you support ‘all’ things, you have to limit your product to what actually is supportable. Microsoft Office works on most systems, but it doesn’t work on all, and it has known conflicts. Because of those conflicts, there are features Microsoft knowingly left out! They would rather support as much as they can for as many people as they can. If your product is a niche product, you can get away with only supporting certain things, but a web app (Drupal, WordPress, etc) cannot. (And this is why you won’t see caching built into WordPress. Too many different server setups!)

In the end, I think that embedding contextual content in a site is a nice idea, but unfeasible. You’ll never be able to support all possibilities, and you’ll never be able to do it in a way that ensures you stay on the right side of the law. If you want to link to someone, make a quote, link back, and use it as a part of your site, branded your way. If the look and feel of the post is important (like Twitter or YouTube), then hope they’ve come up with a way where they want you to be able to embed the content in your site.

Until then, share my content, but leave my style alone on my site, where it belongs.

13 August, 2011
Backup Where You Belong

I’ll make it quick: At the end of the day, there’s only one person who’s responsible for your backups, and that’s you.

Here’s the deal. WordPress does not have a 100% backup everything tool. Neither does Drupal nor Joomla.(All three of the big guys have plugins that can do this, don’t worry, I’ll get to that in a minute.) In fact, I don’t know of any app on the web that does. Even though Google says “You own your data!”, if you use their tool to download everything, it’s not in a form you can just slap back on the web. Their backups remain tied to themselves. You get the data, but then you have to parse it.

This brings up a bigger question, though. What is the point of a backup? In a worst-case world, your backup is to save your bacon for when you screw something up. It’s to restore from a crisis or to roll back a bad change. So why aren’t these sorts of things built into applications?

When you think about it, they’re not built into any application. From Microsoft Word to your favorite Twitter app, if an upgrade breaks something, there’s no ‘roll back’ option. You can uninstall and reinstall, but most of the time that means you have to reconfigure all your favorite settings.(This is actually why I try to make as few special config changes as possible.) Yes, in Microsoft Office, you can save your ‘document’ in total, but that isn’t a direct analog to Web Publishing, because there’s far more than ‘just’ your book, there’s all those settings and preferences. If you’ve ever tried to copy someone’s preferences and settings from one computer to another (and you’re not on a Mac, who makes that shockingly easy) you know what I mean.

The best backup tools are things like Microsoft’s cloud backup, or Apple’s Time Machine. Both make a massive copy and then incremental updates to your entire computer. They are, as we say, OS (Operating System) backups. All your documents, all your applications, all your settings, are backed up. No individual application has ever bothered with this so why should a web app?

The argument goes that you should be able to pick up your web app and put it down on another server via exporting. I can think of one app off the top of my head that can do that: Cpanel. I’ve never tried it myself, but I’ve been told it works pretty well. Still, Cpanel actually falls under the weird realm of operating systems, as it’s really a server management tool. It’s where you logically expect to see things like your backup tools, db access, etc etc and so on and so forth.

In short, it’s the right place to see your backups made.

How do you backup a webapp?

Step 1) Backup ALL the files on your server.
Step 2) Backup all your databases.

That’s kind of it. For most well written apps (WordPress, Drupal, etc) to ‘restore’ these backups, you just copy them back up. For the database stuff, you may need to make a second database and edit your files to point to that DB instead of the original, but it’s pretty fast. Professionally, we have one-click rollbacks installed on databases, but even then, we tend to go ‘Oh, that didn’t work.’ and rename the NEW DB (databasename_date_BAD) and re-upload the old one. Why? Because it works. When the DBs are too big, we have incremental backups and rollbacks set up. Files ditto (actually for files, we ALWAYS have step one ‘make a copy of the old folder structure…’ and the rollback is just renaming things).

We rarely rely on the applications themselves to perform these tasks for one simple reason: They’re BAD at it.

I’ve always been an advocate of the right tool for the right job. A web app is good at its job. A backup tool is good at its job. The two may cross, but there’s nothing wrong with using a backup tool to make backups and a writing tool to write. I don’t use any plugins on my apps to make backups, I do it via the tools built into my server that are, expressly, for making backups. Ditto my computers at home. I know what the right tool is, and I use it.

11 August, 2011
Ban Hammer 1.6 – Languaged Up!

After a very obvious request, I’ve done my best to make Ban Hammer languagable. That is … it has a language pack and you can add in to it. If you have internationalization fixes to add in, drop a comment here and I’ll email you.

Ban Hammer is available for download at WordPress.org

11 August, 2011
Distributed Company

In the past, a company’s staff all sat in the same area, cubes or desks in a little area where they were grouped by their job functions. Shipping sat here, processing here, accounting there. IT had the closet. As time passed and systems grew, teams became more diverse. The shipping mavens needed to know what the processing people were doing, and cross-training became the norm. People stopped being able to say they had one role at work, and started becoming generalists instead of specialists. There was always (and will always) be a role for the super specialist, but not everyone had to be one.

In IT, this has become even more prevalent. It’s not good enough to just be great at Windows IIS, you have to know Apache, Lighttpd, nginx, and countless other systems, just to keep up with our fast paced world. Thankfully, a lot of us spend our time learning the basic concepts of how things work, we learn to think logically, and apply that skill to any product, regardless of our familiarity with it. We adapt.

But for the brick and mortar companies, many people have sat ‘with their team’ for their careers, and the idea of splitting up is mind boggling. “How can we work if half the people I need to talk to are in another building?” they cry, after a reorganization moves people around.

Here’s a true story.

We split up our teams recently, into ‘Design The Software’, ‘Build The Software’ and ‘Support The Software.’ The designers are ‘architects’ who create the scheme of things and decide how the software will work. The builders do the grunt work and build it. The ‘Supporters’, for lack of a better term, are the folks who use it every day and answer the phone when it breaks. Oh yeah, they have to fix it when it breaks.

Many of us straddle at least two teams, and some of us are in all three, so where you actually ended up has very little bearing on what you do, and more on where you sit. I sit a floor away from people I work with every day. Now, when a server goes down, someone over there may be working on it at the same time I am, and conflicts come up.

We’ve tried to address this with ‘team twitter’ accounts (not actually Twitter, we made our own little applet for it in Sharepoint). Someone will post ‘Ticket Foo came in, I’m on it.’ and we know to look there first. Sometimes we post ‘Hey, server Bingo is crashing. Anyone know what’s up?’ and we’ll reply. Personally, I wanted to grab a page from WordPress and make a P2 blog where we could all just login and post, but that got shut down.(We’re trying to rewrite it for SharePoint right now, but oddly people are against sharing personal information with other people who already have access to that information…) Still, not everyone remembers to use it, and since it’s ‘just us’ and not a corporate initiative, we get people complaining ‘I have to run across the hall, down the stairs and down another hall to tell Bob about this!’ and ‘I can’t hear what’s going on!’

We’re far too set in our ways, clearly. The fact that no one is willing to even try to look at the benefits of distributed collaboration depresses me. I don’t have to sit by someone to IM them a question. I don’t have to call them to ask a question. I have email, I have IM, I have a phone, I have a group ‘board’ where we can have lengthy discussions about ideas, before we sit down and waste an hour in a meeting.

What I don’t have is buy in. I don’t have people willing to try something new. “The old way worked!” they shout. No, it really didn’t. It looked like it did, but how much time was wasted running around trying to find someone, not knowing where they sat, when you should have just put a message up and they should have read it, replied, and moved on. Interoffice memos in J.K. Rowling’s world were paper airplanes. Wouldn’t it be nice that you could use that? Oh wait, it’s called email!

The future of communication in a company isn’t going to be ‘How do we schedule a meeting across four continents?’ but in ‘How do we keep our communication flowing, 24/7/365?’ At this point, my company has offices in over a dozen counties. We still rely on ‘shift hand-off’ emails which no one reads because we get too many emails to begin with. We have people who spend so much time filtering email that they half-ass updates to support tickets, so the next shift has only half an idea of what’s going on.

Your company needs to be available when people use it. For a Bank (like I work for), that means every day except the days you’re legally obligated to be closed. Which means there actually isn’t a time when we’re 100% closed.(Sometimes I joke that the sun never sets on our company.) Obviously this isn’t true of all things. A grocery store should be open most hours of the day, if possible. A restaurant should have longer hours on the weekend. An on-line store maybe needs 24/7 support, or maybe it just needs 5 day a week so people can catch a break. But you decide when you need to be available, and then you make it happen. And if being available means you need someone to be around for 14 hours, then you need a way to hand off that person’s work to the next guy in a way they can easily pick up and run with.

The future is decentralization. It’s time to embrace it and learn how to use it best.

8 August, 2011
I Don’t Write For Search Engines (And Neither Should You)

I see a lot of posts where people talk about how to make your site better for search engines, and how to write a post for a search engine. I can honestly tell you that I have never sat down with that as my goal for anything I’ve written. Just like I don’t advocate designing your site for search engines, I would never suggest you customize your content for them. The web is for humans.(At least until our robot overlords take over.)

At the risk of being repetitive, I will reiterate that you are not making your site in order to be ranked number one in search engines. You are making your site for people to read. If you’re making a site just to be number one, you’re doing it wrong.

No matter what your topic, no matter your product, your goal is to make it something people value. So why is it a search for “how to write for search engines” has so many hits? A large number of those hits are for spam sites, who over-sell advertising and promise you hundreds of hits a day. Others, however, offer the same advice I’m telling you. Don’t write for search engines.

Yes, if you get highly ranked on search engines, you’ll attract more people, but it’s not all about getting them to your site. Once you get someone in the door, you have to keep them. If you’ve ever been to a store where you know you need a salesman and they all ignore you, then you know exactly what it’s like to go to a website that’s all SEO and no content of merit.

The part that confounds me is that all the SEO advice is drivel anyway, as it’s stuff you’re already doing. Also, they confuse the idea of writing for SEO benefit and writing SEO friendly content. There are tips and tricks you making your post layout be friendlier to search engines, while simultaneously making them easier for people to read.

Coincidentally enough, Jane Wells (aka JaneForShort, aka if you don’t know who she is, you probably aren’t a WordPress fan) came up with the above comic (with permission from Randall Monroe of XKCD) and I felt it clearly and hilariously made my points for me. (True confession, I actually wrote this post in early July, but not until Jane’s comic did I finish it. Yes, I’m taking advantage of the timing.) In both sides of the argument, the panelists are ignorant of their absolute truth: together, with a good tool and good writing, you become king.

Just recently Andy Stratton spoke at WordCamp Chicago (You can see a copy of his presentation, which he also used at WC Raleigh, at DIET PILLS, SEO, THEME FRAMEWORKS – There are no magic bullets.) and said “If content is king: context is queen […] Content is king, Backlinks are the Emperor.” For years I’ve espoused ‘contextual links.’ I will, rarely, put up a list of links, but when I do, it’s to organize them contextually. A link on it’s own is meaningless for the user who reads it and the site you’re linking to. If no one follows that link, it doesn’t matter how much ‘link juice’ you’re sending them, because no one’s clicking it.

Don’t write for SEO, don’t make links for links sake. Listen to what your teachers said: write clearly, write well. Link with context, and people will see the effects of your work and link back. Write for the humans. We’re the ones reading.

4 August, 2011