It’s not that the terrorist picks an attack and we pick a defense, and we see who wins. It’s that we pick a defense, and then the terrorists look at our defense and pick an attack designed to get around it. Our security measures only work if we happen to guess the plot correctly. If we get it wrong, we’ve wasted our money. This isn’t security; it’s security theater.

Bruce Schnier on why airport security is A Waste of Money and Time in the New York Times.

[P]sychological evidence suggests that is is close relationships, a meaningful life, economic security, and health that contribute most to well-being. While there are marked improvements in happiness when people at low levels of income earn more (as their economic security improves and their range of opportunities grows), as incomes increase this extra earning power converts less effectively into increased happiness. In part, this may stem from people’s tendency to habituate to the consumption level they are exposed to. Goods that were once perceived as luxuries can over time be seen as entitlements or event necessities.

By the 1960s, for instance, the Japanese already viewed a fan, a washingmachine, and electric rice cookers as essential goods for a satisfactory living standard. In due course, a car, an air conditioner, and a color television were added to the list of “essentials.” And in the United States, 83 percent of people saw clothes dryers as a necessity in 2006. Even products around only a short time quickly become viewed as necessities. Half of Americans now think they must have a mobile phone, and one third of them see a high-speed Internet connection as essential.

Emphasis mine. From the State of the World 2010: Transforming Cultures. They also have a nice, WordPress-powered blog. (A necessity.) You can see the context of the quote in Google Books.

Modern versions of Windows include free tools like Defender which are just as good and appear to have less of a performance impact on the computer. But if they really wanted to have a long-term impact on desktop as a vector for attack on web services I’m surprised they didn’t start, sponsor, or promote an Open Source equivalent of McAfee. This seems like a space very well-suited to address with an OS tool in the digital commons, much like a Windows anti-spyware equivalent of SpamAssassin, with self-updating rules and a completely transparent process.

Online, apparently, it’s fine for someone to run into a crowded theatre and yell “fire” and the less basis there is in fact the more people link to them. It’s not uncommon to see crying-wolf reports like the above several times in a week, and a big part of what the WP security team is sifting through things to see what’s valid or not.

A valid security report looks like this, it usually includes sample code and a detailed description of the problem. The WP security team was notified of the KSES problem and it was fixed in 2.5. You can impress your friends by saying whether a security report is valid or not, so it’s a good critical facility to pick up.

All that said, there is a wave of attacks going around targeting old WordPress blogs, particularly those on the 2.1 or 2.2 branch. They’re exploiting problems that have been fixed for a year or more. This typically manifests itself through hidden spam being put on your site, either in the post or in a directory, and people notice when they get dropped from Google. (Google will drop your site if it contains links they consider spammy, you’ll remember this is one of the main reasons I came out against sponsored themes.) Google has some guidelines as well, what to do if your site is hacked. If I were to suggest WordPress-specific ones, I would say:

1. Upgrade your blog to the latest WP. This shouldn’t be hard. There are plugins for it, if you’re techy use Subversion, there is the standard FTP method, and finally Media Temple, Dreamhost, and Bluehost (through SimpleScripts) all have been pretty good about having their one-click upgrade systems ready with new versions within a day or two of a release. If your host is chronically behind, vote with your wallet and switch.
   • If you need someone to help you upgrade, consider hiring help on the wp-pro mailing list. (It has close to a thousand subscribers and consultants on it.) Or you could always ply a geeky friend with caffeine, libations, food, or gadgets. Just get them to setup a system lik the above so you can do it yourself next time.
2. Change your passwords, for yourself and any other users you have on the system. If the attacker grabbed your password when you were on an old version, they can still log in after you’ve upgraded if you don’t change it. There’s a new password strength meter in 2.5 helps you pick a good password.
3. Search through your posts for any that might have been modified, and comb through the directories on your web server looking for anything out of the ordinary. Your host may be able to help you with the latter.

If you’re on the latest version, you’ve changed all your passwords, and something still happens to your blog, don’t panic. It’s not your (or WP’s) fault, but there is likely another account on the server which is malicious and the server you’re on is set up in a way that your neighbors can modify your files. The best thing to do here is to contact your host or sysadmin and have them check things out. They can look at the other accounts and log files in a forensic fashion to identify and find the source.

