It's pre-alpha. I've yet to take a look at the repo, but any software that isn't full of security holes, bugs and flaws at the pre-alpha stage is probably ready for an alpha release. In other words: No duh.
It would actually be surprising to read the headline: "4 students develop bug free, totally secure social networking platform in 3 months"
That being said, I'm excited to see how the project develops -- it's the kind of project that I wish I had the time to contribute to.
I agree with you, but the kind of insecure this is isn't just an 'oops, we screwed up, it's alpha!' kind of insecure. It's a colossal, "I don't know how to build a web app" systemic issue.
Since the sentiment here and in the article seems to be overwhelmingly negative, I'm curious what people think the Diaspora team could have done better. (Not rhetorically, actually curious.)
I guess "be experienced web developers" (or hiring some) would have helped them to avoid writing insecure code. Retaining a security consultant would seem extreme given that this is an early code-only release.
Is their real mistake simply not doing more to counter the hype? I mean, if you take some code you hacked together over the summer, put it on Github, and non-developers start clamouring to use it, that's a vanishingly improbable best-case scenario for some software developers (at least you think it is until you get the bug reports :)). I guess they should have gone out of their way to say "please don't host this without big scary BETA warnings"?
It seems like the most irresponsible parties here are whoever is hosting these services that uninformed members of the public are signing up to.
The thing is, the errors they've made are so basic as to raise questions to their competence. I don't want to give too much away, but think "absolutely no permissions checks anywhere." Think "base64 is not encryption."
They did say in their blog post that there were known bugs and holes. At the bottom. As the last sentence or two. But that's not stopping anyone...
There's only so much you can expect in such a short period of time from a few guys with little experience. I want them to succeed, but they need to develop or hire better engineering talent.
Hiring the UX firm to get that piece right was a smart decision, since UX sells products. But, the product they're selling is a secure, distributed social network--my hope is that they realize this and get help from an outside security expert.
The real value these guys provide is their vision and initiative.
Privacy was the key kickoff point in the first place. You can't have good privacy without good security. When these are your primary reasons for getting started, your 'user experience' has to entail security.
There's load of social networking platforms already far more mature that offer better security, permissioning, and many might say, an overall better user experience (elgg and buddypress spring to mind as names, although I won't say they're necessarily better UX).
Diaspora got a HUGE publicity boost from Facebook's earlier privacy blunders this year, and may be able to ride that wave a bit longer, but the 'federation' aspect they want to add could possibly/probably be added to existing product. Perhaps other products are considering this already? As someone else said yesterday, having an 'HTTP' for social media would be more important than having an 'Apache' for social media.
What is the difference between a pre-alpha release, an alpha release, a beta release, and a public release, from the perspective of a 20 year old college co-ed who is looking at an IM window saying "Hey, Facebook doesn't respect our privacy. Come sign up for Diaspora (linky), it is like Facebook except they won't send your photos to your mom."
Indeed, maybe, just maybe, a 1000 freshmen will install it on their machines tonight, it will wipe those thousand laptops tomorrow and destroy a thousand career the day after, in a similar fashion to how a 1000 freshmen destroyed their careers by dropping acid on Tim leary's suggestion in 1969.
Let's think about what Richard Feynman meant when he said "what do you care what other people think?"
It's been released as pre-alpha. That's responsible. If it has a greater magnetic attraction to naive early adopters than other software, whose problem is it? Ours or the Darwin Awards?
Interesting. So people who have gone through the trouble of subscribing to the development mailing list don't know that this code is nowhere near production release? That's.... odd.
Yes and no. It got a lot of press outside of regular tech circles, and it's also attracting a lot of people who don't even know Ruby. Earlier today I fixed someone's bug report by showing them which half of "<<<" "===" ">>>" to remove from their Rakefile because of a bad merge. Many of the people who've subscribed to the list are incredibly inexperienced.
Heh, then maybe I'm not missing much. I subscribed, noticed it was filling my inbox (and thus making my phone beep), created a gmail filter for it, and promptly forgot I subscribed. 24 hours later, reading your comment makes me not want to really open up that label.
We all started somewhere and were inexperienced, but there was a time, before Google Groups, where the ability to signup to a mailing list was a small hurdle that helped weed out some of the mailing list distraction. September never ends.
And please, don't get me wrong. I love noobs. But nobody's reading the README. Nobody's reading previously filed bugs. Nobody's reading other threads on the ML. It's really, really bad.
Bugs sure. But not security holes. Sure no one plans for security holes, but I can say with decent confidence that the websites I write don't have any obvious security holes.
No matter how many programmers this attracts or momentum the project has, if the underlying software design is bad, people need to either do a rewrite with a better design, or make a patchwork mess of it all until it becomes unmanageable, in which case you do the rewrite you should have done in the first place.
The problem is, there's a lot of eyeballs that are looking at the code right now, and that does help to identify bugs, but if the bugs we're seeing are deep seated architectural issues, then it's not very easy for someone to just go in and fix them. Then Diaspora has to determine if the fixes are worth including, and whether they fit into their system design (assuming they have one). Basically, in order to actually utilize the community interest in any practical way, they need to be solid managers. At 20 years old, with no real world software development experience.
This is something open source doesn't seem to understand, and why even the biggest projects end up being a small-ish team of dedicated professionals, instead of the "bazaar" we imagine.
I totally agree with this comment. I don't know whether Diaspora is architecturally secure or not. I strongly suspect that it isn't, but am unqualified (and insufficiently interested) to constructively prove that.
The things I found were mostly tactical insecurities, springing from a combination of Rails Security 101 errors and "web application programming is hard." They're pervasive tactical insecurities. Maybe they'll all get fixed if a lot of people pick over every line of that codebase for the remaining one month before release. But that won't help address the part of the iceberg below the waterline. (I can't see it, but the amount of ice above the waterline strongly suggests it is there.)
I haven't read the code or the design, but I'll say:
* To the extent that Diaspora's security depends on Rails, their problem is tenable; Rails (when properly configured, which this project isn't) does a really nice job of making CRUD secure.
* To the extent that Diaspora's security depends on cryptography, we needn't worry about the security of their current design at all, because they have no current design; what they have instead is a "hello world" of cryptography; someone professional (or in academia) will need to design something for them, and then write a paper on it.
I'm worried about their federation strategy: even assuming users A@provider1 and B@provider2 don't have their communications compromised, I have a feeling that Here There Be Dragons around this area, in every fashion I can imagine and many that I can't. At the moment, though, their crypto is academic in that it is like a bank vault door securing a vault where one wall is actually open air and passerby on the street could walk in and take the money. It may or may not be a good door, I don't know, but it is not a good vault.
The Rails bits, yeah, those should be solvable if anyone wants to solve them. I really like Rails for a lot of reasons, and my experience has been that I do less damage with it than I used to do with Java.
The Diaspora crew came to my company and gave a talk. It was pretty boring actually. They ARE NOT interested in cryptography in the first place. The only crypto going on is SSL. Whoopy-doo-dah.
If they wanted to actually solve a problem they could have tried to make this system pseudonymous, with all social graphs, user data and messages encrypted. Oh well.
+1 from me. The more I check out the code, the more screwed up stuff I find.
I went to go try and fix the XSS bugs and found no view testing, or integration testing. Just model and controller unit tests. I managed to get a general patch in [1] to help a bit, but there are other, deep seated problems. This needs a lot of work. I'm no security expert by far, so like he says in TFA, I fear for what tptacek or someone that knows what they're doing could do.
The problem with stuff like this is, I'm not going to look at it. This story came about in part because Coda Hale (another security pro) posted a message to Twitter, linking to the crypto code in Diaspora with an abstract "uh oh". It was warranted, I posted a message to that effect, and got an inquiry, which was more properly addressed by Patrick, who has just provided Diaspora with several thousand dollars of free consulting.
What was the problem I was getting at? Oh, yeah: Diaspora has no apparent access to the software security expertise they need to pull this off. I looked at it for 17 seconds, rolled my eyes, and stopped reading. Maybe someone at iSec Partners will take this project under their wings. But why? Most software security professionals are up to their ears in interesting projects that aren't attempts by college kids to take on Facebook.
More than a few of those professionals are now busy working for Facebook.
This isn't "software security expertise" this is a team of people not communicating at all with each other. For example, the Photo controller
edit (show edit form) checks that it's your photo to edit
update (make changes to photo) does not, you can update anyone's photo to anything
destroy (delete the photo) does not, you can delete anyone's photo w/ the id.
This is stuff you just DON'T DO in a web app. It's something any self respecting web developer, especially Rails developer, will look at and shudder. And those are the simple things that immediately stand out. Who knows what kind of security failures are built into this system due to ignorance or just plain lack of care.
This isn't their fault. I'm really torn on how much snark to aim in their direction. They had smart advisors (I like the Pivotal guys). It is not an insane decision to post a code milestone like this, with all the crappy code that entails. Our internal pre-alphas aren't --- well they're not this bad but they're not perfect.
But none of that matters because they've picked a project that they have to get right, and that in the long run is going to be defined in large part by design security.
In another thread, someone from Pivotal said that they didn't really advise them more than just a few conversations during breakfast. They were just working out of their office.
At first, I thought those comments were a CYA distancing from Diaspora, since their release has been so abysmal, but then I watched their presentation to Pivotal again, and it really does seem like everyone there knew about as much about Diaspora as we all did on Sep 14th.
Who's fault is it then? The expectations were set - not that first code release would be awesome - but 'privacy' was the entire reason for diaspora starting.
I was expecting some integral libraries that would encapsulate privacy and authentication logic which would be reused for the entire framework. I don't really care if this was 'only' 3 months of work. That lack of security/privacy checking in that photo update section speaks volumes about where the developers and entire project are at.
Is it doomed? Probably not - apparently even Duke Nukem Forever has a new release date(?) - but they've got a long way to go to convince early adopter techies (people like me) to install this and evangelize on their next round.
Yep. And I don't want to help too much, because what happens if I only fix some problems? I can prevent against basic stuff, if their crypto is bad, that's above me. And if I fix some of it, and then somebody gets burned by something I didn't catch, I'd feel partially responsible.
You're missing the context. You may see Diaspora as a great way to get visibility. I assure you, any competent software security person has much better ways of getting visibility.
Thanks, I was wondering why they had XSS bugs. Surely the point of using a framework is so that you don't have to think (too hard) about that sort of low level security issue?
There are other ways to get XSS bugs than bad html escaping. For example, if you redirect to a user-provided location, they can inject javascript and/or http headers.
Thanks, but it sort of tastes like ash. Locally we have a engineering tradition of Big Red Buttons. If you know a process is out of control, you have to hit the Big Red Button. All work stops, the company starts losing huge amounts of money instantly, etc. The reason we're taught to hit the Big Red Button is that quality issues quickly propagate past the point where you can stop them.
On the Internet, with a highly anticipated release getting mainstream media attention and a dedicated community, quality issues propagate quickly indeed.
But nobody ever wants to hit the Big Red Button. I would greatly have preferred getting a solid eight hours of sleep rather than spending several hours checking if errors were exploitable (yes), sending four emails to try to find someone on the inside, and getting quoted in a piece which is sure to ruin several someones' day. But there are people putting data into Diaspora instances as we speak, so Big Red Button it is.
"They are going to get burned in a very serious manner very, very quickly if they actually succeed in doing what they're trying to do."
And by "burned in a very serious manner" he means someone is going to see their vacation photos and change their username to "Ima Douche."
If someone totally took over my Facebook account I'd be minorly annoyed and that's about it. Unless you're putting your social security number into your Diaspora account, who cares?
I think it's easy to underestimate how valuable something like a Facebook account actually is.
If I meant someone real harm and had access to their Facebook account, I could cause them a lot of trouble. I could send messages to their friends asking for unreasonable favours, starting arguments or causing other offence, I could embarrass them in front of their family. I could stalk them in real life. Look what happened when 4chan got hold of the passwords to a bunch of Christian student Facebook accounts:
You are, as usual, a voice of uncut pragmatism. But if nobody cared about what was in Diaspora, there wouldn't be much point to Diaspora. I agree that this is mostly a logic puzzle and not a practical issue.
Diaspora will be fine, now it's on Github it has so many skilled eyes on it. All they need to do is deal with the flood of pull requests effectively. A lot of people want this to win. A lot of hackers will commit code to it because it's a project with the world's eyes on. I wouldn't be surprised if Facebook picked up a few people who commit really good code to it either.
In theory, this is great, but it's really hard to do actual work while wading through 6 separate reports of "It says the db can't connect to this host and port, what do? Derp!" The mailing list is even worse.
It's really hard to separate real, actual issues from a few hundred people who don't know how to run a ruby-based website.
Even the people that seem to know enough to help fix bugs are stuck arguing about whitespace and license choice. That's a waste of time both for them and the diaspora time when there are clearly bigger issues to solve.
If anyone thinks that, they would be best served talking to the Joomla or Drupal (or any other popular, large-scale, user-facing, and general purpose open source project out there) and get their perspective on how that actually works out in reality.
I know we have this sense that open source software development is one big happy stone soup where everybody pitches in, but at some point, people have to make architectural and system design decisions and map out a direction in order to make any sense of those changes.
In other words, "many eyeballs" don't make all bugs shallow, they make them more noticeable. Which in Diaspora's case, is more of a problem than a benefit.
The Register is simply silly journalism for the tech set: tailoring shocking headlines and 'begging the question' far more often than they actually do research.
Very disappointing especially with $200k behind them to do this properly and so many hopeful supporters.
As we predicted this is just another propitiatory system with open source code. Sort of like OpenID.Clever PR but not really what it claims to be.
How do you justify using the 'open' when it is based upon a propitiatory naming system? With Diaspora, whoever owns trydiaspora.com (anyone know who does?) owns your content and connections, meaning you are effectively trusting someone who is hiding their identity. Nice.
We try repeatedly to reach out to the Diaspora team when they kicked-off with an alternative that is 100% open and user-centric called NetID (see http://ucentric.org) but were ignored.
I guess that when you have $200,000 and no one to answer to, you can pretty much ignore your stated goals and anyone trying to help you achieve them.It also looks like that is basically what they are delivering for the $200k they raised as their blog suggests it is now an open project for the community to finish off...
As a side issue, is there any truth in the rumor that Zuckerberg gave them $100K?
The code of OpenSSH and OpenBSD are available for years, and that is why it is most secure. Just think how many people tried to find a hole in OpenSSH's code!
Opening the code is the most important step. If the idea is worth and code is useful it will be improved by community, just because it is useful for them. nginx is a classic example - people around the globe are improving it because they find it useful.
The code for OpenSSH and OpenBSD is secure because Theo Deraadt personally roped crazy smart people into the project to audit the entire BSD operating system line-by-line, and then set up a regime that treated all code as guilty until proven innocent. He was the first person ever to have done either of those two things.
(I had the privilege of being a semi-involved bystander while this happened; I have one or two findings from the audit and wrote their first several advisories).
Security does not just happen for open source projects. The notion that it does is one of the more harmful myths in software security. If you have any questions about this, or about the difference between a bug (blows up in your face and ruins your day, causing you to write a patch out of anger) and a security flaw (hides in the shadows waiting for an adversary to find and exploit it), just ask Wordpress, Sendmail, or BIND.
Open source makes a lot of software security problems easier, iff you care about security --- like nginx always has, and maybe Apache not so much until recently. But slapping a GPL on your codebase and pushing it to Github does not make magical unicorns poop security findings into your mailbox.
Nope. It is good that Theo is so paranoid^Wpassionate, but it isn't a whole reason. The whole reason is that so many people are involved, both on contributing and seeking design or coding flaws. Crowd-sourcing is the key.
I didn't say that opening the code makes it secure by a magic, what I said is that if the code is useful for some skilled people they will fix and improve the code, at least for themselves. Good ones will submit the patches back to the community.
"landmines" implies intent. Strongly. Landmines don't happen by accident, they're placed. The title is rather offensive, probably for linkbait reasons.
Agree with elbrodeur, it's a "duh" situation. Pre-alpha, no warranty, known security holes and bugs. They haven't advertised it as anything it isn't.
What I think people should do is fork the open source php version of Facebook that they released about 2 years ago, call it something else, and basically beat them at their own game using their own software.
Facebook operates on a lot of open source software.
The best thing diaspora can do is to take a look at that open source facebook release - and just run it on a server - add some federation functions, and voila, a prototype primitive facebook and twitter killer with a lot of potential
> The best thing diaspora can do is to take a look at that open source facebook release - and just run it on a server - add some federation functions, and voila
But I'm not talking about a "weekend" - What if you had 2 years to do this, with yourself and a technical co-founder? Wouldn't it work with proper project planning? I'm not sure where the "weekend" vibe came from?
Facebook Open Platform is a snapshot of the infrastructure that runs Facebook Platform. It includes the API infrastructure, the FBML parser, the FQL parser, and FBJS, as well as implementations of many common methods and tags.
http://developers.facebook.com/fbopen/
Design work will need to be done from scratch. But I think there's some good basic structures in there.
how would this method remove the slew of security vulnerabilities and other development issues?
there's nothing wrong with green field dev. especially in this case. fairly sure slapping on some 'federation functions' would result in a hell of a mess.
not so sure about that. If you, for example, build a google buzz interface to the facebook backend, you can take advantage of the federated open stack that's being backed big time by google itself, as well as the Mozilla project (ie Salmon protocol, etc)
It would actually be surprising to read the headline: "4 students develop bug free, totally secure social networking platform in 3 months"
That being said, I'm excited to see how the project develops -- it's the kind of project that I wish I had the time to contribute to.