The self-hosting dilemma

Today, the sources for the open-source alternative to Facebook, Diaspora were released. Similarly to what is often done by Google, the “old” Sun, and other big software companies when they release something Free or Open Source, the sources weren’t available incrementally, but were just made available with a big code drop, from where the actual (supposedly) open development started.

How does this work out? For now, there seem to be a lot of hype, as expected for something like this. On the other hand, Jürgen found already a problem with missing input sanitisation and expressed quite a few doubts about its distribution model. While I agree that it’s too soon to tell the future, I also have a lot of doubts.

While Jürgen actually criticises the technical side (and as you might guess, I agree with his points), I’m also very doubtful about the social part of the project. Why is that? Well, the main problem is that Diaspora for many looked like a way to “take control of their data” by hosting their own instances. This is something that, I fear, is going to hurt the collective soon enough. With a single word: spam.

While the instances should be more similar to Status.net (multi-user) than to WordPress (single-user) and the other blog engines, there is definitely a huge front of users who want not to upload their content at all, and rather get a huge number of instances around the globe. How is that bad, aren’t distributed systems better? Well, yes and no. While distributed, peer-to-peer networking is more resilient (because there usually isn’t just one “master” node), their load on the network can in theory become massive enough to be a problem; if each Diaspora user (or each family) were to host their own instance, and they actually reached and overtook Facebook, it would probably be a problem, but that’s quite unlikely to begin with.

Assuming that this actually became the case, or that at least enough “groups” of people actually set up instances (which would make much more sense I guess) what the result is going to be? Well, from one side you would have a situation similar more to Jabber than Status.net I guess; the (IMHO) big problem with Jabber is that S2S has never been perfect and a lot of people ended up being unable to contact others in a stable manner over it; nowadays, GTalk is likely the major provider of Jabber users, and that actually increased it quite a lot, to the point I don’t even use MSN any more (Facebook solved the other half of the problem, my non-techie friends). Servers that come and go, stale connections, slow connections, all that trouble is going to make Diaspora quite difficult to handle for most people, who nonetheless will still want to have their own installation of it; after all, isn’t that what it was designed for in the first place?

Once that problem is solved, the other problem is going to be access control and information push, which seems to be what most of the people having a problem with Facebook are concerned with. I haven’t looked at the actual architecture, so I might be totally wrong, but how is the distributed approach going to help people saving themselves? As I wrote before I don’t consider hands-on approaches to applications availability a bad thing in absolute, so in this I think that Facebook is most likely going to be much more effective for protecting users from rogue applications; if there is no central authority, it’s just in the hands of users to make sure that they don’t enable “rogue” applications. And again, I sincerely expect most people to just click “Enable” on enough of those, if it actually gains users on the “lower tech guys”; the same way that Facebook applications a few years ago kept spamming me with “John Doe knows something nasty about you” when notifications were shared — they dropped the feature from the API entirely as far as I can tell.

Okay, let’s assume that the Diaspora users will all be savvy enough to choose their applications well and the architecture is good enough to actually avoid spreading these applications like viruses over the Diaspora network. What is the next obvious step? Spam within the network. While to actually send content you have to have a dual-opt-in handshake (friend request, and accepted friend), the very request can be spam enough. Just think of the way the “followers” work on StatusNet right now: when you receive the notification or look at your followers’ list, there are high chances that the user is just providing a link to a spam site. Ooops. Now make this trivial to implement thanks to an open API to send requests and… consider that I did receive more than a couple of similar “spam requests” on Facebook, and there they had to go through the registration process and a more complex request API, and a centrally-managed firewall/antispam.

Then there is the sore problem that Jürgen noted: security. Not only the current demos seem to have a bit of concerns of XSS as they don’t sanitise input – at least partially – but there is the problem of using a bunch of “vendorized” (actually bundled) Rubygems, including Rails. I have nothing against Rails; heck this very blog is running on Rails, but to actually keep it running properly I have configured Apache, tweaked it, installed ModSecurity and configured it with IDS and RBL — and this is for an application that has no webservice nature, so it should only allow actions through the limited comments interface or after login. While I’m no expert sysadmin, I’m pretty sure I have done a much better job that the average Diaspora user is ever going to think about; the nature of the “just fire it up and it’s done” is also going to be prone to ignoring updates and new releases for as long as possible. And you know what this bring us? A number of Internet-facing, private, around-the-globe servers with possibly-vulnerable code running cleanly. D’uh!

I know of a number of users who complained when ISPs started filtering SMTP peering, as they couldn’t run their own mail server; the cause? Spam, due mostly to a huge number of misconfigured mail servers. I wouldn’t be surprised if providers started filtering, or blocking users, based on Diaspora-caused spam.

Sincerely, I don’t think there is much difference, nothing that makes Diaspora particularly different from or special compared with things like phpBB (one of the worst security tracks I can think of), WordPress and the other commonly used web applications — on a technical level at least. What really is bad is the idea of self-hosting it for each person, or each family, or group. But that, seems to be what most people advertised the project for, as a “revolution” for social networking.

I’m skeptic, but I’ll be looking from the sidelines; for what I’m concerned Facebook is already enough; the best use for it I have is the sync with the Motorola Milestone so I can actually have the email addresses and the phone numbers of my acquaintances available when I’m on the go even if I didn’t copy them (yet) on my main addressbook. But even that is pretty vague. We’ll see.

One thought on “The self-hosting dilemma

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s