Slashdot Mirror
Security Concerns Paramount After Early Reviews of Diaspora Code
Stoobalou writes with this excerpt from Thinq.co.uk:
"Following the release of the source code for the Diaspora social networking platform, hackers and tinkerers the world over have been poring over the code in order to improve, enhance, and otherwise help the project in its attempt to unsettle Facebook. Sadly, the current opinion is that the code just isn't up to scratch. While the team clearly stated that 'we know there are security holes and bugs' in the code that was released, it's possible that they weren't aware of just how many show-stopping issues there are — issues which make it hard to recommend that you roll your own Diaspora server just yet."
Yeah, but it will be like email is now. People won't need to run their own servers. They will be able to pick from a variety of free diaspora hosts who get their revenue from ad dollars and harvesting your data (and that of your friends, who might host their own diaspora node at home, or on another service), and then we will be free of facebook's horrible privacy violations, and be in a new universe of less accountable companies with even worse problems.
I can't wait, diaspora, here I come!
I'm more interested in the protocol than the code. If the protocol is vulnerable to attacks/fraud then it is a show stopper.
If the ruby-web-stuff-code contains bugs and security holes, I'll just write my own (read: wait for someone else to do it).
I couldn't find any relevant info about the protocol in TFA. Am I missing something?
Is anyone actually surprised that a bunch of Ruby developers can't write secure code?
No, but then I wouldn't be surprised if you substituted Python, Perl, Java, or C for Ruby in that statement. The proportion of programmers who can write secure code is a relatively small proportion of the number that can write code in any language.
That's one of the reasons why, as I said in the last story, I am more interested in the protocols than in the implementation. A set of standard protocols for social networking (ideally built on top of XMPP) would allow lots of different implementations, which would reduce the damage that could be done by a flaw in one of them.
I am TheRaven on Soylent News
Am I missing something here? This is the way it should work, and the true strength of open source. Assuming they have the skillset to address the security issues found, I just don't see an issue. This isn't release level software yet, and I would expect that anyone putting up such a site based on it would publish that fact. I'm pleased that they are getting such great input on key security flaws.
Irrelevant. A bug is a bug, and can be fixed. So long as they actually fix the bugs instead of pushing out a release, they should do fine.
Can anyone tell me why 99% of
Not if it's anything like every big project I've worked on.
First, projects go through a phase of "how can we do this" where various components are mashed together with the expectation that things will work later. That's a good thing to do while gathering initial funding.
Then they go through the phase of "we can do this" where some parts of the project work, but most is broken.
That's followed by the "demonstration" phase, where things work under perfect circumstances. That seems to be where Diaspora is at now.
Next is the "we can do this well" phase, where the once-connected components are split up and divided into their appropriate layers and security is locked down, now that there's a clear idea of what the security model must support.
Finally is the "continued development" phase, where the project is stable enough that new components don't need major changes to security, and extra features can be added.
I've had a few projects that started with the frameworks and various layers of abstraction, and they've invariably failed after many refactorings and revisions. Heck, one project I worked on was a web-based game engine, which turned into a giant security model, and finally died without a single line of actual game code written. It took eight months to fail miserably. Projects change, and requirements change. Going into a security model too early can be worse than not having one.
You do not have a moral or legal right to do absolutely anything you want.
It's not a jab at all. It's perfectly normal for inexperienced coders to have security issues in their applications, just like you can have any other bug.
Yeah, they've only focused on the "fun stuff." Or rather, it sounds more like their purpose was "Facebook's so annoying to use. Let's make one that works like we want!" without really caring about the backend stuff. Maybe they assume that the "open source community" will do all the backend stuff for them -- even though they're the ones getting paid?
Or possibly, that they are smart enough to recognize that having "something" to show possible investors (and more importantly, current investors) is worth a great deal more than a framework that can't be demonstrated.
Don't get me wrong -- I really, *really* hope that the security model gets implemented well in Diaspora, and they don't get destracted by "ooh, shiny!" syndrome. But expecting them to go to folks who have given them money -- people who likely know even less about security than these college students -- and say, "This mystery code will work, it's really better, we just can't demonstrate it," is unreasonable.
Prototype first, then refine. Bugs happen, just fix them and move on. It looks like they're on their way to me. If you (or others) think you can fix these bugs or fundamental flaws in their security model, talk to them. You might just find yourself a job at a potentially big startup.