so still sounds better than 1.7 million names released.....lol
think I'll wait tho....
Four New York University students who raised a bundle of cash to build a privacy-preserving alternative to Facebook sure have their work cut out for them. The release of pre-alpha source code for their Diaspora social Website was only a few hours old on Wednesday when hackers began identifying flaws they said could seriously …
so still sounds better than 1.7 million names released.....lol
think I'll wait tho....
It's written in RoR so good luck competing on scale.
Could be another twitter, doing another $160M investment round every 3 weeks to keep up with server orders with zero revenue (p.s. good luck getting your money back).
Haven't we dispelled the myth that RoR magically makes your code secure yet?
I thought half the point of this was that it was distributed? So the creators shouldn't *have* to have a giant pile of servers.
Pity the pre-alpha is poor quality, but I think it's a bit too early to call whether it's broken-and-unfixable or just broken.
I think the purpose is that you run your own private Diaspora instance, or "seed". So if you are only managing your own interactions, scaling shouldn't be an issue. Of course, I suspect Diaspora hosters will pop up, in which case I agree, RoR may need replacing.
I could write a Java app which won't scale, or a C++ app, or a Ruby on Rails app. Scalability is a function of design not the language the design is implemented in.
Except RonR isn't a language, it's a badly-scaling app written in Ruby.
RoR is something of a black box, and Ruby itself is a slow, interpreted language. This stack is great for low-volume websites, don't get me wrong, but it won't scale up to many millions of users. That's where particularly Java has the edge, with a huge choice of mature APIs such as Spring and Hibernate, the likes of GWT for the front end, and multi-gigabyte caching technology e.g. Coherence.
Let's just hope that these four students are studying anything related to IT... If they are then they are failing badly.
Some flaws are to be expected, but falling to know exploits as XSS just shows a lack of knowledge, testing and ability to design in security.
I'm half tempted to go try a bit of SQL injection just for the giggle, but I suspect it wouldn't be much of a challenge.
I had a look at the Diaspora site - if the kids' ability to code is as bad as their ability to use English, it's doomed.
Pity. It's a great idea.
That's the whole point of open source, guys. These bugs get disinfected by daylight and scrutiny instead of festering unseen and unfixed.
Bugs are to be expected, but there's no reason to have things like XSS flaws and bad user input validation, even in "pre-alpha" software. That just suggests bad coding practice and generally sloppy programming.
Well, up to a point. There's a case for releasing your code in order to accept scrutiny and improvements, and releasing it in the hopes someone will fix it for you. On the basis of what some people describe as 'open source', you could sell an empty plot of land and call it an 'open source house'.
I really think Diaspora have become a victim of their own success. Four guys expressed mild dissatisfaction with the Evil Empire, and speculated about setting up a rival business - and suddenly people started giving them money to buy X-Wings with. Now we're several months down the line, and people are asking when the X-Wings will arrive, because many outside of open source still think there's an inexhaustible supply of enthusiast-programmers ready to jump on every project going.
Furthermore, many in the business of commenting on the IT industry - who have a vested interests in telling one story, or another, about open source, regardless of the truth - are keen to punt up any website that uses something other than IIS, as an example of 'open source'. Hell, F5's "BIG-IP" system runs on Linux - and F5 use a tonne of open source technology in their stack - but that doesn't make Facebook, or any other site that F5 manage, 'open source'.
"Bugs are to be expected, but there's no reason to have things like XSS flaws and bad user input validation, even in "pre-alpha" software. "
Yes there is. It's called limited time and resources. I expect the modus of these devs was to get basic functionality up to some level, throw it to the wolves and then work on the security and other issues identified thereafter. Ultimately the software will be stronger for it.
As a rather apt analogy for anyone who didn't fully understand the genious behind your insightful comment, imagine writing a C/C++ application and not bothering to free memory while you develop all the features. Instead you'll wait til everything more or less works and then implement proper memory management.
Yes, it's the same with security.
Instead of Facebook pwning you, *everyone* gets to pwn you. Isn't that what Diaspora is all about?
The key here is "ALPHA RELEASE", read that to mean complete bloody mess which we hope the testers will help us to fix, for the "BETA RELEASE".
OK, we all got that? Right, deep breaths everyone and calm down...
It's not even an alpha release! This is the pre-alpha release. "Hey you guys, a PRE-ALPHA RELEASE has flaws!" And hackers are still finding security flaws in widely distributed licensed software that has been gold for years.
...Of this kind of thinking.
I've always been amazed of the reaction to 'public beta' software ever since Apple Pubic Beta'd Mac OS X. There's all the bitching and moaning about the fact this bit and that bit don't work.
As stated above, this is why it's called a 'Beta'. It isn't finished.
As for Diaspora, it's in ALPHA fer chrissake, that's one BEFORE Beta! Of COURSE it's going to have huge amounts of fail in it. They haven't finished cooking it yet.
(Not that I'll ever use it even when it's baked to perfection. I'm a grumpy, miserable anti-social(site) git.)
They started coding in secrecy and then dumped a blob of code onto the net, the code shows their amateurishness. If they had started working in the open and used a real free software type development model then all these security issues would have been written out of the software by now. N00bs.
this is Pre-Alpha code. I'm surprised this even compiles the code is so new
Did everybody miss the pre-alpha part? I'm not surprised it has holes in it.
Isn't this sort of thing the whole point of doing an alpha developer release?
When I read up on this I thought it was a stupid idea - everyone has to run their own web server. Ridiculous. Most facebook users are the least technical users on the net. Sounds like a recipe for disaster.
are generally competent enough to run some torrent client or other. At first glance, Diaspora looks to me to be technically similar.
It'll be like OpenID. You can run your own OpenID server, or you can use Google, Yahoo, or MyOpenID to do it for you.
After corrupting what a Beta should be, the Webbies are now forgetting about Alphas...
I would expect them to be designing out the security flaws from day one, but then not everyone works that way. I have worked with developers who build up and out until they have a skeleton app and then flesh it out and fix problems as they go - not my personal preference, but it takes all sorts.
Over and above that - this is a pre alpha release right?
Yes they're naive, but they are clearly open to suggestions, as we can see from this addition to the readme:
so if you have security criticisms you can now make them constructive by mentioning them to: firstname.lastname@example.org
It is indeed brave (and perhaps stupid) of them to release the code this early, and it should probably have more health warnings on it, so the enthusiastic puppies that are keen to run it in public have at least been warned _before_ they get burned, but to some extent the point of their work is to provide a condensation nucleus around which the focus of community interest can crystallise.
As for RoR's scalability -- diaspora is decentralised, so if it scales to dealing with one person's content and contacts, that's already enough for it to be useful. I seriously doubt that the implementation will remain if s uch things get in the way. The useful outputs of this project will be the protocols and the community that forms around the project -- there are bound to be alternative implementations if the current implementation causes any problems.
<i>As for RoR's scalability -- diaspora is decentralised, so if it scales to dealing with one person's content and contacts, that's already enough for it to be useful.</i>
On top of that, Diaspora is all about the protocols. There's no reason that someone couldn't write a more scalable implementation in Java sometime later if it takes off. At this stage, Rails isn't a bad choice because of the size of the Rails dev community.
You either have a zero defect mentality, or you don't.
These dorks don't. They're concentrating on functionality first, which means they'll always be playing catch up with exploits.
Hopefully some grown-ups will step in and fix it for them, which they focus on their core competencies: begging for handouts.
Like how your email address becomes inactive after 1 month, your other online info and accounts should be the same.
If i don't use a site like Facebook or Bebo for 1 month then my info should be deleted.
It would save people from having to change their identities when they reach their teens =]
Easy solution. No need to wait for Diaspora or anything else. Just - DON'T BE ON FACEBOOK!
Makes you wonder how mankind used to cope...
I haven't seen the code yet, but I thought everyone should know that one should have the escaping, sanity checks and anti-xss code written before the first form was even created, so I'm really surprised that they apparently released such vulnerable code. Zero assumption programming is heavy, but good practice. perhaps an extreme example: don't even assume that the webserver you are talking to is your own, even on localhost. What if a hacker replaced it?
I think this is the traditional web client/server path:
form -> submit (js sanity checks) -> server sanity checks -> memcache -> db escape -> db
(db || memcache) -> template -> entity conversion -> display.
If classes always handle IO from the beginning and consistently used then in theory there should be no chance of sql injection, xss, buffer overruns, etc.
Allowing users to write html increases complexity, but that too can be locked down with bbcode or predefined tags. Anything not allowed should be entity escaped at presentation time.
If they're using their own webserver with a distributed db, then the above should still apply, except that memcache would probably be malloced memory in the app, with db messages compressed and encrypted, and also sanity checked on receipt.
Security experts themselves get owned, especially by XSS flaws. And these guys _are_ just students. And maybe they haven't had the "write all the libraries perfectly first before even one line of business logic" idiocy beaten into them yet. That may be good comp sci, but it's lousy business.
As for yourself, despite all your cleverness, you've just been XSS'ed:
Good on them for having a go and sharing where they have got to so far. At this stage (and this may be surprising to some) security probably isn't the main factor holding things back. Installing a standalone social networking server which you can invite a few relatives and friends onto doesn't necessarily open you up to attacks from world + dog. Having an invitation on a particular server instance to create accounts open to entire world + dog almost certainly does.
They'll need a process in which many more interested developers can participate, and creating that isn't easy. I participated in an invitation/recommendation only experiment with facilities similar to FB but used by about 100 people several years before FB existed. What killed this wasn't security issues which were never investigated to this extent, but the lead developer not open-sourcing the code so that other interested parties could continue it when he ran out of money.
The hardest part is going to be how very many independently-operated social networking servers (possibly implemented differently) talk to each other, so that friend of friend relationships can be used to enable easier cross authentication and communication of shared interest between different servers. If open source social networking developers don't achieve some kind of useful and secure federation protocol people won't migrate from a single global social networking platform to an archipelago of isolated social networking islands just because they don't like having a single company running the show and deciding all the policies.
+1 upvote as agree - and is that where NoSQL-style databases come in, with their apparent better handling of data distributed across machines?
As other posters say, it's pre-alpha so it's bound to have flaws: +1 upvoted all of your comments as I agree.
Feature and security priorities are debated by other posters, differing opinions here are always going to be the case. Academic discussion.
When to release? Nothing wrong in them releasing this now, or last week or next week or next month. But to maintain momentum of publicity it was probably about the right time, before it got forgotten about. As they say, it's better to be talked about than not at all.
They probably wanted to psychologically reward themselves with releasing it "hey look what we did", like many people do when creating and releasing an unfinished website.
can anyone please point me to some REAL examples of pre-alpha code?
and how bad it ALWAYS IS.. ummm its pre-alpha.. NOT alpha, which is not meant for the masses.
Gee guys and gals, give them a break eh?
Here they are, being bombarded with "where are the status updates", and "I bet they stole all the money and stayed at burning man". and now they RUSHED to get it out ASAP for people to get a sample. and now you guys/gals go and say its horrible?
go make one yourself, and see how hard it is!!! You wanted results, and something to show for it, and you got it.. what do you expect for 4 guys in a summer?
I admit, I'd love to have this a lot better than what it is, and I won't be able to release to the "masses" with my site either, until it gets more stable, but everything takes time...
God I hate to say this but "Rome wasn't built in a day"...
Alpha for the masses? How times have changed. Final is for the masses. Beta is for the restricted populace (subscribed testers). Alpha is for specifically chosen people (based on their knowledge, toolchain, and a variety of different systems). Pre-alpha? Can anybody explain why a pre-alpha is anything other than a demo in a boardroom meeting? Pre-alpha certainly shouldn't be live, that's inviting problems.
It is a good start, but it has a long way to go to rival the likes of Facebook. Time to get more coders on-board and get the ball rolling, concentrating on core functionality (inc. security) rather than usable demos.
When starting a new project, there are 2 approaches:
1. Get the base functionality done first, noting bugs and security stuff as "todo", then fix it.
2. Build a perfect infrastructure, then add the functionality.
Approach #1 is potentially dangerous (if you get the architecture wrong, you have lots of changes to make, and if you don't build in security from the start, you may not be able to add it later). But it has some major advantages:
- You have a working environment early, for testing ideas and prototyping
- You have a working demo environment (so it's easy to get backers and funding)
- You can prove to yourself that it will work in principle, which aids motivation.
- Other hackers like working code...it's much more motivating for people to potentially join a new project if there is something released that works, at least a bit.
- It gives the artists, css, documentation, and translation people something to start work on earlier, helping with critical paths.
Approach #2 only works well if you have a very small group (ideally one) who already have the design fully-formed in their heads, or if you want ultra-perfection (eg NASA) and have a matching budget.
So I applaud them choosing model #1...provided that the FIXMEs do actually get fixed before release!
Elgg is much further down the road and has a large community with a long list of very well established sites that prove it's abilities.
I see only reasons to stay with Elgg, it has flexibility and though young, is well down the development road by comparison.
Am I wrong? http://community.elgg.org/
It seems they've taken the MS developers play book of "Release early" but let's see if they start knocking off the bugs.
BTW Distributed servers, low update bandwidth, synchronization.
Sounds like Lotus Notes. (Wonder how far the Chandler project got on those unglamorous but *crucial* elements.
At least in this case the privacy violations are, in fact, bugs.
In Facebook they're called "features".
Yes John Smith 19, it does sound a lot like Lotus Notes :-)
Bill Murty, I hadn't heard of Elgg, thanks for that. After a quick glance though, it doesn't look decentralized/distributed?
GNU Social is the one I've been watching. I think these guys have a bit better idea of what they are doing, and I don't think they took anyone's $200k to do it either. Come on the whole world, join in!
Question for the scaling-savvy commentards out there:
How, in your opinions, does Django compare with Rails in terms of robustness and scalability?
It's not just the little guys - Adobe has "urged caution" about a new beta - these guys are in PRE-ALPHA.
read my title. read it again.
It is a shame some people don't understand it and either use the developer release and get burnt or give up on it (yes you are as bad as they are), but this release was never about good code. it was never about code. it was never about creating a social network. It was about creating community of developers willing to work together and a community of users to get the ball rolling. The only way they could do that was by fulfilling the promises they made before, those promises were aimed at a few people, a few are forgiving, but they were heard by everyone, and everyone are not. Suddenly they *had* to release something or fail. They can throw away all their code and start again and it would still have been worth it.
As for security from the start (this bits just in general, not specific to this case): that is just crap that gets burned into our minds at uni cos it's the only way to make incompetent devs take security seriously. A well designed program can have security inserted afterwards in a few lines of code. Lets hope they designed it well. good security != good design, one can lead to the other (a well designed program can be made secure painlessly), but not the other way around (secure garbage is still garbage).
A pre-alpha release is expected to be bug-ridden. It's purpose is to demonstrate a concept an attract developers and funding. IT'S NOT FOR END USERS.
An alpha release is still expected to be bug-ridden, but mainly functional. It's purpose is to begin the testing cycle for correction of major bugs and addition of new minor features. IT'S NOT FOR END USERS.
A beta release is expected to be fully functional, but still needing minor bug correction. IT'S NOT FOR END USERS.
And then comes the release candidate! This is a complete product, completely debug to the max of the abilities of the developers. It will soon be released except some major hidden bug is found. IT'S NOT FOR END USERS.
And only after all this we have a release version. This is the only one destined for end users.
It's ridiculous to criticize a pre-alpha release because it's bug ridden and security flawed. This is what you would expect about it.
Yes, it's ridiculous to criticise a pre-alpha for having bugs in it.
Unfortunately, it's worse than that. (Probably.)
Diaspora was supposed to be a distributed, Darknet version of Facebook. There is nothing in the code that even starts to deal with those concepts. It certainly does not demonstrate them.
Now, it's too early to say whether the team have it all mapped out as to how it will develop in the future. In which case, sure, there's nothing to worry about.
But if they have, they've not told the internet about it.
Biting the hand that feeds IT © 1998–2017