I follow or am involved with many, many WordPress blogs – some that receive millions of pageviews a day and have pageranks of 8 or 9 and are huge targets all the way to small personal blogs. Those that have followed the two basic tenets — keep up with upgrades and use good passwords — have never had a problem. Those that fall behind upgrades, like Al Gore did, have.

If you’re tech-savvy, take a look through your blogroll and see if anyone is on an old version. If they are, consider contacting them to help out. Like a barn raising, if we all work together it’ll happen a lot faster.

I often hear reasons why people don’t want to upgrade, here’s the most common and my best response:

• I’m scared something will break, or I don’t know how. Ask a friend to help or hire a professional on the aforementioned wp-pro list. Long-term, try to use a plugin like WPAU or a host that will do upgrades.
• One of my plugins doesn’t work with the new version. This is getting rarer as we have a very public testing cycle for plugin authors to try their stuff with the latest version, but still common. I would suggest checking for an upgrade to the plugin on the author’s site, contacting the author about the incompatibility you found, maybe even donate some money, or finally search for an alternative plugin that provides similar functionality but works with the latest and greatest version of WordPress. In the big picture, though, having a secure site is much more important than the functionality of a single plugin, so you should seriously consider turning off a plugin for a few days instead of putting off core upgrades.
• I don’t like the new version, they moved my cheese. We believe every new release is better, but sometimes people just aren’t comfortable with a change, which is fine. The good news is that we constantly improve things based on feedback, including interfaces, and that more importantly for almost everything you can imagine annoying you there is a plugin that changes it. For example in 2.5 the page is fixed-width to allow for greater readability, but there’s a plugin to make it stretch to the full width of the window.
• I modified core files, so upgrades are hard. You should never ever modify core files in WP. If you find you have to, file a ticket for a new hook or filter so your modifications can be a plugin — it makes things so much easier.
• Upgrades are too frequent. If it takes you more than 5 minutes to upgrade your blog, you’re doing it wrong. Historically we do a major release about 3 times a year, and a minor release about once a month. Minor releases almost never break anything, so they are the easiest. (And often the most important.) WordPress is fast-evolving software, so this is a good problem to have.
• I don’t know when there’s an upgrade. No excuses here. Since 2.3 we include a big honking notice at the top of your dashboard when there’s a new release available. It’s also worth subscribing to our dev blog, it’s not like it’s going to flood your RSS reader.

Of course the millions of blogs on WordPress.com never worry about any of this, nor do the folks on good hosts that have one-click upgrades. The WP community takes security very seriously and has always done its best to respond diligently to any known problems, but all that work is for naught if you don’t upgrade. Hosting an application yourself is a responsibility. In the future we’re hoping to make this whole thing easier, for example with built-in functionality like WPAU. Until that day though, I hope the above helps. Feel free to copy, republish, or steal this post in whole or part for whatever you like.

The response became too long for a comment, so here it is:

Kate, thousands of people every day remove the WordPress link, or my link, or search and replace the WP logo with their own and redistribute it, use it to spam, distribute hate speech, or any number of awful things you can imagine. So why have hundreds of people spent thousands of hours working on it?

Though the freedom intrinsic in the GPL that has allowed people to abuse WordPress it has allowed even more people to do amazing things and over time the good far, far outweighs the bad. Most importantly I feel like WordPress would have never gotten off the ground if it hadn’t been open from the beginning. (In fact there were several more functional blogging programs started around the same time that have since withered away.)

Ultimately I know our software isn’t going to change anyone’s spots. Good people will do good things with it, and bad people will do bad things with it — regardless of any protections I put in place. Windows Vista, a multi-billion dollar enterprise, was cracked within days. Does any piddling encoding I can do in PHP really matter? If protection like that isn’t broken it’s a statement of popularity, not security. I suppose could harass the bad guys, shut down their host, send them scary letters, but it’s just going to stress me out and like cockroaches they’ll pop up someplace else. I also know that most projects, software, and ideas die from obscurity, not piracy.

If you accept that bad people are going to be bad then the real question becomes how do you maximize the effect of the good instead of treating them just like the bad. (No one likes to be treated like a criminal.) In my brief experience here’s three things that work:

