Diaspora: what next?

It was a summer to remember for the founders of Diaspora, the “privacy-aware, personally-controlled, open-source, do-it-all social network”. Talk about being in the right place at the right time …

Back in the firestorm about Facebook privacy last May, the four NYU students raised $200,000 for their project on Kickstarter. Since then they’ve moved to San Francisco, gotten free office space at Pivotal Labs, gone to Burning Man … and on September 15, released their software to the community.

Congratulations! And as summer turns into fall, it’s a great time to assess their progress.

To start with, kudos to them for hitting their target date — something I don’t think they’ve gotten enough credit for. At the beginning of the summer, they said they’d have something available to turn over the community in three months, and voila, here it is. While it’s clearly at a very early stage, they’ve got some decent functionality. As somebody who’s been there a bunch of times, I’m impressed with what they’ve accomplished. People who haven’t ever developed ambitious software from scratch have no idea how challenging this is.

Now that Diaspora’s released their code, they’re getting lots of feedback at a relatively early stage. With an open source code base, people can get involved, and judging from the discussions on HackerNews, Slashdot, and the Googlegroups, mailing list, there’s a lot of interest and even their critics hope they’ll succeed. It’s a good first step.

However, they’ve cut a few corners to get there.

After Dan Goodin quoted him in The Register as saying “The bottom line is currently there is nothing that you cannot do to someone’s Diaspora account, absolutely nothing,” Patrick McKenzie went into more detail yesterday in Security lessons learned from the Diaspora Launch. It’s great reading if you’re a programmer or just curious about why most software today is so insecure. Steve Klabnik has more. On Slashdot, pedantic_bore notes “there are virtually no comments or design docs” — and after downloading the code, I only see a few specifications and tests. Ouch.

This was probably the right tradeoff for Diaspora to make over the summer. If the guys had spent all their time becoming security experts, they couldn’t have gotten as far as they have. There’s a huge amount of value in giving people something to play with even if it’s insecure. We took a similar approach at Qworky late last year when we decided to build a security-free “preview” release, knowing we’d have to reimplement from scratch.

Still, it’s very challenging to make software truly secure unless you focus on security and quality from the very beginning. It doesn’t seem like Diaspora’s had a thorough external security review so there are likely to be problems lurking in their architecture and protocols.* And when I asked some security experts for suggestions about what Diaspora should do next (see the first comment), they came back with sensible suggestions like threat modeling, a security review, and secure coding training for developers — none of which currently show up on Diaspora’s roadmap and project management systems. Not good.

It’s easy to be skeptical. Retrofitting security and reliability is notoriously difficult and not a lot of fun; will they prioritize it? There are quite a few other privacy-friendly open-source social networks being developed, with Appleseed, OneSocialWeb, elgg, Crabgrass, and others farther along than Diaspora. Can they build on their excitement so far and fault ahead?

They certainly have a chance. There’s not very much code yet (just a few thousand lines) so if they start to focus on it now they have a decent chance of cleaning it up — or at worst, it won’t take long to rewrite. See the comments for more discussion of the options.

I hope so too.

And building on Sonya Lynn’s point: listening to and involving the community will be the key to Diaspora’s success. Assuming they still have a chunk of that $200,000 left, they should consider bringing somebody on board to do community organizing — perhaps initially reaching out to security researchers, who could be a lot of help right now. And it seems to me that the vast majority of the people involved so far are guys; they might try to get some suggestions from Sarah Mei of Pivotal Labs and Kaliya Hamlin of the Internet Identity Workshop, who just gave a great session on diversifying open source projects at the Women Who Tech teleconference.

One way or another, now’s an interesting time for Diaspora and their supporters. The opportunity is there, and over the next few months we’ll see if they can seize it. Stay tuned!

jon

Thanks to Alexander, Jason, Adam, Sonya Lynn, and Rainey for feedback on the draft version of this post

Posted by jon on Thursday, September 23rd, 2010, at 4:17 pm, and filed under Uncategorized.

Security work is ongoing, you can’t really spike on it, it has to be kept in mind throughout the development of other features. I’m closing this issue, we can talk about it in IRC or something.

Well, yeah, it’s an ongoing challenge … and on top of that you typically need to spike on security work at various points in the lifecycle. For example, on Twitter, Adam Shostack recommended threat modeling and using safer platforms. And on Facebook, Jason Geffner made an excellent point:

“My suggestions to them would be as follows:
1. Secure design review
2. Full source code security review
3. Security training for their designers and developers

#1 and #2 will help fix existing vulnerabilities, #1 and #3 will deter future vulnerabilities.”

All great suggestions. However all of these will take time, and since they’ve deferred them over the summer, they’ll have to spike to catch up. And the longer they put ’em off, the bigger the hole they’re digging themselves.

Adam, I agree that a full source code review is often not the best way to go for the exact reasons you cited above. However, in this specific case, the code base is very small and a full code review would not take more than a few days.

I wasn’t aware of the size of the codebase. Jon mentioned somewhere else that it was 3300 lines, and I agree that’s currently possible. However, a one time code review will give them a burn-down list of bugs, once. What do they do to stay secure is the more relevant long term question (to me).

> On Slashdot, pedantic_bore notes “there are virtually no comments or design docs” — and after downloading the code, I only see a few specifications and tests.

That’s because it’s an XP project. Like it or not, the lack of comments and docs is a feature, not a bug. The tests and Pivotal Tracker stories serve as live documentation, and information is recorded via wikis and mailing lists.

Also, code review happens all the time via pairing and refactoring. Not to say they couldn’t benefit from community code review, which it looks like they have.

> they might try to get some suggestions from Sarah Mei of Pivotal Labs and Kaliya Hamlin of the Internet Identity Workshop, who just gave a great session on diversifying open source projects

They are well placed to receive that advice, since Pivotal Labs is hosting them 🙂

Alex, I’m a big fan of agile methods and agree with their philosophy of avoiding unnecessary documentation. But security architecture and design requires up-front thought and writing it down to get it right. As for comments, my experience is that when there aren’t any at all, it’s extremely hard for new people to understand the code. A formal security code review is a complement to the very valuable code cleanup that gets done with pairing and refactoring; as Jason and Adam point out, it’s expensive — but it pays a lot of benefits where it’s feasible.

Wayne, totally agree that it’s an industry-wide problem. And great link to Parasoft! Back in the I was the architect for C/C++ static analysis tools like PREfix and PREfast, so competed with them. Good to hear they’re still around. Disappointingly, though, they don’t seem to offer any Ruby tools … and neither do other static analysis vendors. There are some great tools in the Ruby environment (Cucumber, RSpec, Selenium) but still some crucial gaps for doing high-reliability software.

[…] From a security perspective, it’s swiss cheese, filled with security 101 errors. In Diaspora: what next?, I argued This was probably the right tradeoff for Diaspora to make over the summer. If the guys […]

[…] journal. The posts about Diaspora are a good template for how things might work out over time: thought piece, (1, 2), and details on Liminal States, summary and presentation on Tales from the Net, and here on […]