Security Camera - Photo by Sirius Rust
Beth threw down the gauntlet, and I had to pick it up. I’m sort of surprised I hadn’t written about this before. I think a lot about both of these, not so much for myself, but for organizations that I work with whose work is fairly sensitive.
First off, some definitions – I think that these two terms do get mixed up quite often, and understanding what’s really being meant by them in a technical context is important.
Security, in this context, is the concept that your personal computing resources and data are safe from both prying eyes, as well as hijack by crackers and spammers who will use those resources and data for their nefarious ends. In the case of your computing resources and personal data inside that box you call your laptop, or protecting the whole of your home or office network, security is a matter of using specific tools that prevent unprivileged outsiders from getting in. Wifi passwords, firewalls, password protected fileshares, virus protection software, etc. are the tools of the trade here. Security of your private data that is “in the cloud” is largely at the mercy of the software developers who hold your data. Luckily, most of them take security quite seriously. (That said, your data “in the cloud” can be compromised by lack of security on your network or laptop – someone installs a key logger, for instance, and grabs all of your passwords.)
Privacy, in this context, is that you can control, in a granular sense, what information about you is exposed to whom. Privacy is, as Beth says, primarily a matter of human behavior, but there are very interesting intersections with technology and security. In some instances, services have default privacy settings that are a lot less private than someone might like – and it takes some know-how to figure out how to correct those settings. Privacy is, also, a set of decisions that get made – sometimes in haste, or without much consideration. Your drunken decision to post that picture of you (or a co-worker) dancing in your underwear on a table at a party, the cat is out of the bag, and may never be able to be put back.
Security and privacy in the context of online communities, as Beth points out, are different beasts. The software that drives online communities (such as Drupal, phpBB, and others) have options to allow for varied levels of security. You might need to have a password to see anything. Or you might just need a password to make comments. You might not be able to just register for an account – you might need to go through an admin. These days, most software driving communities have roles you can assign people to, with specific privileges granted per role.
But privacy is made up of policy (the policy of the organization running the community) as well as the behavior of the members – their collective agreement that “what happens in Vegas, stays in Vegas.”
Tagged as:
nptech,
privacy,
security,
web2.0
Now that the Idealware CMS report is out, I get to have my say about it. Here’s the first post, there might be more to come.
The thing that is prompting this post is the little storm about the security metric that we used to try and get a handle on the security of the 4 different systems we reviewed. More on that in a bit.
You might think that comparing four different open source packages that, in essence, do pretty the same thing (in a broad sense) would be a cakc walk. In fact, nothing could be farther from the truth. The developers of each project have completely different sets of assumptions about what the right way to do things is, and completely different philosophies and ethos when it comes to building interfaces and functionality. Making apples-to-apples comparisons of these systems was one of the most difficult analytical tasks I’ve taken on in a while (and, actually much of the heavy lifting of designing the analysis was done by Laura Quinn), and until you attempt such a thing, please be somewhat tempered in your complaints about it.
Now the security issue. One of the 12 different aspects we are comparing is “Scalability and security”. The report isn’t about security, it’s a very, very broad comparison of the systems, with security as a very small component. That’s just the context. Two (yes, just two) questions out of many relate to security. First, a simple metric relating to security reports, and second, what processes are in place in the communities to deal with security. This wasn’t designed to be an in-dept, complex analysis of security. If it had been, we would have done a lot more work on how to measure security. On the Four Kitchens blog, they say, “While both reports above seem to identify Drupal (and Joomla! and WordPress, to be fair) as having notably bad [emphasis mine] security, they’re also both based on one superficial metric: self-reported vulnerabilities.” Now I can’t speak about the IBM report (I haven’t even read it yet), but our report says no such thing. Drupal gets a “Solid” on Scalability and security. Solid, which is only one step below Excellent. And you know why it got a “Solid”? Because, indeed, it does have more reported security vulnerabilities than Plone (as do Joomla and WordPress.)
David Geilhufe, who also takes issue with the security metric, has some good points. Yes, sheer numbers of vulnerabilities are not anywhere near the best metric of whether or not a system is secure or not. As a quick comparative look between a small number of open source systems, it’s hard to argue that it contributes no information. Four Kitchens seems to suggest that part of the reason for more vulnerabilities in Drupal compared to Plone is that it’s more popular. But, if you’ve been an observer to the Linux/Windows FUD wars, you’ll remember that Microsoft has that exact same argument about why there are more security vulnerabilities in Windows as compared to Linux. And the Linux folks say, in response, “It’s not popularity, it’s design.” I’m sure that Four Kitchens, and most open source software developers agree with that perspective. In reviewing Plone, and talking with people who develop for Plone, I was convinced that the reason that Plone had fewer reported vulnerabilities was not just because it was less popular – it’s because it (and Python and Zope) was more secure by design.
I am completely happy with Drupal’s security (otherwise, it wouldn’t have gotten a “Solid.”) I think the Drupal community takes security extremely seriously, and if they didn’t, I wouldn’t have chosen it as a platform for development. I also think that the Joomla and WordPress communities take security seriously. In our estimation, they were all really good. But Plone was just that much better.
Tagged as:
CMS,
drupal,
idealware,
plone,
security