1. Give people the tools they need to succeed. This can be interpreted on a lot of levels, but personally I’ve found at the most base the freedoms provided by the GPL and other open source licenses are incredibly empowering.
2. Celebrate the successes. Talk, connect, promote, and embrace the people who are creating things on top of your creation. (The best revenge against someone doing something bad is helping create something awesome.)
3. Provide a way for people to choose to help you, and try to remove as much friction from that process as possible. Now that you’ve ignored the bad people and delighted the good, by their very nature they’ll want to give something back.

The success stories around this model are numerous and growing every day. People can and do rip-off the entire Wikipedia, but it’s still become one of the top ten sites on the internet and a marvel of what can happen when you let go. (Not to mention it is run entirely on open source software.) WordPress itself was built on top of a pre-existing GPL product called b2/cafelog. Anyone can run the software behind our hosted service WordPress.com and create competitive sites, and many have, but it hasn’t hurt us one bit. Linux, GNU, and the thousands of related desktop projects haven’t taken a bit longer than folks had hoped, but the impact they’re having, especially on emerging economies, is dramatic. The list goes on and on. It’s not hard to join the movement, but first you have to figure out who you’re fighting, who you’re trying to help, and if the price of freedom is something you’re willing to embrace.

PHP 4.0 was release in May of 2000, by 2004 when the first version of PHP 5.0 was released, PHP 4 had achieved complete dominance and was completely ubiquitous in both script and hosting support.

Fast forward 3 more years and PHP 5 has been, from an adoption point of view, a complete flop. Most estimates place it in the single-digit percentages or at best the low teens, mostly gassed by marginal frameworks. Even hosted PHP-powered services who have no shared host compatibility concerns like 30boxes, Digg, Flickr, and WordPress.com, have been slow to move and when they do it will probably be because of speed or security, not features.

