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.
If the roller manufacturer put a big warning on their packing, whose fault is the accident?
...serious hats off to them if they've learned enough to be dangerous (literally)...
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.
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...
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.
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.
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?
However, the Diaspora github readme says this in bold:
"PLEASE, DO NOT RUN IN PRODUCTION. IT IS FUN TO GET RUNNING, BUT EXPECT THINGS TO BE BROKEN"
So, shame on the register for calling this news.
So I'm not surprised users ran out to try it.
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.
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.
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.
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.)
* 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.
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.
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.
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  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.
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 is a dumb idea for a project.
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.
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.
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.
A code review by frickin entire world???
This will help them WHEN THEY DO THEIR ALPHA RELEASE. Thanks...
Reading all this actually is the first moment I imagined that diaspora wouldn't be the total disaster it threatened to be.
Diaspora? Or doing a security audit of Diaspora's code?
Reasons to work on this?
Visibility, visibility, visibility, visibility, visibility, and visibility.
Did I mention visibility?
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.
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?
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:
Your online reputation is valuable.
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.
Point them towards Hackety Hack :)
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.
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.
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.
So, fuck off.
Watch your tone. Mindlessly contradicting him in his field of expertise is not advisable.
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.
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
In fact, maybe I should do such a thing..
I want to live in your world.
Because you make it sound awfully similar to the "StackOverflow in a weekend" episode:
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.
Design work will need to be done from scratch. But I think there's some good basic structures in there.
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.