Liminal states

Back in April, four NYU students decided to raise money to spend the summer hacking on their project: a privacy-friendly open source social network. They put up a page on Kickstarter, a crowdsourced funding site. Talk about being in the right place at the right time: after a great article Four nerds and a cry to arms against Facebook came out in the New York Times, in a few weeks Diaspora* had raised $200,000.

At which point they moved to San Francisco, got free office space, spent the summer hacking, went to Burning Man … and on September 15, released their software to the community. Basic functionality is in place: status updates, photos, “aspects” to control who sees what. Kudos to them.

Alas, from a security perspective, the code was swiss cheese: filled with holes — just like most web startups. But then again, most web startups aren’t basing their appeal primarily on privacy. If Diaspora winds up with a bad reputation for security, they’re doomed. So rather than comparing themselves to the typical web startup, I think it’s better to think of Diaspora as having a chance to be the next dominant social network, the successor to Friendster, MySpace, and Facebook.

Taking off my security hat for a moment: this was probably the right tradeoff for them to make at first. 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.

Still, the major reason people are excited about Diaspora is because of privacy — and you can’t have privacy without security. f they get a reputation for security holes, then it doesn’t matter how privacy-aware they try to be: people won’t trust them. The recent catastrophic failure of Haystack highlights what can happen to projects that misset expectations and put their users at risk. So if they want people to trust them, they’re going to have to raise their game. And security is notoriously difficult and expensive to add after the fact. What to do?

When I looked at the kinds of security 101 bugs in their code — missing validation and authorization, script injection — I thought to myself, wait a second, I’ve seen these before. Back in 2001, when Microsoft made it’s own transition to star taking security seriously, I was architect for PREfix and PREfast in Microsoft Research, and wound up working with the SWI team when we shut down Windows development for two months in the first security push. Since then, there’s been huge progress — and, with all due respect to my former colleagues, significant challenges remain.

Diaspora’s not Microsoft, of course. They’re small and need to move fast, and don’t have a lot of resources. Oh, and they’re not the evil empire — a definite plus: just as Linux and BSD got a lot of help from people who wanted an alternative to Microsoft, Diaspora’s likely to continue to benefit from the fear and loathing Facebook continues to inspire. Still, there’s a lot to learn here from cross-fertilizing Microsoft’s experience with the best security practices from the open-source world. Here’s some ideas.

1. Reach out to the security community. Diaspora appears to be doing virtually nothing here, so there’s huge room for improvement. Microsoft used to be even worse, treating security researchers as the enemy, and minimizing communication about security issues. By engaging with their critics, and providing a lot more information, they’ve learned a lot about how to improve their security — and also helped shift others’ perception of the company.
2. Add security experts to the team. Computer security is hard and you need to have somebody who understands it deeply involved in the design and engineering process. You also need to have a main point of contact with the community. The skills for these are somewhat different so they might be two different people — and because it’s such an exciting project, Diaspora may well be able to find people to join part-time very cheaply.
3. Review the code. Actually this is a lesson from Tor and BSD as well: when you look at the code from a security perspective, you find plenty of things that you’d otherwise miss. On Hacker News, Locke1689 commented that from his experience “the most effective part of Microsoft’s security practice is that we had dedicated developers whose only job is to evaluate the security of proposed changesets”. And it’s worth thinking about going further: formal multi-role code reviews are very expensive, but fortunately Diaspora’s code base is small.
4. Document security properties and do threat modeling. If you don’t describe the system’s properties, you don’t know what to test. If you don’t know what the threats are, how can you claim that your system protects privacy? If you don’t know what the threats are, how can you claim that your system protects privacy? It’s fun, too!. This is a place where Diaspora could really get a lot of help from the community if they can come up with a good way of sharing and refining threat models on their wiki. With many eyes, all threats are shallow — or at least a lot shallower than they would be otherwise. How cool would it be if computer security classes all over the world used Diaspora as an example, assigned threat modeling as an expertise, and contributed the best ones to the community?
5. Train the developers — and the designers and quality engineers too. Secure software is everybody’s responsibility. Secure programming still isn’t covered in any detail in most undergraduate or graduate programs, so just like Microsoft discovered a decade ago, most developers don’t know the basic practices. Pairing (programming, code reviews, threat modeling) is a very effective way to train while making progress on some of the other items on this list.
6. Use the tools — and develop new one. What can I say, I’m a tools guy. And there are some great specification and testing tools in the Ruby environment like Cucumber, RSpec, Selenium, Burp Suite. There are also some areas where additional tools could be useful, including static analysis, fuzzing, and attack surface estimation. Again, this is a great way for the broader Diaspora community to get involved and supplement the core team; Apache, Linux, Sendmail, and BSD are all great examples of open-source projects that have really benefitted from aggressive tool use.
7. Bake security in at every stage of development, as Damon Cortesi suggested on Quora. Microsoft’s Security Design Lifecycle (SDL) has made a huge difference. Alas, even the Agile version of SDL may well be too heavyweight for Diaspora. There are other good options out there, or perhaps they’ll probably need to break new ground finding something that strikes the right balance for their needs. It won’t be perfect at first but what was really surprising at Microsoft is how quickly even imperfect versions give value by providing a constant reminder of the importance of security.
8. Create a security and privacy advisory board. Microsoft’s Trustworthy Computing Advisory Board has about 20 experts from academia and has been incredibly valuable in many ways: feedback on priorities, suggestions for improvements, tough design and architecture reviews, sharing their understanding of Microsoft with their colleagues, and in some cases getting their students involved. Obviously Diaspora can’t afford to fly everybody around to get together in person but virtual meetings can be almost as effective.
9. The longer you wait the tougher it gets. Probably the biggest lesson: putting it off doesn’t make it any easier. When security isn’t designed in up front, it’s incredibly expensive to retrofit it. By the time Microsoft started paying serious attention to security in 2001, they had created a huge hole for themselves and even now after investing over a billion dollars they’re still playing catchup. Diaspora’s code base is tiny right now. Might as well get started.

Yes, it’s a lot. Will Diaspora and its community rise to the challenge? I hope so — like so many people out there, I’d really like to see a path to getting off Facebook.

If not, oh well: they’re not the only game in town. The learnings here useful for Appleseed, OneSocialWeb, and any of the other projects in this space. Shmoozing at the party on Wednesday night, it was interesting how many people really hate Facebook and can’t wait for an alternative. It’s just a matter of time until somebody gets it right.

jon

Thanks to Adam, Jason, Alem, Sarah, tptacek, Locke1689, mahmud, Wayne, PeterH, Ed, Steve, SonyaLynn, Steve, Michael, Damon, Dan, Michael, Sarah, Window, and Nick for comments on previous iterations