Some app makers felt sorry for PHP 5 and decided to create the world’s ugliest advocacy site and turn their apps in to protest pieces at the expense of their users. (Hat tip: Mark J.) They say “Web hosts cannot upgrade their servers to PHP 5 without making it impossible for their users to run PHP 4-targeted web apps” ignoring the fact that there isn’t a released PHP app today that isn’t PHP 5-compatible and recent upgrade issues have been caused by PHP itself in point releases. (See WP#3354.) It’s easy to always promote the newest thing, but why, and is it for us or our users?

Now the PHP core team seems to have decided that the boost their failing product needs is to kill off their successful one instead of asking the hard questions: What was it that made PHP 4 so successful? What are we doing to emphasize those strengths? Why wasn’t PHP 5 compelling to that same audience? Are the things we’re doing in PHP 6 crucial to our core audience or simply “good” language problems to solve? Will they drive adoption? How can we avoid releasing (another) PCjr?

I wonder if PHP 5+ should be called something other than PHP. A unique name would have allowed the effort to stand on its own, and not imply something that’s an upgrade from what came before when in many cases it’s just different, not better, from an end-user perspective. Continue to maintain PHP 4 as like a PHP-lite. Make it harder, better, faster, stronger.

For all the noise though, this isn’t a big deal. It’s easy to forget that PHP 4 hasn’t had any real innovation in the past 3 years while at the same time apps and services built on top of it have created some of the richest and most compelling user experiences the web has seen. (Née Web 2.0.) None of the most requested features for WordPress would be any easier (or harder) if they were written for PHP 4 or 5 or Python. They’d just be different. The hard part usually has little to do with the underlying server-side language.

Someday on our mailing lists I hope half the words wasted pontificating on “language version wars,” which are even duller than language wars, go toward design, copywriting, information, performance — the things that truly matter.

• The SQL problem in 2.2 requires both registration to be enabled (off by default) and the blog to be upgraded to 2.2. It is a serious problem but I’ve heard of fewer than 5 exploits from the flaw. Even if you assume there are 100 blogs for every one we heard about, that’s still an incredibly small percentage of the millions of WordPresses out there, especially considering, as Wincent points out, the problem has been in the public for a while now.
• Getting people to upgrade web software is hard. We work as best we can with hosting companies, but a consideration is that it’s best to roll several security fixes into one release. It’s not responsible to do a release if we know of another problem, so sometimes there is a lag between an initial report and a final release, not to mention the testing required of a product used as much as WP.
• Wincent digs up the server crack that modified the files of 2.1.1 for a few days. Ignoring the fact that it was a server issue and had nothing to do with WordPress the software, we actually had NO reported exploits of the problem. (Though I’m sure there are at least a handful out there with problems, it wasn’t enough to hit our radar.) Despite that we took a hit and publicized the issue as much as we could to get the word out.
• Also about 2.1.1, the problem was found through someone proactively auditing the codebase.
• Finally Wincent says of WP “[a]nd if you insist on installing it, then you need to watch the trac like a hawk.” You would think complete transparency of the problems (it was on our bug tracker and mailing list) would be a good thing, especially considering the software Wincent uses doesn’t have a bug tracker, and the only way to submit a bug is through a contact form.

We can and do review new code for problems, and pick the vast majority up before any releases. I think the real issue though is not that WP has bugs which are sometimes security related, which all software not written by djb does, but that the mechanisms for updating complex web software are a pain. Right now the best experiences are probably with folks like Media Temple or Dreamhost that have pretty foolproof one-click upgrades and are quick with updates.

Making notification better and upgrading more painless for people not lucky enough to be on a host like that are problems with some very clever minds on them, and I’m confident that we’ll have good progress toward each in the next major release of WP.

Finally, I suppose we could act more like our proprietary competitors and try to downplay or hide security issues instead of trumpeting them loudly in our blog, but I think the benefit of having people well-informed outweighs the PR lumps we take for doing the right thing. I truly believe talking about these things in the open is the best way to address them.

In some ways it’s a good problem to have. When a product is popular, not only does it have more eyes from security professionals on it, but any problems garner a level of attention which is not quite warranted by the frequency of the general event, like Angelina Jolie having a baby. There are certainly things intrinsic to coding that can make software more or less secure, but all things being equal the software with the most eyes on it, which usually means Open Source, will be the most robust in the long term.

I’m not even talking about deciding they can change the world by decree. (Which has already been addressed.) The latest in their line of enlightened changes is that the author of the Well-formed Web spec has changed the capitializition of the wfw:commentRSS element at some unknown point to lowercase Rss. This arbitrary decision has been codified by the validator, which now reports the millions and millions of feeds that use the previously correct capitialization as invalid. Confusion ensues.

If the previous paragraph makes your eyes glaze over, congratulations, you’re normal.

Here is a post on their mailing list which also explains the issue and includes a link to the archive.org version of the page with the capitialization everyone uses, which was there for at least two years. One line can cause so much trouble.

But wait, there’s more. “In addition, this feed has an issue that may cause problems for some users.” They’ve also started marking all uses of content:encoded as potentially causing problems, which is funny because it actually avoids a ton of problems and (again) people have been using it in RSS 2.0 feeds for 3+ years now, and I even asked Dave Winer about it in the past and he said that was fine. Their documentation on the topic seems more geared toward instilling fear, uncertainty, and doubt in RSS 2.0 than addressing the reason they’ve decided to start warning about this element. Where a validator normally provides stability, the feed validator has become the Homeland Security of the RSS world, keeping us all in a constant state of dulled fear, insensitive to whatever warnings they’re giving us today because we just want it to stop.

I’m sure the content:encoded change can be rationalized with a perfectly convincing argument. I wouldn’t be surprised if someone as smart as Sam could do the same for the arbitrary wft:CommentRSS change. I know that the code is open source and we could fork it and create another version of the validator that doesn’t invalidate half the blogosphere on a Tuesday afternoon. But then we would have more than one validator, and that defeats the point.

Description

When you run your text through this code it will define all the acronyms it can using the acronym tag. It also has a few other niceities, so check it out.

Installation/Usage

Pass whatever text you want to use through it, and add whatever acronyms you want to add to the array by copying what I have already. The sortr_longer must be above the acronymit function.

Code

Reverse Sort Array on Length

acronymit

Notes

You can speed it up a bit by commenting out the sort line if the array is in order of longest acronyms first. The reason for this is because the function goes down the array looking for that text to acronymfy, and it’ll grab whatever it comes to first. So if you have an acronym defined for LAMB and one for MB, if MB is first on the list, it will eat the last two letters of LAMB. To make people (mainly me) not have to sort it manually by acronym length I wrote a small function to reverse sort the array by the length of the key string.