This code was released to developers as an incomplete preview. I'm not sure why people are holding it to the same standards as a finished product that's being released to end users. Seems like a pretext to talk trash.
I don't think anybody is "holding it to the same standards as a finished product."
I haven't read the code myself, but the OP is claiming "really, really bad security holes", and calls out the encryption code.
Security is not something that can be bolted on after the fact; it needs to be baked in from the start, in a product like this. And, remember, security/privacy was Diaspora's raison d'etre.
No one expects the first code dump to be polished, or feature-complete. But if there are serious flaws there, of the magnitude described, pointing it out isn't just "trash talk."
"It can't be bolted on after the fact" doesn't mean it's impossible to take an insecure codebase and make it secure. It means that you can't leave it to the last thing and then just toss a few security things into your product. It means you have to rearchitect major pieces of the product, possibly all the major pieces, possibly switching around what the major pieces are entirely. If you want to show that in the "vast majority of cases" that happens, you need to start by establishing not merely that a particular codebase went from "insecure because nobody hardly thought about security" to "reasonably secure", but that the transition was easy.
Facebook probably isn't the best starting point because anything working at that scale is a challenge no matter what.
(Edit: Though if one measure's Diaspora's eventual size if it reaches its goals and considers what percentage of the man-hours have been put in to date, this is still early in the process and major rearchitecting of every component was inevitable anyhow, so hopefully with one of those they can install some security too.)
Indeed. These guys should be lauded for getting something out. It's a very non-trivial accomplishment.
I'm afraid that Diaspora might be in an impossible position. If they release something early, they'll get a lot of bad press from knuckleheads like this one that the quality is no good. If they release late, everyone will be clamoring over the wasted $250k in the interim, demanding: "when will we see something?".
I'd argue just the opposite. Especially in today's world. "Getting Something Out" is very easy. I can come up with a project idea tonight, start coding, then publish the code within an hour. Then iterate (or not) to my heart's content. Granted, it's harder with a group. But still, it's always easy to publish shit code. Non-shit is a little harder, but also easier to do with experience and talent.
Now growing it over time, standing up to public scrutiny, hardening, balancing, monetizing -- those are much harder problems. Getting code out? Not really, in my opinion.
Their product is released to end users, because the first thing every early adopter is doing with their shiny new host-you-own federated social network is sending out invites.
So they should develop the whole thing behind closed doors because some people are going to have to suffer the embarassment of having someone post "hahaha disregard that ... " on their mini facebook wall?
Their code is out there, they have openly said it is full of bugs and they now have a hell of a lot of eyes, They will get a massive benefit from this being opened early and it really isnt their problem if people refuse to ignore all their and everyone elses advice and give out their banks password
Basic authorization for resource access isn't the kind of thing you add later. This isn't just an issue of bugs or being in development, it's a fundamental issue with their development process.
Furthermore, one of the primary goals of the project was to make something more privacy-conscious than Facebook, and so far they show they have a development process that pays less attention to access control than any Rails app I'm aware of.
For brand new/"experimental" projects with both user permissions and a non-trivial set of features, built by a small team, I've always found it easiest to work like this:
1. Build features, ignoring permissions entirely.
2. When the feature set is relatively stable, default to disallowing everything.
3. Re-enable one feature at a time as you add appropriate permissions checks.
Step 1 looks horribly irresponsible if you don't know 2 is coming. But if you do, it avoids a false sense of security from half-finished permissions in rapidly changing code, and it keeps up early motivation since you're rolling out "exciting" features right away. And counting on step 2 ensures you're always checking whether something is allowed, instead of foolishly checking whether something isn't allowed.
Whether this scenario applies to Diaspora at all ... I don't know. Time and another release will tell. But I do think there are valid situations where authorization is "the kind of thing you add later" for appropriate values of "later".
Part of me wants to say 'Cut them some slack, they just put their work-in-progress code on Github like they promised!'[1], but I understand that most of the criticism stems from caring enough about the project to want it to succeed. At this point, they should be thankful for the attention and the guidance more experienced people are providing for free.
The question is, do the problems in the code establish beyond doubt that this team is not capable of delivering a final product that will see some level of acceptance? I really hope not.
1: I'm assuming that - I would hope they didn't think this was release-ready material.
Invites are not implemented. They have already changed websockets many times since the release. If you have an install you're probably busy merging changes and reconfiguring your web server, flushing the database and debugging it and all people capable of maintaining such an unstable environment realize that it's for testing only, I have yet to meet anyone who's using it to store personal/production data. Stop freaking people out, only devs are playing with it, and if some people are not, this is open source, there's nothing we can do about it.
And may I add, I think it is really great that many public seeds are being deployed, this is the only and best way to test a social federated network, pre-alpha or not.
I haven't looked at the code, so I can't say this is the case, but...
There's some stuff that good/experienced developers do upfront naturally. There are some security, design and performance things that are clearly a case of bad development versus "this is an early release".
"Bad development" sounds like some kind of phrase from a 1950's development model.
"Fundamentals" are things like: there's no identifiable data model, the code is pure spaghetti and structure is a fleeting concept.
From my very quick scan of their code, it's readable, the parts of the data model I looked at are fairly obvious (thanks Rails), dependencies are identified, crypto seems fairly localised. Correction of bugs seems definitely doable. Extra features shouldn't require a total refactoring. Looks good to me for an alpha drop.
Next up: posts criticising the spelling in the comments in the Diaspora code.
First impressions are important. Just as I was excited to hear about a decentralized, privacy-aware social network back in May, I am now worried when it's made available for us to watch its course.
The fact is, the implementation is obviously problematic. I won't go as far as saying that the design is flawed, although some security vulnerabilities are certainly pointing that way. It's obvious that Diaspora's developers are inexperienced, and therefore could use all the help they can get from us. This is one point in favour of an early release, in my book. On the other hand, early design and implementation decisions have profound implications during the lifespan of a project (this is especially true when it comes to security), and I will not trust my personal details to Diaspora in its current form; the project still has a (very) long way to go before being technically up-to-date.
I don't think this article was that mean spirited. The author did submit patches, and is planning on submitting more patches. I interpreted it as a concerned party that wants the project to succeed and is thus pointing out a very real concern, asking others to help, and is himself helping.
I haven't read the code myself, but the OP is claiming "really, really bad security holes", and calls out the encryption code.
Security is not something that can be bolted on after the fact; it needs to be baked in from the start, in a product like this. And, remember, security/privacy was Diaspora's raison d'etre.
No one expects the first code dump to be polished, or feature-complete. But if there are serious flaws there, of the magnitude described, pointing it out isn't just "trash talk."